Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

[Paul Sztorc via bitcoin-dev]

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"  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

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

[Tao Effect via bitcoin-dev]

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" 
>  > 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 
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] New difficulty algorithm needed for SegWit2x fork? (reformatted text)

[greg misiorek via bitcoin-dev]

Yes, I agree. Hard forks should be as much scrutinized by fellow bitcoiners, 
i.e. developers and holders and not only rushed by miners or some other 
investment gurus, whose incentives are not entirely clear, to remain as 
decentralized as economically possible.


From: bitcoin-dev-boun...@lists.linuxfoundation.org 
 on behalf of Mark Friedenbach 
via bitcoin-dev 
Sent: Monday, October 9, 2017 10:19 PM
To: Scott Roberts; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] New difficulty algorithm needed for SegWit2x fork? 
(reformatted text)

The problem of fast acting but non vulnerable difficulty adjustment algorithms 
is interesting. I would certainly like to see this space further explored, and 
even have some ideas myself.

However without commenting on the technical merits of this specific proposal, I 
think it must be said upfront that the stated goal is not good. The largest 
technical concern (ignoring governance) over B2X is that it is a rushed, poorly 
reviewed hard fork. Hard forks should not be rushed, and they should receive 
more than the usual level of expert and community review.

I’m that light, doing an even more rushed hard fork on an even newer idea with 
even less review would be hypocritical at best. I would suggest reframing as a 
hardfork wishlist research problem for the next properly planned hard fork, if 
one occurs. You might also find the hardfork research group a more 
accommodating venue for this discussion:

https://bitcoinhardforkresearch.github.io/
Welcome - Bitcoin Hard Fork Research
bitcoinhardforkresearch.github.io
Bitcoin Hard Fork Research This website will be updated with relevant ongoing 
information about Bitcoin hard fork research. Resources: BIP-MMHF, draft patch 
last ...



On Oct 9, 2017, at 3:57 PM, Scott Roberts via bitcoin-dev 
mailto:bitcoin-dev@lists.linuxfoundation.org>>
 wrote:

Sorry, my previous email did not have the plain text I intended.

Background:

The bitcoin difficulty algorithm does not seem to be a good one. If there
is a fork due to miners seeking maximum profit without due regard to
security, users, and nodes, the "better" coin could end up being the
minority chain. If 90% of hashrate is really going to at least initially go
towards using SegWit2x, BTC would face 10x delays in confirmations
until the next difficulty adjustment, negatively affecting its price relative
to BTC1, causing further delays from even more miner abandonment
(until the next adjustment). The 10% miners remaining on BTC do not
inevitably lose by staying to endure 10x delays because they have 10x
less competition, and the same situation applies to BTC1 miners. If the
prices are the same and stable, all seems well for everyone, other things
aside. But if the BTC price does not fall to reflect the decreased hashrate,
he situation seems to be a big problem for both coins: BTC1 miners will
jump back to BTC when the difficulty adjustment occurs, initiating a
potentially never-ending oscillation between the two coins, potentially
worse than what BCH is experiencing.  They will not issue coins too fast
like BCH because that is a side effect of the asymmetry in BCH's rise and
fall algorithm.

Solution:

Hard fork to implement a new difficulty algorithm that uses a simple rolling
average with a much smaller window.  Many small coins have done this as
a way to stop big miners from coming on and then suddenly leaving, leaving
constant miners stuck with a high difficulty for the rest of a (long) averaging
window.  Even better, adjust the reward based on recent solvetimes to
motivate more mining (or less) if the solvetimes are too slow (or too fast).
This will keep keep coin issuance rate perfectly on schedule with real time.

I recommend the following for Bitcoin, as fast, simple, and better than any
other difficulty algorithm I'm aware of.  This is the result of a lot of work 
the
past year.

