Your method would change the number of Bitcoins in existence. Why? On Oct 10, 2017 12:47 PM, "Tao Effect via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > Is that what passes for a technical argument these days? Sheesh. > > Whereas in Drivechain users are forced to give up their coins to a single > group for whatever sidechains they interact with, the generic sharding algo > lets them (1) keep their coins, (2) trust whatever group they want to trust > (the miners of the various sidechains). > > Drivechain offers objectively worse security. > > -- > Sent from my mobile device. > Please do not email me anything that you are not comfortable also sharing > with the NSA. > > On Oct 10, 2017, at 8:09 AM, Paul Sztorc via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > I think this response speaks for itself. > > On 10/10/2017 10:09 AM, Tao Effect wrote: > > Hi Paul, > > I thought it was clear, but apparently you are getting stuck on the > semantics of the word "burn". > > The "burning" applies to the original coins you had. > > When you transfer them back, you get newly minted coins, equivalent to the > amount you "burned" on the chain you're transferring from — as stated in > the OP. > > If you don't like the word "burn", pick another one. > > -- > Please do not email me anything that you are not comfortable also sharing with > the NSA. > > On Oct 10, 2017, at 4:20 AM, Paul Sztorc wrote: > > Haha, no. Because you "burned" the coins. > > On Oct 10, 2017 1:20 AM, "Tao Effect" wrote: > >> Paul, >> >> It's a two-way peg. >> >> There's nothing preventing transfers back to the main chain. >> >> They work in the exact same manner. >> >> Cheers, >> Greg >> >> -- >> Please do not email me anything that you are not comfortable also sharing with >> the NSA. >> >> On Oct 9, 2017, at 6:39 PM, Paul Sztorc wrote: >> >> That is only a one-way peg, not a two-way. >> >> In fact, that is exactly what drivechain does, if one chooses parameters >> for the drivechain that make it impossible for any side-to-main transfer to >> succeed. >> >> One-way pegs have strong first-mover disadvantages. >> >> Paul >> >> On Oct 9, 2017 9:24 PM, "Tao Effect via bitcoin-dev" < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> Dear list, >> >> In previous arguments over Drivechain (and Drivechain-like proposals) I >> promised that better scaling proposals — that do not sacrifice Bitcoin's >> security — would come along. >> >> I planned to do a detailed writeup, but have decided to just send off >> this email with what I have, because I'm unlikely to have time to write up >> a detailed proposal. >> >> The idea is very simple (and by no means novel*), and I'm sure others >> have mentioned either exactly it, or similar ideas (e.g. burning coins) >> before. >> >> This is a generic sharding protocol for all blockchains, including >> Bitcoin. >> >> Users simply say: "My coins on Chain A are going to be sent to Chain B". >> >> Then they burn the coins on Chain A, and create a minting transaction on >> Chain B. The details of how to ensure that coins do not get lost needs to >> be worked out, but I'm fairly certain the folks on this list can figure out >> those details. >> >> - Thin clients, nodes, and miners, can all very easily verify that said >> action took place, and therefore accept the "newly minted" coins on B as >> valid. >> - Users client software now also knows where to look for the other coins >> (if for some reason it needs to). >> >> This doesn't even need much modification to the Bitcoin protocol as most >> of the verification is done client-side. >> >> It is fully decentralized, and there's no need to give our ownership of >> our coins to miners to get scale. >> >> My sincere apologies if this has been brought up before (in which case, I >> would be very grateful for a link to the proposal). >> >> Cheers, >> Greg Slepak >> >> * This idea is similar in spirit to Interledger. >> >> -- >> Please do not email me anything that you are not comfortable also sharing with >> the NSA. >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >