Atomic swaps using cut and choose

[TPTB_need_war]

Also, how can a PoS coin be attacked using this? Does this mean that PoS coins are more secure as atomic altcoins than PoW?

Unlike hashrate (electricity), stake only has to be purchased once and attack forever, so therefor rental prices for stake should be much lower (since stake costs less than hashrate).


I think we solved the jamming problem with CLTV version of DE. So there was a positive outcome from this thread. I am happy that DE can work.

[1714910393]

1714910393

[1714910393]

1714910393

[1714910393]

1714910393

[1714910393]

1714910393

[1714910393]

1714910393

[1714910393]

1714910393

[jl777]

Also, how can a PoS coin be attacked using this? Does this mean that PoS coins are more secure as atomic altcoins than PoW?

Unlike hashrate (electricity), stake only has to be purchased once and attack forever, so therefor rental prices for stake should be much lower (since stake costs less than hashrate).


I think we solved the jamming problem with CLTV version of DE. So there was a positive outcome from this thread. I am happy that DE can work.

Yes scrutiny leads to progress.

"stake costs less than hashrate" this appears to be the same as saying donuts cost less than springs.

Sometimes the stake required to attack will cost more than hashrate and vice versa. So it all depends on the specific coins being talked about.

And I am not thinking it is so easy to cause deep reorgs at will. It could be that the DE for low security coins needs to be done over longer periods of time and in small increments, ie overlapped micropayment channels.

I am not conviced by general statements, especially when they have counterexamples that prove they are incorrect. I can easily name many PoS coins that are more expensive to obtain stake enough to attack against a set of PoW coins whose hashrate is lower.

Sorry, general scare statements dont work on me. Only specific failure cases, which can then be generalized and solutions usually devised. I know that if I just say, sure in theory it wont work and dont push for a solution, then it would limit things to BTC <-> LTC and gradually more and more, so at worst it is a slow process, but we dont have to outrun the bear, we just need to be more secure than a CE.

James

[TPTB_need_war]

I think we solved the jamming problem with CLTV version of DE. So there was a positive outcome from this thread. I am happy that DE can work.

Yes scrutiny leads to progress.

I think we should celebrate TierNolan's original protocol, the implementation of CLTV in Bitcoin recently, and now my added improvement of "Coin Days Destroyed" to squelch jamming. DE can be a reality! Hooray! I am excited about you implementing this. All altcoins that are excited too, need to implement CLTV.

Also, how can a PoS coin be attacked using this? Does this mean that PoS coins are more secure as atomic altcoins than PoW?

Unlike hashrate (electricity), stake only has to be purchased once and attack forever, so therefor rental prices for stake should be much lower (since stake costs less than hashrate).

"stake costs less than hashrate" this appears to be the same as saying donuts cost less than springs.

Sometimes the stake required to attack will cost more than hashrate and vice versa. So it all depends on the specific coins being talked about.

I am making a mathematical asymptotic argument similar conceptually to the arguments about Big O and Big Theta computational complexity classes (wherein at any particular/small values the conclusion might be opposite of the asymptotic reality). The point is mathematical structure in that stake only has to be purchased once, whereas electricity has to be paid continuously. Thus in terms of mathematical structure (all other variables the same, e.g. market cap, etc), then hashrate will be structurally more expensive than stake. Stake is not as secure as hashrate because stake is paid once for an eternal attack and hashrate must be paid continuously else the attack ends (is finite in duration). In short, stake enables an infinite duration attack (at no extra cost) and thus stake is free and hashrate is finite and thus it is not free. If you don't believe that, then just consider that one can short a PoS coin (thus recovering the cost of the stake making it less than free) and the market is likely to sell off the coin during any stake-based attack because the market understands the only way to overcome the attack is to fork the coin. Whereas with PoW, the market may ignore the attack because it will be ephemeral unless the attacker can profit from the attack enough to pay for the ongoing cost of the electricity.

This is the fundamental reason that PoS is not secure. Apparently some PoS coins have been attacked with stake, and the common case are the exchanges which control huge amounts of stake.

And I am not thinking it is so easy to cause deep reorgs at will. It could be that the DE for low security coins needs to be done over longer periods of time and in small increments, ie overlapped micropayment channels.

I presume I did not adequately explain the economic argument. The point is that once you incentivize profitable PoW attacks, the attacker can now sustain an attack indefinitely (or the DE is abandoned). Thus there is no longer period of time which is sufficient (from a mathematical structural perspective, although there might be particular cases that are secure, you can't state them with equations that enable reliable decisions). I understand you want to find some reasonable middle ground, but I presume you would play with fire if you pursued this similar to those who argued that PoS was an acceptable middle ground (yet even today we see that Bitshares' DPOS is probably controlled by a few exchanges and I think someone told me Nxt is controlled by a dictator).

I comprehend and am aware of the stance that says nothing is perfect and choose some practical middle ground. But I argue we can do better than some muddled middle ground where for example Bitcoin is already controlled by a Chinese mining cartel that has 65% of the hashrate and is provably lying about the Great Firewall of China being a hindrance for them (their motivation is obviously to make higher profits with higher transaction fees by constraining block size). This outcome I predicted in 2013, even I nailed in 2013 the block size as the specific failure mode, and everyone was arguing at that time that I was loony. Their % of the hashrate will increase on the next block reward halving this year, because the marginally profitable miners are the first to go (and I suspect the Chinese mining cartel is getting subsidized electricity with political connections/corruption).

You can make the reasonable argument that the insecurity of the proposed cut & choose algorithm only impacts those altcoins without CLTV and thus it is better than no DE for those coins. In that case, maybe I can agree with that. But do fully acknowledge the Pandora's box security threat so enabled (but at least isolated to those who trade for those altcoins). Thus I don't think it will be a very popular case, if proper disclosures are made. Who would trade BTC for an altcoin where they might lose their funds due to an attack (particularly even a long-range lie-in-wait attack) and where the developers of that altcoin are unable to add the CLTV op code.