=== Begin difficulty algorithm ===
# Zawy v6 difficulty algorithm (modified for bitcoin)
# Unmodified Zawy v6 for alt coins:
# http://zawy1.blogspot.com/2017/07/best-difficulty-algorithm-zawy-v1b.html
# All my failed attempts at something better:
# 
https://github.com/seredat/karbowanec/commit/231db5270acb2e673a641a1800be910ce345668a
#
# Keep negative solvetimes to correct bad timestamps.
# Do not be tempted to use:
# next_D = sum(last N Ds) * T / [max(last N TSs) - min(last N TSs];
# ST= Solvetime, TS = timestamp

# set constants until next hard fork:

T=600; # coin's TargetSolvetime
N=30; # Averaging window. Smoother than N=15, faster response than N=60.
X=5;
limit = X^(2/N); # limit rise and fall in case of timestamp manipulation
adjust = 1/(1+0.67/N);  # keeps avg solvetime on track

# begin difficulty algorithm

avg_ST=0; avg_D=0;
for ( i=height;  i > height-N;  i--) {  # go through N most recent blocks
avg_ST += (TS[i] - TS[i-1]) / N;
avg_D += D[i]/N;
}
avg_ST = T*limit if avg_ST > T*limit;
avg_ST = T/limit

[bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

[Tao Effect via bitcoin-dev]

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 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

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

[Tao Effect via bitcoin-dev]

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" 
>> > > 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 
>> 
>> 
>> 
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

[Paul Sztorc via bitcoin-dev]

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"
>>> >> > 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

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

[Tao Effect via bitcoin-dev]

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 
>  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" 
>  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

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

[CryptAxe via bitcoin-dev]

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
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

[Tao Effect via bitcoin-dev]

It would not change the number of Bitcoins in existence.

--
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 12:50 PM, CryptAxe  wrote:
> 
> Your method would change the number of Bitcoins in existence. Why? 
> 
>> On Oct 10, 2017 12:47 PM, "Tao Effect via bitcoin-dev" 
>>  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 
>>>  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" 
>>>  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.linuxfoundat

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

[Lucas Clemente Vella via bitcoin-dev]

2017-10-09 22:39 GMT-03:00 Paul Sztorc via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> 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.
>

I understand the first-mover disadvantages, but I keep thinking that if the
new chain is Pareto optimal, i.e. is in all aspects at least good as the
original chain, but in some so much better to justify the change, the
initial resistance is an unstable equilibrium. Like a herd of buffaloes
attacking a lion: the first buffalo to attack is in awful disadvantage, but
if a critical mass of the herd follows, the movement succeeds beyond
turning back, and every buffalo benefited, both those who attacked the lion
and those that didn't (because the lion was chased away or killed).

-- 
Lucas Clemente Vella
lve...@gmail.com
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

[Paul Sztorc via bitcoin-dev]

What if two sidechains are implemented at once? What if people get excited
about one sidechain today, but a second even-better one is published the
very next week? What if the original mainchain decides to integrate the
features of the sidechain that you just one-way pegged to?

In these cases, the user looses money, whereas in the two-way peg they
would not lose a thing.

While the one-way peg is interesting, it really doesn't compare.

Paul

On Oct 10, 2017 4:19 PM, "Lucas Clemente Vella"  wrote:

2017-10-09 22:39 GMT-03:00 Paul Sztorc via bitcoin-dev :

> 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.
>

I understand the first-mover disadvantages, but I keep thinking that if the
new chain is Pareto optimal, i.e. is in all aspects at least good as the
original chain, but in some so much better to justify the change, the
initial resistance is an unstable equilibrium. Like a herd of buffaloes
attacking a lion: the first buffalo to attack is in awful disadvantage, but
if a critical mass of the herd follows, the movement succeeds beyond
turning back, and every buffalo benefited, both those who attacked the lion
and those that didn't (because the lion was chased away or killed).

-- 
Lucas Clemente Vella
lve...@gmail.com
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

[Tao Effect via bitcoin-dev]

What?

That is not correct.

There is a fixed amount of Bitcoin, as I said.

The only difference is what chain it is on.

It is precisely because there is a fixed amount that when you burn-to-withdraw 
you mint on another chain.

I will not respond to any more emails unless they’re from core developers. 
Gotta run.

--
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 1:23 PM, James Hudon  wrote:
> 
> You're asking for newly minted bitcoin to go to you but you burned the 
> bitcoin used in the peg. You're effectively losing your money and then 
> stealing from the miners to gain it back. The miners had to issue your amount 
> of bitcoin 2 times (once for your original bitcoin, again to make you whole). 
> Why would they agree to this?
> --
> hudon
> 
>> On Oct 10, 2017, at 13:13, Tao Effect via bitcoin-dev 
>>  wrote:
>> 
>> It would not change the number of Bitcoins in existence.
>> 
>> --
>> 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 12:50 PM, CryptAxe  wrote:
>>> 
>>> Your method would change the number of Bitcoins in existence. Why? 
>>> 
>>> On Oct 10, 2017 12:47 PM, "Tao Effect via bitcoin-dev" 
>>>  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 
  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" 
>>>  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 
>

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

[Lucas Clemente Vella via bitcoin-dev]

2017-10-10 11:09 GMT-03:00 Tao Effect via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> 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 have to change Bitcoin to recognize a transfer from the sidechain
back into Bitcoin, you kill the purpose of the sidechain. You could as well
just change the Bitcoin to implement whatever desirable features the
sidechain would have. The whole idea of sidechains is to keep Bicoin
unchangend, and allow for the voluntary transfer of tokens out of Bitcoin
to the sidechain of your choosing.


-- 
Lucas Clemente Vella
lve...@gmail.com
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

[James Hudon via bitcoin-dev]

You're asking for newly minted bitcoin to go to you but you burned the bitcoin 
used in the peg. You're effectively losing your money and then stealing from 
the miners to gain it back. The miners had to issue your amount of bitcoin 2 
times (once for your original bitcoin, again to make you whole). Why would they 
agree to this?
--
hudon

> On Oct 10, 2017, at 13:43, Tao Effect via bitcoin-dev 
>  wrote:
> 
> What?
> 
> That is not correct.
> 
> There is a fixed amount of Bitcoin, as I said.
> 
> The only difference is what chain it is on.
> 
> It is precisely because there is a fixed amount that when you 
> burn-to-withdraw you mint on another chain.
> 
> I will not respond to any more emails unless they’re from core developers. 
> Gotta run.
> 
> --
> 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 1:23 PM, James Hudon  wrote:
>> 
>> You're asking for newly minted bitcoin to go to you but you burned the 
>> bitcoin used in the peg. You're effectively losing your money and then 
>> stealing from the miners to gain it back. The miners had to issue your 
>> amount of bitcoin 2 times (once for your original bitcoin, again to make you 
>> whole). Why would they agree to this?
>> --
>> hudon
>> 
>>> On Oct 10, 2017, at 13:13, Tao Effect via bitcoin-dev 
>>>  wrote:
>>> 
>>> It would not change the number of Bitcoins in existence.
>>> 
>>> --
>>> 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 12:50 PM, CryptAxe  wrote:
 
 Your method would change the number of Bitcoins in existence. Why? 
 
 On Oct 10, 2017 12:47 PM, "Tao Effect via bitcoin-dev" 
  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 
>  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" 
  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 sen

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

[CryptAxe via bitcoin-dev]

You could technically call myself and Chris 'core developers'. You don't
get to have a fixed rate of Bitcoin and a second way to mint coins at the
same time.

On Oct 10, 2017 1:46 PM, "Tao Effect via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> What?
>
> That is not correct.
>
> There is a fixed amount of Bitcoin, as I said.
>
> The only difference is what chain it is on.
>
> It is precisely because there is a fixed amount that when you
> burn-to-withdraw you mint on another chain.
>
> I will not respond to any more emails unless they’re from core developers.
> Gotta run.
>
> --
> 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 1:23 PM, James Hudon  wrote:
> >
> > You're asking for newly minted bitcoin to go to you but you burned the
> bitcoin used in the peg. You're effectively losing your money and then
> stealing from the miners to gain it back. The miners had to issue your
> amount of bitcoin 2 times (once for your original bitcoin, again to make
> you whole). Why would they agree to this?
> > --
> > hudon
> >
> >> On Oct 10, 2017, at 13:13, Tao Effect via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> It would not change the number of Bitcoins in existence.
> >>
> >> --
> >> 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 12:50 PM, CryptAxe  wrote:
> >>>
> >>> 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

Re: [bitcoin-dev] New difficulty algorithm needed for SegWit2x fork? (reformatted text)

[Scott Roberts via bitcoin-dev]

I agree: a new difficulty algorithm starting from zero is inconceivably 
rushed. But it's also inconceivable to not have one ready in two months 
if my understanding of our current situation is correct. Is there any 
complaint or suggestion about this algorithm or the appropriate goals of 
an ideal difficulty algorithm? I feel like there is a discussion that needs 
to be hashed out before a draft BIP at the HF page, but I do not know 
where is best or who would be interested. If the community shows it is 
receptive and supportive I think I could get Karbowanek coin to put it 
into live action and solicit hash attacks. They are currently using a 
simpler N=17 like this since last November. They have tested all my 
attempted improvements the past few months, so they are familiar with all 
the in and outs. 

This particular coin split is looking different. Assuming users currently 
prefer SW, it still seems like miner support is going to convince enough 
users that SegWit2x is a worthy if not superior alternative. The result 
could be both coins oscillating with long delays, as long as the price is 
similar. As soon as it is not similar, maybe the loser will be in a death 
spiral, pushed to the margin like previous coins. This might be a bitcoin 
feature. But the 2016 window seems like it is too brutal. It seems like it 
will result in an accidental winner before the better coin can be 
determined by more rational means.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] New difficulty algorithm needed for SegWit2x fork? (reformatted text)

[Ben Kloester via bitcoin-dev]

Mark, this seems an awful lot like an answer of "no", to my question "Is
there a contingency plan in the case that the incumbent chain following the
Bitcoin Core consensus rules comes under 51% attack?" - is this a correct
interpretation?

In fact, beyond a no, it seems like a "no, and I disagree with the idea of
creating one".

So if Bitcoin comes under successful 51%, the project, in your vision, has
simply failed?

*Ben Kloester*

On 10 October 2017 at 13:19, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The problem of fast acting but non vulnerable difficulty adjustment
> algorithms is interesting. I would certainly like to see this space further
> explored, and even have some ideas myself.
>
> However without commenting on the technical merits of this specific
> proposal, I think it must be said upfront that the stated goal is not good.
> The largest technical concern (ignoring governance) over B2X is that it is
> a rushed, poorly reviewed hard fork. Hard forks should not be rushed, and
> they should receive more than the usual level of expert and community
> review.
>
> I’m that light, doing an even more rushed hard fork on an even newer idea
> with even less review would be hypocritical at best. I would suggest
> reframing as a hardfork wishlist research problem for the next properly
> planned hard fork, if one occurs. You might also find the hardfork research
> group a more accommodating venue for this discussion:
>
> https://bitcoinhardforkresearch.github.io/
>
> On Oct 9, 2017, at 3:57 PM, Scott Roberts via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Sorry, my previous email did not have the plain text I intended.
>
> Background:
>
> The bitcoin difficulty algorithm does not seem to be a good one. If there
> is a fork due to miners seeking maximum profit without due regard to
> security, users, and nodes, the "better" coin could end up being the
> minority chain. If 90% of hashrate is really going to at least initially
> go
> towards using SegWit2x, BTC would face 10x delays in confirmations
> until the next difficulty adjustment, negatively affecting its price
> relative
> to BTC1, causing further delays from even more miner abandonment
> (until the next adjustment). The 10% miners remaining on BTC do not
> inevitably lose by staying to endure 10x delays because they have 10x
> less competition, and the same situation applies to BTC1 miners. If the
> prices are the same and stable, all seems well for everyone, other things
> aside. But if the BTC price does not fall to reflect the decreased
> hashrate,
> he situation seems to be a big problem for both coins: BTC1 miners will
> jump back to BTC when the difficulty adjustment occurs, initiating a
> potentially never-ending oscillation between the two coins, potentially
> worse than what BCH is experiencing.  They will not issue coins too fast
> like BCH because that is a side effect of the asymmetry in BCH's rise and
> fall algorithm.
>
> Solution:
>
> Hard fork to implement a new difficulty algorithm that uses a simple
> rolling
> average with a much smaller window.  Many small coins have done this as
> a way to stop big miners from coming on and then suddenly leaving, leaving
> constant miners stuck with a high difficulty for the rest of a (long)
> averaging
> window.  Even better, adjust the reward based on recent solvetimes to
> motivate more mining (or less) if the solvetimes are too slow (or too
> fast).
> This will keep keep coin issuance rate perfectly on schedule with real
> time.
>
> I recommend the following for Bitcoin, as fast, simple, and better than
> any
> other difficulty algorithm I'm aware of.  This is the result of a lot of
> work the
> past year.
>
> === Begin difficulty algorithm ===
> # Zawy v6 difficulty algorithm (modified for bitcoin)
> # Unmodified Zawy v6 for alt coins:
> # http://zawy1.blogspot.com/2017/07/best-difficulty-
> algorithm-zawy-v1b.html
> # All my failed attempts at something better:
> # https://github.com/seredat/karbowanec/commit/
> 231db5270acb2e673a641a1800be910ce345668a
> #
> # Keep negative solvetimes to correct bad timestamps.
> # Do not be tempted to use:
> # next_D = sum(last N Ds) * T / [max(last N TSs) - min(last N TSs];
> # ST= Solvetime, TS = timestamp
>
> # set constants until next hard fork:
>
> T=600; # coin's TargetSolvetime
> N=30; # Averaging window. Smoother than N=15, faster response than N=60.
> X=5;
> limit = X^(2/N); # limit rise and fall in case of timestamp manipulation
> adjust = 1/(1+0.67/N);  # keeps avg solvetime on track
>
> # begin difficulty algorithm
>
> avg_ST=0; avg_D=0;
> for ( i=height;  i > height-N;  i--) {  # go through N most recent blocks
> avg_ST += (TS[i] - TS[i-1]) / N;
> avg_D += D[i]/N;
> }
> avg_ST = T*limit if avg_ST > T*limit;
> avg_ST = T/limit if avg_ST < T/limit;
>
> next_D = avg_D * T / avg_ST * adjust;
>
> # Tim Olsen suggested changing reward to protect against hash attacks.
> # Karbowanek co

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

[Ben Kloester via bitcoin-dev]

I don't get it. At the moment, the number of Bitcoin is fixed (at 21
million) by the geometric decay of the block reward.

Adding any other means of creating coins besides the existing block reward,
or altering the block reward schedule, is extremely likely to be seen as
messing with fixed supply. And not adding another method to create coins
wouldn't work - because then redemptions would have to come out of miner's
block reward, which I don't imagine they're going to share just because you
ask.

The only way you might convince users that adding a second way to mint
coins is not messing with fixed supply, is if there is some kind of proof
that the number of coins being minted is accounted for by past burnt coins.
We could call this 'regeneration'. But then you also need a way to prevent
double-regeneration, in which the same burnt coins are used as proof twice.

And you would also need per-sidechain accounting, so that you can't just
regenerate burnt coins that were originally burnt for sidechain A when all
you have is coins on sidechain B. But where to put all this logic? Building
a system that enforces the accounting for sidechains into Bitcoin, as Lucas
pointed out, is not much different to just building the sidechain itself
directly into Bitcoin.

And if you did assemble all that, what you have anyway is a two way peg,
which I suspect will be isomorphic to the very sidechain proposals you seem
to be criticising/attempting to do better than.



*Ben Kloester*

On 11 October 2017 at 07:43, Tao Effect via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> What?
>
> That is not correct.
>
> There is a fixed amount of Bitcoin, as I said.
>
> The only difference is what chain it is on.
>
> It is precisely because there is a fixed amount that when you
> burn-to-withdraw you mint on another chain.
>
> I will not respond to any more emails unless they’re from core developers.
> Gotta run.
>
> --
> 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 1:23 PM, James Hudon  wrote:
> >
> > You're asking for newly minted bitcoin to go to you but you burned the
> bitcoin used in the peg. You're effectively losing your money and then
> stealing from the miners to gain it back. The miners had to issue your
> amount of bitcoin 2 times (once for your original bitcoin, again to make
> you whole). Why would they agree to this?
> > --
> > hudon
> >
> >> On Oct 10, 2017, at 13:13, Tao Effect via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> It would not change the number of Bitcoins in existence.
> >>
> >> --
> >> 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 12:50 PM, CryptAxe  wrote:
> >>>
> >>> 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 Szto

