1⟫ Segregated Witness and LightningNetwork - Larger block space, which will increase the capacity of bitcoin transaction, making room for more people. And empty rooms always tend to fill up, so I expect many new users from this idea. It also fixes malleability issues, and makes 0 confirm double spend harder so we can now build instant transaction systems with greater confidence and less risk of double spend with lightning network technology. Huge project, definitely nr.1.
I like this idea. if we have larger block space, the voice of hard fork will be smaller. Lightening Network is necessary to future bitcoin mass adoption, now the speed is too slow. We need speed it up
But.....is this using side chains of BTC to accomplish this? If so, lets say that I create a side token and use it in my network with clients. I set a 100 BTC block size for my side chain and side network and 0 confirmations for payments. Now, my first block fills and I have paid all that in and out on my token. I have to, at some point, send my side token TX's to the main block chain and if my token is a 1 to 1 BTC exchange, then my 1 block would quickly throw 4 blocks at the main block chain. Or am I thinking about this wrong? A constant use side network with a bigger block could quickly lag down the main block chain. Or, I could have my token at 4 to 1 and that still gets confusing. Either way, people are spending 100 BTC and sending it in a big 4 block lump. Right?
maybe i do not get you and misunderstood, why are 100 bitcoin 4 blocks? did you confuse it with the old mining reward for a block? as far as i understand side chains take out existing bitcoins let us say a 100. then you can us these 100 bitcoin as usual and just do the transactions and confirmations on an other chain. after some time you send the 100 bitcoins back to the block chain. in total you have made 2 transactions (in and out) on the block chain. but possibly hundreds or thousands of transactions of the chain.
A->B->C->...->Y->Z->A. Where A is the block chain. imagine that you send 100 bitcoins every time. so only transactions to B and from Z are on the block chain and the whole other bunch is not. this is how you prevent spam on the block chain.
ok, i guess what i was missing was that you only have to account to the main chain twice. i imagined that the side chain gathered say four blocks of TX and then sent them or something like that. i assume that the side chain used in this manner will still account those TX's once per day or something and only as an overall net change from the day before. somehow i was thinking that each TX still made it to the block chain eventually versus a simple overall change of funds in the side chain.
i still see the company at large at risk though, say my side token is "quickpay" the way i see this service working is not that a client actively buys my quickpay token and then buys and sells through my site. instead, they deposit their BTC and my site automatically buys quickpay with their BTC, still showing their balance to them in BTC. but, when they then buy something from outside the network, how does that work? I promise them 0 confirmations, so i have to quickly put out enough of my tokens to pay their debt, and i have to deal with confirmations because i am dealing with the main chain, so then i have to provide the purchase, the traded currencies or whatever and they can be gone before my outside TX gets confirmed. the only safety would be to delay their exit from my site/token.
i don't know, it is late here, what i do see is that this would all be very possible if the entire system got enclosed by the side chain. you could trade back and forth, no delays and the only time you would have to wait is leaving the side chain, converting back to BTC. that only works if both trading parties on on the same side chain.