Topic: Sidechain Technical Feasibility Discussion - page 3. (Read 13976 times)

It's not inflationary because the value of spin-off foocoin is already incorporated in the value of bitcoin. Bitcoin (pre-spin-off) = bitcoin (ex-spin-off) + foo coin.  

This does not mean that foo coin couldn't possibly replace bitcoin or even possibly (though the prevailing view seems to discount this) co-exist alongside bitcoin. In this sense I don't agree with Peter R that the process is non-threatening, to the extent that your allegiance is to ex-spin-off bitcoin as opposed to pre-spin-off bitcoin), but in and of itself the spin-off process is not inflationary.

I don't think it serves the same purpose as side chains though.

Correct.  To put some numbers on that, the namecoin chain is currently about 4GB of data, and its mined by >80% of Bitcoin's hashrate.

Though I'd like to see something deployed that didn't force merged mining. I think having the flexibility to do other things is good.

Whats interesting now that this has had some press coverage is that people have piped up and pointed out places where they'd invented substantially similar things in the past. So we're now up to ~5 independent inventions of the core idea... perhaps a good sign.

What you propose is creating competing systems with their own redundant supply of coins. I am boggling that you call it non-threatening (what do you think people holding those coins will do as the ownership of them diverges from Bitcoin? Sit idly while their coins remain worthless because people are using Bitcoin instead of it? ... No, they're going to go out and tell people to accept their Foocoins instead and suggest that old bitcoins will soon be worthless) and non-inflationary.

It may be a useful thing to do, especially as a promotional method— for someone who already was convinced they wanted to create a new currency...  but it doesn't address the issues that the sidechain idea hopes to address, including giving people the freedom to choose to use new transaction processing systems as they see fit without the loss of network effect and adoption dillution that comes from having to choose to accept a whole different currency.

no but good observation: they could prevent the coins from being spent, including being spent back into the main chain. 

PS, in case you don't know, in general a 51% attack can't steal coins.  But they can claim EVERY block reward which is what happened to CoiledCoin.  For alt-coins that have block rewards that could be seen as a problem.  For the proposed merged-mined sidechain implementation, there is no block reward so nothing to claim.

So miners who 51% the side-chain can steal coins?

IF and WHEN we figure out whether this is even possible THEN we can debate its merits.  Before that significant debate seems premature... or feel free to go start another thread.  I was hoping to discuss technical feasibility here.  I will change the title.

these kinds of proposals are not covered by consensus and will not get implemented, I'm sure. you can't just upgrade, there are plenty of stakeholders which have to agree.


who cares about the opinion of one person. that's not how a market economy works.

@peter r: Spin-offs is a good idea, in fact it may be mine.  I posted it on the other forum on March 26 as a way to handle adding multiple currencies to bitcoin if the core devs would not add it.  But please do not sidetrack this discussion into it.

WRT transaction capacity:

The Satoshi scalability model gets us somewhere.  I haven't re-analyzed it since bitcoin was much smaller, but IIRC I think it gets us to worldwide international settlement bandwidth with a high enough tx fee to eliminate micro payments.

Regardless, the various transaction parameters: bandwidth, settlement times etc, have been significant motivators of alt-coins.  Clearly Bitcoin has either been seen deficient by some in this respect (esp the 10 minute average confirmation time), or we need blockchains with different parameters to satisfy different needs.


@benjyz: Nobody is talking about a private blockchain...

1. I'm not talking about hashing power.  I am talking about network effect, the first mover advantage.  Why MS word is STILL the standard word processor....
2. It does not move away from consensus.  Consensus is still required for any features to be added to the bitcoin blockchain.  And as an owner of a coin, its my choice whether I want to move it to the "quick&tinyCoin" sidechain (just to make something up) for use in a cloud storage solution.
3. You can have your opinion, but lots of people see the scam-coin movement as detrimental to the public image of crypto-currencies.  Additionally, let's imagine someone does create Bitcoin2 that really does have compelling features, solving lots of Bitcoin's current problems.  Let's imagine that it exceeds the Bitcoin first mover advantage.  The resulting transfer of value from Bitcoin to Bitcoin2 is not going to paint a pretty picture to the general public, potential investors, Venture Capitalists, etc.  It would set crypto-currency adoption back many years IMO.  Solving this is one purpose of the "spin-off" idea...
4. What's "the problem?" that it doesn't solve... 1 through 4?


But this is going to be my last response debating the merits rather then the technique of this feature.  It has value to many, perhaps not to you.

In Bitcoin the chain is public for a good reason. Making it private requires an innovation, which I fail to see here. I doubt that ZK proofs are the solution. These things are much too complex to be properly audited.


1. you're referring to the hashing-power. I don't see much reason why miners should attack good coins. after all they mostly care about $'s and if they think the coin is good, they'll support it to make money.
2. well, this seems to move away from the consensus model, that is absolutely constitutional to Bitcoin. this kind of staging would be likely introducing many problems, and I personally don't see the upside. I don't think one can so radically alter Bitcoin and I'm surprised that others do. such changes introduce risk to an existing capital base invested in Bitcoin.
3. I don't understand what that is supposed to mean. issuing worthless coins isn't inflation. only currency systems that are worthwhile get value from the market. this is a non-problem in my opinion. it's the same as in the stock market. plenty of bad stock is issued every day, but that is party of the healthy incentive mechanism.
4. I don't see how side-chains as proposed solve the problem. It would help if suggestions would be put in a format where one can judge whether they are serious concrete proposals or plans/speculations. I think one should distinguish much more clearly between the two (something like BIP draft format). There is quite a lot of hand-waving going on, especially with regards to the so called 2.0 concepts.

I think I prefer spin-offs to side-chains:  https://bitcointalksearch.org/topic/spin-offs-bootstrap-an-altcoin-with-a-btc-blockchain-based-initial-distribution-563972

Spin-offs facilitate low-risk experimentation of new innovations in a non-threatening and non-inflationary way.  They also require no changes to the core of bitcoin and allow new mining techniques + experimentation with PoS.  


Adding side-chains or increasing the transaction capacity of the current bitcoin network requires changes to the code.  I would prefer to increase the capacity of the primary blockchain consistent with the Satoshi model.  I believe this can be done by propagating new blocks by transaction hash to reduce the orphan cost, floating the miners fee, and eventually floating (or increasing) the maximum block size.  

This is an open question AFAIK and very interesting.  The sidechain would not be allowed to create any bitcoin, so the current mining "subsidy" would not exist.  Having a tiny or zero mining reward at least would avoid Coiled Coin's fate (51%ed by a pool operator starting merged mining).

Miners could gain txn fees.  However, I think that the most likely miners would be those who benefit from the side chain in other ways.  For example, if a side chain solved the micro payment problem (high frequency, small payments), services that accept micro payments would be interested in mining the coin.  The current coin subsidy has overshadowed this possibility on the bitcoin blockchain, but look at the core devs.  They are paid by TBF which was funded by contributions from companies invested in bitcoin's future success.

@Benjyz:  the concept of "sidechains" is an attempt to allow a bitcoin to move from one blockchain to another.  Its still a bitcoin, its just hosted on a different blockchain.  So essentially the price of a bitcoin on blockchain A cannot diverge from that of a bitcoin on blockchain B because the bitcoins freely move between the blockchains.

Let us keep this topic technical in nature: whether a particular technology *should* be offered as a sidechain or as an alt-coin is a topic better discussed elsewhere.  However, let me briefly offer several possible justifications for side chains:  
1. Bitcoin may have such a strong momentum and monopoly in the digital coin space that even alt-coins with useful features are unlikely to succeed.
2. As a live proving ground for features that could be added the the Bitcoin core blockchain.  These features may be useful, but not cool enough to build a successful alt-coin around.
3. There may be a reluctance (by responsible stewards of the digital currency concept anyway) to inflate the total crypto-currency pool by creating new alt-coins.  
4. The main bitcoin chain cannot easily carry worldwide VISA/MC levels of load

As far as I understand there are 3 different ideas here: i) sidechains for scaling ii) sidechains as staging (Bitcoin 2.0) iii) sidechains as Altcoins. Of these only i) makes sense to me, which does not require a market. I think ii) is a bad idea. I'm not sure about iii). I believe eventually (in 5-10 years) we will have a sort of chain based exchange mechanism, but it will look very different than what exists today.

