Paul Sztorc [ARCHIVE] on Nostr: đź“… Original date posted:2017-10-10 đź“ť Original message:I think this response ...
đź“… Original date posted:2017-10-10
đź“ť Original message: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 <truthcoin at gmail.com
>> <mailto:truthcoin at gmail.com>> wrote:
>>
>> Haha, no. Because you "burned" the coins.
>>
>> On Oct 10, 2017 1:20 AM, "Tao Effect" <contact at taoeffect.com
>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> <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/0bebbbfd/attachment-0001.html>;
đź“ť Original message: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 <truthcoin at gmail.com
>> <mailto:truthcoin at gmail.com>> wrote:
>>
>> Haha, no. Because you "burned" the coins.
>>
>> On Oct 10, 2017 1:20 AM, "Tao Effect" <contact at taoeffect.com
>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> <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/0bebbbfd/attachment-0001.html>;