fore (seems to be the case on
every great idea I have for Bitcoin) and was not practical; but I'm glad to
have had your response which was certainly educational for me.
Andy
--
Dr Andy Parkins
andypark...@gmail.com
--
hich 32 MB until they do the 1,000,000 hash+lookup operations on their
> X GB blockchain).
Excellent.
Andy
--
Dr Andy Parkins
andypark...@gmail.com
--
Open source business process management suite built on Java
blocks come at 10 minutes, regardless of hash rate. So we
can make it harder by picking a harder algorithm -- SCRYPT or BLOWFISH, or
just by upping the size of the data that needs hashing. The advantage of
upping the size of the input is that, unlike an algorithm change, you can't
bui
re now IO-bound, not CPU-bound, and
any hashing engine will, effectively, be the same.
I'm making the assumption that SHA-256 is not cacheable from the middle
outwards, so the whole block-chain _has_ to be transferred for every hash.
Apologies in advance if this is
till don't get the potential 5% scam being used at 100% capacity.
Andy
--
Dr Andy Parkins
andypark...@gmail.com
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with e
kind" is just as liquid as the BTC, then fair enough,
there is a risk, but that just incentivises the merchant in those cases to
not allow withdrawal/deposit until 6 confirmations have been received.
Those merchants then move from "at risk" to "not at risk"
n magstripe credit cards.
"[If] there was a large enough population" -- why are bitcoin users more
dishonest than credit card users? Most people are honest, so it seems
unlikely that that 5% attack surface would be used at 100%; or even 40%
necessary to equal the 2% chargeback r
fraudulant too, just as in the CC case?
The comparison would then be 2% chargebacks for credit cards, equivalent to
0.1% (5%*2%) for bitcoin.
Not that I think that makes anything else you say invalid.
Andy
--
Dr Andy Parkins
andypark...@gmail.com
-
e wanted to make a
> change, as well as all commits merged into one diff for a "what actually
> changed here?" review.
I think that code review is fundamentally hard. There is only so much you can
do to make it easier; and I'm not sure encouraging contributors to squash
th
viewing. There are lots of things that make it easier.
Since the large commit is always available, no facilities have been lost.
Personally I work hard in my repositories to make coherent, small, well
described commits. If I had gone to that e
git-merge-base finds the common ancestor between master and feature-branch,
and then compares feature-branch against that.
Andy
--
Dr Andy Parkins
andypark...@gmail.com
--
October Webinars: Code for Performance
Free In
On Tuesday 23 July 2013 11:17:28 Peter Todd wrote:
> On Tue, Jul 23, 2013 at 11:00:24AM +0100, Andy Parkins wrote:
> > > Increasing the resource usage by SPV clients on full nodes is
> > > undesirable;
> >
> > I don't think that's thinking big enough.
there
are two branches growing, and you have to be able, when verifying a new
transaction, to say which branch it's one... which branch of the blockchain.
Andy
--
Dr Andy Parkins
andypark...@gmail.com
--
See
On Tuesday 23 July 2013 10:47:03 Peter Todd wrote:
> On Tue, Jul 23, 2013 at 10:30:13AM +0100, Andy Parkins wrote:
> > One additional URL makes this pretty much perfect:
> > GET /rest/block-with-tx/TX-HASH
> >
> > Construction of the transaction-hash-to-block databas
On Tuesday 23 July 2013 10:42:05 Pieter Wuille wrote:
> On Tue, Jul 23, 2013 at 10:30:13AM +0100, Andy Parkins wrote:
> > One additional URL makes this pretty much perfect:
> > GET /rest/block-with-tx/TX-HASH
> >
> > Construction of the transaction-hash-to-bloc
but suddenly makes it possible for an SPV client to trace the
providence of any transaction without needing to maintain the entire chain.
Andy
--
Dr Andy Parkins
andypark...@gmail.com
--
See everything from the browser to
forward. The client is simple. The server is two
threads, one listening on the socket and then briefly locking and updating a
queue, and one thread briefly locking and removing from the queue.
Andy
--
Dr Andy Parkins
andypark...@gmail.com
-
982
Fair enough.
I'm usually behind the state-of-the-art when I suggest things here :-) I
should just trust you guys have already planned everything I might think of.
Andy
--
Dr Andy Parkins
andypark...@gmail.com
---
ol is only a small part of
what bitcoind does. Adding another thread listening for HTTP requests at the
same time as on 8333 for stadnard format.
Anyway -- I've obviously misunderstood what the idea behind a HTTP protocol
wa
. The hardest
operation for light clients is finding out the block that contains a
particular transaction -- something that bitcoind already knows.
I'd like to see support for HTTP POST/PUT of signed transactions and block
announcements too.
Andy
--
Dr
Not quite secure yet, because you didn't sign your email.
Andy
--
Dr Andy Parkins
andypark...@gmail.com
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The pla
ne of those chains,
zero.
It doesn't seem impossible that clients could be made far more permissive
about acknowledging the existence of blockchains that they wouldn't
necessarily accept themselves (if the proof of work was valid) and warning
the users that it's going o
d anything for them and bitcoin would work exactly the same.
Lost coins never enter the economy ever again, and so supply is slightly lower
than it would have been, making all the non-lost coins worth ever so slightly
more. Effectively: price adjustments will take care of lost coins.
And
med via normal bitcoin mechanisms isn't it -- multi-factor or
not? This invoice system has one primary job: to ensure that the target of
the payment is who the payer thinks it is -- that's not affected by multi-
factor methods of protecting my wallet.
Andy
--
Dr Andy Parkins
andypark..
X-9977.bitinv to a signed GnuPG email. The receipient can
easily confirm I sent it because the filename must match the contents and
GnuPG protects against tampering.
Andy
--
Dr Andy Parkins
andypark...@gmail.com
--
Mon
y? AF_INET, AF_INET6, AF_CUSTOM_TOR, and leave space for a few more
would be, say, four bits out of 64 mostly unused.
Andy
--
Dr Andy Parkins
andypark...@gmail.com
signature.asc
Description: This is a digitally signed m
rotocol noise.
"I support getdata10" makes it far easier to discover that the peer supports
getdata10 than sending getdata11 and watching it fail does.
Andy
--
Dr Andy Parkins
andypark...@gmail.com
--
Liv
n message. So why not make
the change be simply: one of the service bits indicates that "getcmds" is
available?
Then the version message doesn't need any on-the-wire change.
Andy
--
Dr Andy Parki
the ecosystem
of thin/spv/semi-thin/headers-only/blocks-on-demand/reverse-search-
blockchain/memory-pool-query clients becomes more varied, it's going to be
more an more important. The particular example that occurs is thin clients
connecting to the network are going to want to ensure they are
-confirmation
transaction by creating my transaction with that 1-confirm as its "base". (2)
your expiry from memory pool becomes easy -- if the "base" is more than N
blocks below the current head, then that transaction won't be included.
Retransmission is possible with t
On 2012 January 31 Tuesday, Andy Parkins wrote:
> - Increase the version number in transactions to make a new transaction
>structure
> - Dump the "scriptPubKey" field completely. Everything will be pay-to-
>script-hash in version2 transactions
> - Replace it w
a big difference. Thanks for the correction.
Andy
--
Dr Andy Parkins
andypark...@gmail.com
signature.asc
Description: This is a digitally signed message part.
--
Keep Your Developer Skills Current with LearnDevNow!
The m
x27;m happy to be called wrong)
It doesn't seem like it to me. The new transaction types will be rejected by
old clients won't they? They don't pass IsStandard().
Andy
--
Dr Andy Parkins
andypark...@gmail.com
signature.asc
Description: This is a
well; but perhaps I'm
just not familiar enough with the conventions. As far as I understand; no
pre-BIP16 miner is going to allow BIP16 into the blockchain because it's not
going to pass the IsStandard() test.
I'd repeat: the reasonable thing to do is to increase the version
nly a
matter of switching from the hash check to running the two scripts as
normal).
Andy
--
Dr Andy Parkins
andypark...@gmail.com
signature.asc
Description: This is a digitally signed message part.
--
Keep Your
_PUSH { }
OP_CHECKSIG
OP_PUSHPARMETER {1}
OP_PUSH { }
OP_CHECKSIG
OP_ADD
OP_ADD
OP_PUSH {1}
OP_GREATERTHAN
(I'm sure someone cleverer than I can improve on the above)
-
Let the flaming commence...
Andy
--
Dr Andy Parkins
andypark...@gmail.com
signature.asc
De
ff
i.e. there are a few unused bits (~5) available in the base58 representation
that can be added without changing the number of symbols in the address.
Andy
--
Dr Andy Parkins
andypark...@gmail.com
signature.asc
Description: T
On 2011 December 22 Thursday, Joel Joonatan Kaartinen wrote:
> On Thu, 2011-12-22 at 11:52 +0000, Andy Parkins wrote:
> > Why should they have to? Joining the network as a node is very low cost
> > to the other nodes. You can't force any node not to be lazy, since
&g
portant though to distinguish between "you must be verifying"
and "if you do verify, you must be honest about it". No node should be forced
to do any work it doesn't want to; but they should be forced to be truthful
about the work they choose to do.
Andy
--
Dr Andy P
his idea before, but that time I was using it as a
double-spend prevention method).
Andy
--
Dr Andy Parkins
andypark...@gmail.com
signature.asc
Description: This is a digitally signed message part.
--
Write once. Por
means they
don't.
This heirarchical method lets every client supply all the information they
have -- nobody has to make a decision to leave something out. The internal
debate they would have "is my gui version more important than my protocol
engine version?" is unnecessary.
Andy
--
onstrably good
practices for verifying identity; rather than the ridiculous amount of trust
that comes pre-installed for me in my browser.
Andy
--
Dr Andy Parkins
andypark...@gmail.com
signature.asc
Description: This is a
and full
client conceptually.
Andy
--
Dr Andy Parkins
andypark...@gmail.com
--
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will
provide at least the possibility of a
human-readable name for a bitcoin-address?
Isn't there a possibility that one day we might want to be able to say "send
me those bitcoins you owe me to bitcoin.yahoo.co.uk/andyparkins"? Or
similar?
Andy
--
Dr
any of an infinite number of other
variations that _I_ as the mapper get to choose rather than whoever wrote
the BIP; all of which are arguably no less "elegant" than that simple email.
There is no equivalent in the other direction though. For someone who
want
re we started, and HTTPS is acceptable.
Andy
--
Dr Andy Parkins
andypark...@gmail.com
signature.asc
Description: This is a digitally signed message part.
--
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is h
> wow, really. Maybe you could review some RFCs, there are thousands of
> examples where some really smart engineers chose the exact opposite
> path which you propose below.
Could you point me at an example?
Andy
--
Dr Andy Parkins
andypark...@gmail.com
signature.asc
Description: T
iasing
system. But there is very little anonymity in a supplier-client relationship
anyway (you have to say what goods you want, and where you want them, and you
had to interact with a website when you were ordering already).
Andy
--
Dr Andy Parki
//"; can be optional when
they're typing. If, in the future, bitcoin gets a distributed peer-to-peer
alias system, then a new URL type can be added easily "bcalias://andyparkins"
might automatically fin
hat they don't, tut tu) move the majority of the funds to
five USB sticks, and keep them in five fire-proof safes or deposit boxes or
whatever only because deposited funds are pooled.
> This is just my view. Thanks and keep the thought-provoking stuff coming!
Thanks for the encourageme
sn't present); and would only need storing for the pending transactions, so
no incompatible change is needed to the block format.
Andy
--
Dr Andy Parkins
andypark...@gmail.com
--
Cloud Services Checklist: Pricing and
ink I have a response to that one.
I saw the "I got lucky" result as a benefit, as it made it harder to fork the
chain. We got an advantage from the luck.
I'll have to abandon this suggestion. It's not going to work.
Thanks for the feedback everyone.
Andy
--
Dr A
h is pretty bad, as a long-connected client will
drift). They don't have to, but if miners aren't using time that approximates
what their peers are using, under my system, their blocks would be rejected:
so an incentive to use that "c
given
difficulty isn't required, but a higher difficulty beats a lower difficulty.
So whatever the hashing power of the network at that moment, it's used. That
makes the chain more secure, not less.
Andy
ught about, and could be game-overs; but I do like the idea of
there being no target difficulty, and instead the blocks are issued at a fixed
ten minute rate (or rather the rewards are).
Andy
--
Dr Andy Parkins
andypark...@gmail.com
signature.asc
Description: This is a digitally signed mess
only generatable for the time when the
rest of the network is willing to add them to the chain.
Andy
--
Dr Andy Parkins
andypark...@gmail.com
signature.asc
Description: This is a digitally signed message part.
--
All
On 2011 November 23 Wednesday, Jorge Timón wrote:
> 2011/11/23, Andy Parkins :
> > Let's abandon the idea of a target difficulty. Instead, every node just
> >
> > generates the most difficulty block it can. Simultaneously, every node
> > is listening for &qu
f
the period, and will check it's valid. If it's not then the next highest on
the list will be requested. So again,
I recognise that this is a pretty large change to make; and so don't really
expect it to happen. Perhaps one day though... when all the wishlist items go
58 matches
Mail list logo
