Topic: On The Longest Chain Rule and Programmed Self-Destruction of Crypto Currencies - page 3. (Read 17939 times)

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.

In a way you did:


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.

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.

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.

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.

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.

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.

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?

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.

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.

Isn't that what he is proposing with this:

Users want to band-limit the block chain, so they don't sample high frequency ephemeral attack block chains as being the true signal (because these can contain double-spends). They do this by applying a smoothing filter which is the number of confirmations they wait.

The only decentralized way I can see to defeat the ephemeral 50+% attack is to increase the period of time in which the attacker must be able to control the block chain, i.e. maintain 50+% of the hashrate.

In the current longest chain rule implementation, increasing the number of confirmations before accepting a payment as final forces the hacker to keep his double-spend chain secret longer.

In my proposed variation where the majority hashrate can unwind double-spends (and their derivative transactions), increasing the number of confirmations before accepting a prior transaction as final forces the attacker to maintain his public double-spend chain longer.

The smoothing filter applies to the attacker's period in both cases, and the choice of designs for the longest chain rule determines whether payments or re-spends should be delayed.

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?  

Your sampling analogy deals with effects of aliasing OUTSIDE of the frequency set where the errors occur, whereas the double spend problem occurs in alternate versions of the current set.  In other words, the filter eliminates the audible aliasing by addressing it's consequences while a double spend happens at the exact same frequency as the actual (agreed upon) signal.

Does this flaw in the analogy not point out a possible crack in the thinking here?

Ah so thus the solution to these ephemeral (rented hashrate) 50+% attacks is either in the existing longest chain rule to increase the number of confirmations for finalizing payments to greater than the period the attacker can afford (i.e. 100 or so), or changing the longest chain rule to my proposal which shifts that wait to the duration that a prior transaction has to wait before it can be safely spent again. In my proposal payments still need 1- 6 confirmations as usual to defend against orphans due to propagation delay and < 50% attacks.

So what my proposal does is shift the smoothing filter from slower payments to slower re-spending, as the means of muting ephemeral 50+% (rented hardware) double-spending.

6 confirmations is on the order of 150 BTC cost for the attacker. 100 confirmations on the order of 2500 BTC. The attacker has to recoup that with double-spends.

I couldn't grok what you wrote before so I ignored it. Now I understand your point.

Definitely derivative transactions will be unwound too (thus my quoted statement is incorrect if you haven't waited the say 100 or so confirmations mentioned below), and this does not violate my assertion that insurance increases as n confirmations does.

As you admitted (in the part I didn't grok before), the risk you speak of applies whether my proposal is implemented or not. For example, in the current implementation of longest chain rule, if you got paid in the public orphaned chain and these are double-spent into the secret chain which becomes the longer chain when publicized (thus orphaning the other chain), then your payments are effectively unwound.

My proposal is that you don't trust the longest chain until considerable n confirmations have transpired, because the majority will be trying to unwind those bogus double-spends. So in my proposal, not only do you not deliver goods until a payment has n (usually 1 - 6) confirmations, but also you don't accept payment from a transaction (history) unless the prior transaction has much more than n (say 100 or so) confirmations. Abstractly the smoothing filter applies from both directions.

Note that CryptoNote ring signatures (and probably Zerocash and Zerocoin also) breaks the type of unwinding in my proposal because derivative transactions are unlinkable.

Edit: similar functionality can be obtained in the current implementation of the longest chain rule, by waiting for 100 or so confirmations before accepting a payment as final (to extend out the duration cost for the extended time attacker has to keep his chain secret so your payment isn't orphaned by the attacker's chain). Thus unlinkable coins could still defeat ephemeral 50+% double-spending attacks, but with very slow payments.


You are confused by aliasing error, which can be ephemeral in my proposal.

The confirmations that matter are those in the chain that has the sustainable majority of the hashrate. The only way to differentiate aliasing error from signal, is for the width of the smoothing filter (i.e. the number of confirmations) to be greater than the period of the aliasing error (another way of stating the Nyquist-Shannon sampling theorem). That period is how long the attacker can sustain the hashrate to maintain the longest chain.

Not to mention the obvious:  Double spent coins are the only ones we care about here.

The whole meaning of n confirmations is measuring security against double spends.
Otherwise, 1-2 confirmation would be enough to know the tx was formatted correctly
and was included in the blockchain.

So if you are talking about the possibility of winding them back, then
confirmations lose their meaning, and your "solution" does more harm
than good.

As mentioned in my prior response— if you did this then your proposal is completely ineffective. First you double spend, and then you spend your double-spent coins to yourself.  If you do not also unwind the child transaction then the doublespender walks free for nothing but the cost of an extra transaction. If you do unwind the children then everyone is at constant risk.

Note in my proposal unwinding only affects double-spent coins, so if you never send a double-spend then your transaction will never be unwound. Note a double-spend is not the same as resending the same transaction.

Incorrect. My proposal strengthens the insurance from n confirmations. If you disagree, then walk me through your logic.