I am not conviced by general statements, especially when they have counterexamples that prove they are incorrect. I can easily name many PoS coins that are more expensive to obtain stake enough to attack against a set of PoW coins whose hashrate is lower.

Of course there are scenarios where a PoW coin pays less % of debasement to mining thus requires less cost for a short-term attack than a PoS coin with a huge market cap. This is primarily because Satoshi's PoW design is incorrect. I have a solution to this by making mining unprofitable so that no debasement is paid for mining.

Both the current PoS and PoW designs are flawed. That is one of the major innovations I am working on.

Sorry, general scare statements dont work on me.

The generative essence statement I made upthread was referring to the fact that given no reference point, DE would not be secure,. Without a reference point, nothing can be proven about crypto currency (e.g. double-spends can't be prevented, etc), thus the requirement for a reference point is essential (even Satoshi's PoW suffers from the fact that it is probabilistic and didn't solve the Byzantine General's Problem because it can't identify an attack from a non-attack because the longest chain rule is self-referential). I can make such a general statement and be 100% certain there is no possible exception, because it is a fundamental inviolable mathematical structural issue.

The reference points are provided by my upthread "Coin Days Destroyed" suggestion a few days ago and the point yesterday in this thread about hard-coding the destination addresses in the CLTV. In order words, those reference points do not depend on future confirmations, but are past history (the age of the UXTOs being spent) and future invariants (the hard-coded destinations).

I was just starting treatment for fatty liver disease over the past 2 days (along with running around getting a diagnosis and other foggy brain matters) so apologies that only this morning did I feel alert enough to write a coherent explanation such as this.

Only specific failure cases, which can then be generalized and solutions usually devised. I know that if I just say, sure in theory it wont work and dont push for a solution, then it would limit things to BTC <-> LTC and gradually more and more, so at worst it is a slow process, but we dont have to outrun the bear, we just need to be more secure than a CE.

There is a distinction between theory and inviolable mathematical structure. I will give you another example that I learned when I started to teach myself cryptography over the past 3 years. That is zero knowledge proofs are impossible without an asymmetric trap door function, i.e. they can't be done with hash functions. That is not theory. It is an inviolable fact due to the mathematical structure.

[jl777]

I think we solved the jamming problem with CLTV version of DE. So there was a positive outcome from this thread. I am happy that DE can work.

Yes scrutiny leads to progress.

I think we should celebrate TierNolan's original protocol, the implementation of CLTV in Bitcoin recently, and now my added improvement of "Coin Days Destroyed" to squelch jamming. DE can be a reality! Hooray! I am excited about you implementing this. All altcoins that are excited too, need to implement CLTV.

Also, how can a PoS coin be attacked using this? Does this mean that PoS coins are more secure as atomic altcoins than PoW?

Unlike hashrate (electricity), stake only has to be purchased once and attack forever, so therefor rental prices for stake should be much lower (since stake costs less than hashrate).

"stake costs less than hashrate" this appears to be the same as saying donuts cost less than springs.

Sometimes the stake required to attack will cost more than hashrate and vice versa. So it all depends on the specific coins being talked about.

I am making a mathematical asymptotic argument similar conceptually to the arguments about Big O and Big Theta computational complexity classes (wherein at any particular/small values the conclusion might be opposite of the asymptotic reality). The point is mathematical structure in that stake only has to be purchased once, whereas electricity has to be paid continuously. Thus in terms of mathematical structure (all other variables the same, e.g. market cap, etc), then hashrate will be structurally more expensive than stake. Stake is not as secure as hashrate because stake is paid once for an eternal attack and hashrate must be paid continuously else the attack ends (is finite in duration). In short, stake enables an infinite duration attack (at no extra cost) and thus stake is free and hashrate is finite and thus it is not free. If you don't believe that, then just consider that one can short a PoS coin (thus recovering the cost of the stake making it less than free) and the market is likely to sell off the coin during any stake-based attack because the market understands the only way to overcome the attack is to fork the coin. Whereas with PoW, the market may ignore the attack because it will be ephemeral unless the attacker can profit from the attack enough to pay for the ongoing cost of the electricity.

This is the fundamental reason that PoS is not secure. Apparently some PoS coins have been attacked with stake, and the common case are the exchanges which control huge amounts of stake.

And I am not thinking it is so easy to cause deep reorgs at will. It could be that the DE for low security coins needs to be done over longer periods of time and in small increments, ie overlapped micropayment channels.

I presume I did not adequately explain the economic argument. The point is that once you incentivize profitable PoW attacks, the attacker can now sustain an attack indefinitely (or the DE is abandoned). Thus there is no longer period of time which is sufficient (from a mathematical structural perspective, although there might be particular cases that are secure, you can't state them with equations that enable reliable decisions). I understand you want to find some reasonable middle ground, but I presume you would play with fire if you pursued this similar to those who argued that PoS was an acceptable middle ground (yet even today we see that Bitshares' DPOS is probably controlled by a few exchanges and I think someone told me Nxt is controlled by a dictator).

I comprehend and am aware of the stance that says nothing is perfect and choose some practical middle ground. But I argue we can do better than some muddled middle ground where for example Bitcoin is already controlled by a Chinese mining cartel that has 65% of the hashrate and is provably lying about the Great Firewall of China being a hindrance for them (their motivation is obviously to make higher profits with higher transaction fees by constraining block size). This outcome I predicted in 2013, even I nailed in 2013 the block size as the specific failure mode, and everyone was arguing at that time that I was loony. Their % of the hashrate will increase on the next block reward halving this year, because the marginally profitable miners are the first to go (and I suspect the Chinese mining cartel is getting subsidized electricity with political connections/corruption).

You can make the reasonable argument that the insecurity of the proposed cut & choose algorithm only impacts those altcoins without CLTV and thus it is better than no DE for those coins. In that case, maybe I can agree with that. But do fully acknowledge the Pandora's box security threat so enabled (but at least isolated to those who trade for those altcoins). Thus I don't think it will be a very popular case, if proper disclosures are made. Who would trade BTC for an altcoin where they might lose their funds due to an attack (particularly even a long-range lie-in-wait attack) and where the developers of that altcoin are unable to add the CLTV op code.

I am not conviced by general statements, especially when they have counterexamples that prove they are incorrect. I can easily name many PoS coins that are more expensive to obtain stake enough to attack against a set of PoW coins whose hashrate is lower.

Of course there are scenarios where a PoW coin pays less % of debasement to mining thus requires less cost for a short-term attack than a PoS coin with a huge market cap. This is primarily because Satoshi's PoW design is incorrect. I have a solution to this by making mining unprofitable so that no debasement is paid for mining.

Both the current PoS and PoW designs are flawed. That is one of the major innovations I am working on.

Sorry, general scare statements dont work on me.

The generative essence statement I made upthread was referring to the fact that given no reference point, DE would not be secure,. Without a reference point, nothing can be proven about crypto currency (e.g. double-spends can't be prevented, etc), thus the requirement for a reference point is essential (even Satoshi's PoW suffers from the fact that it is probabilistic and didn't solve the Byzantine General's Problem because it can't identify an attack from a non-attack because the longest chain rule is self-referential). I can make such a general statement and be 100% certain there is no possible exception, because it is a fundamental inviolable mathematical structural issue.

The reference points are provided by my upthread "Coin Days Destroyed" suggestion a few days ago and the point yesterday in this thread about hard-coding the destination addresses in the CLTV. In order words, those reference points do not depend on future confirmations, but are past history (the age of the UXTOs being spent) and future invariants (the hard-coded destinations).

I was just starting treatment for fatty liver disease over the past 2 days (along with running around getting a diagnosis and other foggy brain matters) so apologies that only this morning did I feel alert enough to write a coherent explanation such as this.

Only specific failure cases, which can then be generalized and solutions usually devised. I know that if I just say, sure in theory it wont work and dont push for a solution, then it would limit things to BTC <-> LTC and gradually more and more, so at worst it is a slow process, but we dont have to outrun the bear, we just need to be more secure than a CE.

There is a distinction between theory and inviolable mathematical structure. I will give you another example that I learned when I started to teach myself cryptography over the past 3 years. That is zero knowledge proofs are impossible without an asymmetric trap door function, i.e. they can't be done with hash functions. That is not theory. It is an inviolable fact due to the mathematical structure.

I think if the user can set the timeout values they can decide to accept the risk of blockchain reorg'ed after the swap. NXT PoS limits any reorgs to 720 blocks, so for NXT if the timeout is set above 720 blocks, then it will be beyond the reach of any attack. Couldnt any coin use data from the BTC blockchain from some hours in the past to create a backstop from massive reorg? By using the massive PoW of BTC, a PoS or weaker PoW would get an externally verifiable reference? Why couldnt that be used as the generative essence you say is required?

And if BTC data from recent past is good enough for a generative essence from infinite depth reorgs, then if a timeout is set to be past that, dont we have the finite time from attacks (PoW and PoS) and avoid the mathematical apocalypse you write about above. And so, if the DE submitted OP_RETURN data into all the supported altcoins with data from BTC, wouldnt all such chains get a backstop? Considering you said it was impossible on multiple occasions, there must be some basic error with the above. Just like there are external factors that need to be considered for attacks, there can be external factors that can be injected into the defense.

So, let us assume we have a bi-directional generative essences of protection. The altcoin chains put into their blockchain data from BTC blockchain of recent past (-2hrs?) and the BTC blockchain in turn puts altcoin data into its blockchain. OP_RETURN can be used on all to put a hash or two in all chains. This creates a supernetwork of interlinked blockchains, doesnt it? With all of them backstopped by BTC making it the foundation technically for all the blockchains.

But maybe I misunderstood your objection and the above has a fatal flaw?

My analysis is that the DE allows people to trade without using a third party escrow (CE function) and this is more decentralizing as the funds are now mostly in peoples wallets instead of a big giant pile in Big Vern's accounts. So if you are claiming that DE is bad, then I think you need to consider that a CE centralized trading funds across ALL the coins that are traded at once.

With DE, let us accept your assertion that it will allow some attacker to reorg any chain at will to any depth, as I am sure I couldnt have solved an impossible problem with this post vs. the practical cost of setting it up. Even with this point asserted, I claim that DE provides a better environment as an attack event affects just that one coin, not ALL coins at the DE.

So unless the existing situation of aggregated CE dependency is better for altcoins without CLTV, the DE is an improvement. AND much more importantly, if an altcoin starts trading using the DE, this provides a much stronger impetus for them to add CLTV as compared to the possibility of trading on the DE.

My analysis incorporates the big picture that includes getting altcoins to upgrade. As for the coins without dev teams... At least they can keep trading via DE even after all the CE get hacked to bits or discontinue them.

Doesnt the DE thus improve the situation for the altcoins? From the BTC maximalist point of view, if a lagging altcoin gets out of favor since it is continually attacked, then the DE acts as a spur to evolve. But primarily the DE reduces the concentration of deposits in the CE and gives people more options.

James

[TPTB_need_war]

I think if the user can set the timeout values they can decide to accept the risk of blockchain reorg'ed after the swap.

Users typically can't make such settings from any knowledgeable stance. They are ignorant of the tradeoffs and technical issues. I firmly believe you must make this decision for them (at least the default), because I believe they will blame you (the decentralized exchange concept) for any failure. I speak from decades of experience of making B2C (not B2B) commercial software for customers.

NXT PoS limits any reorgs to 720 blocks, so for NXT if the timeout is set above 720 blocks, then it will be beyond the reach of any attack.

That seems reasonable since checkpoints are required in PoS due to people selling their stake and then doing a long-range attack with stake they no longer own based on reorganization of historical transactions that create stake. Anyone who is buying NXT should hopefully understand the tradeoffs of a PoS system (centralized governance, advantage of less electrical consumption, my arguments against PoS in my prior post, etc).

Couldnt any coin use data from the BTC blockchain from some hours in the past to create a backstop from massive reorg? By using the massive PoW of BTC, a PoS or weaker PoW would get an externally verifiable reference? Why couldnt that be used as the generative essence you say is required?

[...]

But maybe I misunderstood your objection and the above has a fatal flaw?

I assume you mean writing some meta-data into the stronger block chain, that the weaker block chain could refer to as evidence. The hindrance is that decentralized block chains have no external reference point. There is no way to enforce that a particular block in one chain came before a block (nor within some # of blocks after a block) on another chain. Block chains are self-referential, and that is precisely why we need CLTV to implement decentralized exchange. It is also why Blockstream's side chains have security which is as weak as the weakest side chain (because a reorganization in one chain erases coins that have already been reserved in other chains for maintaining the one-to-one exchange peg), which is btw why afaics Side chains are implausible (hopefully this post won't get deleted by the moderator, hehe).

My analysis is that the DE allows people to trade without using a third party escrow (CE function) and this is more decentralizing as the funds are now mostly in peoples wallets instead of a big giant pile in Big Vern's accounts. So if you are claiming that DE is bad, then I think you need to consider that a CE centralized trading funds across ALL the coins that are traded at once.

I have agreed. Remember what I wrote upthread:

I am trying to think of a way to make this practical and robust enough, unless we are facing a prolonged attack from a super power. I like the ideological intent of DE. I will now review your latest reply with a clearer mind.

You won't be able to steal funds, which afaik is the most significant advantage of DE over CE.

Thanks to TierNolan et al, we already have a solution employing CLTV on both chains and even squelched the hypothetical jamming with "coin age" filtering. I even wrote that I am excited about you implementing it.

I think you are trying to argue for cut & choose, but that is not the only way to do DE. We already have a technically sound solution for DE as stated.

I have also stated that the (innovative and clever but yet still economically) technically flawed cut & choose protocol variant might be acceptable if the user understands the risks.

With DE, let us accept your assertion that it will allow some attacker to reorg any chain at will to any depth, as I am sure I couldnt have solved an impossible problem with this post vs. the practical cost of setting it up. Even with this point asserted, I claim that DE provides a better environment as an attack event affects just that one coin, not ALL coins at the DE.

Seems to me the problem of financially incentivizing long-range chain reorganizations by enabling the attacker to steal coins from the 2 of 2 multisig, will infect every coin. Similarly to how Side chains devolves to the security of the weakest chain. However, a key distinction is that Side chains depend on a fungible one-to-one peg, so the catastrophe is much more pervasive because the failure isn't isolated to the participants to the exchange between chains but to the value of all the coins on the chains.

So unless the existing situation of aggregated CE dependency is better for altcoins without CLTV, the DE is an improvement.

Much better altcoins are forced to add CLTV and do DE correctly. Why encourage them to be lazy. Let them die with CE (centralized exchange) if they are too damn lazy to implement CLTV.

You do what ever you want, but you open Pandora's box. If you need to support Nxt, then I say go ahead. But generally supporting DE via the flawed cut & choose seems unsavory to me, but it is of course your decision.

[jl777]

I assume you mean writing some meta-data into the stronger block chain, that the weaker block chain could refer to as evidence. The hindrance is that decentralized block chains have no external reference point. There is no way to enforce that a particular block in one chain came before a block (nor within some # of blocks after a block) on another chain. Block chains are self-referential, and that is precisely why we need CLTV to implement decentralized exchange.

OK, so we are in agreement on most everything.

I want to better understand the above as it seems the main issue to prevent much stronger security. I apologize if I am asking kindergarten level questions on this, but I dont understand the external reference point impossibility. Please bear with me. I like concrete examples:

At noon, BTC block noon_txid appears. This is available to the entire bitcoin p2p network. At first it is a bit vulnerable to a reorg due to any pair of linked blocks would override it. After the next block, it would take 3 blocks to overtake, etc. So after 2 hours, we are past the timestamp variance and also have 10+ blocks protected by zillions of hashes.

ALL the altcoin chains can refer to this noon_txid. Let us call it noon_txid_inalt. I am pretty sure this is possible to do. And I am pretty sure that the presence of noon_txid_inalt proves that it came AFTER noon_txid. Please let us ignore odds of sha256 collisions.

In my previous post, I said bi-directional. So the BTC blockchain now gets the noon_txid_inalt and puts that into its blockchain (a bit past 2PM). call this the noon_altconfirm txid.

I claim that we now know that noon_txid happened before noon_txid_inalt which happened before noon_altconfirm txid. It looks like I can segregate blockchain events on different blockchains into definite categories of time ordering of "before" and "after"

What part of the above is insufficient to satisfy the requirements for the external reference?

James

[TPTB_need_war]

I assume you mean writing some meta-data into the stronger block chain, that the weaker block chain could refer to as evidence. The hindrance is that decentralized block chains have no external reference point. There is no way to enforce that a particular block in one chain came before a block (nor within some # of blocks after a block) on another chain. Block chains are self-referential, and that is precisely why we need CLTV to implement decentralized exchange.

OK, so we are in agreement on most everything.

I want to better understand the above as it seems the main issue to prevent much stronger security. I apologize if I am asking kindergarten level questions on this, but I dont understand the external reference point impossibility. Please bear with me.

Apologies in advance to readers that I will spew a lot of words about the phrase, "kindergarten level questions". I just feel awkward because I don't desire to measure myself or others that way. My intent is all about maximizing production (of myself and others). And I have weaknesses and commit lapses of logic (or insufficient research) sometimes/often.

I didn't mean to belittle anyone's sincere inquiries. Apologies if that seemed to be my tone upthread. To any degree that I felt frustration upthread, it was due to for example when someone conflates 'theory' with "highly abstract mathematical structural fact" and my frustration being not with them (for how can they understand my confidence in some insight if I don't explain it to them) because it is my problem if I am too low on energy or time to explain that distinction. Again it isn't the fault of another person that sometimes I am thinking/articulating in abstractions. And I don't make any claim about relative knowledge or capabilities (except to trolls and intentionally condescending people who deserve to have a mirror put in their face, which is not you James). I just tend to think in abstractions often, but not always (obviously I also think in terms of implementation and example cases otherwise I wouldn't have also written 100,000+ lines of commercially successful code as you have James). I just grow weary sometimes, because verbiage on forums has to repeated over and over for each person. I have 10,000+ posts already on this site. Lol. James your effort on implementing DE is worthy of my reciprocal effort (as you know I've told you that I hope your DE is available for the altcoin I am working on). Apologies the past few days have been exhausting/distracting/struggle for me as I alluded to about my health. Also I am reasonably burned out from too many posts on these forums over the past 3 years in contagion with the chronic health debacle/suffering I've been battling. Again apologies if I don't always communicate with perfect attention to apparent tone and with careful/optimum eludication.

I like concrete examples:

At noon, BTC block noon_txid appears. This is available to the entire bitcoin p2p network. At first it is a bit vulnerable to a reorg due to any pair of linked blocks would override it. After the next block, it would take 3 blocks to overtake, etc. So after 2 hours, we are past the timestamp variance and also have 10+ blocks protected by zillions of hashes.

ALL the altcoin chains can refer to this noon_txid. Let us call it noon_txid_inalt. I am pretty sure this is possible to do. And I am pretty sure that the presence of noon_txid_inalt proves that it came AFTER noon_txid. Please let us ignore odds of sha256 collisions.

In my previous post, I said bi-directional. So the BTC blockchain now gets the noon_txid_inalt and puts that into its blockchain (a bit past 2PM). call this the noon_altconfirm txid.

I claim that we now know that noon_txid happened before noon_txid_inalt which happened before noon_altconfirm txid. It looks like I can segregate blockchain events on different blockchains into definite categories of time ordering of "before" and "after"

What part of the above is insufficient to satisfy the requirements for the external reference?

There is no way to prove that the consensus of the weaker block chain placed those meta-data records in the stronger block chain. There is some meta-data, but it is meaningless, because consensus is the entire challenge of decentralized protocols that require consensus.

Off topic note that per the CAP theorem, Bitcoin forsakes Partition tolerance in order to achieve Consistency and Availability of consensus. You can think of the other block chain as being another partition. We've been discussing these abstract theoretical issues over in the Altcoin Discussion forum in threads such as The Ethereum Paradox, DECENTRALIZED crypto currency (including Bitcoin) is a delusion (any solutions?), and Satoshi didn't solve the Byzantine generals problem. Also include some discussions between monsterer, smooth, and myself in my vaporcoin's thread. So I have the advantage of a few months of discussions about these abstract topics.

[jl777]

There is no way to prove that the consensus of the weaker block chain placed those meta-data records in the stronger block chain. There is some meta-data, but it is meaningless, because consensus is the entire challenge of decentralized protocols that require consensus.

Off topic note that per the CAP theorem, Bitcoin forsakes Partition tolerance in order to achieve Consistency and Availability of consensus. You can think of the other block chain as being another partition. We've been discussing these abstract theoretical issues over in the Altcoin Discussion forum in threads such as The Ethereum Paradox, DECENTRALIZED crypto currency (including Bitcoin) is a delusion (any solutions?), and Satoshi didn't solve the Byzantine generals problem. Also include some discussions between monsterer, smooth, and myself in my vaporcoin's thread. So I have the advantage of a few months of discussions about these abstract topics.

So the issue is not time sequence, but the fact that it is hard to know if the weaker chain put the data in there as part of a consensus or as part of an attack?

If that is the issue, I am confused why we care so much about it? The metadata in the altcoin chain refers to the BTC data, so why does it matter who put it there? It either matches the BTC data or it doesnt. If it matches, it creates a verifiable time sequence. If it doesnt match, then it would be ignored. Could you make a simple example that shows how an attacker can bypass the BTC "clock" and double spend?

I dont think using bitcoin as the reference clock violates the CAP theorem as it defines the bitcoin data as definitive source of data, so Consistency is achieved, along with availability. [I dont want to get into whether bitcoin itself has done this or that with byzantine whatchamacallits]

Maybe to solve the Partition part, the metadata for the altcoin metadata needs to get back into the BTC chain. We are talking about a slow process, but even if it takes a day for all the back and forth, it seems that it isnt impossible. I just dont understand what exactly is needed.

Maybe it is like spontaneous creation of life from inert chemicals which is (nearly) impossible [please it is just an example, dont want to get into any creation/evolution debate either!], but once it is there, it is hard to stop it from replication. And kind of hard to deny that it exists. Since we now have bitcoin, maybe building on it allows to achieve the desired result (better altcoin security) without any violation of proven theorems by changing the problem.

James

P.S. CAP seems to vary from principle, conjecture, to theorem based on exact and precise definitions, I dont know if bitcoin is the exactly same behavior as in the proven CAP theorem, or if a bitcoin + extra is unable to change it to be beyond the confines of what is proven. I dont like to fight against math proofs, but if there is any level of abstraction in the proof then it is usually possible to "work around" it by transforming the problem to a different problem that isnt proven impossible. Since I am not trying to disprove the CAP theorem, but rather create a cross chain security mechanism that isnt covered by the CAP theorem proper

[TierNolan]

I don't want to repeat myself. You will destroy the security of the coin by enabling the hashrate attacker to steal other people's coins.

You mean that you could steal all trades that sell a particular altcoin by rewinding that altcoin?  That means that the altcoin probably has low hash protection. 

It is a good point though that rewind risk does need to be incorporated into the system.   The current implementation has steps that are zero-confirm, you wouldn't want to do that with high value trades.  It is slower, but worth it due to the higher risk.

A rule of thumb is that 1 block "costs" whatever the block reward is (inc fees).

At the moment, it costs 25 BTC to mine a bitcoin block.

You could set the minimum confirms to k * (trade_value) / (25 BTC).  The k parameter is some protection against multiple trades being attacked together.

With a k of 10, a 2.5BTC trade would have a min confirms of 1 block.  A 100 BTC trade would have a requirement of 40.

If the altcoin pays out 0.5BTC of value per block, then 50 confirms would be required on the altcoin.

This is an extra requirement.  There would be a minimum number of confirms, no matter how small the trade.

Since the fee can be done on bitcoin, which has strong protection, these confirms would be mostly for the altcoin confirm.

Another attack would be to stall the altcoin chain.  You could make blocks and push up the difficulty so it stalls.

I think these attacks mean that the altcoin is weakly protected already.  Even a centralised exchange could have problems.  They pay you in altcoins and the transaction gets rewound.  Having said that, they would probably refund the money.

They also do the "lots of confirms" thing.  For weak altcoins, exchanges require deposits to have lots of confirms.

[TPTB_need_war]

NXT PoS limits any reorgs to 720 blocks, so for NXT if the timeout is set above 720 blocks, then it will be beyond the reach of any attack.

That seems reasonable since checkpoints are required in PoS due to people selling their stake and then doing a long-range attack with stake they no longer own based on reorganization of historical transactions that create stake. Anyone who is buying NXT should hopefully understand the tradeoffs of a PoS system (centralized governance, advantage of less electrical consumption, my arguments against PoS in my prior post, etc).

It seems cut & choose with a fee is an appropriate DE protocol for any proof-of-stake coins with frequent checkpoints (that don't support CLTV), which in NXT's case appears to be enforced by nodes that are always online and can form objective reality from the chain they've seen while being online. In other words (an issue which we have discussed and identified in the linked threads I mentioned in my prior post), NXT's 720 block rule is ambiguous to nodes who've recently come online (they don't know which chain was first to appear and can be lied to by a node that has always been online, i.e. propagation is not objective reality to offline nodes), but afaik with proof-of-stake typically there are a more permanent set of nodes (dictators or elected delegates in Bitshare's DPoS) who control the chain, i.e. the coins are essentially centralized. Yesterday monsterer pointed out how PoS can be controlled with even less than 50% of the hashrate, so kudos to monsterer for articulating our prior insight with more clarity on the weakness of PoS.

So an imperfect DE protocol is arguably appropriate for an imperfect deCentralized consensus algorithm. Seems befitting and allows you James to monetize your work, since PoS coins are still quite popular for the time being (and with hubris I will joke that they will need DE to trade for my superior consensus algorithm invisible vaporcoin).

So what I am saying is I think you can monetize. I don't know how to monetize with the dual CLTV technically sound protocol (with my suggested "coin age" filtering improvement to squelch jamming attacks), as it seems to not require a fee.

Cut & choose seems to be inappropriate for proof-of-work coins due to the longer-range lie-in-wait rented hashrate attack on the probabilistic longest-chain-rule (LCR), unless they too are essentially centralized and have some frequent checkpoints generated by some form (either concentrated hashrate in always online nodes/pools that enforce checkpoints or lead developers who release checkpoints frequently) of centralized control.

[TPTB_need_war]

The reference points are provided by my upthread "Coin Days Destroyed"["coin age"] suggestion a few days ago and the point yesterday in this thread about hard-coding the destination addresses in the CLTV. In order words, those reference points do not depend on future confirmations, but are past history (the age of the UXTOs being spent) and future invariants (the hard-coded destinations).

Although the "coin age" reference points are not absolute, i.e. could be rewritten by a chain reorganization attack, this will not reduce the squelching effect on a jamming attack, because that hashrate attack costs electricity (in PoW) and with the dual CLTV DE protocol, the attacker is not reimbursed.

The hard-coded destinations of a dual CLTV DE protocol obviously can't be altered by any hashrate attack so thus are absolute reference points.

[TPTB_need_war]

There is no way to prove that the consensus of the weaker block chain placed those meta-data records in the stronger block chain. There is some meta-data, but it is meaningless, because consensus is the entire challenge of decentralized protocols that require consensus.

Off topic note that per the CAP theorem, Bitcoin forsakes Partition tolerance in order to achieve Consistency and Availability of consensus. You can think of the other block chain as being another partition. We've been discussing these abstract theoretical issues over in the Altcoin Discussion forum in threads such as The Ethereum Paradox, DECENTRALIZED crypto currency (including Bitcoin) is a delusion (any solutions?), and Satoshi didn't solve the Byzantine generals problem. Also include some discussions between monsterer, smooth, and myself in my vaporcoin's thread. So I have the advantage of a few months of discussions about these abstract topics.

So the issue is not time sequence, but the fact that it is hard to know if the weaker chain put the data in there as part of a consensus or as part of an attack?

If that is the issue, I am confused why we care so much about it? The metadata in the altcoin chain refers to the BTC data, so why does it matter who put it there? It either matches the BTC data or it doesnt. If it matches, it creates a verifiable time sequence. If it doesnt match, then it would be ignored. Could you make a simple example that shows how an attacker can bypass the BTC "clock" and double spend?

Because the altcoins are not confirmed spent on the Bitcoin block chain. The altcoin chain is free to disagree with the Bitcoin block chain.

The point about relative ordering of blocks between two chains (i.e. two partitions) is relevant to why it is impossible to enforce that the altcoin chain must follow the Bitcoin block chain's consensus. If you think out how you would attempt to specify a protocol for the altcoin chain so that it must obey the Bitcoin consensus, you will soon realize that it is impossible because no external truth exists in a block chain.

I dont think using bitcoin as the reference clock violates the CAP theorem as it defines the bitcoin data as definitive source of data, so Consistency is achieved, along with availability. [I dont want to get into whether bitcoin itself has done this or that with byzantine whatchamacallits]

Maybe to solve the Partition part, the metadata for the altcoin metadata needs to get back into the BTC chain. We are talking about a slow process, but even if it takes a day for all the back and forth, it seems that it isnt impossible. I just dont understand what exactly is needed.

Maybe it is like spontaneous creation of life from inert chemicals which is (nearly) impossible [please it is just an example, dont want to get into any creation/evolution debate either!], but once it is there, it is hard to stop it from replication. And kind of hard to deny that it exists. Since we now have bitcoin, maybe building on it allows to achieve the desired result (better altcoin security) without any violation of proven theorems by changing the problem.

James

P.S. CAP seems to vary from principle, conjecture, to theorem based on exact and precise definitions, I dont know if bitcoin is the exactly same behavior as in the proven CAP theorem, or if a bitcoin + extra is unable to change it to be beyond the confines of what is proven. I dont like to fight against math proofs, but if there is any level of abstraction in the proof then it is usually possible to "work around" it by transforming the problem to a different problem that isnt proven impossible. Since I am not trying to disprove the CAP theorem, but rather create a cross chain security mechanism that isnt covered by the CAP theorem proper

Sorry but you will need to read and understand deeply the threads I linked to. We've analyzed this already and it is an inviolable mathematical structure.

[TierNolan]

Gmaxwell just released a system for committing to an information exchange.

https://bitcoincore.org/en/2016/02/26/zero-knowledge-contingent-payments-announcement/
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012471.html

I think that solves the exchange problem.  In the article, they say it takes around 20 seconds to build up the proof for 5 SHA256 operations.  

In the zero knowledge proofs, you can prove that you ran a program.  The program of interest here would be

Code:

boolean check(byte[] bob_priv_key) {
    if (computePublicKey(bob_priv_key) != BOB_PUB_KEY) 
        return false;

    if (computeHash160(bob_priv_key) != BOB_PRIV_KEY_HASH)
        return false;

    return true;
}

Bob could send Alice {BOB_PUB_KEY, BOB_PRIV_KEY_HASH, <proof>} and Alice could check that the proof proves that the program was run correctly and that it returned true.  It's a zero-knowledge-proof, which means that it gives Alice no info about bob_priv_key, but proves that Bob knows an input into the program that will get it to return true.

Since elliptic curve calculations are more complex than hashing operations, I think it might not be viable, but would work in theory.

[Edit]
Gmaxwell suggested using one of the schemes from here.

[Edit2]
The lightning dev list has some discussions about an opcode for checking public/private matches.  They call it CHECKPRIVPUBPAIR rather than CHECKPRIVATEKEYVERIFY.

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011827.html

[TPTB_need_war]

Gmaxwell just released a system for committing to an information exchange.

https://bitcoincore.org/en/2016/02/26/zero-knowledge-contingent-payments-announcement/
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012471.html

I think that solves the exchange problem.

Indeed I predicted that

But credit gmaxwell's Coin Witness thread for making me aware of the SNARKs technology in 2013.

Generalized scripting is going to open up 51% attack vectors that didn't exist in a more pure crypto currency usage of a block chain:

I didn't intend to post in this thread again, but seems I remember Monero would soon add multi-sig, and I wanted to make you aware of a potential 51% attack hole enabled by multi-sig:

https://bitcointalk.org/index.php?topic=1364951.msg14002317#msg14002317

I don't know how many of you read the post linked in the above quote, so I wanted to again draw attention to this insoluble problem for scripting on a block chain.

Scripting opens a Pandora's box that destroys the normal security model for block chains. This is more damning than the problem of needing to centralize verification of scripts, because afaics it is entirely insoluble (unless you centralize authorization of which scripts are allowed to run).

The only possible solution I can think of is to make all scripts run as zero knowledge black boxes so that the miners are unable to see any of the data in the block chain.

The only way to do this is zk-snarks. Remember I wrote in 2014 that I thought zk-snarks were essential for block chain 2.0 smart contracts.

[TPTB_need_war]

You could set the minimum confirms to k * (trade_value) / (25 BTC).  The k parameter is some protection against multiple trades being attacked together.

You'd have to base these thresholds on a computation of how many other DE are operating on the same blocks, but then an attacker can DE trade to himself to fool your algorithm into an unbounded value of k (as high as the attacker wants to make it).

There are no solutions like that. The only solution is don't use cut & choose except where checkpoints are trusted, or develop the zero knowledge black box solution.

[TPTB_need_war]

[Edit]
Gmaxwell suggested using one of the schemes from here.

Oh that reminds me what I meant to write in this thread when I woke up this morning but I got sidetracked.

The reason we can't allow Bob to sign instead of revealing his private key in order to reclaim his deposit, is because then the payments in the protocol can only be made contingent on revealing the private key. There is no way to put the deposit first on the block chain yet also have signing it require also signing the other transactions in the protocol, because those "other transactions" are not yet in the block chain when the deposit is confirmed (thus the deposit can't refer to transactions which are not yet confirmed as this would either be a security hole or would be impossible to pre-hash since the transaction paying Bob from Alice is not committed to a destination address).

[TierNolan]

There are no solutions like that. The only solution is don't use cut & choose except where checkpoints are trusted, or develop the zero knowledge black box solution.

The attack is more general and it doesn't specifically attack the cut-and-choose system, I think.

- Offer to sell A altcoins for B Bitcoins to 1000 people
- Perform the atomic trades
- You now have 1000*B Bitcoins and lost your A altcoins
- Victims made sure there was 10*A worth of hashing confirmations on their transactions before moving to the next step
- You spend 50*A altcoins to buying hashing to rewind up to 50*A worth of blocks, which is more than their protection
- This rewinds history and your 1000*A altcoins are now yours again

A defense against this would be to mark the multisigs that are being used as anchors.  Rather than 2 of 2, you could use 2 of 3 with the 3rd key being a standard value.

You can then set k based on how many trades are happening on the altcoin chain.

As long as cross chain transfers are much smaller than real transfers, then this is less of a problem. 

[TPTB_need_war]

A defense against this would be to mark the multisigs that are being used as anchors.  Rather than 2 of 2, you could use 2 of 3 with the 3rd key being a standard value.

You can then set k based on how many trades are happening on the altcoin chain.

Attacker can make anchors for nearly free (large transaction values relative to transaction fees):

...but then an attacker can DE trade to himself to fool your algorithm into an unbounded value of k (as high as the attacker wants to make it).

[jl777]

A defense against this would be to mark the multisigs that are being used as anchors.  Rather than 2 of 2, you could use 2 of 3 with the 3rd key being a standard value.

You can then set k based on how many trades are happening on the altcoin chain.

Attacker can make anchors for nearly free (large transaction values relative to transaction fees):

...but then an attacker can DE trade to himself to fool your algorithm into an unbounded value of k (as high as the attacker wants to make it).

What is the method of attack if peers limit the amount of trades to the total fees paid by an address? other than some small amount for newbie accounts.

Wouldnt that require the attacker to conduct all attacks simultaneously using properly aged UTXO? Or are we assuming arbitrary depth of reorging the altcoin is available to attacker to deploy at anytime? Since the attacker wouldnt get the BTC until the trades complete, it seems he would have to borrow the BTC to buy the hashrate. And if an altcoin can be rewritten at will with the attacker's existing resources, what secures that chain without atomic swaps?

I guess the probability of successful attack creates some expected value, but I am having a hard time correlating the hashcosts for coins with decent trading volumes and the likely number of open trades at any given time. If the success of attack is not 100%, then that raises the risk of lost capital. I think realistic cost estimates are needed to attack the various chains and compare it to trading volume and amount of time that would be at risk

James

[jl777]

Some practical estimates:

Most top 100 bitcoin compatible altcoins trade a total of $1000 to $25000 per day, some get a lot more volume but usually it is due to CNY trading. The second 100 ranked trade $5000 or less as a guideline.

The CE risk is that 100% of all funds for all coins and in this aspect, even if it the only aspect, makes the DE much safer to trade. http://www.coindesk.com/court-cryptsy-ceo-predicted-exchange-failure/ vs blockchains to see where all the funds are. just the open disclosure would make DE superior, even if DE had all the same risks as CE. But I argue that DE risk is dramatically less due to the fragmenting of the funds across all coins. Also, the attacker is only able to make money by selling altcoins for BTC en masse to a lot of buyers which is quite a bit harder than the reverse

Let us say an exchange DE or CE gets 10% of the trading market and roughly $100,000 per day is traded. This would translate to a lot more on deposit, hard to estimate what percentage of trades are vs amount on deposit, if it is 10:1, then that means $1 million is at risk at this CE, all the time, from reorg attacks like DE and many other attacks and internal theft and simply flight of owner.

Now the DE, let us assume 100% of a coin is at risk, it is $2500 in this context. But actually it would be just the trades that are pending and if average trades complete in one hour or so, it might be $100.

With a budget of $100 or even $2500, I am having a hard time seeing that it would be a cash positive expectation if the process isnt fully automated. Even with a fully automated system, the cost to rent hashrate varies in realtime based on supply/demand and it is not like you can buy arbitrary amounts at a fixed cost.

My feeling is that like the cut and choose itself, it is all about positive expected return from conducting the attack and opportunity cost. Unless attacking the DE offers positive expected ROI, it is the same thing as saying someone can attack cut and choose and continue to lose money.

Can you estimate the hashrate it would take to attack some middlemarket coin,or rather, what coin could be attacked with a $2500 budget? Wouldnt the attacker need to pregenerate the blocks ahead of time? if so, there is a very big risk of not being able to make the trades to take advantage of this alternate chain. or can he wait until he has all the trades pending, then buy the hashrate, hope he is able to build a stronger attackchain with his double spends, then complete all the swaps, push the attack chain to reverse the altcoin payments.

Now he gets back the altcoins used for the trade, which had to be of equal value to the BTC gained, so he is stuck with altcoins for a chain that got attacked. maybe that will cause it to lose value and add more risk.

There seem to be quite a few "ifs" that all have to work out and the reward is 5BTC, not any 5000 BTC. So this seems an attack scenario for the financially challenged attacker, unless I am dramatically overestimating the cost to conduct the attack.

James