Pegged Sidechains [PDF Whitepaper]
<< < (14/23) > >>
securedolphin:
Quote from: cjp on October 24, 2014, 10:13:01 PM

The paper suggests creating a new opcode.
Isn't it, by pure accident (I assume), also possible to do it with existing opcodes, along the lines of my proposal here?:
https://bitcointalk.org/index.php?topic=819901.0
https://github.com/cornwarecjp/amiko-pay/blob/master/doc/pay%20with%20blockchain%20knowledge.md

I'm not saying that my approach is necessarily better: one obvious disadvantage is that it's a monstrous script (but then, opcodes only take a single byte of storage). I'm just saying it might be an option to be considered.


From what I understand, there is general aversion to OP_CAT due to inherent vulnerabilities that are hard to contain in the script interpreter (potential stack explosion). It may be safer and simpler to introduce an OP_FIND instead. OP_FINE would A better option may be to re-code your transaction with something like OP_FIND -1 if the substring is not found or the index of the beginning if it is. The return value will be numeric, i.e. CScriptNum type.

If OP_FIND was available and OP_HASH256 variant that would take two arguments rather than one, it would be possible to code p2sh transaction to validate headers of alternative chains. Here is an example for NameCoin. This is just an illustration of the concept. It is likely not to cover all possible malicious inputs.

Input:
<push merge mined header> <-- This is a header that does not satisfy BitCoin difficulty but is good enough for alt chain(s)
<push merkle hashN>,
<push merkle hashN-1>,
..
<push merkle hash2>,
<push merkle hash1>,
<push the merkle root of merge mined chain headers> <-- Obtained through getAuxWork from alt chains or through some other means.
<push the merge mined coinbase> 

Script:
OP_TUCK                          //// Save the merge mining coinbase for subsequent check for inclusion in the merge mined block
OP_FIND                          //// Check that the merkle root of merge mined chain headers is in the coinbase, i.e. that this is indeed a valid proof of work
-1
OP_EQUALVERIFY             //// Exit if the merkle root of side chains is not present in the merge mined coinbase
OP_HASH256_2               ////  Compute HASH256(<merge mined coinbase>, <merkle hash1>), i.e. move up one level in the merkle tree of transactions
OP_TUCK                        ////  Save the result to save it for computation of the next level if needed.
OP_EQUAL                      ////   If the result is equal to the next item then we've reached the top of the merkle tree and it is valid
OP_IF
OP_TRUE                        ///    Push TRUE and do nothing else - essentially finish the script with TRUE
OP_ELSE

OP_HASH256_2               ////  Compute HASH256(<merge mined coinbase>, <merkle hash1>), i.e. move up one level in the merkle tree of transactions
OP_TUCK                        ////  Save the result to save it for computation of the next level if needed.
OP_EQUAL
OP_IF
OP_TRUE
OP_ELSE

OP_HASH256_2               ////  Compute HASH256(<merge mined coinbase>, <merkle hash1>), i.e. move up one level in the merkle tree of transactions
OP_TUCK                        ////  Save the result to save it for computation of the next level if needed.
OP_EQUAL
OP_IF
OP_TRUE
OP_ELSE

...

...

OP_HASH256_2               ////  Compute HASH256(<merge mined coinbase>, <merkle hash1>), i.e. move up one level in the merkle tree of transactions
OP_TUCK                        ////  Save the result to save it for computation of the next level if needed.
OP_EQUAL
OP_IF
OP_TRUE
OP_ELSE

OP_ENDIF   ///
OP_ENDIF   ///
OP_ENDIF   /// Close all IF blocks
OP_ENDIF   ///
OP_FALSE   //// Merkle tree is invalid


Obviously this won't work if the merkle tree is deeper than the number of check blocks. However, that shouldn't be a concern as very deep trees can be accommodated withing the 520 byte script size limit.

Both, OP_FIND and OP_HASH256_2 produce fixed size input, which make them safe from the perspective of causing potential memory/stack explosion.
johnyj:
I stopped reading when I see the word IOU in the white paper ;D
brg444:
Quote from: cypherdoc on November 04, 2014, 06:24:16 PM

maybe. but i'm just going along with what's being advertised here.  a well vetted, tested SC thru a federated system that is then brought online as a Bitcoin linked SC is "unlikely" to fail.  given that, the 2wp is acting like a risk free put.  maybe a call is a better term, i don't know.  but then, my question about manipulation still stands unanswered.  to assume a stable 1:1 price relationship of BTC to scBTC seems naive i think.  there's always volatility and we see signif disparities btwn exchanges today that fluctuate sometimes wildly.