And so there would be free-market merged mining of the sidechains? Choose a sidechain you wish to mine, and pay the additional storage cost for maintaining the chains you perceive as valuable?

what determines the price between two chains? say you have currency C which is pegged to BTC. what determines the ratio at which people exchange C to BTC? say someone has 1M$ worth of C - now he has to find someone who wants to buy 1M$ worth of C for BTC. not only does the price mechanism allow for a value determination of different currencies / approaches, but it also provides a very powerful incentive for developing the software. the mechanism by which one moves currencies into another is called a market. there seems to be a confusion between chains and coin issuance. every coin will have a price and therefore one needs a mechanism to establish the price. I suppose the idea is that Alt-Coins could potentially use the existing hashing-power. I think the same arguments that apply to bitcoin apply to (potential) Alt-coins. Why would someone waste resource to attack a coin instead of mining it?

I find it confusing when people talk about Mastercoin, Ethereum, Counterparty and Opentransactions as if they exist. None of these projects work as of today. Mastercoin has lost 80% in marketcap since IPO, so the market is a very good indicator in this case of how things are going. Let a market establish a price for different projects/chains.

Here's some good overview of Adam Back's thoughts on the concept.

http://www.ofnumbers.com/2014/04/09/paraphrased-notes-from-back-and-hill-interview/

There is none, its in bits and pieces... hang on, updating 2nd reply now with links.  EDIT: updated

Do you have a link to gmaxwell's actual proposal?

Terminology:

SPV: Simplified Payment Verification.  How non-fully-validating wallets have trust in your balance.  Basically a chain of block headers that proves that a certain amount of work has happened after a particular txn was posted.   https://en.bitcoin.it/wiki/Scalability#Simplified_payment_verification

SPV proof of burn:  Someone who wants to "reanimate" coins on the bitcoin blockchain (chain A) needs to submit proof that the coins were spent on chain B into the 1chainAxfer (well known unspendable address -- i.e. the coins were "burned" on that chain) AND that sufficient work has been done subsequently to make it unlikely that a fork will unroll this spend.  Rather than force the chain A miners to access the chain B blockchain, the entity who wants to "reanimate" the coin gathers all this information into a "proof" and submits it as part of the "reanimate" transaction.

Security Firewall: Ensure that no matter what happens on side-chains, people/coins that have only been used on the main chain remain unaffected.  Most importantly, no accidental inflation.

1-way peg:  This refers to moving bitcoins to a sidechain.  To understand the term, note that if it is possible to move bitcoins to the sidechain, the price of the sidechain coins cannot exceed that of 1 bitcoin.  The price is "pegged".  If ever did exceed 1 bitcoin did people would simply move bitcoins to the sidechain and sell them...

2-way peg:  This refers to moving bitcoins to a sidechain and back.  This functionality "pegs" the price of the sidechain coin to that of bitcoin because any deviation simply allows people to move coins to the lower priced chain and sell them.

References:

This chat is really the best description: http://download.wpsoftware.net/bitcoin/wizards/2013-12-18.txt

