CryptAxe [ARCHIVE] on Nostr: 📅 Original date posted:2017-10-10 📝 Original message:Your method would change ...
📅 Original date posted:2017-10-10
📝 Original message: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 at 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 at 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 <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> 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
>>
>>
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> 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/de8cb97c/attachment.html>;
📝 Original message: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 at 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 at 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 <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> 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
>>
>>
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> 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/de8cb97c/attachment.html>;