New transaction malleability attack wave? Another stresstest?

[Zombier0]

This attack wont stop

[1713428988]

1713428988

[1713428988]

1713428988

[1713428988]

1713428988

[1713428988]

1713428988

[yakuza699]

This attack wont stop

Unless miners start to ignore High-s.

[Zombier0]

This attack wont stop

Unless miners start to ignore High-s.

They are not skilld enough

[tl121]

This has been bugging me. I've read elsewhere about the real cost of sending transactions on the Bitcoin network being much, much higher than the banking or Visa network.

The cost per bitcoin transaction includes the cost of running the full nodes.  This includes the nodes that forward the unconfirmed transaction to the node that eventually mines the tranaction, the full node that eventually mines the transaction, and the other full nodes that verify and store the block containing mined transaction.

Assuming the software were 100% efficient, this would, at least include the cost of transmitting the transaction to each node, the cost of verifying the transaction and the cost of storing the transaction.  (In practice there are additional costs and overheads, but these are the essentials based on the design of bitcoin which requires all full nodes to receive and verify the entire block chain.  Most of the extra overheads can, at least potentially, be avoided by clever software design.)

A transaction has an average of two digital signatures to be verified (most of the processing) and 500 bytes of data to be received (and on average transmitted) and stored.  The costs can be worked out, but will depend on the users location.  Some (SWAG) figures for bandwidth cost and storage cost are $0.10 per GB.  You can do your own math and figure out how much it costs a node to process an average bitcoin transaction.  This has to be multiplied by the number of nodes in the network (or the number of nodes that you think are useful to have in the network).

The cost of mining is a fixed cost of running the network.  It remains constant regardless of the number of transactions that are in the blocks being mined.  This is the cost of protecting the value of the bitcoins held by the private key holders.  It is not the cost of processing transactions.

[BitNow]

Can somebody explains in a simple sentence (subject + verb + object) what's the problem with this attack, besides that can be a possible duplicate for your transaction that never gets accepted by the Blockchain and gets deleted by the Blockchain after 1 week (estimated time)?

[tl121]

Can somebody explains in a simple sentence (subject + verb + object) what's the problem with this attack, besides that can be a possible duplicate for your transaction that never gets accepted by the Blockchain and gets deleted by the Blockchain after 1 week (estimated time)?

There are two problems:

1. Some wallets get confused should they send a transaction that gets changed by the attack, giving wrong status information to the user.

2.  The attacker can increase the size of the memory pool of unconfirmed transactions, which uses extra processing resources, memory resources and network bandwidth, potentially causing sluggish performance of the network and crashing weak nodes.

[coins101]

This has been bugging me. I've read elsewhere about the real cost of sending transactions on the Bitcoin network being much, much higher than the banking or Visa network.

The cost per bitcoin transaction includes the cost of running the full nodes.  This includes the nodes that forward the unconfirmed transaction to the node that eventually mines the tranaction, the full node that eventually mines the transaction, and the other full nodes that verify and store the block containing mined transaction.

Assuming the software were 100% efficient, this would, at least include the cost of transmitting the transaction to each node, the cost of verifying the transaction and the cost of storing the transaction.  (In practice there are additional costs and overheads, but these are the essentials based on the design of bitcoin which requires all full nodes to receive and verify the entire block chain.  Most of the extra overheads can, at least potentially, be avoided by clever software design.)

A transaction has an average of two digital signatures to be verified (most of the processing) and 500 bytes of data to be received (and on average transmitted) and stored.  The costs can be worked out, but will depend on the users location.  Some (SWAG) figures for bandwidth cost and storage cost are $0.10 per GB.  You can do your own math and figure out how much it costs a node to process an average bitcoin transaction.  This has to be multiplied by the number of nodes in the network (or the number of nodes that you think are useful to have in the network).

The cost of mining is a fixed cost of running the network.  It remains constant regardless of the number of transactions that are in the blocks being mined.  This is the cost of protecting the value of the bitcoins held by the private key holders.  It is not the cost of processing transactions.

6,000 nodes x $100/month hosting costs (which would be on the higher end), works out at $7m / year. Lets say 300,000 full nodes x $500/month each, that gets you to $1.8bn in full node costs. Add that to $3bn, no lets say $5bn in mining costs. You still get less than $10bn annual costs to operate the network vs. Visa costs of $18bn - $30bn, before taking into consideration MasterCard, banks costs, etc.

At mass payments scale, Bitcoin running its own decentralized back-ups / disaster recovery network is way more efficient.

[BitNow]

Can somebody explains in a simple sentence (subject + verb + object) what's the problem with this attack, besides that can be a possible duplicate for your transaction that never gets accepted by the Blockchain and gets deleted by the Blockchain after 1 week (estimated time)?

There are two problems:

1. Some wallets get confused should they send a transaction that gets changed by the attack, giving wrong status information to the user.

2.  The attacker can increase the size of the memory pool of unconfirmed transactions, which uses extra processing resources, memory resources and network bandwidth, potentially causing sluggish performance of the network and crashing weak nodes.

So: only the weak will suffer.

Thank You for your reply.


Best regards.

[yakuza699]

This attack wont stop

Unless miners start to ignore High-s.

They are not skilld enough

https://github.com/bitcoin/bitcoin/pull/6769

[mikeymillie]

Can somebody explains in a simple sentence (subject + verb + object) what's the problem with this attack, besides that can be a possible duplicate for your transaction that never gets accepted by the Blockchain and gets deleted by the Blockchain after 1 week (estimated time)?

There are two problems:

1. Some wallets get confused should they send a transaction that gets changed by the attack, giving wrong status information to the user.

2.  The attacker can increase the size of the memory pool of unconfirmed transactions, which uses extra processing resources, memory resources and network bandwidth, potentially causing sluggish performance of the network and crashing weak nodes.

So: only the weak will suffer.

Thank You for your reply.


Best regards.

> only the weak will suffer.

[BitNow]

> only the weak will suffer.

I don't understand: how the weak suffering has something to do with centralization?


Thank You and Best regards.

[mikeymillie]

> only the weak will suffer.

I don't understand: how the weak suffering has something to do with centralization?


Thank You and Best regards.

When you suppress the agency of the weakest members of a group, they either forfeit their ability to contribute to it (a.k.a. they leave) or else delegate it to those slightly stronger. 

This next slightly stronger group is now the new "weakest" and the cycle continues. 

The result is that strength of the entire group becomes increasingly concentrated toward a center (or centers, in a multimodal distribution) of mass. 

[BitNow]

OT

When you suppress the agency of the weakest members of a group, they either forfeit their ability to contribute to it (a.k.a. they leave) or else delegate it to those slightly stronger.  

This next slightly stronger group is now the new "weakest" and the cycle continues.  

The result is that strength of the entire group becomes increasingly concentrated toward a center (or centers, in a multimodal distribution) of mass.  

Are we the new strongest?

Do you have something in contrary of been one of the strongest?

Best regards.
/OT

[Perlover]

Can somebody explains in a simple sentence (subject + verb + object) what's the problem with this attack, besides that can be a possible duplicate for your transaction that never gets accepted by the Blockchain and gets deleted by the Blockchain after 1 week (estimated time)?

There are two problems:

1. Some wallets get confused should they send a transaction that gets changed by the attack, giving wrong status information to the user.

2.  The attacker can increase the size of the memory pool of unconfirmed transactions, which uses extra processing resources, memory resources and network bandwidth, potentially causing sluggish performance of the network and crashing weak nodes.

I will tell more

I have Mycelium 2.5.2. It allows to spend from unconfirmed transactions (without this feature a user could not make a next transaction until a next block in blockchechain will be generated but user should have a right to spend a change al least for example from a previous payment without waiting)
But this attack has a biggest problem as you could think - now i cannot spend my money from HD account already 3 days because this attack affected my Mycelium wallet. How it happens:

I did Tx - A. After soon i did other Tx - B. The B uses inputs from Tx A. Both transactions were unconfirmed. But attacker rebroadcasted  a changed new transaction - A'. And this transaction was confirmed! After refreshing in the Mycelium wallet the last one forgot about A and replaced it by A' Tx. But after i had the A', the B transaction which used inputs from my other Txs and from the A! But the A already doesn't exist because it was double-spended for blockchain! And the Tx B looks like normal transaction (not double-spend!) because it has input from A transaction (other hash) - there is original TxID and its Tx was forgotten. Miners and full nodes think that they have the B transaction but didn't get a the A yet (other inputs refere to valid Txs of course). And this transaction hangs in mempool already three days and i cannot use other inputs! As a result of this - i as user cannot use other bitcoins already some days. I tried to archive account in Mycelium, wait 1-2 days and activate account again - and this "zombie" B Tx restored again and holds other outputs of other Tx from spending because the B has them (i see it happens because the Mycelium company has own bitcoin blockchain explorer which remembers this B Tx long time).

I think it problem is not only of the Mycelium wallet software.

While malleability will be in current protocol and the BIP62 doesn't work yet - any atacker will be able to make many shit to other users with wallet software - in this case there will be only one way to use bitcoin: to make one transaction in wallet -> wait until confirmation -> doing next transaction... It is stupid and very not comfortable way of bitcoin using.

What do you think about this?

P.S. I am as an advanced user exported xpriv key in Electrum and after this made new transaction and did double-spend of other inputs which were blocked by B Tx... But should what do not-advanced user? He will think that bitcoin sucks and he lost a money...

[Zyklon87]

Can somebody explains in a simple sentence (subject + verb + object) what's the problem with this attack, besides that can be a possible duplicate for your transaction that never gets accepted by the Blockchain and gets deleted by the Blockchain after 1 week (estimated time)?

There are two problems:

1. Some wallets get confused should they send a transaction that gets changed by the attack, giving wrong status information to the user.

2.  The attacker can increase the size of the memory pool of unconfirmed transactions, which uses extra processing resources, memory resources and network bandwidth, potentially causing sluggish performance of the network and crashing weak nodes.

I will tell more

I have Mycelium 2.5.2. It allows to spend from unconfirmed transactions (without this feature a user could not make a next transaction until a next block in blockchechain will be generated but user should have a right to spend a change al least for example from a previous payment without waiting)
But this attack has a biggest problem as you could think - now i cannot spend my money from HD account already 3 days because this attack affected my Mycelium wallet. How it happens:

I did Tx - A. After soon i did other Tx - B. The B uses inputs from Tx A. Both transactions were unconfirmed. But attacker rebroadcasted  a changed new transaction - A'. And this transaction was confirmed! After refreshing in the Mycelium wallet the last one forgot about A and replaced it by A' Tx. But after i had the A', the B transaction which used inputs from my other Txs and from the A! But the A already doesn't exist because it was double-spended for blockchain! And the Tx B looks like normal transaction (not double-spend!) because it has input from A transaction (other hash) - there is original TxID and its Tx was forgotten. Miners and full nodes think that they have the B transaction but didn't get a the A yet (other inputs refere to valid Txs of course). And this transaction hangs in mempool already three days and i cannot use other inputs! As a result of this - i as user cannot use other bitcoins already some days. I tried to archive account in Mycelium, wait 1-2 days and activate account again - and this "zombie" B Tx restored again (i see it happens because the Mycelium company has own bitcoin blockchain explorer which remembers this B Tx long time).

I think it problem is not only of the Mycelium wallet software.

While malleability will be in current protocol and the BIP62 doesn't work yet - any atacker will be able to make many shit to other user with wallet software - in this case there only one way to use bitcoin: to make one transaction in wallet -> wait until confirmation -> doing next transaction... It is stupid and very not comfortable way of bitcoin using.

What do you think about this?

P.S. I am as an advanced user exported xpriv key in Electrum and after this made new transaction and did double-spend of other inputs which were blocked by B Tx... But should what do not-advanced user? He will think that bitcoin sucks and he lost a money...

I updated Mycelium to v2.5.3 and I couldn't make 3-4tx in a row without being confirmed last tx, then try to send others, here what error I get when I try to send 2nd tx without being confirmed first one http://imgur.com/I7HDhQf which is bullshit as my wallet was synced !

As far as I know you could make tx from Mycelium without being confirmed or make tx like as much as you want before first, second .. tx without being confirmed, but I think these changes are from v.2.5.3 and I think it's better for begginers to wait until this attack is over or BIP62 or whatever is implemented to fix this issue/attack.

[amaclin]

P.S. I am as an advanced user...

...there will be only one way to use bitcoin: to make one transaction in wallet -> wait until confirmation -> doing next transaction... It is stupid and very not comfortable way of bitcoin using.
What do you think about this?

I think that you are not advanced bitcoin user.

[Perlover]

I think that you are not advanced bitcoin user.

I think about you same too.

P.S. Do you have anything to talk about this problem not about me?

P.P.S. Ecть чтo пo дeлy cкaзaть, или нa личнocти бyдeм пepexoдить?

[amaclin]

I think about you same too.
P.S. Do you have anything to talk about this problem not about me?

What problem? Malleability? THIS IS NOT A PROBLEM.

Sorry. I know too little about bitcoin, malleability, etc. I am newbie. You are right. I am not advanced user. Thank you for notice it.

[Perlover]

What problem? Malleability? THIS IS NOT A PROBLEM.

It's problem for wallet software. Read above.

[shorena]

-snip-
I updated Mycelium to v2.5.3 and I couldn't make 3-4tx in a row without being confirmed last tx, then try to send others, here what error I get when I try to send 2nd tx without being confirmed first one http://imgur.com/I7HDhQf which is bullshit as my wallet was synced !

As far as I know you could make tx from Mycelium without being confirmed or make tx like as much as you want before first, second .. tx without being confirmed, but I think these changes are from v.2.5.3 and I think it's better for begginers to wait until this attack is over or BIP62 or whatever is implemented to fix this issue/attack.

If mycelium does not allow you do use unconfirmed change by default, it is fixed and the error you got was perfectly fine. Transactions always refer to other transactions via the ID, thus if the ID changes your 2nd TX becomes invalid. It points to a TX that lost a race for confirmation and is now invalid.

If you have several inputs available Mycelium might be able to use more than one confirmed input and thus can issue several TX without waiting for a confirmation.