00:24:30 are there any serious or semi-serious proposals for how to fix an altcoin 1:1 to bitcoin without a large cost to bitcoin miners given some hardfork changes to bitcoin?
00:26:38 if not for the disabled operators you could probably do it without hardfork changes to bitcoin, though you would only have SPV security in the altcoin-bitcoin direction.
00:27:16 even getting spv security in the altcoin-> bitcoin direction is non-trivial, no?
00:27:26 (given hardfork to reenable opcodes)
00:27:54 you'd have to have the whole chain history, or some subset starting from the time of the bitcoin->altcoin transfer
00:28:03 well, whole block-header-chain-history
00:28:27 yea, you just write a script that can do a spv validation and then takes a chunk of headers of a prespecified sufficient difficulty.
00:28:44 the proof can start at the point the txn of interest was mined.
00:28:45 that gets pretty expensive?
00:28:57 I mean, it's 80 bytes per header. so not really.
00:29:02 very expensive if you hold the alt for an extended period...
00:29:21 well, no miner is gonna mine a tx that is 80 bytes*N where N is a few weeks/months of headers
00:29:24 BlueMatt: oh no, you don't do it over the life of the alt.
00:29:32 crazy no no thats not how it works.
00:30:25 you take some coin and assign it to a scriptPubKey that can be redeemed by anyone who provide a SPV fragment from the altcoin showing any of those coins being reassigned back to bitcoin, with a sum difficulty of at least X.
00:30:47 gmaxwell, BlueMatt: a 1:1 peg - doesnt that import security risk from the alt into bitcoin? (i suggested a 1 way peg "bitcoin staging" only so bitcoin is security firewalled) are we talking about the same area of feature
00:31:39 adam3us: only to the limit of the alt. say the alt was somehow totally insecure... you could then steal all the bitcoins that had been assigned to the altcoin.
00:31:44 but no more.
00:32:01 gmaxwell: hmm that might be ok
00:32:18 adam3us: what gmaxwell said (if you decide to put your btc in the alt, sucks for you)
00:32:43 BlueMatt: one problem there is that isn't really spv security, its "spv transcript" security, in that the bitcoin network isn't going to go out and find a longer chain.
00:32:48 BlueMatt: yes that is an acceptable trade off and already at risk with a 1-way peg
00:33:20 BlueMatt: But I did come up with a way to boost that to more like real SPV security with a bit more script power.
00:33:33 gmaxwell: well, ok, sum difficulty is one way...but very non-ideal
00:34:18 (you make the relase of coins back into bitcoin two phase. The first phase you do a header proof for the release.. and that gets mined.. but it can only output to a special holding script with the following rules:
00:35:13 after N blocks the releasing party can grab the coins. OR at any point, any party can show a longer chain to prove the release was bogus. and then they can only be redeemed with a new release on a chain longer than that one.
00:35:55 In any case I think most of the stuff thats been said of any technical substance on this is in the coinwitness thread (where I suggest using SNARKs for C to compact the proofs, though its not essential): https://bitcointalksearch.org/topic/really-really-ultimate-blockchain-compression-coinwitness-277389
00:36:17 obviously if you compact the proofs things start sounding more interesting from a scaling perspective.
00:37:04 also if the headers of the altcoin form a MMR (insertion ordered binary tree) it may be cheaper to prove long spans of difficulty.
00:37:09 yea, though depending on cutting-edge crypto is ugly...
00:38:02 BlueMatt: well there are less ambitious (efficiency wise) ways to construct these proofs, but they're larger... though I'm not sure if we could get the direct proofs down with special support. Maybe.
00:38:08 SPV fragments can be pretty small.
00:39:02 yea, its all a bit expensive, really
00:39:23 it would be fun to be able to peg arbitrary altcoins to bitcoin as it really addresses the issues altcoins cause
00:40:02 allows them to innovate (ie risk people's money) while not costing bitcoin's digital scarcity/competing on store-of-value
00:40:51 BlueMatt: one way is easy— just have them validate bitcoin too.
00:40:55 BlueMatt: agreed
00:41:57 BlueMatt: one point is that you could coinjoin your cross chain merges perhaps, to make them smaller. e.g. one proof and then a dozen transactions hop the gap.
00:44:18  gmaxwell sure, but if you only peg one-way its really not particularly useful
00:44:40 well, it is, but not as useful
00:44:54 gmaxwell: sure, you could limit to like 1 coinjoin'd alt->btc tx per day
00:45:03 but even that could be expensive
00:45:29 I dunno, I mean, it's a seralized transaction and spv proof, plus some additional headers.
00:45:43 well, if you have 100 alts all doing that, it does
00:46:04 BlueMatt: I like 1:1 peg idea, I only suggested 1-way peg to insulate security, if you can insulate security to the coins in the alt, thats even better
00:47:41 as long as you limit it to the people who transferred their coins...
00:47:49 gmaxwell: hmm...
00:47:57 lets say there are 2^12 txn per altcoin block, ... lets imagine you make the altcoin txn themselves hashtree so you can get to only their outputs.. so say maybe 64 bytes for the altcoin output, 384 bytes for the spv tree. 4 bytes for a spv index, and 12 80 byte headers = 1.4k.
00:48:15 it's bigger than a typical ecdsa signature, but not murderous.
00:48:48 and if they coinjoin the biggest parts (960 bytes of headers, 384 bytes of hashes) can be shared.
00:49:56 adam3us: yea,  I don't think there is a security need to make it one way. If you can never "pull back" more from an altcoin than was sent to it, then only the holders of the altcoin are at risk.
00:50:43 gmaxwell: seems plausible indeed, i just didnt think of it in those terms at the time.  good
00:51:22 the altcoin is also a bitcoin node, and monitors bitcoin for coins assigned to the altcoin, and then permits someone on the altcoin to emerge those coins from thin air.. and then when you want to send them back you make a special transaction in the altchain and prove you did it to bitcoin.
00:51:23 gmaxwell: i suppose the other thing is it itself requires bitcoin changes, perhaps non-trivial ones, and that is part of the reason for the exercise.
00:51:46 yea, unfortunately it requires changes to bitcoin.
00:52:18 we could _almost_ do it in script without the disabled opcodes, but there are enough little corners that I suspect we can't.


2-peg side chain links:

2-way pegging, Adam Back: http://sourceforge.net/p/bitcoin/mailman/message/32108143/

Description of skip-lists that can space-efficiently prove difficulty (SPV proof of burn):

The High-Value Hash Highway: https://bitcointalksearch.org/topic/the-high-value-hash-highway-98986
Compact SPV proofs via block header commitments: http://sourceforge.net/p/bitcoin/mailman/message/32111357/

Let us centralize and clarify discussion on bitcoin sidechains.  

The basic idea has been around since at least mid-2012 (any earlier references?) and is to allow value to be moved from the bitcoin network into a separate blockchain and back.  But a possible implementation has only emerged relatively recently (gmaxwell).

First, if both blockchains "see" each other then side chains are easy.  Let's say you want to move value from chain A to chain B.  The owner spends bitcoins on chain A from any address (say 1Me) into a well-known unspendable address (let's pretend the address prefix is 1chainBxfer).  Nodes on chain "B" are watching chain A, perhaps only as a SPV node to see txouts going to 1chainBxfer.  When a suitable transaction is found and sufficiently confirmed, a coinbase txn is allowed on chain B that grants coins to the same addresses as the txins on chain A (1Me).

And you can spend back from B to A in the same way.

Basically, a similar technique was used to fund mastercoins, except that the mastercoin bitcoin address IS spendable (which therefore inflates the TOTAL crypto-currency (MC+bitcoin) supply) and the transfer was a one-time "kickoff" deal.


The real question is how to spend in both directions (2-peg is what people have been saying) when chain A is not aware of chain B?  I think that the general consensus is that this is impossible which is why the sidechain idea languished for 2 years.  

However, the real question is "what is the MINIMUM amount of information that chain B requires and how can that be provided to B with the smallest, safest API changes to B?"

The first requirement is to ensure that the total number of bitcoins will never exceed the amount mined, regardless of errors or antagonistic players on the side chains.  This ensures that errors on a side chain will never inflate the total number of bitcoins on the bitcoin blockchain.  This is easily solved by requiring only allowing "reanimations" of coins on the bitcoin blockchain.  That is, an output transaction was created to an "unspendable" address in the bitcoin blockchain to transfer the coin to chain B.  To transfer value back to the bitcoin blockchain, this txo must be "spent".  It probably does not matter which TXO gets spent to reanimate a coin (in fact choosing a random one will help anonymity), it only matter that the size of the "reanimating" txins = the spending txo's (miner's fees will need to come from a normal txin).

Now, the worst case scenario is that someone will be able "reanimate" all the coins transferred to another chain, stealing them.  This could cause the sum of the spendable "bitcoins" on the bitcoin blockchain and the sidechain to exceed 21M.  But the 21M limit is not broken, on the bitcoin blockchain (presumably the other chain dies a horrible gox-like death at this point :-( because its coins are no longer "backed")...


To stop that, we need to prove ownership of a off-chain coin to the bitcoin blockchain...

BRB :-)