No it is not naive and Adam has explained exactly why. The peg being algorithmic, it creates even more efficient arbitrage. There are very good reasons for why the 1:1 price exchange will remain stable. You need to propose a reason why it will not because from my point of view and many others here it is clear as day.

Quote from: adam3us on November 04, 2014, 11:31:42 AM

Clearly given that this is the best case confirmation time for bitcoins, and the peg protocol is algorithmic there will be effectively ZERO spread, because the algorithmic peg is an unlimited standing offer at parity (plus per KB fees) and is in direct competition to any market offer, and rational actors take the lowest offer.

...

One can look to other bitcoin arbitrage scenarios for a hint at how it works.  Look at the spread between btc-e & bitstamp now that multiple people are systematically arbitraging it.  That is a far riskier arbitrage because you are relying on governance and security management of bitstamp & btc-e in the face of 50% failure rate of bitcoin exchanges.  Ok these ones are survivors and better than full history average no doubt but still there is non zero risk there and yet the spread is basically 0, this is because of competition amongst arbitrators.  Compare to a 2wp, where there is an algorithmic arbitrage.  A bot can take that all-day long at zero risk (using smart-contracts).


Quote from: cypherdoc on November 04, 2014, 06:24:16 PM

true, it's into the future.  but how far?  there will be a transition point and if a risk free put (on BTC) exists today, why not move a major portion of your BTC to the SC today and leave it there? 


2140 is how far. Until then, block subsidy will entice miners to stay on the mainchain. Meanwhile they will merge mine any sidechain that will gain significant traction and value AND the mainchain. Your argument about smaller miners losing money and mining only the sidechain holds no ground. First smaller miners will soon be extinct and as long as the most important majority of the mining power does not defect there is no danger for the mainchain.
Boussac:
Quote from: laurentmt on November 04, 2014, 08:37:00 PM


Well, seems better to wait for answers from the experts.

Still waiting. The way this fungibility issue is ignored in this otherwise awesome white paper is puzzling with so many bright minds as co-signers.

I assume for simplicity a 1:1 peg between bitcoin and sidecoin.
Perfect fungibility would mean I can redeem any set of unspent outputs totalling one sidecoin on the sidechain to release any locked bitcoin on the blockchain.

To illustrate this notion, suppose there is perfect fungibility and the sidechain is used as a mixer for the blockchain.
I assume for simplicity a 1:1 peg between bitcoin and sidecoin.

"Dirty" BTCs are transferred to the sidechain and come back clean as sidecoins but with a 10% laundering fee: in the off-chain market  I can only get one sidecoin for 1.1 BTC because I would need 1.1 BTC to get a clean sidecoin in a sidechain transaction.
The point is  that, with fungibility, the spread between the pegged rate and the market rate can be significant.

I could have taken any example where the function of the sidechain requires fungibility and commands a transaction fee.
Transaction fees on a sidechain are not necessarily market driven because of market imperfections.
Therefore fungibility is an important design parameter for sidechains.
Luke-Jr:
Quote from: Boussac on November 05, 2014, 03:18:24 PM

Quote from: laurentmt on November 04, 2014, 08:37:00 PM


Well, seems better to wait for answers from the experts.

Still waiting. The way this fungibility issue is ignored in this otherwise awesome white paper is puzzling with so many bright minds as co-signers.

I assume for simplicity a 1:1 peg between bitcoin and sidecoin.
Perfect fungibility would mean I can redeem any set of unspent outputs totalling one sidecoin on the sidechain to release any locked bitcoin on the blockchain.

To illustrate this notion, suppose there is perfect fungibility and the sidechain is used as a mixer for the blockchain.
I assume for simplicity a 1:1 peg between bitcoin and sidecoin.

"Dirty" BTCs are transferred to the sidechain and come back clean as sidecoins but with a 10% laundering fee: in the off-chain market  I can only get one sidecoin for 1.1 BTC because I would need 1.1 BTC to get a clean sidecoin in a sidechain transaction.
The point is  that, with fungibility, the spread between the pegged rate and the market rate can be significant.

I could have taken any example where the function of the sidechain requires fungibility and commands a transaction fee.
Transaction fees on a sidechain are not necessarily market driven because of market imperfections.
Therefore fungibility is an important design parameter for sidechains.

Can you come up with an example that is plausable? Having a hard time following enough to figure out what the actual question is...
Navigation
Message Index
Next page
Previous page