Re: [bitcoin-dev] New difficulty algorithm needed for SegWit2x fork? (reformatted text)

[ZmnSCPxj via bitcoin-dev]

Good morning Ben,

I am not Mark, and I am nowhere near being a true Core developer yet, but I 
would like to point out that even under a 51% attack, there is a practical 
limit to the number of blocks that can be orphaned.  It would still take years 
to rewrite history from the Genesis block, for instance.

What little data we have (BT1 / BT2 price ratio on BitFinex) suggests that 
tokens solely on the 2X chain will not be valued as highly as tokens solely on 
the Core chain.  As miners generate tokens that are only for a specific chain, 
they will have higher incentive to gain tokens on the Core chain rather than 
the 2X chain.

As is commonly said, hodling is free, whereas mining is not.  Hodlers have much 
greater power in hardfork situations than miners have: simply by selling their 
tokens on the 2X chain and not in the Core chain, hodlers can impose economic 
disincentives for mining of the 2X chain.

Miners can switch to BCH, but that is valued even less than BT2 tokens are, and 
thus even less attractive to mine on.

We should also pay attention, that BCH changed its difficulty algorithm, and it 
is often considered to be to its detriment due to sudden hashpower oscillations 
on that chain.  We should be wary of difficulty algorithm changes, as it is the 
difficulty which determines the security of the chain.

--

If we attempt to deploy a difficulty change, that is a hardfork, and hodlers 
will be divided on this situation.  Some will sell the tokens on the 
difficulty-change hardfork, some will sell the tokens on the 
non-difficulty-change hardfork.  Thus the economic punishment for mining the 2X 
chain will be diluted due to the introduction of the difficulty-change 
hardfork, due to splitting of the hodler base that passes judgment over 
development.

Thus, strategy-wise, it is better to not hardfork (whether difficulty 
adjustment, PoW change, or so on) in response to a contentious hardfork, as 
hodlers can remain united against or for the contentious hardfork.  Instead, it 
is better to let the market decide, which automatically imposes economic 
sanctions on miners who choose against the market's decision.  Thus, it is 
better to simply let 2X die under the hands of our benevolent hodlers.

Later, when it is obvious which fate is sealed, we can reconsider such changes 
(difficulty adjustment, PoW change, block size) when things are calmer.  
However, such changes cannot be safely done in response to a contentious 
hardfork.

--

If indeed the Core chain is eradicated, then Bitcoin indeed has failed and I 
would very much rather sell my hodlings and find some other means to amuse 
myself.

Regards,
ZmnSCPxj___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] New difficulty algorithm needed for SegWit2x fork? (reformatted text)

[Mark Friedenbach via bitcoin-dev]

You phrase the question as if “deploying a hard fork to bitcoin” would protect 
the bitcoin chain from the attack. But that’s not what happens. If you are hard 
forking from the perspective of deployed nodes, you are an different ledger, 
regardless of circumstance or who did it. Instead of there being one altcoin 
fighting to take hashpower from bitcoin, there’d now be 2. It is not at all 
obvious to me that this would be a better outcome.

If that isn’t reason enough, changing the difficulty adjustment algorithm 
doesn’t solve the underlying issue―hashpower not being aligned with users’ (or 
even its owners’) interests. Propose a fix to the underlying cause and that 
might be worth considering, if it passes peer review. But without that you’d 
just be making the state of affairs arguably worse.

