Pages:
Author

Topic: New transaction malleability attack wave? Another stresstest? - page 11. (Read 41229 times)

legendary
Activity: 1260
Merit: 1019
Is he saying that implementing BIP 62 opens up a new known attack vector?
That is I wanna say
legendary
Activity: 2940
Merit: 1333
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

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?
legendary
Activity: 1666
Merit: 1057
Marketing manager - GO MP
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.
sr. member
Activity: 435
Merit: 250
I wonder if any of us can double bitcoin due to this attack Smiley
legendary
Activity: 2576
Merit: 1186
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.
legendary
Activity: 1106
Merit: 1026
I'm curious, why is `SCRIPT_VERIFY_LOW_S` not a standard verification flag?
legendary
Activity: 2576
Merit: 1186
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).

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-implemented

https://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)
Rules 2-6 are also not implemented, and BIP 66 extended rule 1 to all transactions, regardless of their version.

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.
legendary
Activity: 1666
Merit: 1057
Marketing manager - GO MP
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.
hero member
Activity: 968
Merit: 515
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).

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-implemented

https://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.
legendary
Activity: 1806
Merit: 1164
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?
hero member
Activity: 616
Merit: 500
I AM A SCAMMER
In which part of the world, it is Sunday now ?

It's a rather rainy Sunday in the UK right now.
Stop posting BS for signature payment only. Check my post date. I posted 2 days ago. That was not a Sunday.
legendary
Activity: 1078
Merit: 1024
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.  Grin 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?
legendary
Activity: 3542
Merit: 1352
Cashback 15%
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.
legendary
Activity: 1260
Merit: 1019
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.  Grin Let us talk about it later.
member
Activity: 60
Merit: 10
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.
legendary
Activity: 1610
Merit: 1004
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!
legendary
Activity: 3542
Merit: 1352
Cashback 15%
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?
full member
Activity: 132
Merit: 100
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 is a cloud mining ponzi with an eyewash of legitimacy. They have 1 Phs vouch from BitFury and selling unmetered hash power. Reliable, professional etc. are all vague words flying in bitcoin industry.
legendary
Activity: 1260
Merit: 1019
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.
copper member
Activity: 1498
Merit: 1528
No I dont escrow anymore.
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.
Pages:
Jump to: