On The Longest Chain Rule and Programmed Self-Destruction of Crypto Currencies

[jonald_fyookball]

If miners who have a winning block can simply reroute funds or unwind transactions because they claim they saw a related transaction
in a previous orphaned block, what's to stop miners from doing that arbitrarily?  

Miners cannot reroute transactions. They can only record them in the block chain.
They can't "unwind" transactions. They can only decide to include them or not. If a miner does not include a transaction in a block, another miner will include it in the next block.

Isn't that what he is proposing with this:

c. If a mining node is in possession of an orphaned block chain which contains transactions that are missing or double-spent in a received longer block chain, the mining node broadcasts this fact and all mining nodes which agree (i.e. had seen this fork before it was orphaned) are expected to add this fact to the next winning block which thus marks any double-spent coins as forfeited to the ether (or adds the spends that were omitted).

[1715686650]

1715686650

[1715686650]

1715686650

[1715686650]

1715686650

[1715686650]

1715686650

[AnonyMint]

If miners who have a winning block can simply reroute funds or unwind transactions because they claim they saw a related transaction
in a previous orphaned block, what's to stop miners from doing that arbitrarily?  

Because in my proposal, the majority hashrate won't agree unless they also saw the previous orphaned block. Thus it isn't arbitrary, rather it is only the longest chain rule consensus of the sustained hashrate.

What you are missing from your analysis is that my proposal retains the longest chain rule. It only allows that rule to use smoothing filter to remove aliasing error spikes in the hashrate that are not sustained and impose double-spends.

What I did was view all the variables of the longest chain rule and realized we had another degree-of-freedom to tinker with, without violating the coherence of the rule.

[AnonyMint]

Let me try to make this more comprehensible.

The way it is now, we wait 1 - 6 confirmations to make sure orphans or a < 50% attack can't unwind our transaction.

However that doesn't stop an attacker who can rent 100% of the hashrate for 6 confirmations for on the order of 6 x 25 = 150 BTC in cost (rough estimate based on block reward).

The way it is now, the only way to stop that ephemeral 50+% attacker is to wait say 100 or more confirmations to increase the rental cost that the attacker must recoup with double-spends.

Premised on the notion that the larger the value of the double-spends, the more difficult for the attacker to scale it and the more (dead or alive?) bounty that will be put on his head.

Excruciatingly slow transactions (e.g. 100 or more confirmations) are very undesirable.

Instead I proposed a new rule which is consistent with the Longest Chain Rule consensus, which allows the consensus to unwind double-spends (and their derivative transactions). Note this proposal appears to not be compatible with unlinkable block chains such as CryptoNote (Monero et al) and Zerocash.

Thus it is not necessary to increase the number of confirmations to wait on a transaction to more than the typical 1 - 6 as we only need to make sure the consensus hashrate has seen our transactions in a longest chain (before it would be orphaned by the attackers secret longer chain).

Instead in my proposal, we increase the delay that a completed transaction must wait before being transacted again (e.g. 100 or more confirmations), so it won't be unwound as a derivative transaction of an attacker's double-spend, which is much more desirable than excruciatingly slow transactions, because often we don't transact received funds too quickly any way.

[drawingthesun]

Let me try to make this more comprehensible.

The way it is now, we wait 1 - 6 confirmations to make sure orphans or a < 50% attack can't unwind our transaction.

However that doesn't stop an attacker who can rent 100% of the hashrate for 6 confirmations for on the order of 6 x 25 = 150 BTC in cost (rough estimate based on block reward).

The way it is now, the only way to stop that ephemeral 50+% attacker is to wait say 100 or more confirmations to increase the rental cost that the attacker must recoup with double-spends.

Premised on the notion that the larger the value of the double-spends, the more difficult for the attacker to scale it and the more (dead or alive?) bounty that will be put on his head.

Excruciatingly slow transactions (e.g. 100 or more confirmations) is very undesirable.

Instead I proposed a new rule which is consistent with the Longest Chain Rule consensus, which allows the consensus to unwind double-spends (and their derivative transactions). Note this proposal appears to not be compatible with unlinkable block chains such as CryptoNote (Monero et al) and Zerocash.

Thus it is not necessary to increase the number of confirmations to wait on a transaction to more than the typical 1 - 6 as we only need to make sure the consensus hashrate has seen our transactions in a longest chain (before it would be orphaned by the attackers secret longer chain).

Instead in my proposal, we increase the delay that a completed transaction must wait before being transacted again (e.g. 100 or more confirmations), so it won't be unwound as a derivative transaction of an attacker's double-spend, which is much more desirable than excruciatingly slow transactions, because often we don't transact received funds too quickly any way.

Making everyone wait 100 confirmations is not a very good idea.

Why not just make a seller wait 100 confirms upon receiving a large transaction, to reduce the chance they will be double spent against? Let people decide how long to wait, why enforce it?

Is waiting for 100 confirms less secure than your idea of forcing all coins to be locked for 100 confirms prior to being spent?

[drawingthesun]

If making the seller and buyer wait for 100 confirms is too slow, why can't the seller just look at the buyers address they are going to spend from has an amount of coin that is 100 confirms old.

The seller says they will only accept 100 confirm aged transactions, so the buyer uses an address with the right age or instead waits.

[drawingthesun]

My above suggestion could even be implemented as a function in the client.

The seller sets that large value purchases must either wait for 100 confirms or come from an address that already has 100 confirms (or a mix of both)

The client automatically makes sure that the payment isn't processed until either of the criteria are satisfied.

[jonald_fyookball]

If miners who have a winning block can simply reroute funds or unwind transactions because they claim they saw a related transaction
in a previous orphaned block, what's to stop miners from doing that arbitrarily?  

Because in my proposal, the majority hashrate won't agree unless they also saw the previous orphaned block. Thus it isn't arbitrary, rather it is only the longest chain rule consensus of the sustained hashrate.

What you are missing from your analysis is that my proposal retains the longest chain rule. It only allows that rule to use smoothing filter to remove aliasing error spikes in the hashrate that are not sustained and impose double-spends.

What I did was view all the variables of the longest chain rule and realized we had another degree-of-freedom to tinker with, without violating the coherence of the rule.

I see your point but I think there's problems.  Consider this scenario:

Chain #1 (eventually orphaned)

block 1: Alice , who has 100 BTC, sends 100 BTC to Bob.

block 2:  Charlie sends 100 BTC to alice

block 3:   Bob sends 100 BTC to Charlie

Chain #2:

block 1: Alice sends 100 BTC to Charlie

block 2: (nothing)

block 3: (nothing)

block 4: nothing -- longest chain

result:  chain 2 as the longest chain is accepted,
however,  Charlie doesn't get the initial 100 BTC,
because miners see it was spent on Bob.  Bob gets the 100 BTC.
However,  Alice is now missing 100 BTC she should have
gotten in block 2,  and Charlie is missing an ADDITIONAL 100 BTC.
from block 3.

Therefore, "double spend attack by omission" can easily occur.

[drawingthesun]

I believe that locking coins for 16 hours (100 confirms) after being received is too un-user friendly to ever be accepted.

Making people wait longer and longer for larger and larger transactions works now and should be the norm.

A service could even be created by the likes of bitpay, where you store a balance through them and they take on the waiting risk with merchants.

[AnonyMint]

Making everyone wait 100 confirmations is not a very good idea.

Why not just make a seller wait 100 confirms upon receiving a large transaction, to reduce the chance they will be double spent against? Let people decide how long to wait, why enforce it?

I did not propose to enforce the number of confirmations. Your multiple redundant posts are very noisy. Perhaps take some time to study more or let me reply first.

[drawingthesun]

Making everyone wait 100 confirmations is not a very good idea.

Why not just make a seller wait 100 confirms upon receiving a large transaction, to reduce the chance they will be double spent against? Let people decide how long to wait, why enforce it?

I did not proposed to enforce the number of confirmations.

In a way you did:

Instead in my proposal, we increase the delay that a completed transaction must wait before being transacted again (e.g. 100 or more confirmations), so it won't be unwound as a derivative transaction of an attacker's double-spend, which is much more desirable than excruciatingly slow transactions, because often we don't transact received funds too quickly any way.

Instead of making the buyer and seller wait at point of sale, you make the seller wait to be able to reuse the funds. The confirmations needed take place once a transaction happens to safegaurd not that current transaction, but the next one.

Now:

A sends 1 btc to B
B sends 1 btc to C
C waits 100 confirms
C sends goods to B.

Your solution:

A sends 1 btc to B
B waits 100 confirms
B sends 1 btc to C
C sends goods right away to B

So we still wait 100 confirms, but it happens before the transaction takes place and no one is allowed to send bitcoin with less than 100 confirms.

[AnonyMint]

Instead in my proposal, we increase the delay that a completed transaction must wait before being transacted again (e.g. 100 or more confirmations), so it won't be unwound as a derivative transaction of an attacker's double-spend, which is much more desirable than excruciatingly slow transactions, because often we don't transact received funds too quickly any way.

Instead of making the buyer and seller wait at point of sale, you make the seller wait to be able to reuse the funds. The confirmations needed take place once a transaction happens to safegaurd not that current transaction, but the next one.

Now:

A sends 1 btc to B
B sends 1 btc to C
C waits 100 confirms
C sends goods to B.

YourMy solution:

A sends 1 btc to B
B waits 100 confirms
B sends 1 btc to C
C sends goods right away to B

So we still wait 100 confirms, but it happens before the transaction takes place and no one is allowed to send bitcoin with less than 100 confirms.

Both in "Now" and in "My Solution" these number confirmations that any user waits is entirely up to their desired risk of a double-spend.

The advantage of my "My Solution" is this wait doesn't make transactions excruciatingly slow for those transactions at risk of double-spend (which could become more likely as the trend towards rentable hashrate becomes more widespread).

"My Solution" leverages all the existing delays between the time users receive a transaction and re-transact it.

[AnonyMint]

If miners who have a winning block can simply reroute funds or unwind transactions because they claim they saw a related transaction
in a previous orphaned block, what's to stop miners from doing that arbitrarily?  

Because in my proposal, the majority hashrate won't agree unless they also saw the previous orphaned block. Thus it isn't arbitrary, rather it is only the longest chain rule consensus of the sustained hashrate.

What you are missing from your analysis is that my proposal retains the longest chain rule. It only allows that rule to use smoothing filter to remove aliasing error spikes in the hashrate that are not sustained and impose double-spends.

What I did was view all the variables of the longest chain rule and realized we had another degree-of-freedom to tinker with, without violating the coherence of the rule.

I see your point but I think there's problems.  Consider this scenario:

Chain #1 (eventually orphaned)

block 1: Alice , who has 100 BTC, sends 100 BTC to Bob.

block 2:  Charlie sends 100 BTC to alice

block 3:   Bob sends 100 BTC to Charlie

Chain #2:

block 1: Alice sends 100 BTC to Charlie

block 2: (nothing)

block 3: (nothing)

block 4: nothing -- longest chain

result:  chain 2 as the longest chain is accepted,
however,  Charlie doesn't get the initial 100 BTC,
because miners see it was spent on Bob.  Bob gets the 100 BTC.
However,  Alice is now missing 100 BTC she should have
gotten in block 2,  and Charlie is missing an ADDITIONAL 100 BTC.
from block 3.

Therefore, "double spend attack by omission" can easily occur.

In my proposal, if Charlie waits the 100 or so confirmations, he would not be in Block 3 and thus would not experience an unwind.

If in my proposal the sustained majority hashrate unwinds the double-spends to the ether, then both Bob & Charlie don't get 100 BTC from Alice. But Charlie should not have accepted the payment as final, because he has seen the orphaned chain and seen there is a double-spend that will be unwound.

If in my proposal the sustained majority hashrate unwind to the transactions in the orphaned chain, then Bob gets 100 BTC from Alice.

I don't see any problem.

Edit: apply the above to Bitcoin, then Bob's transactions are unwound when they are orphaned. Charlie's send to Alice would probably get propagated to the Chain #2.

[jonald_fyookball]

100 confirmations isn't a problem? 

If Bitcoiners are going to wait that long,
you really don't need any special
"unwinding" in the protocol.
 
Miners can just refuse to accept
chains of 100 blocks or more.

[AnonyMint]

100 confirmations isn't a problem?  

If Bitcoiners are going to wait that long,
you really don't need any special
"unwinding" in the protocol.
  
Miners can just refuse to accept
chains of 100 blocks or more.

Re-read my reply to drawingthesun.

[jonald_fyookball]

100 confirmations isn't a problem?  

If Bitcoiners are going to wait that long,
you really don't need any special
"unwinding" in the protocol.
  
Miners can just refuse to accept
chains of 100 blocks or more.

Re-read my reply to drawingthesun.

Yes I realize participants can choose their own number of confirmation according to their risk tolerance.
The issue still remains:  an attacker can double spend simply by building a longer chain
that doesn't include the transaction at all, effectively sending the coins back to himself.

[AnonyMint]

The issue still remains:  an attacker can double spend simply by building a longer chain
that doesn't include the transaction at all, effectively sending the coins back to himself.

Nope.

c. If a mining node is in possession of an orphaned block chain which contains transactions that are missing or double-spent in a received longer block chain, the mining node broadcasts this fact and all mining nodes which agree (i.e. had seen this fork before it was orphaned) are expected to add this fact to the next winning block which thus marks any double-spent coins as forfeited to the ether (or adds the spends that were omitted).

[jonald_fyookball]

The issue still remains:  an attacker can double spend simply by building a longer chain
that doesn't include the transaction at all, effectively sending the coins back to himself.

Nope.

c. If a mining node is in possession of an orphaned block chain which contains transactions that are missing or double-spent in a received longer block chain, the mining node broadcasts this fact and all mining nodes which agree (i.e. had seen this fork before it was orphaned) are expected to add this fact to the next winning block which thus marks any double-spent coins as forfeited to the ether (or adds the spends that were omitted).

How do you which is "the next winning block" ?

If it is the very next block after a longest-chain-wins reorg, and the attacker
wins that block , the attacker could exclude it as well.

And if it doesn't have to be the very next block, then the attacker could work
the other side of the attack, create an orphan transaction on purpose and
spring it several blocks after a reorg, thus double spending that way.

EDIT:  Furthermore, even if an honest miner solves the "next winning block"
required to make the honest correction, what is to stop the 51% attacker
from undoing that block as well?  Where does it end?

[Cryddit]

I don't know if the hash rate solution to byzantine-generals is in fact the right solution.  In the presence of rentable computer power, it doesn't necessarily fulfil the assumptions that the security of the model is based on.

There are other solutions to byzantine-generals, but they require O(n^2) communication so they're even harder to scale to large numbers of users.

We have Eve, Sybil, and Trent to worry about. 

Eve is eavesdropping on the blockchain to discover where (what IP address) transactions originate.  In addition, she does blockchain analysis to identify actors and associate them with past transactions.  Generally, we tolerate Eve because we can't create a completely opaque Eve-proof system without creating a Trent. 

Sybil can create any number of wallets/accounts at any time, making voting mechanisms useless.  The hash rate consensus mechanism was supposed to counter Sybil, but in the presence of rentable hashing power, Sybil can (if she pays money) subvert this mechanism as well.  Sybil is endemic to anonymous trustless systems. 

Trent is the "trusted" authority - a centralized node whose defection is capable of making the system not work.  We have tried very hard to avoid creating a Trent.  The Zerocoin proposal's main problem is that it requires a Trent to set up the encryption parameters.  If Trent defects, there can be any amount of hidden coins in the blockchain and nobody will be able to show it.   Existing solutions to Sybil attacks require Trent to issue accounts linked to keys so that Sybil can't just make up as many new ones as she wants.   

Anyway:  No way to completely avoid Eve and Sybil without creating Trent.  No way to completely avoid Trent without tolerating Eve and Sybil. 

[Peter R]

However that doesn't stop an attacker who can rent 100% of the hashrate for 6 confirmations for on the order of 6 x 25 = 150 BTC in cost (rough estimate based on block reward).

An absurd attack deserves an equally absurd defence:  we'll rent 101% of the world's electricity production so that your hashpower will hash in reverse!

[AnonyMint]

However that doesn't stop an attacker who can rent 100% of the hashrate for 6 confirmations for on the order of 6 x 25 = 150 BTC in cost (rough estimate based on block reward).

An absurd attack deserves an equally absurd defence:  we'll rent 101% of the world's electricity production so that your hashpower will hash in reverse!

Hopefully you were just joking? Clearly that is 100% of the sustained hashrate that exists at any point in time, not 100% of the world's electricity production. And of course you don't need 100% of it, just 50+% (> 50%). I was just providing an estimate of the maximum cost to mount the attack, which turns out to be absurdly low.

Edit: The absurd nature of the attack is today probably 50% of the hashrate is not rentable (thus greater than 6 confirmations is probably not necessary now). But this could change over time if the trend is towards getting market prices for ASICs.