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 <truthc...@gmail.com >> <mailto:truthc...@gmail.com>> wrote: >> >> Haha, no. Because you "burned" the coins. >> >> On Oct 10, 2017 1:20 AM, "Tao Effect" <cont...@taoeffect.com >> <mailto:cont...@taoeffect.com>> 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 <truthc...@gmail.com >>> <mailto:truthc...@gmail.com>> 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 >>> <mailto: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 >>> <mailto:bitcoin-dev@lists.linuxfoundation.org> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> <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
