Topic: Pegged Sidechains [PDF Whitepaper] - page 4. (Read 14558 times)

Yes, but BTC-via-SC1 and BTC-via-SC2 would be different assets on SC3.
Although you can treat them identical if you want to (ie, if you trust SC1 and SC2 equally).

Is it possible to get this kind of architecture ?

If, on a normally functioning sidechain, a 'whale' decides to arbitrarily inflate the price of sidechaincoin (SCC) by buying up the order book on some exchange platform, so that let's say SCC are temporarily trading at 1.3 BTC / SCC on said exchange, any existing holder of SCC will simply sell their SCC for BTC, realising the 30% risk free profit (arbitrage), and then if desired, transferring those 1.3 BTC back to 1.3 SCC (because there is an algorithmic peg enforced at the cryptographic level that allows you to make this transfer - you do understand that this is the concept, right?). There is no put or call here, there is just arbitrage.

The principle of no arbitrage gives you the approximate stable price - 1 to 1. Any delta from that is due to second order effects of the type that Back refers to in the above post. Only in cases of catastrophic failure would there be a large divergence (and that's OK too, because "joining" a sidechain is entirely voluntary), and such an eventuality can only be temporary (either the sidechain 'crashes' entirely, or it comes back into quasi-equilibrium).

There seems to be some confusion about floating rates, sidechains are algorithmically pegged not floating.

Lets try a thought experiment.  Say you can directly move a bitcoin to a sidechain or move it back to the mainchain with either direction taking 10minutes and normal bitcoin fees.

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.

Now we introduce the concept of time-preference.  For security reasons (rather similar to coinbase maturity which sees you unable to spend freshly mined coins for 100 blocks) the algorithmic peg has a time-delay.

Now if you planned to hold anyway for that period or longer, then you dont care and the situation is unchanged.

But if you want to do a sidechain BTC transaction faster, you swap it for a small premium with someone who already has BTC on the sidechain and is planning to long term hold, or swap with someone trying to go the other direction.  What you pay them will be small due to the mechanics of arbitrage.  They'll just look for some small fee because to them if they're already long term BTC holders its basically free money, like interest on BTC to move funds back and forth and provide liquidity service for sidechains.  The $ exchange rate is immaterial, the best candidate for sidechain liquidity provider is someone who is anyway holding their own or other peoples BTC for long term storage.

Anyone who tried to sell  BTC on one chain for a lower than time-preference cost on another chain would just lose money.

I think the above logic and economic concept & precedent is extremely simple.  It seems like some people misunderstood Konrad Graf's comments, he's just talking about the mechanics of the low arbitrage spread.

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).

The remaining non-imaginary risk is side-chain implementation defect, but the point of side-chains is to allow experimentation on new features to occur outside of bitcoin core.  This is actually a good thing for bitcoin core's risk because it doesnt have to take as much new development risk itself.  Sidechain development will also be rigorous like bitcoin, and you should look at the reputation of the authors of the sidechain you are considering using and have others review it or certify it before you dump your lifesavings into it.  You can still do long term holding on bitcoin if you prefer, and benefit from the even lower than current mainchain risk.

The current pattern in bitcoin infrastructure is most transactions are offchain (in exchanges and other offchain accounting).  Much of that code is not open, or inexpertly written or relying on firewalls and host security and hot wallet ratios plus you're vulnerable to governance failures, operator theft and or blackmail.  Most bitcoin lost to date has been for these reasons.  If, using sidechains, we get more innovation and more onchain transactions, its better to be onchain in a sidechain than offchain from bitcoin.  You dont even own bitcoins offchain, you have an IOU for a bitcoin from a human who typically has no banking governance nor operational security experience, though with better capitalization and management things are improving.

I would think more transactions, more transaction types and more uses for bitcoin, and faster innovation on bitcoin and more onchain transactions and zerotrust/smart-contract based infrastructure are all positive things for bitcoin, and it seems to be that most people with a technical understanding hold the same view.

