Topic: How is same signed transaction not reusable, also quantum security of ECDSA? (Read 6574 times)

If you have 2 inputs: 1 BTC on input A and 1 BTC on input B and you send 1.5 BTC total to a third party, the extra 0.5 BTC doesn't remain on your original inputs, which are considered spent, it becomes a new input to an address you own. This new input is known as change.

So inputs A & B are no longer yours, the blockchain considers them spent and they can never be reused. The only way for you to access the remaining balance is by creating a new transaction from the change input.

I didn't understand this until I finally read Satoshi's paper. It's pretty easy to understand the important points even if some parts are lost on you as long as you understand the basics of cryptographic signatures

A balances design such as the mini-blockchain of Cryptonite, is able to prune transaction history after some period of aging, thus indeed the transaction signature size does matter relative to a non-prunable Bitcoin, not just the public address which can be the hash of the public keys as you explained.

Also the transaction signature size impacts the maximum transaction rate per second for a given bandwidth of full clients.

So who was "@#$@#$ nonsense, hysterical jibberish".

Edit: Note pruning Bitcoin's txids won't require that transactions include a block chain length expiration field, because address reuse can't create a duplicate txid. The txid in Bitcoin is not a nonce rather the hash of the transaction which contains the output being spent, i.e. there is no way to reload an address with a duplicate txid, because all transactions are iterative hashes of hashes of hashes (etc) of the historical tree of preceding transactions history feeding the input.

Hilarious. You admit everything I was saying. Did you forget what you wrote, or are you just in vendetta mode against me?


There is something I need to research in there. You wrote that signatures don't end up in the UTXO set. So perhaps signatures are not in the blockchain...which would be news to me.

Edit: So UTXO is the "set of spendable coins" thus I think gmaxwell is pointing out above that the increased signature sizes won't impact the memory requirements of verifying transactions. Yet I am still thinking the increased signature sizes will bloat the downloadable blockchain (and thus also memory or hard disk seek speed requirements for producing the UTXO), for those that can't be pruned. Incorrect?  (with pruning, this might or might not be too onerous, I haven't done the calculations at Visa scale)

Cripes even you admit the higher probability of the vulnerability of the math:

No you do not! Are you sure you are qualified as a cryptographer?


I did not laud Ed25519. Performance "considerations" is a human value judgement, assuming the performance domain has not been provably explored to its limits, thus the lower degrees-of-freedom claim is vacuous. (I wonder how many readers have the IQ to comprehend that? I hope many) Additionally the orthogonal point that focusing on performance is not same as focusing on security considerations. I don't know all the details, but Bernstein did apparently at least include some security considerations (some mention about primes, etc) too, nevertheless that is orthogonal to my first point. Also the third orthogonal point that I see merit in Schneier's logic on not using ECC unless it is necessary (some of his reasons I repeated in my prior post in this thread, yet you should read his words).


As Schneier says we play the best odds. And as cryptographers we shouldn't take risks that can be avoided.

ECC has a few reasons to be suspected (read Schneier's words), and specific curves even more suspect and I included suspicion on the k variant used by Bitcoin with the justifications upthread.

And it is not just the mathematical attack, it is that there are 4 or more possible attacks combined:

1. Mathematical attack given shorter keys
2. Quantum Computer with Shor's algorithm
3. NSA possibility planted weak curves in standards
4. NSA possibility attempting to weaken many RNGs (this affects all crypto, but adds to the 3 above giving them more weight)


It is my understanding that the entire history of unpruned signatures are stored in the block chain.

My current understanding is that a balances design would not require such an extensive history of signatures.


I will grant you are good at insults and judging others.

Perhaps if you slow down and give others a chance to present their responses to your thoughts, we could get to a conclusion and then know what is what.

It may be that I am entirely wrong, but I don't see you've made all the winning points yet.

And even if you are entirely correct, the entire point of discussion is to help clarify everything. So how is that a waste of time? You ask for donations for helping, yet then hurl insults. I was actually earlier thinking about sending you 0.1 BTC as a token of my appreciation and was even not offended by your initial diatribe about balances that didn't come from anything I wrote in my OP.

I figured you were helping me any way, even if you seem so cocky to assume that others are idiots and must be thinking stupid.

But now you've gone completely overboard with your personality and comprehension defects.


Refutation (entertaining potential issues and then proving they are not an issue) is one of the most important jobs of a cryptographer and security analyst isn't it?

You should applaud probing.

Rather I detect that you are angry that you would offer any assistance to anyone who might upset the Bitcoin applecart or create an alternative coin. Sorry if I refuted resoundingly what you probably thought were slamdunks to shut me up. My IQ tends to find the maximum breadth tree of possibilities, so you better make sure there is no stone unturned before you cockeyed (as in cocky) assume you've won an argument with me.

It is necessary that in the process of everything assistance will flow around. That is how open source and academic research works.

If Bitcoin is rock solid, it will all flow back mostly to Bitcoin any way. I want the best coin, and if it ends up Bitcoin, then great.

So far, I think my logic is sound, yet I am open to any convincing logic you can present. But it is clearly becoming very difficult to have any discussion with you that doesn't conform to your biased vested interests.

I am trying to look at this objectively. We shouldn't take risks if there are not tradeoffs to not taking them. Note I did specifically write "need more study" above, so I am not yet asserting there are no counter-balancing tradeoffs.


You conflate orthogonal concerns.

While we may have feature A now, we may still have feature A and get rid of a doubt that we don't need, while gaining other features too. Maybe without tradeoffs, but I am not asserting that "until more study".

You are really frightened of any talk about an alternative coin design.


Then the Bitcoin blockchain bloat will grow worse due to longer signatures and that may be a factor that is driving centralization of pools. And other considerations...




So deploy them now to eliminate the doubt if you conflate the tradeoffs because you assert by implication there are none.

And don't wait until after the attack has started, because then weeks will be weeks too late.

Jesus indeed, especially the humorous part about my ignorance. Got a mirror handy?

I had enough of your insults.

You need to work on your reading comprehension. Let me re-quote what I wrote about Ed25519, "Even shifting to Berstein's  curve25519 (as Tor and others are).......doesn't alleviate the (perhaps slim)".

Now I will compose a response to the points you've made.

Using merklized key, a Lamport public key could be reused (for limited times) https://en.wikipedia.org/wiki/Lamport_signature#Public_key_for_multiple_messages

Using CHECKSIG 2.0 I proposed at https://bitcointalksearch.org/topic/checksig-20-258931 , we can use one signature for many inputs from the same "address"

Hey you keep trying to put words in my mouth that I have not written.

Please learn to read more carefully. Go back and re-read my post please. I never insisted nor asserted that in the last reply that you are replying to.

I will kindly ask you to stop trolling, even though you are the moderator. You first asserted that I was talking about balances and went into long diatribes, when in fact my logic was correct and I never mentioned balances nor alluded to them.

You are hearing voices apparently.

Actually, we have a stronger assurance than for SHA-1. The parameters in secp256k1 (which is not a NIST selected curve, contrary to your repeated instance) are fixed entirely by performance considerations, similar to the Ed25519 work which you lauded up-thread. There (far) are fewer degrees of freedom in secp256k1 than in SHA1.

This isn't to say that it might not turn out that there are snazzy new mathematical weaknesses possible, but there appears to be no room to have forced the selection of them. ... and snazzy new mathematical weaknesses are possible for anything. As soon as you've gone down the paranoid path of ANYTHING IS POSSIBLE OMG.  ... Well, anything is possible, and anything else might be insecure for unknown reasons too.

Yes, the signatures are larger. But you were saying

Which is just @#$@#$ nonsense, and I was responding pointing out that public keys would be no larger, and so your invocation of balances is just hysterical jibberish.

You've continually repeated misinformation in this thread (and in other threads, now that I connect your name). I realize that it's due to your ignorance and not due to malice, but it means that interacting with you is a waste of time.  ... and I'm worried that I'm rewarding your poor understanding and poor research by continuing to respond to ridiculous claims.

Do your own work for a bit, instead of making me feel like you're just converting every doubt you have into a FUDdy misstatement of fact in order to make other people do the work in refuting you.

Because that is an emulation of exactly what we have now!  It's fine but it's effectively what we have now. Jesus.

None of these things follow from that premise. You might as well have listed "Peace on earth and goodwill towards men".  We can already deploy merkel signatures, with no incompatibility at all—(many) existing clients can already send coins to them, and would deploy them in weeks if there were ever an indication of our current checksig becoming weak. "Balances" are entirely orthogonal.

Why is that example better than forcing all coins to spent entirely and change to be sent to another coin? If Alice wants to pay two in the same block, she can use a fan-out of 3 (1 is for the change).

Then Bob doesn't get paid twice and Carol doesn't get cheated out of her payment.

And then we don't have race conditions nor need such a complex logic for a balances system.

I don't know what you are thinking about auctions, while I am thinking orthogonal block chains (merged mined) can be built for esoteric features.

As for what we might gain with a balances system (more study needed though):

1. Decentralization since peers don't need so much resources (RAM, CPU, and network bandwidth).

2. Block chain scaling to Visa scale.

3. Replace ECDSA with lamport or Merkel with huge key lengths (e.g. 4096 bit). Public key hashes might remain 256-bit.

4. Radically improved anonymity per my posts you moved out of your CoinJoin thread.

You first raised the issue of balances in this thread. In the OP, I admitted my understanding was incomplete (of the details), yet no where in the OP did my logic assert balances in Bitcoin. I asserted that whatever Bitcoin is doing it had to be a Nonce in the transaction signature. I was correct in my logic. My mind often works in generative essence mode, meaning I distill away details down to the essence so I can factor the domain efficiently (especially initially in a field where my detailed domain knowledge is weak).


I did realize they could reuse the key again later, e.g. sending from key that received the change back to the key they previously spent from. And a system that employed balances and discarded transaction records after some interval, would not be able to prevent this.

I didn't think it is entirely pointless since a Lamport signature is so brittle. However...


Here is where my detailed domain knowledge is weak. I don't understand this. I am thinking a coin is spent only once entirely and its change it sent to another key.


In what way does forcing all of a coin to be spent and change sent to another key constrain users?

I will leave the performance claim on the back-burner, since it may be irrelevant or not, and would require much more study.


Payments? You mean a fan-out of more than 2? Why does that conflict with my assumption above?


Mea culpa, I missed the one letter difference ("k" instead of the "r"):

https://bitcointalksearch.org/topic/why-did-bitcoin-choose-secp256k1-over-secp256r1-151120

Note the above link and the following have no proof that it is not a honeypot:

https://bitcointalksearch.org/topic/m.37328

The doubt raised for P-256 is that NIST is working hard to pollute standards, the seeds were not chosen in a way that involved no human judgement, and the same problem exists for the "k" standard. And it has been chosen by someone anonymous (Satoshi) with no justification and we also have some reason to suspect Satoshi wasn't some unfunded cryptographer acting alone.

I am not spreading FUD, rather the FACT that we don't have the usual safeguards as was the case for SHA-1 which had seeds sqrt(1), sqrt(2), etc.

Blind faith is for religion.


I was responding specifically to your comment about lamport signature reuse. A single duplicated spend for a lamport key reduces the effective key-size by half on average (and you can reduce this somewhat with modest computation by choosing a pair of messages which have a minimum hamming distance), which is not great, but you're generally only concerned with the exposure between the time you spend and the time your transaction is buried in the chain.

Though you're likely exaggerating the risk in the ECDSA case, "if there exists" is not sufficient. Even ignoring the (probably enormous) overhead of the required error correction, solving a 256 bit discrete log problem on a QC requires a QC with thousands of bits of state to perform billions of operations.