Is he saying that implementing BIP 62 opens up a new known attack vector?
That is I wanna say 
Topic: New transaction malleability attack wave? Another stresstest? - page 11. (Read 41234 times)
The really juicy bit about this thing is that the core developers don't want to fix it because it might prevent future vaporware uses of the bitcoin protocol to be established.
https://np.reddit.com/r/Bitcoin/comments/3nfb2y/eli5_for_double_spends_bitcoin_being_sent_twice/cvnl2wo
https://np.reddit.com/r/Bitcoin/comments/3nfb2y/eli5_for_double_spends_bitcoin_being_sent_twice/cvnl2wo
Any idea what this is referring to?
Quote
schemes that make malleability irrelevant are subject to dangerous signature replay attacks if not handled very carefully
Is he saying that implementing BIP 62 opens up a new known attack vector?
Furthermore, when we were initially planning to begin roll-out, Peter Todd (IIRC) brought forward some very real issues with the BIP that would have potentially been problematic, so there was a general feeling that BIP 62 had not been sufficiently reviewed/considered, and was therefore too risky.
What about removing malleability altogether?
Just a thought. I know you guy's won't do that because of dumb ideological reasons.
In case that is claimed to be not clear: Enumerate every necessary use case in the transactions and remove the ability to encode anything else into transaction data.
I wonder if any of us can double bitcoin due to this attack 
I'm curious, why is `SCRIPT_VERIFY_LOW_S` not a standard verification flag?
You're conflating standards with the IsStandard filter.The former is defined by common use, while the latter is miner/relay policy entirely up to the individual user to decide.
You can decide to filter with SCRIPT_VERFIY_LOW_S if you like, but maybe 5% of legit transactions will probably be filtered if you do so.
If everyone did, then those 5% would never confirm until someone malleated them.
I'm curious, why is `SCRIPT_VERIFY_LOW_S` not a standard verification flag?
Quote
OK. This is not "someone". It is me.
Right now the stress-test is paused. I reserve a right to resume it.
Ask me anything.
Apparently you used the low/high s attack (http://blog.coinkite.com/post/130318407326/ongoing-bitcoin-malleability-attack-low-s-high).Right now the stress-test is paused. I reserve a right to resume it.
Ask me anything.
How is it possible that so many transactions were affected if v2 transaction are protected against this kind of attack?
Quote
The advantage for programs using v2 transactions is that they can generally be constructed to be non-malleable by third parties, so v2 transactions can more safely be used for applications like the initial bond part of establishing a micropayment channel.
http://bitcoin.stackexchange.com/questions/35904/how-much-of-bip-62-dealing-with-malleability-has-been-implementedhttps://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki
Quote
NOTICE: This document is a work in progress and is not complete, implemented, or otherwise suitable for deployment.
Why? Apparently rules 1-6 have been implemented, 7 only affects special outputs and 8,9 shouldn't be a problem (for third party malleability)But the main reason it isn't suitable right now is the "Block validity" section, which uses block version >=3 to trigger it.
We already are on block version 3 for BIP 66, so this needs to be updated for another version.
Furthermore, when we were initially planning to begin roll-out, Peter Todd (IIRC) brought forward some very real issues with the BIP that would have potentially been problematic, so there was a general feeling that BIP 62 had not been sufficiently reviewed/considered, and was therefore too risky.
The only sure-fire way to prevent becoming a victim is to wait for confirmations.
Wrong. There are no "100%-safe" ways at all.First way is "risky & cheap". Second way is "no-so-risky as first, but not-so-cheap"
Bitcoin itself is risky. If you do not want to be a victim - pay to third party banks and use your national currency.
You are my personal hero of the day.
The really juicy bit about this thing is that the core developers don't want to fix it because it might prevent future vaporware uses of the bitcoin protocol to be established.
https://np.reddit.com/r/Bitcoin/comments/3nfb2y/eli5_for_double_spends_bitcoin_being_sent_twice/cvnl2wo
Also, see my sig.
Quote
OK. This is not "someone". It is me.
Right now the stress-test is paused. I reserve a right to resume it.
Ask me anything.
Apparently you used the low/high s attack (http://blog.coinkite.com/post/130318407326/ongoing-bitcoin-malleability-attack-low-s-high).Right now the stress-test is paused. I reserve a right to resume it.
Ask me anything.
How is it possible that so many transactions were affected if v2 transaction are protected against this kind of attack?
Quote
The advantage for programs using v2 transactions is that they can generally be constructed to be non-malleable by third parties, so v2 transactions can more safely be used for applications like the initial bond part of establishing a micropayment channel.
http://bitcoin.stackexchange.com/questions/35904/how-much-of-bip-62-dealing-with-malleability-has-been-implementedhttps://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki
Quote
NOTICE: This document is a work in progress and is not complete, implemented, or otherwise suitable for deployment.
Why? Apparently rules 1-6 have been implemented, 7 only affects special outputs and 8,9 shouldn't be a problem (for third party malleability)EDIT: Ok, all txs are version 1. Version 2 hasn't implemented yet.
I had to restore wallet from seed on another device then create new trezor wallet to send the funds there. Annoying...
Any suggestions?Well, my only suggestion now is to use a different wallet because the trezor is not currently able to rescan its transaction and ignore the 0 confirmation duplicated tx.
Regarding your sentiment to "pay to third party banks and use your national currency", no thank you I will choose to be a victim!
If myTrezor.com is currently not able to handle the duplicate transactions gracefully what wallet are you using with your Trezor and how well is it working?
In which part of the world, it is Sunday now ?
It's a rather rainy Sunday in the UK right now.
Regarding your sentiment to "pay to third party banks and use your national currency", no thank you I will choose to be a victim!
Quoted. 
Let us talk about it later.Is your argument that since you pay a bank to use their service, it's more secure?
How is putting your trust in a single entity more secure?
So does this necessarily mean that any outputs in that transaction won't be received by the address it was sent to? If so, the balance won't be affected if the transaction was invalidated, right?
The entire tx chain (from the tx I linked to) has been invalidated. This means that the sender needs to create new txs otherwise you'll never get paid.
Thanks for the clarification. Already requested a separate payout with the reason you have just stated in here.
Regarding your sentiment to "pay to third party banks and use your national currency", no thank you I will choose to be a victim!
Quoted. Let us talk about it later. So does this necessarily mean that any outputs in that transaction won't be received by the address it was sent to? If so, the balance won't be affected if the transaction was invalidated, right?
The entire tx chain (from the tx I linked to) has been invalidated. This means that the sender needs to create new txs otherwise you'll never get paid.
I had to restore wallet from seed on another device then create new trezor wallet to send the funds there. Annoying...
Any suggestions?[/quote]
Well, my only suggestion now is to use a different wallet because the trezor is not currently able to rescan its transaction and ignore the 0 confirmation duplicated tx.
Regarding your sentiment to "pay to third party banks and use your national currency", no thank you I will choose to be a victim!
Good thing you only wasted an hour. I'm waiting for over 6 hours for this particular transaction to confirm: http://btc.blockr.io/zerotx/info/844f88ef20fb5d2d2ecf897772d429d9bca1d3cab6314e5ed3017b48940f096a
This tx will not confirm. It belongs to a tx chain that has already been invalidated by a malleated tx (original is here).
So does this necessarily mean that any outputs in that transaction won't be received by the address it was sent to? If so, the balance won't be affected if the transaction was invalidated, right?
Bit-x signature payout gone wrong. This is exactly what you should not do currently, spend unconfirmed inputs.
LOL. They say on their ad that they are professionals in crypto.But they are blockchain spammers. They even do not know how to combine several payouts to one transaction.
Bit-x signature payout gone wrong. This is exactly what you should not do currently, spend unconfirmed inputs.
LOL. They say on their ad that they are professionals in crypto.But they are blockchain spammers. They even do not know how to combine several payouts to one transaction.
Good thing you only wasted an hour. I'm waiting for over 6 hours for this particular transaction to confirm: http://btc.blockr.io/zerotx/info/844f88ef20fb5d2d2ecf897772d429d9bca1d3cab6314e5ed3017b48940f096a
This tx will not confirm. It belongs to a tx chain that has already been invalidated by a malleated tx (original is here).
Bit-x signature payout gone wrong. This is exactly what you should not do currently, spend unconfirmed inputs.
Jump to: