I just want to point this out, to make sure that no one overlooked it.

Lots of problems get really, really easy once you give up security.  Trusted systems have wildly different properties than trustless systems.  If you don't mind moving from a trustless to a trusted system, then what you are proposing can work*.

P.S.  Nothing in this thread is new.  Even the posts telling you it won't work are recycled.

* For some values of work.  If bitcoin had been designed as a trusted system (even a distributed-trust system like you are proposing), I'm not sure that they would have worked in the sense of being worth trading 6 cents for, much less $600+.

Ugh.  What exactly do you think bitcoin is doing?

Your coins are "locked" to your account until you unlock them by spending.

Discarded by whom?  "Considered invalid" by whom?  Which ancient block?

Bitcoin is an imperfect solution to a very hard problem.  You can't just handwave it all away like Dilbert's boss.

http://dilbert.com/strips/comic/1994-10-17/

They don't.

No one will accept your transaction until it is final (nLocktime in the past and/or nSequence at maximum).

Look for IsStandard functions.  Modify them to return without checking.


No there is not.

Your best bet is to organized a group of people interested in running a non-standard relay subnetwork.

No, "fixing" this problem would kill bitcoin.

If someone can create new coins out of thin air, then bitcoin's supply is no longer limited.  If someone can move coins without proving the private key, then your coins are no longer yours.

Bitcoin's value comes from the usefulness of these properties.  Without them, there is no point.

The good news is that no one can force anyone else to accept changes they dislike.

Most nodes enforce rules that aren't in the protocol.  The example getting the most press right now is padded signatures.  The R and S values in a signature should not be padded with null bytes when they are short.  If they are padded, they are considered nonstandard, and most nodes will not relay them.  But, they are perfectly valid in the protocol, and if they make it into a block, no node will reject that block.

The much more common one involves script patterns.  The protocol allows huge discretion on what you can set as your output script, but the network will only accept a few templates as standard.  If I recall correctly, there was an incident a while back where gox was sending malformed payments that could not be redeemed.  Unfortunately, they made their way to a miner that did not enforce standardness, so they were committed to the blockchain and lost forever.

When you send, you are sending to a hash.  You have no idea what it is the hash of.  It could be a compressed pubkey, it could be an uncompressed pubkey.  You don't know and don't care.

The transactions that you are redeeming will be either compressed or uncompressed depending on the keys and addresses you received them with, which depends on where your addresses came from.

Basically, it comes down to whether or not the person writing the key generator understands compressed keys or not.  There is only one reason why uncompressed keys should ever be made new, and that reason is that the author didn't know how to compress them.  Also, that isn't a very good reason.

Also, stop that.

Search is not quite so useless here that it wouldn't have answered your question.

The decision is made when the address is created, or on a more meta level when the software that generates the keys is written.

It sounds like the strip utility you are running doesn't understand windows binaries.  Maybe find one that does?

A good understanding of bitcoin in general seems to be both a necessary and a sufficient condition for redeeming properly designed paper wallets.

You must understand that bitcoin spends old transactions into new transactions.
You must understand that transactions are redeemed in entirety.

A firm grasp on those two concepts will be sufficient for most people.  Things get a bit more complicated if your paper wallet uses P2SH multisig (which it totally should).

If you search this board for that URL, you'll find at least one thread, maybe more.  The short version is that djb has a huge ego.  The long version is that the things he dislikes about secp256k1 don't matter, or at the very least, don't matter to us.

Are you sure you stripped the binary?

Oh, right.  I forgot about another confounding factor.

Apparently gox's software didn't properly age coins before spending them.  Not normally a problem, but when the hot wallet is low, things can get interesting.

He mentions that SR2 was a scam using this as cover.  It is quite possible that gox is the same.

This is my understanding, the best that I've been able to put together.

Gox's custom software doesn't always strip leading zero bytes from signature values.  Sipa estimated (on IRC) that only ~1% of gox transactions had excessive padding.

A while back, this was no big deal because the network would happily relay both forms, so any attempt at changing the transaction would result in a race.  Later, the default node behavior changed to not relay the padded version.  Once this changed, the original would pretty much always lose the race, if there was one.

Next, someone made a bot to "fix" transactions on the fly.  Quite possibly this person was sick of waiting for their money and/or was just being helpful.

So, we have 3 eras.

First, all transactions confirm normally.
Second, 1% of transactions never confirm.
Third, 1% of transactions confirm in modified form.

Only the third era is vulnerable, but it is a relatively short era.  I don't think anyone knows exactly how long it has been going on, but it can't have been years because the second era isn't that old either.

Now, to exploit this, you'd need to get lucky, or you'd need to keep up a massive circular flow out of and then back into gox.  Remember that each transaction has about a 1% chance.  So, 99% of the time that you withdraw your balance, it works fine.  And you have to wait 6 or 7 confirmations (minimum) before you can try again.  You'd get about 85 chances per year, so if we assume the third era was about a year long, figure the average attacker could have doubled their money about once in that time.

It just doesn't add up.  Someone is lying, or there are very important things that we don't know yet.

This assumes that they were replacing transactions, not balances.  This assumption may not be valid.

More directly, you can see that hex is base 16, so 16¹⁰ = 1,099,511,627,776

In that case, just generate the address yourself and present it to the user.  Then use -walletnotify to monitor payments to that address.  Unlock when the payment has enough confirmations.

If you want the transaction to purchase perpetual access rather than instant, just ask for a signing address before presenting the payment address, and tie them together in a database, then use the signmessage/verifymessage scheme above.