Paul Sztorc [ARCHIVE] on Nostr: 📅 Original date posted:2017-10-10 📝 Original message:Haha, no. Because you ...
📅 Original date posted:2017-10-10
📝 Original message:Haha, no. Because you "burned" the coins.
On Oct 10, 2017 1:20 AM, "Tao Effect" <contact at 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 <truthcoin at 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171010/25fb5d8e/attachment.html>;
📝 Original message:Haha, no. Because you "burned" the coins.
On Oct 10, 2017 1:20 AM, "Tao Effect" <contact at 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 <truthcoin at 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171010/25fb5d8e/attachment.html>;