Its not that a sidechain displaces bitcoin hypothetically and that this is bad; a sidechain is bitcoin, its the mechanism to internetwork bitcoin, to build on it.  Sidechains no more displace bitcoin than HTTP displaces the TCP and IP protocol it is transported on.  Alt-coins and alt-shares are in nominal competition with bitcoin, though it seems highly unlikely they would catchup with bitcoin's network effect nor reach an appreciable real-life usage; but sidechains are not in competition.

Bitcoin has one advantage over sidechains - it has the subsidy, and full node security, so I'm sure it'll be able to defend itself against abandonment or insecurity, and sidechains depend on bitcoin anyway so all bitcoin users on which ever chains have a meta-incentive to see bitcoin main remain secure.   We have decades of subsidy ahead to deal with fee-only security for bitcoin, and sidechains may move forward the ways to do that because the sidechain by default has only fee security from the start.

Anyway one potential use for a sidechain is to host a beta for a major new bitcoin version.  If that version after say $1b value running in it for a year, gets upgraded into bitcoin, that hasnt displaced bitcoin, its facilitated its feature and performance upgrade, which is a good thing for everyone.

The exciting thing about the internet wasnt just the ability to send IP packets, but all the applications and permissionless innovation that could be built using that transport.  Same for bitcoin.

Adam

actually, i had a whole new thread post describing this attack written and prepared to put up on Sunday but decided to have Melbustus look at for review.  we had been discussing it back and forth when i saw your post mentioning a whale on the plane coming home Monday.  i didn't respond to you at the time b/c i've been thinking about it alot and changing it up (as you can see from the detail described in my thread and the concept of a risk free put).

not that it matters.

Good idea. The "use fee" could be reversible, like a deposit. That way, normal users are not penalized.

Being the guy who first (to my knowledge) proposed this nature of attack, I'll just say that the first thing which comes to mind would be some sort of progressive use fee on the sidechain itself somehow.  I anticipate using primarily sidechains that impose some sort of a use cost (even if there are options) mostly because they they can be used in a variety of healthy ways.  As always, if the sidechain is not a transparent box I'm not playing.

Actually, the attack I was thinking of was your simplistic form applied in such a way as to produce a resonance.  The normal engineering method of dealing with such issues is to introduce some method of dampening.

What are the chances that a side chain becomes the dominant chain?  To answer this, we need to determine at what point miners will likely point more processing power at the side chain than at the main chain.  At this point, the side chain will be more highly secured by processing power than the main chain and the side chain can be considered dominant over the main chain.  So at what point will the reward for mining the side chain be higher than the reward for mining the main chain?

Currently, the average tx fee per transaction is roughly 0.0002 and the average tx fee reward per block is roughly 0.1 btc (I can show how I calculated this and/or show sources if needed).  The current block reward for newly created coins is 25 btc.  The side chain will have to achieve a reward of greater than 25 btc per block to overtake the main chain (I did not include the tx fee reward because this is currently negligible and will likely be negligible if a side chain has many more txs.  Also, this is a conservative estimate).  To achieve a reward of greater than 25 btc per block, the side chain will have to generate 125,000 txs per block (25/0.0002) assuming tx fees on the side chain are equal to tx fees on the main chain (these fees will likely be lower but this is a conservative estimate).  Therefore, the rate at which the side chain overtakes the main chain is 208 txs per second.

This estimate also does not take into account the possibility that the side chain can issue a secondary coin as a block reward, which can further reduce the number of transactions needed to overtake the main chain.  Also, halving of the bitcoin block reward over time will reduce the number of transactions needed to overtake the main chain.  With discussion of side chains being used for everyday transactions and bitcoin being used for long-term storage, I can see this overtaking as a real possibility.

There are a few assumptions about future conditions in this analysis.  However, at current rates and with the only assumption being that side chain tx fee rates = bitcoin tx fee rates, then the side chain will need to achieve a tx rate of roughly 200 txs per second to overtake bitcoin in terms of processing power through miner arbitrage. 

Also,
when side chain tx fee rates  = 50% (0.0001) of bitcoin tx fee rates:  bitcoin overtaken @ 400 txs per second
when side chain tx fee rates  = 10% (0.00002) of bitcoin tx fee rates:  bitcoin overtaken @2000 txs per second (roughly that of visa and mastercard)

When the block reward eventually drops to 0, then the side chain will only have to generate more tx fees than bitcoin to become the dominant chain. 

Please point out the flaw in my logic.


tl;dr
Roughly, the point at which a side chain can overtake bitcoin as the dominant chain at current rates is 200 tx/sec.

I haven't read all yet but the paper looks very interesting. Would the network get any slower with say 50 sidechains?

This is the bit that I don't really agree with (or don't understand properly). The hashpower to block a proof and the hashpower to successfully use a false one will only add up to 100% if the bitcoin client knows the current greatest proof of work on the side chain.

 The parent chain won't be monitoring all nodes of all side chains because this would be too burdensome on the bitcoin nodes so it won't always know the longest proof of work chain on the side chain. This will reduce the percentage of hashpower needed to double spend.

 Say I try to double spend a coin on the side chain by redeeming it to the parent chain and spending it on the side chain. A block is found with my transaction redeeming it to the parent chain so I produce this to the parent chain with an spv proof and the contest period begins.
 Now this block is orphaned and my other transaction, spending on the side chain is valid.

 Somebody supplies the block chain with details of the re-org and it now invalidates my transaction redeeming to the parent chain. Now my question is do I have from now until the end of the contest period to try and better this re-org proof? If so I am not trying to better the length of proof of work on the side chain at the end of the contest period, I am trying to better the length of the sidechain proof of work at the time the re-org proof is submitted. I have the whole of the contest period to work away building a proof of work that includes my transaction redeeming the coin to the parent chain but I don't have to beat the longest side chain proof of work I only have to beat the proof of work when the re-org was submitted. Then just before the contest period ends I submit my re-org and validate the transaction redeeming the coin on the parent chain that has been spent on the side chain.

 Or does the redemption transaction have to be re-submittted to the parent chain if a re-org is submitted and the contest period starts again? (but then maybe bad actors could submit false re-orgs to cancel redemptions because the parent chain doesn't know the current longest side chain pow)

 I'm also concerned that checking the re-org proofs for all side chains would be an extra burden on the parent chain nodes.

 Anyway I realise that many of these details might still be being worked out by the designers or have been considered and aren't an issue.
 Also I might be completely misunderstanding it.

 I don't think that any of these problems could not be overcome and I think side chains are a great idea, I'm just trying to analyse where weak points might be  (because this will definitely get analysed by people trying to beat the system anyway) and improve my understanding.

 

It's a sidechain parameter; see sidechains.pdf section 6.1 (page 16, line 479-480).
Yes, they can have that.

The sidechain's consensus is always a simple majority balance like Bitcoin (unless someone invents some other algorithm) - the 66% requirement applies only to transfers out of it.

Wait where did that 66% come from? You mean that a sidechain can have a completely different consensus system where the larger chain is beign somehow decided by more than 66% of the total hashing power?

Thanks for the replies. I guess I was thinking that for a blockchain to be part of the sidechain experiment, it would probably be helpful to have many active users and hopefully not be dominated by large mining ventures?

For some reason, some people seem to have the misconception that a 51% attack is holding 51% of bitcoins.

Conceivably, but the Donkey-blockchain must have been created with a higher-than-50% limit on what an attacker would need to steal.
It's a tradeoff against censorship risk: So, in one example, the attacker might need 90% to steal, but then he only needs 10% to censor return transactions.

Yes, what else could it mean? 
So that could mean BTC could conceivably be stolen, as BTC could be pegged in the "Donkeycoin" blockchain?