Bitcoin Forum
September 20, 2019, 07:50:34 PM *
News: Latest Bitcoin Core release: 0.18.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 3 4 5 6 »  All
  Print  
Author Topic: What the "average user" needs to know about Transaction Mutability  (Read 38565 times)
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1005


Gerald Davis


View Profile
February 11, 2014, 11:45:49 PM
Last edit: February 19, 2014, 08:40:01 PM by DeathAndTaxes
 #1

Early statements seemed to suggest that this issue was limited only to custom implementations and services relying on the unconfirmed transaction id as proof of payment.  That normal users running standard clients were fine. This however isn't exactly the case anymore with one or more unknown third parties spamming modified versions of any transactions they receive into the network.  First let me say, none of this should be considered giving MtGox a pass.  Their issues go beyond just transaction mutability and the way they handled the issue was just awful however we can't pretend this isn't an issue for average users.  

I am running the stock reference client (Bitcoin QT or bitcoind) and don't externally use tx ids for any backend processing.  Am I stick affected?

Yes although the level this affects you may vary depending on your usage.  The Bitcoin reference client as currently implemented (i.e. QT client & bitcoind) does rely on transaction ids which can produce some unexpected behavior for end users.  Other major clients are likely affected to some degree you should contact the developers of those clients for more information.  To provide some reassurance these issues do not result in a risk of losing funds, but they can lead to scenarios which are confusing and complicated to resolved.  The long term goal should be immutable transaction ids (hashes) but a short term patch is also needed to make the behavior of the client predictable and intuitive.

The two major areas that a "normal user" will encounter unexpected client behavior relating to mutable transactions are duplicate transactions being reported & unconfirmed change output breaking subsequent transactions.

What is the problem with duplicate transactions being reported?
The first issue is that the QT client is blissfully unaware of the fact that a transaction is a duplicate (same inputs, outputs, and fee) of another transaction, so it reports both txs to the user as if they are unique transactions.  This can be confusing to the user. It may appear they received two payments, or that they accidentally spent coins twice.  Not only is the transaction reported twice, the duplicate(s) are included in the balance reported to the user which further reinforces the perception that the duplicates are an additional unique transaction.  This also appear to affect the balances in the "accounts" system of the reference client.

How can Transaction Mutability break break transactions which use unconfirmed change outputs?
All transactions use as their inputs (money going in) the outputs of a prior transactions.  The reference client as well as other major clients does not allow users to spend the output of unconfirmed transactions.  This is done for obvious reasons, the incoming transaction may never be confirmed and that would prevent any subsequent transactions from confirming as well.  If the clients allowed it this could be chained to involve many people.  Bob sends a coin to John who uses it unconfirmed to send a coin to Sarah who uses it unconfirmed to send a coin to Bill.  If Bob's tx doesn't confirm (say Bob double spent John, or the tx was spammy with no fee) then all the other tx break.  

Most clients however make an exception for unconfirmed change (i.e. output from a transaction back to the same wallet).   In the absence of a third party intentionally mutating transaction hashes this presents no issue as the wallet can be confident the transaction will eventually be confirmed.   The active efforts of malicious third parties, to mutate transactions however makes that assumption flawed and it should be changed.

Side note on inputs & outputs
Quote
If you understand how Bitcoin "really works" you can skip down to the example and conclusion.  For those who are operating under an abstracted understanding of Bitcoin using "address balances" belief that Bitcoin works on "address balances" the rest won't make much sense without a little background on how Bitcoin "really works".  This is a very high level explanation and a lot has been left out or abstracted away but it isn't important to the discussion of the issue.  Forget about address or wallet balances.  Bitcoin works on the concept of inputs and outputs.  The input of every transaction is the output of some previous transaction.  When a user "sends coins" to you, in that tx he is creating an new output which until spent can be used in as the input of a new tx.  The output is "locked" to your corresponding private key so it can only be spent by you.   When you "spend" those "coins" you are creating a new transaction which uses up that output by putting it in the input of this new transaction and in the process create one or more new outputs.  Those outputs can be used in subsequent transactions by the holder of the corresponding private key.    The process of creating a transaction "spends" previous unspent output which is referenced in the input side of the transaction making it spent.  There is no such thing as a half spent output.  All outputs are either unspent (never included as an input in another transaction) or spent (included as an input in a transaction).  Since an output can't be "half spent" when the value one is attempting to transfer is less than the value of the output(s) being spent then the client will add a new output equal to the difference which goes back to the users wallet.  This is commonly called "change" or a "change output".  If you had a 1 BTC unspent output and wanted to spend 0.6 BTC your client would create a new transaction which includes a single input that references the 1 BTC unspent output and two outputs, one would have a value of 0.6 BTC to the recipient and the second would have a value of 0.4 BTC back to your wallet.  So 1 BTC in and 1 BTC out.  Prior to the transaction you had an unspent output with a value of 1 BTC.  After the transaction that output would be considered spent by the network.  Instead you would have a new unspent output with a value of 0.4 BTC.  The receiver would also have an unspent output with a value of 0.6 BTC.

The key point to take away is you don't transfer balances. A transaction "spends" one or more specific, unique unspent outputs by referencing them in the input side of the transaction and the creates one or more new specific, unique outputs by stating the value and conditions for use in the output side of the transaction.  All outputs in the bitcoin network are unique and are explicitly referenced in the transaction by their unique tx id and index.

The input portion of a transaction identifies the specific, unique output(s) being "spent" in the transaction by their unique combination of transaction id and index..  The input of a transaction doesn't reference a generic value (i.e. "spend one of my BTCs at this address") it references a specific output of a specific transaction (i.e. "spend output #0 of tx id 0e11592f65c349e44363362fe78791ccf3777da31b6bb0217422140212884356).  If the transaction id of the output being spent changes (and is included in a block) after the new transaction is created then it is referencing a transaction id which while valid can never be confirmed (because only one of the transactions in a pair of duplicates can be included in a block and the "other one" already is).  

At a protocol level the potential for an issue applies to any unconfirmed unspent output being spent in a new transactions.  The protocol makes no distinction between "normal" and "change" outputs.  Everything is an output.   However all "stock" clients prevent the user from spending unconfirmed outputs received from outside the wallet so unless you are running a modified or custom client the issue practically is limited to change outputs.  The reference client (and AFAIK many others) exempt "change" outputs from the requirement of being confirmed before being spent.  The tx id is being relied upon by the client while it is still mutable.  The tx id of the change output being spent may be modified, and the chance of that happening is now greatly increased due to ongoing malicious modification of transactions by one or more unknown third parties.

An example might help.  Lets image a hypothetical user which has a single unspent output worth 1 BTC and the user spends 0.6 BTC.  

A very simplified view of the tx would look something like this (non relevant portions removed)
Code:
Tx Id: "A"
-------
Inputs
[0]: <prior tx hash> <prior tx index> Value: 1.0 BTC

Outputs
[0]: <PubKey Of Receiver> Value: 0.6 BTC                      <- Payment
[1]: <PubKey Of Change Address> Value: 0.4 BTC            <- Change

Now this transaction is signed and hashed.  The transaction id is the computed hash, which in this example is "A".  The problem occurs if the user makes another spend before tx A is confirmed in a block.  There is no method for a user to restrict the client to only use confirmed change outputs in a new transaction.  So lets see what happens if the user creates a new tx and spends 0.3 BTC more.

Code:
Tx Id: "B"
-------
Inputs
[0]: Tx_Id: A Tx_Index: 1 Value: 0.4 BTC                           <- Note the reference to "A".

Outputs
[0]: <PubKey Of Second Receiver> Value: 0.3 BTC
[1]: <PubKey Of Second Change Address> Value: 0.1 BTC
Now this transaction is signed and hashed.  The hash is "B".  

Contrary to popular understanding of "spending coins", the user isn't spending some generic 0.4 BTC "balance" he is spending a specific unique output (id: "A", index: 1).  If a third party mutates tx "A" so this it now has a tx id of "Z", and "Z" not "A" ends up in a block first, then transaction "B" will never confirm.  It output it references (id: "A", index: 1) in the input side of the transaction can never be included in a block because "Z" already is.  

Potential short term fixes:
The first issue is really just a reporting issue.  The client is reporting data to the user which is confusing or inconsistent.  Clients should still record duplicate transactions but they should one a single tx in a duplicate pair should be shown to the user.  When the client computes the balance of the wallet, duplicates (both received and sent) should be excluded from the total.  Ultimately It doesn't matter which one of the duplicates is hidden as long as only one is shown.  The client will need to handle a situation where if flags and hides one transaction in a pair of duplicates and that ends up being the one which gets included in a block.  For consistency the confirmed transaction should always be shown to the user and the unconfirmed one hidden.  When this happens the user would see no change other than the tx id would change when the duplicate is included in a block.

The second issue can't be fixed other than by preventing the use of unconfirmed change.  The client could either by default or by user set option block all unconfirmed outputs from being spent.  The capability to do this already exists in clients as they already block the spending of "non-change" unconfirmed outputs.  Change would be treated the same as any other output.  Just 1 confirm is sufficient to ensure the tx id won't change in most cases.  In some situations this may result in the user not being able to make a second transactions until the change from the first one is confirmed.  Wallets can preemptively seek to reduce this scenario by monitoring the number of available outputs.  When the number of outputs is low, the client could use more than one change output in the next outbound transaction.  This requires no protocol changes because the protocol has no concept of "change" and already supports having more than two outputs.  A client could even prompt a user to authorize (will require wallet to be unlocked) the creation of a "splitting" transaction if the number of outputs is very low and the value is very high. A wallet with a three outputs with a value of one BTC each is more flexible than a wallet with only one output with a value of three BTC so the wallet could recommend the user split the output.

While these changes wouldn't make transactions immutable they would make the behavior of clients more consistent with the expectations of users and avoid confusing situations that can arise from transactions being mutated.



On edit: Changed title and introduction to reflect recent updates.

On edit2:  Yes mutability is a word.  OO languages have a concept of mutable (changeable) vs immutable (unchangeable) objects.  You can stop PM me that the "correct" word is malleable.  They are synonyms and developers programmers working in high level OO languages are more likely to use the word mutable over malleable.
http://en.wikipedia.org/wiki/Immutable_object
1569009034
Hero Member
*
Offline Offline

Posts: 1569009034

View Profile Personal Message (Offline)

Ignore
1569009034
Reply with quote  #2

1569009034
Report to moderator
PLAY NOW
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1569009034
Hero Member
*
Offline Offline

Posts: 1569009034

View Profile Personal Message (Offline)

Ignore
1569009034
Reply with quote  #2

1569009034
Report to moderator
1569009034
Hero Member
*
Offline Offline

Posts: 1569009034

View Profile Personal Message (Offline)

Ignore
1569009034
Reply with quote  #2

1569009034
Report to moderator
1569009034
Hero Member
*
Offline Offline

Posts: 1569009034

View Profile Personal Message (Offline)

Ignore
1569009034
Reply with quote  #2

1569009034
Report to moderator
acoindr
Legendary
*
Offline Offline

Activity: 1050
Merit: 1001


View Profile
February 11, 2014, 11:56:45 PM
 #2

I thought I saw something saying one of the devs (not sure if Gavin) did think handling the problem with software upgrade was indeed necessary, to resolve "edge case" problems with mutability. Has something indicated otherwise?
acoindr
Legendary
*
Offline Offline

Activity: 1050
Merit: 1001


View Profile
February 12, 2014, 12:06:49 AM
 #3

Here is the source:

http://www.coindesk.com/massive-concerted-attack-launched-bitcoin-exchanges/

Quote
Bitcoin developer Jeff Garzik said the core bitcoin block chain consensus mechanism and payment system are continuing to work as before, and are not directly impacted by transaction malleability.

He added: “Web wallets and other services that build services on top of bitcoin are reporting problems similar to MtGox, and are taking safety measures to ensure no fund loss, during this network disruption.

Yesterday’s statement must be revised:  we will likely issue an update fixing two edge cases exposed by this attack.”
Barek
Full Member
***
Offline Offline

Activity: 168
Merit: 100


View Profile
February 12, 2014, 12:11:13 AM
 #4

Ongoing work here:

https://github.com/bitcoin/bitcoin/pull/3651
rebel24
Member
**
Offline Offline

Activity: 114
Merit: 10


View Profile
February 12, 2014, 12:13:53 AM
 #5

At first I was pretty scared about this, thinking it affected the entire network, but now that I think I understand it it's not as bad.


Here's my understanding-- its basically like a 51% attack, but its not a 51% attack its just 1 transaction they are trying to change and they are trying to spread that to dominate the network as quick as possible.

So who loses? Whoever is the victim of that 1 transaction for the most part-- and the clear target would be the exchanges.

The DDos attacks almost seem like a distraction, or a synergistic attack - but the maleability issue seems to come from an intention to steal coins transaction by transaction.

You guys agree or what?
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1005


Gerald Davis


View Profile
February 12, 2014, 12:15:37 AM
 #6

Here is the source:

http://www.coindesk.com/massive-concerted-attack-launched-bitcoin-exchanges/

Quote
Bitcoin developer Jeff Garzik said the core bitcoin block chain consensus mechanism and payment system are continuing to work as before, and are not directly impacted by transaction malleability.

He added: “Web wallets and other services that build services on top of bitcoin are reporting problems similar to MtGox, and are taking safety measures to ensure no fund loss, during this network disruption.

Yesterday’s statement must be revised:  we will likely issue an update fixing two edge cases exposed by this attack.”

I hadn't seen that update.  My intent wasn't to be controversial but to rather point out in plain english the types of issues that normal users running the reference client are likely to experience. I updated the title.
Lauda
GrumpyKitty
Legendary
*
Offline Offline

Activity: 2338
Merit: 2118



View Profile
February 12, 2014, 12:16:33 AM
 #7

At first I was pretty scared about this, thinking it affected the entire network, but now that I think I understand it it's not as bad.


Here's my understanding-- its basically like a 51% attack, but its not a 51% attack its just 1 transaction they are trying to change and they are trying to spread that to dominate the network as quick as possible.

So who loses? Whoever is the victim of that 1 transaction for the most part-- and the clear target would be the exchanges.

The DDos attacks almost seem like a distraction, or a synergistic attack - but the maleability issue seems to come from an intention to steal coins transaction by transaction.

You guys agree or what?
Like a 51% attack? No. A 51% attack enables you to double spend and take control, this shouldn't. It's kind of like spamming the network, or you could call it DDoS.

████████████████████████████
████████▀▀ █▀ █▀ ▀██████████
█████████▄ ▄▄▄▄▄▄███████████
██████████▀     ▀  ▀████████
███████▀ ▀  ▄█▀▀▀█▀▀████████
██████▄      █▄  ▀▀  ▀██████
██████         ▄▄█▄ ▄ ▀█████
█████ ▄         ▀▀ ▄ ▀ █████
██████▌          █▀█▀ ▐█████
███████  ▄▌         ▄ ██████
████████▄█         ▄████████
█████████▀     ▄▄ ▄█████████
████████████████████████████
.JACKMATE'S...........
.
MAJESTIC..
████████████████████████
███████████████████████
████████████████████████
████████████████████████
████████████████████████
████████████████████████
████████████████████████
████████████████████████
████████████████████████
████████████████████████
████████████████████████
████████████████████████
████████████████████████
.
..WIN 1 BITCOIN ON EVERY PREMIER LEAGUE MATCHDAY..
████████████████████████████████
████████████▀█▀ ▀█▀█▀███████████
███████████▄ ▄▄▄▄▄▄▄████████████
███████████▀▀▄▄▄▄▄▄▄▄███████████
█████████▀▄ ██▀▄▄▄ ▀ ▄▀█████████
███████▀ ▀█████▄▄▄█▄▄▄██████████
███████▀▄████████▀  ▀█ █▐███████
███████ ▀█████████▄█▀▀██ ███████
████████ ███▀██████ ▄ ██ ███████
████████▌▐▀▄ ██████████ ▄███████
█████████▄██▌▐█████▀██ █████████
████████████▄▀▀▀▀▀▄ ▀▄██████████
████████████████████████████████
.
.JOIN US - IT'S FREE! .
TheFootMan
Hero Member
*****
Offline Offline

Activity: 490
Merit: 500


View Profile
February 12, 2014, 12:17:50 AM
 #8

Here is the source:

http://www.coindesk.com/massive-concerted-attack-launched-bitcoin-exchanges/

Quote
Bitcoin developer Jeff Garzik said the core bitcoin block chain consensus mechanism and payment system are continuing to work as before, and are not directly impacted by transaction malleability.

He added: “Web wallets and other services that build services on top of bitcoin are reporting problems similar to MtGox, and are taking safety measures to ensure no fund loss, during this network disruption.

Yesterday’s statement must be revised:  we will likely issue an update fixing two edge cases exposed by this attack.”

I hadn't seen that update.  My intent wasn't to be controversial but to rather point out in plain english the types of issues that normal users running the reference client are likely to experience. I updated the title.

Well although the problem was known before, nobody exploited it on a large scale until now. And why now?
Barek
Full Member
***
Offline Offline

Activity: 168
Merit: 100


View Profile
February 12, 2014, 12:18:11 AM
 #9

You guys agree or what?

You misunderstand. There is an explanation here.

https://bitcointalk.org/index.php?topic=458386.0


Well although the problem was known before, nobody exploited it on a large scale until now. And why now?

Because Mt.Gox put it in the spotlight. I doubt more than a handful of people were aware of this before.
Lauda
GrumpyKitty
Legendary
*
Offline Offline

Activity: 2338
Merit: 2118



View Profile
February 12, 2014, 12:18:33 AM
 #10


Well although the problem was known before, nobody exploited it on a large scale until now. And why now?
Because it was not a priority issue and (almost) nobody was trying to abuse it, until now.

████████████████████████████
████████▀▀ █▀ █▀ ▀██████████
█████████▄ ▄▄▄▄▄▄███████████
██████████▀     ▀  ▀████████
███████▀ ▀  ▄█▀▀▀█▀▀████████
██████▄      █▄  ▀▀  ▀██████
██████         ▄▄█▄ ▄ ▀█████
█████ ▄         ▀▀ ▄ ▀ █████
██████▌          █▀█▀ ▐█████
███████  ▄▌         ▄ ██████
████████▄█         ▄████████
█████████▀     ▄▄ ▄█████████
████████████████████████████
.JACKMATE'S...........
.
MAJESTIC..
████████████████████████
███████████████████████
████████████████████████
████████████████████████
████████████████████████
████████████████████████
████████████████████████
████████████████████████
████████████████████████
████████████████████████
████████████████████████
████████████████████████
████████████████████████
.
..WIN 1 BITCOIN ON EVERY PREMIER LEAGUE MATCHDAY..
████████████████████████████████
████████████▀█▀ ▀█▀█▀███████████
███████████▄ ▄▄▄▄▄▄▄████████████
███████████▀▀▄▄▄▄▄▄▄▄███████████
█████████▀▄ ██▀▄▄▄ ▀ ▄▀█████████
███████▀ ▀█████▄▄▄█▄▄▄██████████
███████▀▄████████▀  ▀█ █▐███████
███████ ▀█████████▄█▀▀██ ███████
████████ ███▀██████ ▄ ██ ███████
████████▌▐▀▄ ██████████ ▄███████
█████████▄██▌▐█████▀██ █████████
████████████▄▀▀▀▀▀▄ ▀▄██████████
████████████████████████████████
.
.JOIN US - IT'S FREE! .
lnternet
Sr. Member
****
Offline Offline

Activity: 299
Merit: 253


View Profile
February 12, 2014, 12:19:34 AM
 #11

Thanks D&T!

1ntemetqbXokPSSkuHH4iuAJRTQMP6uJ9
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1005


Gerald Davis


View Profile
February 12, 2014, 12:23:24 AM
 #12

Here's my understanding-- its basically like a 51% attack, but its not a 51% attack its just 1 transaction they are trying to change ...

You guys agree or what?

No it is nothing like a 51% attack or even a normal double spend.  Using those terms just leads to unnecessary confusion and fear.

The issues outlined don't present a risk of losing funds for end users.   They do however have the possibility of making the client behave in a way that is counter intuitive to a user, especially one which is a non-developer and lacks a detailed understanding of what is going on behind the scenes.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1005


Gerald Davis


View Profile
February 12, 2014, 12:28:17 AM
Last edit: February 12, 2014, 12:40:35 AM by DeathAndTaxes
 #13

Well although the problem was known before, nobody exploited it on a large scale until now. And why now?

I have two theories.  The mass mutating of transactions occured shortly after MtGox suspended withdrawals and the statement by core developers so my assumption is the "mass mutater(s)" are either
a) the same entities which used it to exploit MtGox's lack withdraw system.  Now that the option to stealthily profit from this is gone, they are just using it to "grief the network"

OR

b) it is someone trying to prove a point  ("oh it isn't a problem, and only affects poorly designed custom clients? Well lets just see about that").

Either way the reality is that mass modification of transaction hashes has never occurred before.  But the genie is out of the bottle now, and given the ease at which someone looking to disrupt the network can carry on this modifications I don't expect they will stop.  Casual users are the ones who are most likely to be affected (caught in the crossfire) simply because they may not understand what is going on.  The issues are more of a nuisance nature, and don't present a security risk (outside of those incorrectly relying on txid for unconfirmed tx as proof of transactions) but they do make the system as a whole look bad (likely the intent of whoever is doing it).
Stevets
Member
**
Offline Offline

Activity: 70
Merit: 10


View Profile
February 12, 2014, 12:30:44 AM
 #14

You guys agree or what?

You misunderstand. There is an explanation here.

https://bitcointalk.org/index.php?topic=458386.0


Well although the problem was known before, nobody exploited it on a large scale until now. And why now?

Because Mt.Gox put it in the spotlight. I doubt more than a handful of people were aware of this before.

Because MtGox said they would not allow withdrawals until the issue non-issue was fixed. They dug a hole and this is their way of forcing a fix so they can get out of it.
dorobotsdream
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
February 12, 2014, 12:32:46 AM
 #15

Wouldn't there be some way to discourage miners from solving a block with malleated (or should I say mallified :-) ) transactions?

If there is less of a reward, it might not be worth the energy or investment, and if malleated transaction do not get mined, they would be pointless, wouldn't they?
Carlton Banks
Legendary
*
Offline Offline

Activity: 2492
Merit: 1885



View Profile
February 12, 2014, 12:34:51 AM
 #16

Sensible suggestions D&T, as has been pointed out, the first solution has already been implemented.


Interesting that Mt Gox appeared to be the only affected service at first. It looks like the "attacker" waited until Gox announced on Monday, watched the markets react, then stabilise, then unleashed the attack on the other exchanges on Tuesday.

So, systematic FUD campaign? Seems very like it. And the biggest wave of the whole attack happened just after a few bad news stories, too. Someone's definitely trying to exploit the exchange rate.

Vires in numeris
rebel24
Member
**
Offline Offline

Activity: 114
Merit: 10


View Profile
February 12, 2014, 12:36:56 AM
 #17

You guys agree or what?

You misunderstand. There is an explanation here.

https://bitcointalk.org/index.php?topic=458386.0


Well although the problem was known before, nobody exploited it on a large scale until now. And why now?

Because Mt.Gox put it in the spotlight. I doubt more than a handful of people were aware of this before.

Because MtGox said they would not allow withdrawals until the issue non-issue was fixed. They dug a hole and this is their way of forcing a fix so they can get out of it.

I actually think I do understand.... I read that first post, and it confirms what I said in my post above. Correct me if I'm wrong but I think I'm right.


And if I understand correctly, this is an issue where the THEIVES have to act QUICKLY.

If you wait 10-20 minutes (confirmations), then there is way too many computers, ie: the whole network with the transaction and question already confirmed and buried under other ones- can't change the hashes now. (lest you do a 51% attack, which presumably again is harder with the passage of time)
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1005


Gerald Davis


View Profile
February 12, 2014, 12:37:17 AM
 #18

Wouldn't there be some way to discourage miners from solving a block with malleated (or should I say mallified :-) ) transactions?

If there is less of a reward, it might not be worth the energy or investment, and if malleated transaction do not get mined, they would be pointless, wouldn't they?

There really is no such thing as a Bitcoin "network" it is a loose organization of independent nodes.  A particular node has no way of knowing which tx is the original and which one is the modified one.  The modified one potentially could be received first.   There is also no way to reduce the compensation to miners as the tx and its duplicate are identical in terms of the inputs, outputs, and fee paid.

It may be possible to reduce the % of times that the duplicate gets included in a block by improving the tx selection criteria among miners who voluntarily upgrade their systems, but it probably would never reduce it to zero even among participating miners.  There is also the possibility that the attacker/griefer is also mining and favoring the duplicates over the original.   Both are valid copies of the transaction, a block containing either one is considered valid by other nodes.


Barek
Full Member
***
Offline Offline

Activity: 168
Merit: 100


View Profile
February 12, 2014, 12:47:35 AM
 #19

And if I understand correctly, this is an issue where the THEIVES have to act QUICKLY.

If you wait 10-20 minutes (confirmations), then there is way too many computers, ie: the whole network with the transaction and question already confirmed and buried under other ones- can't change the hashes now. (lest you do a 51% attack, which presumably again is harder with the passage of time)

The thieves can only copy transactions, they cannot change the contents. Only one of the copies can be included in the blockchain. If further transactions are based on one of the transactions that will never be part of the blockchain, all these transactions will also timeout when the not-included copy does.

This changes nothing on the usual practice that once a transaction is part of the blockchain it is safe to trust it. A 51% attack actually rewrites the blockchain.
FeedbackLoop
Hero Member
*****
Offline Offline

Activity: 742
Merit: 500



View Profile
February 12, 2014, 12:55:13 AM
 #20

This changes nothing on the usual practice that once a transaction is part of the blockchain it is safe to trust it. A 51% attack actually rewrites the blockchain.

NO it actualy doesn't: https://en.bitcoin.it/wiki/Attacks#Attacker_has_a_lot_of_computing_power

Sorry for the tangent, second time that 51% BS was creeping in, and thank you DandT.

Pages: [1] 2 3 4 5 6 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!