And so yes, *if* this incentive problem can’t be solved, and the unaltered 
bitcoin chain dies from disuse after suffering a hashpower attack, especially a 
centrally and/or purposefully instigated one, then bitcoin would be failed a 
failed project.

The thesis (and value proposition) of bitcoin is that a particular category of 
economic incentives can be used to solve the problem of creating a secure 
trustess ledger. If those incentives failed, then he thesis of bitcoin would 
have been experimentally falsified, yes. Maybe the incentives can be made 
better to save the project, but we’d have to fix the source of the problem not 
the symptoms.

> On Oct 10, 2017, at 6:44 PM, Ben Kloester  wrote:
> 
> Mark, this seems an awful lot like an answer of "no", to my question "Is 
> there a contingency plan in the case that the incumbent chain following the 
> Bitcoin Core consensus rules comes under 51% attack?" - is this a correct 
> interpretation?
> 
> In fact, beyond a no, it seems like a "no, and I disagree with the idea of 
> creating one".
> 
> So if Bitcoin comes under successful 51%, the project, in your vision, has 
> simply failed?
> 
> Ben Kloester
> 
> 
>> On 10 October 2017 at 13:19, Mark Friedenbach via bitcoin-dev 
>>  wrote:
>> The problem of fast acting but non vulnerable difficulty adjustment 
>> algorithms is interesting. I would certainly like to see this space further 
>> explored, and even have some ideas myself.
>> 
>> However without commenting on the technical merits of this specific 
>> proposal, I think it must be said upfront that the stated goal is not good. 
>> The largest technical concern (ignoring governance) over B2X is that it is a 
>> rushed, poorly reviewed hard fork. Hard forks should not be rushed, and they 
>> should receive more than the usual level of expert and community review.
>> 
>> I’m that light, doing an even more rushed hard fork on an even newer idea 
>> with even less review would be hypocritical at best. I would suggest 
>> reframing as a hardfork wishlist research problem for the next properly 
>> planned hard fork, if one occurs. You might also find the hardfork research 
>> group a more accommodating venue for this discussion:
>> 
>> https://bitcoinhardforkresearch.github.io/
>> 
>>> On Oct 9, 2017, at 3:57 PM, Scott Roberts via bitcoin-dev 
>>>  wrote:
>>> 
>>> Sorry, my previous email did not have the plain text I intended.
>>> 
>>> Background: 
>>> 
>>> The bitcoin difficulty algorithm does not seem to be a good one. If there 
>>> is a fork due to miners seeking maximum profit without due regard to 
>>> security, users, and nodes, the "better" coin could end up being the 
>>> minority chain. If 90% of hashrate is really going to at least initially go 
>>> towards using SegWit2x, BTC would face 10x delays in confirmations 
>>> until the next difficulty adjustment, negatively affecting its price 
>>> relative 
>>> to BTC1, causing further delays from even more miner abandonment 
>>> (until the next adjustment). The 10% miners remaining on BTC do not 
>>> inevitably lose by staying to endure 10x delays because they have 10x 
>>> less competition, and the same situation applies to BTC1 miners. If the 
>>> prices are the same and stable, all seems well for everyone, other things 
>>> aside. But if the BTC price does not fall to reflect the decreased 
>>> hashrate, 
>>> he situation seems to be a big problem for both coins: BTC1 miners will 
>>> jump back to BTC when the difficulty adjustment occurs, initiating a 
>>> potentially never-ending oscillation between the two coins, potentially 
>>> worse than what BCH is experiencing.  They will not issue coins too fast 
>>> like BCH because that is a side effect of the asymmetry in BCH's rise and 
>>> fall algorithm. 
>>> 
>>> Solution: 
>>> 
>>> Hard fork to implement a new difficulty algorithm that uses a simple 
>>> rolling 
>>> average with a much smaller window.  Many small coins have done this as 
>>> a way to stop big miners from coming on and then suddenly leaving, leaving 
>>> constant miners stuck with a high difficulty for the rest of a (long) 
>>> averaging 
>>> window.  Even better, adjust the reward based