From rhavar at protonmail.com  Sun Jul  2 20:35:22 2017
From: rhavar at protonmail.com (Rhavar)
Date: Sun, 02 Jul 2017 16:35:22 -0400
Subject: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions
Message-ID: <uupN1N30M_M_-fb7bBfHgn2XnpTpRNWCP3BpFiHXDHQiWqUf4u3POgd58tpDZS5fQjSst59JaxFdIRb7qt9Hb8V9QHHKqe0YBAW0XnRBqiw=@protonmail.com>

==Abstract==
BIP125 allows transactions to opt into replaceability with a primary use case
of allowing users to increase the fees of unconfirming transactions, helping create
a more efficient fee market place.
However this goal is hindered when the receiver of a transaction spends from the
unconfirmed output, which exposes the sender to the awkward position of needing
to pick between needing to pay an effectively unbounded amount of money as per the BIP125 rules, or not fee bump at all.
This is especially problematic in the case of batched sends in which there are
multiple independent receivers. In practice this means wallets and services can not effectively low ball the fee of transactions, with the intention of fee bumping due to the risk of the receiver spending or sweeping it before it confirms.
In order to support a healthy fee marketplace, this proposal aims to increase
the utility of bip125 by making transactions that spend an unconfirmed BIP125
output non-standard.
==Summary==
This policy specifies a max chain depth of 1 for any BIP125 transactions.
==Impact==
Receivers of BIP125 transactions will need to wait until the transaction
has confirmed before spending from it. This will not be significantly different
than it is currently as they receivers need to be monitoring for replacements.
If senders want to make further transactions before the BIP125 transaction confirms,
and need to utilize the change of the transaction: they will need to replace the
transaction with a one that makes the other send in "pass through" style or first
finalize the BIP125 transaction and then chain from the spend normally.

-Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170702/4e901484/attachment.html>

From greg at xiph.org  Sun Jul  2 20:56:07 2017
From: greg at xiph.org (Gregory Maxwell)
Date: Sun, 2 Jul 2017 20:56:07 +0000
Subject: [bitcoin-dev] BIP proposal: No chaining off replaceable
	transactions
In-Reply-To: <uupN1N30M_M_-fb7bBfHgn2XnpTpRNWCP3BpFiHXDHQiWqUf4u3POgd58tpDZS5fQjSst59JaxFdIRb7qt9Hb8V9QHHKqe0YBAW0XnRBqiw=@protonmail.com>
References: <uupN1N30M_M_-fb7bBfHgn2XnpTpRNWCP3BpFiHXDHQiWqUf4u3POgd58tpDZS5fQjSst59JaxFdIRb7qt9Hb8V9QHHKqe0YBAW0XnRBqiw=@protonmail.com>
Message-ID: <CAAS2fgQGDFOm+vmPuJJU2=hpdZE6KC5WPzY6utvFk_g5wPQ58g@mail.gmail.com>

On Sun, Jul 2, 2017 at 8:35 PM, Rhavar via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> ==Abstract==
>
> BIP125 allows transactions to opt into replaceability with a primary use
> case
> of allowing users to increase the fees of unconfirming transactions, helping
> create
> a more efficient fee market place.

I don't really see how this is desirable:  Just replace it-- the
receiver foolishly spent it at its own peril, spending a unconfirmed
payment from a third party is something that Core never does, it's
reckless unless you're doing something like CPFPing it to yourself,
which is harmless (either it'll work, or it'll fail and you'll be fine
with that).

Beyond being paternalistic the issue I see with your proposal is that
its contrary to miner income-- you're asking miners to ignore these
spends that otherwise they could accept.  This seems unstable-- some
people would ignore your rule even if it were otherwise widely
adopted, leading to the network behavior having higher volatility.

Instead, perhaps a BIP that very strongly advises parties to not spend
unconfirmed outputs from third parties while making a payment to third
parties would achieve your end?

From rhavar at protonmail.com  Sun Jul  2 21:01:19 2017
From: rhavar at protonmail.com (Rhavar)
Date: Sun, 02 Jul 2017 17:01:19 -0400
Subject: [bitcoin-dev] BIP proposal: No chaining off replaceable
	transactions
In-Reply-To: <CAAS2fgQGDFOm+vmPuJJU2=hpdZE6KC5WPzY6utvFk_g5wPQ58g@mail.gmail.com>
References: <uupN1N30M_M_-fb7bBfHgn2XnpTpRNWCP3BpFiHXDHQiWqUf4u3POgd58tpDZS5fQjSst59JaxFdIRb7qt9Hb8V9QHHKqe0YBAW0XnRBqiw=@protonmail.com>
	<CAAS2fgQGDFOm+vmPuJJU2=hpdZE6KC5WPzY6utvFk_g5wPQ58g@mail.gmail.com>
Message-ID: <i0RP2rjFVA8h3PMYT7lbELniTxCKKpcjayO9cRygp2qVyURqIbGPMXvJ1RVjgsJIRU9HcE4-ud2Vt5d8qYWGKfDxE1jeFtbRMSim5Mis-6c=@protonmail.com>

> I don"t really see how this is desirable: Just replace it-
That's not really realistic. In practice some receivers do big sweeps and include unconfirmed inputs. Replacing the transaction means you need to pay the cost of the sweep, which you probably don't want to do (can be in the order of $100s of dollars).
> Beyond being paternalistic the issue I see with your proposal is thatits contrary to miner income
This applies to pretty much all non-standard transactions.

-Ryan

> -------- Original Message --------
> Subject: Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions
> Local Time: July 2, 2017 3:56 PM
> UTC Time: July 2, 2017 8:56 PM
> From: greg at xiph.org
> To: Rhavar <rhavar at protonmail.com>
> bitcoin-dev at lists.linuxfoundation.org <bitcoin-dev at lists.linuxfoundation.org>
> On Sun, Jul 2, 2017 at 8:35 PM, Rhavar via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> ==Abstract==
>>
>> BIP125 allows transactions to opt into replaceability with a primary use
>> case
>> of allowing users to increase the fees of unconfirming transactions, helping
>> create
>> a more efficient fee market place.
> I don"t really see how this is desirable: Just replace it-- the
> receiver foolishly spent it at its own peril, spending a unconfirmed
> payment from a third party is something that Core never does, it"s
> reckless unless you"re doing something like CPFPing it to yourself,
> which is harmless (either it"ll work, or it"ll fail and you"ll be fine
> with that).
> Beyond being paternalistic the issue I see with your proposal is that
> its contrary to miner income-- you"re asking miners to ignore these
> spends that otherwise they could accept. This seems unstable-- some
> people would ignore your rule even if it were otherwise widely
> adopted, leading to the network behavior having higher volatility.
> Instead, perhaps a BIP that very strongly advises parties to not spend
> unconfirmed outputs from third parties while making a payment to third
> parties would achieve your end?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170702/5b724d82/attachment.html>

From luke at dashjr.org  Sun Jul  2 21:10:19 2017
From: luke at dashjr.org (Luke Dashjr)
Date: Sun, 2 Jul 2017 21:10:19 +0000
Subject: [bitcoin-dev] BIP proposal: No chaining off replaceable
	transactions
In-Reply-To: <uupN1N30M_M_-fb7bBfHgn2XnpTpRNWCP3BpFiHXDHQiWqUf4u3POgd58tpDZS5fQjSst59JaxFdIRb7qt9Hb8V9QHHKqe0YBAW0XnRBqiw=@protonmail.com>
References: <uupN1N30M_M_-fb7bBfHgn2XnpTpRNWCP3BpFiHXDHQiWqUf4u3POgd58tpDZS5fQjSst59JaxFdIRb7qt9Hb8V9QHHKqe0YBAW0XnRBqiw=@protonmail.com>
Message-ID: <201707022110.21325.luke@dashjr.org>

This isn't BIP material, as it merely describes a local policy.

(BIP125 itself is also local policy, but one that involves standardisation 
since it expresses how wallets interoperate with nodes with that policy.)

If you wish to suggest this policy change, you should just implement it and 
open a merge/pull request on the applicable project.

Luke


On Sunday 02 July 2017 8:35:22 PM Rhavar via bitcoin-dev wrote:
> ==Abstract==
> BIP125 allows transactions to opt into replaceability with a primary use
> case of allowing users to increase the fees of unconfirming transactions,
> helping create a more efficient fee market place.
> However this goal is hindered when the receiver of a transaction spends
> from the unconfirmed output, which exposes the sender to the awkward
> position of needing to pick between needing to pay an effectively
> unbounded amount of money as per the BIP125 rules, or not fee bump at all.
> This is especially problematic in the case of batched sends in which there
> are multiple independent receivers. In practice this means wallets and
> services can not effectively low ball the fee of transactions, with the
> intention of fee bumping due to the risk of the receiver spending or
> sweeping it before it confirms. In order to support a healthy fee
> marketplace, this proposal aims to increase the utility of bip125 by
> making transactions that spend an unconfirmed BIP125 output non-standard.
> ==Summary==
> This policy specifies a max chain depth of 1 for any BIP125 transactions.
> ==Impact==
> Receivers of BIP125 transactions will need to wait until the transaction
> has confirmed before spending from it. This will not be significantly
> different than it is currently as they receivers need to be monitoring for
> replacements. If senders want to make further transactions before the
> BIP125 transaction confirms, and need to utilize the change of the
> transaction: they will need to replace the transaction with a one that
> makes the other send in "pass through" style or first finalize the BIP125
> transaction and then chain from the spend normally.
> 
> -Ryan

From truthcoin at gmail.com  Sun Jul  2 21:32:50 2017
From: truthcoin at gmail.com (Paul Sztorc)
Date: Sun, 2 Jul 2017 17:32:50 -0400
Subject: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
 Merge Mined drivechains
In-Reply-To: <lYqi6yZAdUknHWs2DvSaM3h1tf3EVLngILZV9gbVBm5JVI96RvBGZaPBEFYNzt0QBkjdJ614BTsWjUkmuuqSd7RPFx-ihUL6SIXocqyW_ss=@protonmail.com>
References: <CAGL6+mHQ_vMc2JYVqwfP89WOZdUF2WDtWfh7ccL1PQve=nC+zQ@mail.gmail.com>
	<OozQK1_gWeExd5578AYH_dHnSKSvx63FJc2rIBBcaJF4f07qzsR8rr-ka5epwMFCjqDuidAWZiZqqlvn4xvSuUpDY0KkV014VQs6_E3Rp_A=@protonmail.com>
	<2f2e6b7c-2d47-518a-5a8f-0b5333607aac@gmail.com>
	<lYqi6yZAdUknHWs2DvSaM3h1tf3EVLngILZV9gbVBm5JVI96RvBGZaPBEFYNzt0QBkjdJ614BTsWjUkmuuqSd7RPFx-ihUL6SIXocqyW_ss=@protonmail.com>
Message-ID: <98d35291-5948-cb06-c46a-9d209276cee2@gmail.com>

Hi,

Sorry for the delay, I overlooked this email until now. I see that Chris
and CryptAxe both answered but I will also answer, because the message
was addressed to me.

On 6/30/2017 12:00 AM, ZmnSCPxj wrote:
> >Your way is actually very similar to mine. Mine _forces_ the bribe to be
> >in the earliest txn (the coinbase) and to only occur once. Yours doesn"t
> >do anything to refund the briber, if the sidechain (but not the
> >mainchain) reorganizes (as it can easily do, if an older sidechain
> >parent is extended while the mainchain proceeds normally). This creates
> >additional risk.
>
> I don't understand this part.  In my scheme, a sidechain cannot
> reorganize unless the mainchain reorganizes, since the consensus loop
> only cares about matching the current block; it ignores splits and
> does not consider them valid.

If I've understood you correctly, you have said that each OP Return
links the (ex)-latest block to a brand new block, and that whichever
message of this kind comes first (in the mainchain) wins and the rest
are discarded.

So what if I had a sidechain represented by a jumble of capital letters,
discarded entries as lowercase letters.

Mainchain Block #200001:  [0 --> Q], [0 -->v], [0 -->s], [0 -->b],
Mainchain Block #200002:  [Q --> H], [Q --> z],
Mainchain Block #200003:  [H --> F]
Mainchain Block #200004:  [F --> J], [F -->w]
Mainchain Block #200005:  [H --> P], [J -->x]
Mainchain Block #200006:  [P --> D]

Isn't the chain {{ Q --> H --> F --> J  }} now starting to reorg, with a
competing chain {{ Q --> H --> P --> D  }} ?

> But I suppose you are considering something like the Ethereum
> mutability feature, which I do not think is something you would want
> in a sidechain.

What I do want to do, is retain the existing model to some extent.
Specifically, to the degree where sidechains could salvage some bad
situations (eg value overflow incident, or March 2013 incident).

> >I think mine is also much more space-efficient. Even if ours each had
> >exactly one h* per sidechain per block, it seems that I only require one
> >hash to be communicated (plus an indicator byte, and a ~2 byte counter
> >for the ratchet), whereas you require two. Since its overhead per
> >sidechain per block, it actually might really add up.
>
> Do you not provide a single sidechain's h* twice in the block?  Once
> in the coinbase and once in the briber's separate transaction?
That is a good point. Technically, we do include it twice, but the
second instance (briber-transaction) can be "shuffled" out if the
counterparties are part of the same Lightning Network (which I expect to
the be the case, in equilibrium).

>
> In my scheme at least there is no indicator byte -- the "previous
> block" hash is the indicator of which sidechain it is extending.  From
> your other emails on this list, it seems the ratchet is for
> withdrawals from sidechain to mainchain?  If so, should it not only
> appear in only some of the sidechains (the ones which are currently
> doing some withdrawal?)?

No, sorry. There are many tangled issues (Drivechain (total system);
side-to-main withdrawals (OP CountACKs); individual Drivechains
themselves; Blind Merged Mining (OP BribeVerify)). The ratchet is not
about withdrawals, it is exclusively about Blind Merged Mining, and
making a better OP BribeVerify that offers better guarantees to both sides.

Paul


From greg at xiph.org  Mon Jul  3 02:28:34 2017
From: greg at xiph.org (Gregory Maxwell)
Date: Mon, 3 Jul 2017 02:28:34 +0000
Subject: [bitcoin-dev] BIP proposal: No chaining off replaceable
	transactions
In-Reply-To: <i0RP2rjFVA8h3PMYT7lbELniTxCKKpcjayO9cRygp2qVyURqIbGPMXvJ1RVjgsJIRU9HcE4-ud2Vt5d8qYWGKfDxE1jeFtbRMSim5Mis-6c=@protonmail.com>
References: <uupN1N30M_M_-fb7bBfHgn2XnpTpRNWCP3BpFiHXDHQiWqUf4u3POgd58tpDZS5fQjSst59JaxFdIRb7qt9Hb8V9QHHKqe0YBAW0XnRBqiw=@protonmail.com>
	<CAAS2fgQGDFOm+vmPuJJU2=hpdZE6KC5WPzY6utvFk_g5wPQ58g@mail.gmail.com>
	<i0RP2rjFVA8h3PMYT7lbELniTxCKKpcjayO9cRygp2qVyURqIbGPMXvJ1RVjgsJIRU9HcE4-ud2Vt5d8qYWGKfDxE1jeFtbRMSim5Mis-6c=@protonmail.com>
Message-ID: <CAAS2fgTwYJ+paz5k8HP5Y0jz3_9a9sjApyUsYpZEmrYea5VhpQ@mail.gmail.com>

On Sun, Jul 2, 2017 at 9:01 PM, Rhavar <rhavar at protonmail.com> wrote:
> That's not really realistic. In practice some receivers do big sweeps and
> include unconfirmed inputs. Replacing the transaction means you need to pay
> the cost of the sweep, which you probably don't want to do (can be in the
> order of $100s of dollars).

Perhaps I am not following what you're saying here.

If the receiver is paying a higher feerate than your replacement,
he'll get it confirmed as fast or faster than your replacement in any
case.

From rhavar at protonmail.com  Mon Jul  3 03:02:44 2017
From: rhavar at protonmail.com (Rhavar)
Date: Sun, 02 Jul 2017 23:02:44 -0400
Subject: [bitcoin-dev] BIP proposal: No chaining off replaceable
	transactions
In-Reply-To: <CAAS2fgTwYJ+paz5k8HP5Y0jz3_9a9sjApyUsYpZEmrYea5VhpQ@mail.gmail.com>
References: <uupN1N30M_M_-fb7bBfHgn2XnpTpRNWCP3BpFiHXDHQiWqUf4u3POgd58tpDZS5fQjSst59JaxFdIRb7qt9Hb8V9QHHKqe0YBAW0XnRBqiw=@protonmail.com>
	<CAAS2fgQGDFOm+vmPuJJU2=hpdZE6KC5WPzY6utvFk_g5wPQ58g@mail.gmail.com>
	<i0RP2rjFVA8h3PMYT7lbELniTxCKKpcjayO9cRygp2qVyURqIbGPMXvJ1RVjgsJIRU9HcE4-ud2Vt5d8qYWGKfDxE1jeFtbRMSim5Mis-6c=@protonmail.com>
	<CAAS2fgTwYJ+paz5k8HP5Y0jz3_9a9sjApyUsYpZEmrYea5VhpQ@mail.gmail.com>
Message-ID: <g7lk-YxVIztIZUQxt6-I3FCQoagNsr7Ol787gAnQD-ZGc_Py_v42lmOzeIdgb447960GqhtezPOVHYefjkn88w0Myw-bYXgiU_CooQ4rX-w=@protonmail.com>

> Perhaps I am not following what you"re saying here.
> If the receiver is paying a higher feerate than your replacement,
> he"ll get it confirmed as fast or faster than your replacement in any
> case.

It actually doesn't really matter much.
Let's say I want to pay Alice and Bob (unrelated entities), so I send it to them (together) with a low-fee transaction of paying 50 sat/byte. After an hour it's obvious that it's not confirmed (maybe there was a big backlog, or no blocks mined), so I want to replace my small transaction with one that pays 70 sat/byte.
But in the mean time, Alice has swept her wallet (or used a service that has done so) and generated 50KB of descendant transactions paying 40 sat/byte (i.e. total fees of 0.02 BTC or $50).
According to the BIP125 rules, I would need to pay for the cost of invalidating all the transactions (an absolute higher amount of fee) along with the replay cost of the descendant transactions.
So in this case, for me to fee bump the transaction I'm looking at throwing away $50 because of descendant transactions that were totally out of my control. If I don't fee bump, I violate my promise to Bob to pay in a timely manner (and also probably Alice, as it wasn't in her control she was using an exchange that did this).
If I guarantee to fee bump, the amount I risk is effectively unbounded. And even if the descendant transactions have a higher fee rate, and are assisting by CPFP boosting my transaction -- it very well might not be enough.
--
The idea of this proposal comes from the problems *in practice* of trying to low-ball fee estimation with scheduled continuous fee bumps until it confirms. At the moment it's not viable, but if this proposal was adopted then it would be.
Personally I think it's of critical piece of having a stable fee market. Fee estimation is a fools game, even the new and improved fee estimation in master today was suggesting x30 fees to what was required (and I successfully made transactions with). People (and especially services) being able to be able to dynamically increase their fees sanely when dealing with withdrawals (and especially batched ones) will go a long way to helping the overall ecosystem.

-Ryan

> -------- Original Message --------
> Subject: Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions
> Local Time: July 2, 2017 9:28 PM
> UTC Time: July 3, 2017 2:28 AM
> From: greg at xiph.org
> To: Rhavar <rhavar at protonmail.com>
> bitcoin-dev at lists.linuxfoundation.org <bitcoin-dev at lists.linuxfoundation.org>
> On Sun, Jul 2, 2017 at 9:01 PM, Rhavar <rhavar at protonmail.com> wrote:
>> That"s not really realistic. In practice some receivers do big sweeps and
>> include unconfirmed inputs. Replacing the transaction means you need to pay
>> the cost of the sweep, which you probably don"t want to do (can be in the
>> order of $100s of dollars).
> Perhaps I am not following what you"re saying here.
> If the receiver is paying a higher feerate than your replacement,
> he"ll get it confirmed as fast or faster than your replacement in any
> case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170702/a1b04eb8/attachment.html>

From james.hilliard1 at gmail.com  Mon Jul  3 04:17:08 2017
From: james.hilliard1 at gmail.com (James Hilliard)
Date: Sun, 2 Jul 2017 23:17:08 -0500
Subject: [bitcoin-dev] BIP proposal: No chaining off replaceable
	transactions
In-Reply-To: <g7lk-YxVIztIZUQxt6-I3FCQoagNsr7Ol787gAnQD-ZGc_Py_v42lmOzeIdgb447960GqhtezPOVHYefjkn88w0Myw-bYXgiU_CooQ4rX-w=@protonmail.com>
References: <uupN1N30M_M_-fb7bBfHgn2XnpTpRNWCP3BpFiHXDHQiWqUf4u3POgd58tpDZS5fQjSst59JaxFdIRb7qt9Hb8V9QHHKqe0YBAW0XnRBqiw=@protonmail.com>
	<CAAS2fgQGDFOm+vmPuJJU2=hpdZE6KC5WPzY6utvFk_g5wPQ58g@mail.gmail.com>
	<i0RP2rjFVA8h3PMYT7lbELniTxCKKpcjayO9cRygp2qVyURqIbGPMXvJ1RVjgsJIRU9HcE4-ud2Vt5d8qYWGKfDxE1jeFtbRMSim5Mis-6c=@protonmail.com>
	<CAAS2fgTwYJ+paz5k8HP5Y0jz3_9a9sjApyUsYpZEmrYea5VhpQ@mail.gmail.com>
	<g7lk-YxVIztIZUQxt6-I3FCQoagNsr7Ol787gAnQD-ZGc_Py_v42lmOzeIdgb447960GqhtezPOVHYefjkn88w0Myw-bYXgiU_CooQ4rX-w=@protonmail.com>
Message-ID: <CADvTj4oWV9iWi1OvnopucgF-Jwbr=ssEeH8FHsFQfSRb+zD6DQ@mail.gmail.com>

This seems like something that might be better dealt with by modifying
the RBF eviction policy to calculate feerate separation between the
transactions in the mempool and opportunistically evict the sweep
transaction+parent if it has a sufficiently different feerate from the
bumped fee replacement. Basically you allow the fee bumped replacement
to evict the sweep transaction+parent if there is more than 1MB of
transactions(or whatever the block size/weight limit is) of
transactions between the sweep transaction+parent feerate and bumped
fee replacement feerate. This way the sweep transaction parent only
gets replaced if it is unlikely that miners would ever produce a block
template with transactions at the sweep transaction+parent feerate at
the same time as the replacement transaction feerate. From the miners
point of view this give a higher fee block template overall since it
would be unlikely that one would see transactions with the feerate of
both the CPFP sweep and the replacement parent in the same block
template.

On Sun, Jul 2, 2017 at 10:02 PM, Rhavar via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Perhaps I am not following what you"re saying here.
>
> If the receiver is paying a higher feerate than your replacement,
> he"ll get it confirmed as fast or faster than your replacement in any
> case.
>
>
> It actually doesn't really matter much.
>
> Let's say I want to pay Alice and Bob (unrelated entities), so I send it to
> them (together) with a low-fee transaction of paying 50 sat/byte. After an
> hour it's obvious that it's not confirmed (maybe there was a big backlog, or
> no blocks mined), so I want to replace my small transaction with one that
> pays 70 sat/byte.
>
> But in the mean time, Alice has swept her wallet (or used a service that has
> done so) and generated 50KB of descendant transactions paying 40 sat/byte
> (i.e. total fees of 0.02 BTC or $50).
>
> According to the BIP125 rules, I would need to pay for the cost of
> invalidating all the transactions (an absolute higher amount of fee) along
> with the replay cost of the descendant transactions.
>
> So in this case, for me to fee bump the transaction I'm looking at throwing
> away $50 because of descendant transactions that were totally out of my
> control.  If I don't fee bump, I violate my promise to Bob to pay in a
> timely manner (and also probably Alice, as it wasn't in her control she was
> using an exchange that did this).
>
> If I guarantee to fee bump, the amount I risk is effectively unbounded. And
> even if the descendant transactions have a higher fee rate, and are
> assisting by CPFP boosting my transaction -- it very well might not be
> enough.
>
> --
>
> The idea of this proposal comes from the problems *in practice* of trying to
> low-ball fee estimation with scheduled continuous fee bumps until it
> confirms. At the moment it's not viable, but if this proposal was adopted
> then it would be.
>
> Personally I think it's of critical piece of having a stable fee market. Fee
> estimation is a fools game, even the new and improved fee estimation in
> master today was suggesting x30 fees to what was required (and I
> successfully made transactions with). People (and especially services) being
> able to be able to dynamically increase their fees sanely when dealing with
> withdrawals (and especially batched ones) will go a long way to helping the
> overall ecosystem.
>
>
> -Ryan
>
>
> -------- Original Message --------
> Subject: Re: [bitcoin-dev] BIP proposal: No chaining off replaceable
> transactions
> Local Time: July 2, 2017 9:28 PM
> UTC Time: July 3, 2017 2:28 AM
> From: greg at xiph.org
> To: Rhavar <rhavar at protonmail.com>
> bitcoin-dev at lists.linuxfoundation.org
> <bitcoin-dev at lists.linuxfoundation.org>
>
> On Sun, Jul 2, 2017 at 9:01 PM, Rhavar <rhavar at protonmail.com> wrote:
>> That"s not really realistic. In practice some receivers do big sweeps and
>> include unconfirmed inputs. Replacing the transaction means you need to
>> pay
>> the cost of the sweep, which you probably don"t want to do (can be in the
>> order of $100s of dollars).
>
> Perhaps I am not following what you"re saying here.
>
> If the receiver is paying a higher feerate than your replacement,
> he"ll get it confirmed as fast or faster than your replacement in any
> case.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

From rhavar at protonmail.com  Mon Jul  3 16:25:33 2017
From: rhavar at protonmail.com (Rhavar)
Date: Mon, 03 Jul 2017 12:25:33 -0400
Subject: [bitcoin-dev] BIP proposal: No chaining off replaceable
	transactions
In-Reply-To: <CAAS2fgQGDFOm+vmPuJJU2=hpdZE6KC5WPzY6utvFk_g5wPQ58g@mail.gmail.com>
References: <uupN1N30M_M_-fb7bBfHgn2XnpTpRNWCP3BpFiHXDHQiWqUf4u3POgd58tpDZS5fQjSst59JaxFdIRb7qt9Hb8V9QHHKqe0YBAW0XnRBqiw=@protonmail.com>
	<CAAS2fgQGDFOm+vmPuJJU2=hpdZE6KC5WPzY6utvFk_g5wPQ58g@mail.gmail.com>
Message-ID: <iDdhZQY7PDg6PB_wvTYaeE9iovhulpKLTM8RQAUo1JD1lioXXIMA3pZud54PXMf9njV0leui0N7AeXjjD6ANTlnam7B26AsgSH7cBIxMfNo=@protonmail.com>

I was told my arguments are a bit incoherent, so I'll try again:

> Beyond being paternalistic the issue I see with your proposal is that
> its contrary to miner income-- you"re asking miners to ignore these
> spends that otherwise they could accept.

It is no more paternalistic than non BIP125 transactions. First of all, I'd like to emphasis we're talking about very small amounts of money, either way it's not going to matter too much as no one is going to care.

> This seems unstable-- some
> people would ignore your rule even if it were otherwise widely
> adopted, leading to the network behavior having higher volatility.

Actually, I believe the opposite. The problematic unconfirmed BIP125 descendants tend to be low fee rate sweeps, that won't be mined any time soon anyway. Miners who ignored that, but instead took the replacement transaction would be able to put it in a block and make more money. The low fee rate sweep will eventually be recreated anyway, with a slightly different set of inputs.
Thus I believe miners who used my policy would make more than miners who didn't.
But the reality is that if my proposal was deployed, people would stop spending from bip125 outputs until they confirm, in the first place. There's no good reason to do so, so no incentive to try route around the network. The only reason people do so now is because they can, and there's no harm in doing so (for things like sweep transactions, where you don't care if you need to keep redoing it). My proposal would drastically simplify feebump logic, and make fee bumps actually predictable.
As a concrete example: bitcoin core's feebump command completely breaks when there exists descendant transactions, and for it it would would not only require a fair bit of logic but a change in interface (so the user can control how much they're willing to lose)
I believe this proposal offers a huge amount of benefits for users/services wanting to make use of bip125 for feebumping, which will result in a more stable fee market. While creating extremely little to no disadvantages.
Unless someone can think of a legitimate use case that spending unconfirmed bip125 transactions is useful?

-Ryan

> -------- Original Message --------
> Subject: Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions
> Local Time: July 2, 2017 3:56 PM
> UTC Time: July 2, 2017 8:56 PM
> From: greg at xiph.org
> To: Rhavar <rhavar at protonmail.com>
> bitcoin-dev at lists.linuxfoundation.org <bitcoin-dev at lists.linuxfoundation.org>
> On Sun, Jul 2, 2017 at 8:35 PM, Rhavar via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> ==Abstract==
>>
>> BIP125 allows transactions to opt into replaceability with a primary use
>> case
>> of allowing users to increase the fees of unconfirming transactions, helping
>> create
>> a more efficient fee market place.
> I don"t really see how this is desirable: Just replace it-- the
> receiver foolishly spent it at its own peril, spending a unconfirmed
> payment from a third party is something that Core never does, it"s
> reckless unless you"re doing something like CPFPing it to yourself,
> which is harmless (either it"ll work, or it"ll fail and you"ll be fine
> with that).
> Beyond being paternalistic the issue I see with your proposal is that
> its contrary to miner income-- you"re asking miners to ignore these
> spends that otherwise they could accept. This seems unstable-- some
> people would ignore your rule even if it were otherwise widely
> adopted, leading to the network behavior having higher volatility.
> Instead, perhaps a BIP that very strongly advises parties to not spend
> unconfirmed outputs from third parties while making a payment to third
> parties would achieve your end?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170703/a5c7b16c/attachment-0001.html>

From ZmnSCPxj at protonmail.com  Tue Jul  4 07:21:23 2017
From: ZmnSCPxj at protonmail.com (ZmnSCPxj)
Date: Tue, 04 Jul 2017 03:21:23 -0400
Subject: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
	Merge Mined drivechains
In-Reply-To: <98d35291-5948-cb06-c46a-9d209276cee2@gmail.com>
References: <CAGL6+mHQ_vMc2JYVqwfP89WOZdUF2WDtWfh7ccL1PQve=nC+zQ@mail.gmail.com>
	<OozQK1_gWeExd5578AYH_dHnSKSvx63FJc2rIBBcaJF4f07qzsR8rr-ka5epwMFCjqDuidAWZiZqqlvn4xvSuUpDY0KkV014VQs6_E3Rp_A=@protonmail.com>
	<2f2e6b7c-2d47-518a-5a8f-0b5333607aac@gmail.com>
	<lYqi6yZAdUknHWs2DvSaM3h1tf3EVLngILZV9gbVBm5JVI96RvBGZaPBEFYNzt0QBkjdJ614BTsWjUkmuuqSd7RPFx-ihUL6SIXocqyW_ss=@protonmail.com>
	<98d35291-5948-cb06-c46a-9d209276cee2@gmail.com>
Message-ID: <GDZ42AMqaETJGYZovJzkVZkxZE3UmCQ8q5fFTAajV6sX2LHFol6iEYahkY_sMrPv5m11lHZvuKXmD_PwXa5_S7x18vcP1FkQr0ZBROxj6HE=@protonmail.com>

Good morning Paul, Chris, and CryptAxe,
@Paul
>> >Your way is actually very similar to mine. Mine _forces_ the bribe to be
>> >in the earliest txn (the coinbase) and to only occur once. Yours doesn"t
>> >do anything to refund the briber, if the sidechain (but not the
>> >mainchain) reorganizes (as it can easily do, if an older sidechain
>> >parent is extended while the mainchain proceeds normally). This creates
>> >additional risk.
>>
>> I don"t understand this part. In my scheme, a sidechain cannot
>> reorganize unless the mainchain reorganizes, since the consensus loop
>> only cares about matching the current block; it ignores splits and
>> does not consider them valid.
>
>If I"ve understood you correctly, you have said that each OP Return
>links the (ex)-latest block to a brand new block, and that whichever
>message of this kind comes first (in the mainchain) wins and the rest
>are discarded.
>
>So what if I had a sidechain represented by a jumble of capital letters,
>discarded entries as lowercase letters.
>
>Mainchain Block #200001: [0 --> Q], [0 -->v], [0 -->s], [0 -->b],
>Mainchain Block #200002: [Q --> H], [Q --> z],
>Mainchain Block #200003: [H --> F]
>Mainchain Block #200004: [F --> J], [F -->w]
>Mainchain Block #200005: [H --> P], [J -->x]
>Mainchain Block #200006: [P --> D]
>
>Isn"t the chain {{ Q --> H --> F --> J }} now starting to reorg, with a
>competing chain {{ Q --> H --> P --> D }} ?
No, because at block #20005, the topmost sidechain block is J, not H, and the H->P will not be considered as valid -- only the J->x is valid, even though H->P comes first.
Please see the pseudocode I sent before in detail and consider how it will work with your given mainchain blocks example.
>> But I suppose you are considering something like the Ethereum
>> mutability feature, which I do not think is something you would want
>> in a sidechain.
>
>What I do want to do, is retain the existing model to some extent.
>Specifically, to the degree where sidechains could salvage some bad
>situations (eg value overflow incident, or March 2013 incident).
I suppose some kinds of mutability are desirable. In my model, a sidechain reorg can be forced if the sidechain code is forked to specifically force some previously-valid block to become invalid, by developer fiat. In the example you gave, basically, if you want to reorg from Q->H->F->J to Q->H->P->D then you would fork the sidechain consensus code to declare that block F is invalid.
I am hesitant to make mutability something that is easy to force, however.
>> >I think mine is also much more space-efficient. Even if ours each had
>> >exactly one h* per sidechain per block, it seems that I only require one
>> >hash to be communicated (plus an indicator byte, and a ~2 byte counter
>> >for the ratchet), whereas you require two. Since its overhead per
>> >sidechain per block, it actually might really add up.
>>
>> Do you not provide a single sidechain"s h* twice in the block? Once
>> in the coinbase and once in the briber"s separate transaction?
>
>That is a good point. Technically, we do include it twice, but the
>second instance (briber-transaction) can be "shuffled" out if the
>counterparties are part of the same Lightning Network (which I expect to
>the be the case, in equilibrium).
Payments on LN are finalized when the payee provides a preimage for a hashlock, whether by chain or by LN. Although I suppose you can use a bribelocked timelocked contract instead of a hashlocked timelocked contract. I suppose it would be almost the same, except the bribelock is provided off-chain as a proof of existence in a mainblock coinbase.
In addition, it may be possible to create a payment channel specifically between a sidechain operator and a mainchain miner.
>> In my scheme at least there is no indicator byte -- the "previous
>> block" hash is the indicator of which sidechain it is extending. From
>> your other emails on this list, it seems the ratchet is for
>> withdrawals from sidechain to mainchain? If so, should it not only
>> appear in only some of the sidechains (the ones which are currently
>> doing some withdrawal?)?
>
>No, sorry. There are many tangled issues (Drivechain (total system);
>side-to-main withdrawals (OP CountACKs); individual Drivechains
>themselves; Blind Merged Mining (OP BribeVerify)). The ratchet is not
>about withdrawals, it is exclusively about Blind Merged Mining, and
>making a better OP BribeVerify that offers better guarantees to both sides.
Can you describe the ratchet better? I am sorry but when I first heard of "blind" merge mining, the first thing that came to mind was the use of OP_RETURN. This is truly blind as the mainchain miner is given what is effectively a blob of data, and the mainchain miner cannot expect any kind of format from OP_RETURN. This has the tremendous advantage of not even requiring a softfork.
@Chris
>What if a attacker pays a large fee to have his *invalid* block hash included in the bitcoin mainchain? Would this block *have* to be included in the sidechain's blockchain forever since *it was* included in bitcoin blockchain?
In my scheme, if you read carefully through the pseudocode, a block list node is valid only if its block is valid.
Basically, in my scheme, the OP_RETURN data *is* the sidechain block headers stored on the mainchain. To save space, the sidechain block headers are reduced to only the previous-block-header commitment and the current-block-data commitment. All of the other data you would want to put in the block header (e.g. UTXO set commitment, signalling bits, time-of-day...) would be part of the current-block-data instead of the block header. Thus if the current-block-data is invalid the sidechain block header is invalid and another sidechain block header based on the previous block header will be searched for.
My understanding is that your attack scenario is not helped by OP_BRIBEVERIFY alone, as a rich sidechain attacker can provide a bigger bribe to an invalid h* especially since the mainchain miner will not even check the h*, just insert it into the coinbase.
>Maybe I am missing something here, but why we do *explicitly* commit to the previous block hash? Isn't it implicitly committed to via SHA256(SHA256())?
In order to eliminate having to specify a sidechain index, and to remove sidechain indexes altogether. Instead the sidechain is identified by its topmost block header hash.
@CryptAxe
>The ratchet system is actually what links the h* data from bribes to sidechain blocks. h*'s (which are sidechain block hashes) are added to the ratchet system if they move the sidechain forward or start a split like I mentioned before. Then a sidechain can request of their local mainchain node to verify the headers they have downloaded from sidechain peers and form the side chain.
I see. However, then, I propose that my OP_RETURN scheme is superior as the sidechain block headers are indeed visible directly on the mainchain, and the mainchain node does not even need to be "local", but can be sourced anywhere, without requiring a ratchet structure (whose purpose I still have not managed to grok).
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170704/0888a4be/attachment.html>

From andreas at schildbach.de  Tue Jul  4 11:50:30 2017
From: andreas at schildbach.de (Andreas Schildbach)
Date: Tue, 4 Jul 2017 13:50:30 +0200
Subject: [bitcoin-dev] BIP proposal: No chaining off replaceable
	transactions
In-Reply-To: <uupN1N30M_M_-fb7bBfHgn2XnpTpRNWCP3BpFiHXDHQiWqUf4u3POgd58tpDZS5fQjSst59JaxFdIRb7qt9Hb8V9QHHKqe0YBAW0XnRBqiw=@protonmail.com>
References: <uupN1N30M_M_-fb7bBfHgn2XnpTpRNWCP3BpFiHXDHQiWqUf4u3POgd58tpDZS5fQjSst59JaxFdIRb7qt9Hb8V9QHHKqe0YBAW0XnRBqiw=@protonmail.com>
Message-ID: <ojfve0$jq6$1@blaine.gmane.org>

Your BIP would take away the only way the *receiver* has to raise the
fee: CPFP. And the receiver is arguably the more important party in this
question. After all the sender has no real incentive for his payment to
be confirmed; it's receiver who has.


On 07/02/2017 10:35 PM, Rhavar via bitcoin-dev wrote:
> ==Abstract==
> 
> BIP125 allows transactions to opt into replaceability with a primary use
> case
> of allowing users to increase the fees of unconfirming transactions,
> helping create
> a more efficient fee market place.
> 
> However this goal is hindered when the receiver of a transaction spends
> from the
> unconfirmed output, which exposes the sender to the awkward position of
> needing
> to pick between needing to pay an effectively unbounded amount of money
> as per the BIP125 rules, or not fee bump at all.
> 
> This is especially problematic in the case of batched sends in which
> there are
> multiple independent receivers. In practice this means wallets and
> services can not effectively low ball the fee of transactions, with the
> intention of fee bumping due to the risk of the receiver spending or
> sweeping it before it confirms.
> 
> In order to support a healthy fee marketplace, this proposal aims to
> increase
> the utility of bip125 by making transactions that spend an unconfirmed
> BIP125
> output non-standard.
> 
> 
> ==Summary==
> 
> This policy specifies a max chain depth of 1 for any BIP125 transactions.
> 
> ==Impact==
> 
> Receivers of BIP125 transactions will need to wait until the transaction
> has confirmed before spending from it. This will not be significantly
> different
> than it is currently as they receivers need to be monitoring for
> replacements.
> 
> If senders want to make further transactions before the BIP125
> transaction confirms,
> and need to utilize the change of the transaction: they will need to
> replace the
> transaction with a one that makes the other send in "pass through" style
> or first
> finalize the BIP125 transaction and then chain from the spend normally.
> 
> 
> -Ryan
> 
> 
> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 



From chris at suredbits.com  Tue Jul  4 15:06:06 2017
From: chris at suredbits.com (Chris Stewart)
Date: Tue, 4 Jul 2017 10:06:06 -0500
Subject: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
 Merge Mined drivechains
In-Reply-To: <GDZ42AMqaETJGYZovJzkVZkxZE3UmCQ8q5fFTAajV6sX2LHFol6iEYahkY_sMrPv5m11lHZvuKXmD_PwXa5_S7x18vcP1FkQr0ZBROxj6HE=@protonmail.com>
References: <CAGL6+mHQ_vMc2JYVqwfP89WOZdUF2WDtWfh7ccL1PQve=nC+zQ@mail.gmail.com>
	<OozQK1_gWeExd5578AYH_dHnSKSvx63FJc2rIBBcaJF4f07qzsR8rr-ka5epwMFCjqDuidAWZiZqqlvn4xvSuUpDY0KkV014VQs6_E3Rp_A=@protonmail.com>
	<2f2e6b7c-2d47-518a-5a8f-0b5333607aac@gmail.com>
	<lYqi6yZAdUknHWs2DvSaM3h1tf3EVLngILZV9gbVBm5JVI96RvBGZaPBEFYNzt0QBkjdJ614BTsWjUkmuuqSd7RPFx-ihUL6SIXocqyW_ss=@protonmail.com>
	<98d35291-5948-cb06-c46a-9d209276cee2@gmail.com>
	<GDZ42AMqaETJGYZovJzkVZkxZE3UmCQ8q5fFTAajV6sX2LHFol6iEYahkY_sMrPv5m11lHZvuKXmD_PwXa5_S7x18vcP1FkQr0ZBROxj6HE=@protonmail.com>
Message-ID: <CAGL6+mEeuhQp3TiLFOOAWO_wcRZXsfASKNT4364SSNzER6_xgw@mail.gmail.com>

Hi ZmnSCPxj,


In my scheme, if you read carefully through the pseudocode, a block list
> node is valid only if its block is valid.
>

It seems this is a contradiction against the "blind" part of blind merge
mining. How can a bitcoin blockchain node enforce this without tracking the
sidechain?

Basically, in my scheme, the OP_RETURN data *is* the sidechain block
> headers stored on the mainchain.  To save space, the sidechain block
> headers are reduced to only the previous-block-header commitment and the
> current-block-data commitment.  All of the other data you would want to put
> in the block header (e.g. UTXO set commitment, signalling bits,
> time-of-day...) would be part of the current-block-data instead of the
> block header.  Thus if the current-block-data is invalid the sidechain
> block header is invalid and another sidechain block header based on the
> previous block header will be searched for.


It seems both of our schemes need to include 2 32 bit hashes in the
blockchain. Your scheme needs a previous block header hash and the current
block header hash, while mine includes the current block header hash
twice.  We can just commit to all that information via the block header
hash and if a sidechain node lies to us will we are doing IBD the hashes
won't match with what was included in the bitcoin blockchain.

I'll follow your discussion with Paul about sidechain reorgs, but I think
his proposal is more desirable -- it follows what actually happens in the
bitcoin mining process where we *can* have chain splits when miners
simultaneously find a block. Other miners will pick one of the two blocks
to mine on top of and eventually one chain will become longer than the
other. Therefore that chain will have it's block's orphaned and the
miners/nodes following the dead chain will reorg on top of the longest
chain.

In Paul's scheme, we replace PoW with a bribe. At the conceptual level
these are somewhat similar. In PoW a miner is willing to pay a certain
amount of money (on electricity) to try to find a bitcoin block. With
OP_BRIBEVERIFY a sidechain miner is willing pay a certain amount of money
to find a block.

In PoW, there is nothing at the software level that says a miner cannot
just decide to build on a old block. I could decide to build on the genesis
block if I wanted to. Obviously this is a stupid idea as I'll never
overtake the bitcoin blockchain with 8 years of PoW behind it -- but it
doesn't mean I couldn't try if I wanted too. Your scheme from what I
understand prevents this from happening -- and I don't think that is
desirable. You might be able to make an argument that a rich attacker can
*stall* mining progress on the drivechain, but I think the same argument
can be made with a rich miner on the bitcoin blockchain as well. I think
miners have threatened to do that if BIP148 caused a chain split.

Can you link to the aforementioned pseudocode? I must have missed it on the
mailing list.

-Chris

On Tue, Jul 4, 2017 at 2:21 AM, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Paul, Chris, and CryptAxe,
>
> @Paul
>
> >> >Your way is actually very similar to mine. Mine _forces_ the bribe to
> be
> >> >in the earliest txn (the coinbase) and to only occur once. Yours
> doesn"t
> >> >do anything to refund the briber, if the sidechain (but not the
> >> >mainchain) reorganizes (as it can easily do, if an older sidechain
> >> >parent is extended while the mainchain proceeds normally). This creates
> >> >additional risk.
> >>
> >> I don"t understand this part. In my scheme, a sidechain cannot
> >> reorganize unless the mainchain reorganizes, since the consensus loop
> >> only cares about matching the current block; it ignores splits and
> >> does not consider them valid.
> >
> >If I"ve understood you correctly, you have said that each OP Return
> >links the (ex)-latest block to a brand new block, and that whichever
> >message of this kind comes first (in the mainchain) wins and the rest
> >are discarded.
> >
> >So what if I had a sidechain represented by a jumble of capital letters,
> >discarded entries as lowercase letters.
> >
> >Mainchain Block #200001: [0 --> Q], [0 -->v], [0 -->s], [0 -->b],
> >Mainchain Block #200002: [Q --> H], [Q --> z],
> >Mainchain Block #200003: [H --> F]
> >Mainchain Block #200004: [F --> J], [F -->w]
> >Mainchain Block #200005: [H --> P], [J -->x]
> >Mainchain Block #200006: [P --> D]
> >
> >Isn"t the chain {{ Q --> H --> F --> J }} now starting to reorg, with a
> >competing chain {{ Q --> H --> P --> D }} ?
>
> No, because at block #20005, the topmost sidechain block is J, not H, and
> the H->P will not be considered as valid -- only the J->x is valid, even
> though H->P comes first.
>
> Please see the pseudocode I sent before in detail and consider how it will
> work with your given mainchain blocks example.
>
>
> >> But I suppose you are considering something like the Ethereum
> >> mutability feature, which I do not think is something you would want
> >> in a sidechain.
> >
> >What I do want to do, is retain the existing model to some extent.
> >Specifically, to the degree where sidechains could salvage some bad
> >situations (eg value overflow incident, or March 2013 incident).
>
> I suppose some kinds of mutability are desirable.  In my model, a
> sidechain reorg can be forced if the sidechain code is forked to
> specifically force some previously-valid block to become invalid, by
> developer fiat.  In the example you gave, basically, if you want to reorg
> from Q->H->F->J to Q->H->P->D then you would fork the sidechain consensus
> code to declare that block F is invalid.
>
> I am hesitant to make mutability something that is easy to force, however.
>
> >> >I think mine is also much more space-efficient. Even if ours each had
> >> >exactly one h* per sidechain per block, it seems that I only require
> one
> >> >hash to be communicated (plus an indicator byte, and a ~2 byte counter
> >> >for the ratchet), whereas you require two. Since its overhead per
> >> >sidechain per block, it actually might really add up.
> >>
> >> Do you not provide a single sidechain"s h* twice in the block? Once
> >> in the coinbase and once in the briber"s separate transaction?
> >
> >That is a good point. Technically, we do include it twice, but the
> >second instance (briber-transaction) can be "shuffled" out if the
> >counterparties are part of the same Lightning Network (which I expect to
> >the be the case, in equilibrium).
>
> Payments on LN are finalized when the payee provides a preimage for a
> hashlock, whether by chain or by LN.  Although I suppose you can use a
> bribelocked timelocked contract instead of a hashlocked timelocked
> contract.  I suppose it would be almost the same, except the bribelock is
> provided off-chain as a proof of existence in a mainblock coinbase.
>
> In addition, it may be possible to create a payment channel specifically
> between a sidechain operator and a mainchain miner.
>
> >> In my scheme at least there is no indicator byte -- the "previous
> >> block" hash is the indicator of which sidechain it is extending. From
> >> your other emails on this list, it seems the ratchet is for
> >> withdrawals from sidechain to mainchain? If so, should it not only
> >> appear in only some of the sidechains (the ones which are currently
> >> doing some withdrawal?)?
> >
> >No, sorry. There are many tangled issues (Drivechain (total system);
> >side-to-main withdrawals (OP CountACKs); individual Drivechains
> >themselves; Blind Merged Mining (OP BribeVerify)). The ratchet is not
> >about withdrawals, it is exclusively about Blind Merged Mining, and
> >making a better OP BribeVerify that offers better guarantees to both
> sides.
>
> Can you describe the ratchet better?  I am sorry but when I first heard of
> "blind" merge mining, the first thing that came to mind was the use of
> OP_RETURN.  This is truly blind as the mainchain miner is given what is
> effectively a blob of data, and the mainchain miner cannot expect any kind
> of format from OP_RETURN.  This has the tremendous advantage of not even
> requiring a softfork.
>
>
> @Chris
>
> >What if a attacker pays a large fee to have his *invalid* block hash
> included in the bitcoin mainchain? Would this block *have* to be included
> in the sidechain's blockchain forever since *it was* included in bitcoin
> blockchain?
>
> In my scheme, if you read carefully through the pseudocode, a block list
> node is valid only if its block is valid.
>
> Basically, in my scheme, the OP_RETURN data *is* the sidechain block
> headers stored on the mainchain.  To save space, the sidechain block
> headers are reduced to only the previous-block-header commitment and the
> current-block-data commitment.  All of the other data you would want to put
> in the block header (e.g. UTXO set commitment, signalling bits,
> time-of-day...) would be part of the current-block-data instead of the
> block header.  Thus if the current-block-data is invalid the sidechain
> block header is invalid and another sidechain block header based on the
> previous block header will be searched for.
>
> My understanding is that your attack scenario is not helped by
> OP_BRIBEVERIFY alone, as a rich sidechain attacker can provide a bigger
> bribe to an invalid h* especially since the mainchain miner will not even
> check the h*, just insert it into the coinbase.
>
> >Maybe I am missing something here, but why we do *explicitly* commit to
> the previous block hash? Isn't it implicitly committed to via
> SHA256(SHA256())?
>
> In order to eliminate having to specify a sidechain index, and to remove
> sidechain indexes altogether.  Instead the sidechain is identified by its
> topmost block header hash.
>
>
> @CryptAxe
>
> >The ratchet system is actually what links the h* data from bribes to
> sidechain blocks. h*'s (which are sidechain block hashes) are added to the
> ratchet system if they move the sidechain forward or start a split like I
> mentioned before. Then a sidechain can request of their local mainchain
> node to verify the headers they have downloaded from sidechain peers and
> form the side chain.
>
> I see.  However, then, I propose that my OP_RETURN scheme is superior as
> the sidechain block headers are indeed visible directly on the mainchain,
> and the mainchain node does not even need to be "local", but can be sourced
> anywhere, without requiring a ratchet structure (whose purpose I still have
> not managed to grok).
>
> Regards,
> ZmnSCPxj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170704/204bed07/attachment-0001.html>

From shaolinfry at protonmail.ch  Wed Jul  5 01:30:26 2017
From: shaolinfry at protonmail.ch (shaolinfry)
Date: Tue, 04 Jul 2017 21:30:26 -0400
Subject: [bitcoin-dev] Height based vs block time based thresholds
Message-ID: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>

Some people have criticized BIP9's blocktime based thresholds arguing they are confusing (the first retarget after threshold). It is also vulnerable to miners fiddling with timestamps in a way that could prevent or delay activation - for example by only advancing the block timestamp by 1 second you would never meet the threshold (although this would come a the penalty of hiking the difficulty dramatically).
On the other hand, the exact date of a height based thresholds is hard to predict a long time in advance due to difficulty fluctuations. However, there is certainty at a given block height and it's easy to monitor.
If there is sufficient interest, I would be happy to amend BIP8 to be height based. I originally omitted height based thresholds in the interests of simplicity of review - but now that the proposal has been widely reviewed it would be a trivial amendment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170704/5ed65add/attachment.html>

From hozer at hozed.org  Wed Jul  5 02:25:33 2017
From: hozer at hozed.org (Troy Benjegerdes)
Date: Wed, 5 Jul 2017 02:25:33 +0000
Subject: [bitcoin-dev] Height based vs block time based thresholds
In-Reply-To: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
References: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
Message-ID: <20170705022533.GH4885@hostname.unassigned>

On Tue, Jul 04, 2017 at 09:30:26PM -0400, shaolinfry via bitcoin-dev wrote:
> Some people have criticized BIP9's blocktime based thresholds arguing they are confusing (the first retarget after threshold). It is also vulnerable to miners fiddling with timestamps in a way that could prevent or delay activation - for example by only advancing the block timestamp by 1 second you would never meet the threshold (although this would come a the penalty of hiking the difficulty dramatically).

If there are miners that start doing 1 second timestamp advances, it would be
simpler (and probably safer) to require a minimum block time spacing of say
30 seconds or 1 minute, and orphan blocks that are too close in time and more
than say an hour behind real-time.

I cannot picture any realistic scenario in which an attempt to block activation
in this way is in anything other than a very expensive temper tantrum for any
miners foolish enough to attempt it.

It *might* be a delay tactic as a 'nuclear option' attack vector for a mining
cabal to run up the difficulty so high as to make it impractical to mine any
new blocks after the adjustment, but there are plenty of altcoins that have
hardforked and gotten along just fine after the same kind of thing due to
profit-switching pools.


> On the other hand, the exact date of a height based thresholds is hard to predict a long time in advance due to difficulty fluctuations. However, there is certainty at a given block height and it's easy to monitor.
> If there is sufficient interest, I would be happy to amend BIP8 to be height based. I originally omitted height based thresholds in the interests of simplicity of review - but now that the proposal has been widely reviewed it would be a trivial amendment.

> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


From bram at bittorrent.com  Wed Jul  5 03:39:09 2017
From: bram at bittorrent.com (Bram Cohen)
Date: Tue, 4 Jul 2017 20:39:09 -0700
Subject: [bitcoin-dev] Height based vs block time based thresholds
In-Reply-To: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
References: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
Message-ID: <CA+KqGkqMtHzxzKObn7OkXsdrP4sKOFm-z1bJWThhPe4jXFmzDw@mail.gmail.com>

On Tue, Jul 4, 2017 at 6:30 PM, shaolinfry via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Some people have criticized BIP9's blocktime based thresholds arguing they
> are confusing (the first retarget after threshold). It is also vulnerable
> to miners fiddling with timestamps in a way that could prevent or delay
> activation - for example by only advancing the block timestamp by 1 second
> you would never meet the threshold (although this would come a the penalty
> of hiking the difficulty dramatically).
>
> On the other hand, the exact date of a height based thresholds is hard to
> predict a long time in advance due to difficulty fluctuations. However,
> there is certainty at a given block height and it's easy to monitor.
>

You could get most of the best of both with a combination of the two: Have
the activation be a timestamp plus a certain number of blocks to come after
maybe about 100, which is more than enough to make sure all the games which
can be played with timestamps have passed but a small enough amount that it
doesn't add much uncertainty to wall clock time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170704/029eec8d/attachment.html>

From luke at dashjr.org  Wed Jul  5 03:50:51 2017
From: luke at dashjr.org (Luke Dashjr)
Date: Wed, 5 Jul 2017 03:50:51 +0000
Subject: [bitcoin-dev] Height based vs block time based thresholds
In-Reply-To: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
References: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
Message-ID: <201707050350.53122.luke@dashjr.org>

I've already opened a PR almost 2 weeks ago to do this and fix the other 
issues BIP 9 has. https://github.com/bitcoin/bips/pull/550

It just needs your ACK to merge.


On Wednesday 05 July 2017 1:30:26 AM shaolinfry via bitcoin-dev wrote:
> Some people have criticized BIP9's blocktime based thresholds arguing they
> are confusing (the first retarget after threshold). It is also vulnerable
> to miners fiddling with timestamps in a way that could prevent or delay
> activation - for example by only advancing the block timestamp by 1 second
> you would never meet the threshold (although this would come a the penalty
> of hiking the difficulty dramatically). On the other hand, the exact date
> of a height based thresholds is hard to predict a long time in advance due
> to difficulty fluctuations. However, there is certainty at a given block
> height and it's easy to monitor. If there is sufficient interest, I would
> be happy to amend BIP8 to be height based. I originally omitted height
> based thresholds in the interests of simplicity of review - but now that
> the proposal has been widely reviewed it would be a trivial amendment.

From luke at dashjr.org  Wed Jul  5 04:10:43 2017
From: luke at dashjr.org (Luke Dashjr)
Date: Wed, 5 Jul 2017 04:10:43 +0000
Subject: [bitcoin-dev] Height based vs block time based thresholds
In-Reply-To: <00qcLaDJFDoC9D6644P_aLf7_n5B1pqCPj_c02QlqySsrJLsB6TZipXMD8L7l3lJcw5NoLP6dphCMruKJCIMkJUIDYbIw0iDd322vsNFmNw=@protonmail.ch>
References: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
	<201707050350.53122.luke@dashjr.org>
	<00qcLaDJFDoC9D6644P_aLf7_n5B1pqCPj_c02QlqySsrJLsB6TZipXMD8L7l3lJcw5NoLP6dphCMruKJCIMkJUIDYbIw0iDd322vsNFmNw=@protonmail.ch>
Message-ID: <201707050410.45217.luke@dashjr.org>

It's not pointless: it's a wake-up call for miners asleep "at the wheel", to 
ensure they upgrade in time. Not having a mandatory signal turned out to be a 
serious bug in BIP 9, and one which is fixed in BIP 148 (and remains a problem 
for BIP 149 as-is). Additionally, it makes the activation decisive and 
unambiguous: once the lock-in period is complete, there remains no question as 
to what the correct protocol rules are.

It also enables deploying softforks as a MASF, and only upgrading them to UASF 
on an as-needed basis.

Luke


On Wednesday 05 July 2017 4:00:38 AM shaolinfry wrote:
> Luke,
> I previously explored an extra state to require signalling before
> activation in an earlier draft of BIP8, but the overall impression I got
> was that gratuitous orphaning was undesirable, so I dropped it. I
> understand the motivation behind it (to ensure miners are upgraded), but
> it's also rather pointless when miners can just fake signal. A properly
> constructed soft fork is generally such that miners have to deliberately
> do something invalid - they cannot be tricked into it... and miners can
> always chose to do something invalid anyway.
> 
> > -------- Original Message --------
> > From: luke at dashjr.org
> > To: bitcoin-dev at lists.linuxfoundation.org, shaolinfry
> > <shaolinfry at protonmail.ch> I"ve already opened a PR almost 2 weeks ago
> > to do this and fix the other issues BIP 9 has.
> > https://github.com/bitcoin/bips/pull/550
> > It just needs your ACK to merge.
> > 
> > On Wednesday 05 July 2017 1:30:26 AM shaolinfry via bitcoin-dev wrote:
> >> Some people have criticized BIP9"s blocktime based thresholds arguing
> >> they are confusing (the first retarget after threshold). It is also
> >> vulnerable to miners fiddling with timestamps in a way that could
> >> prevent or delay activation - for example by only advancing the block
> >> timestamp by 1 second you would never meet the threshold (although this
> >> would come a the penalty of hiking the difficulty dramatically). On the
> >> other hand, the exact date of a height based thresholds is hard to
> >> predict a long time in advance due to difficulty fluctuations. However,
> >> there is certainty at a given block height and it"s easy to monitor. If
> >> there is sufficient interest, I would be happy to amend BIP8 to be
> >> height based. I originally omitted height based thresholds in the
> >> interests of simplicity of review - but now that the proposal has been
> >> widely reviewed it would be a trivial amendment.

From shaolinfry at protonmail.ch  Wed Jul  5 04:00:38 2017
From: shaolinfry at protonmail.ch (shaolinfry)
Date: Wed, 05 Jul 2017 00:00:38 -0400
Subject: [bitcoin-dev] Height based vs block time based thresholds
In-Reply-To: <201707050350.53122.luke@dashjr.org>
References: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
	<201707050350.53122.luke@dashjr.org>
Message-ID: <00qcLaDJFDoC9D6644P_aLf7_n5B1pqCPj_c02QlqySsrJLsB6TZipXMD8L7l3lJcw5NoLP6dphCMruKJCIMkJUIDYbIw0iDd322vsNFmNw=@protonmail.ch>

Luke,
I previously explored an extra state to require signalling before activation in an earlier draft of BIP8, but the overall impression I got was that gratuitous orphaning was undesirable, so I dropped it. I understand the motivation behind it (to ensure miners are upgraded), but it's also rather pointless when miners can just fake signal. A properly constructed soft fork is generally such that miners have to deliberately do something invalid - they cannot be tricked into it... and miners can always chose to do something invalid anyway.

> -------- Original Message --------
> From: luke at dashjr.org
> To: bitcoin-dev at lists.linuxfoundation.org, shaolinfry <shaolinfry at protonmail.ch>
> I"ve already opened a PR almost 2 weeks ago to do this and fix the other
> issues BIP 9 has. https://github.com/bitcoin/bips/pull/550
> It just needs your ACK to merge.
> On Wednesday 05 July 2017 1:30:26 AM shaolinfry via bitcoin-dev wrote:
>> Some people have criticized BIP9"s blocktime based thresholds arguing they
>> are confusing (the first retarget after threshold). It is also vulnerable
>> to miners fiddling with timestamps in a way that could prevent or delay
>> activation - for example by only advancing the block timestamp by 1 second
>> you would never meet the threshold (although this would come a the penalty
>> of hiking the difficulty dramatically). On the other hand, the exact date
>> of a height based thresholds is hard to predict a long time in advance due
>> to difficulty fluctuations. However, there is certainty at a given block
>> height and it"s easy to monitor. If there is sufficient interest, I would
>> be happy to amend BIP8 to be height based. I originally omitted height
>> based thresholds in the interests of simplicity of review - but now that
>> the proposal has been widely reviewed it would be a trivial amendment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170705/06457a6c/attachment-0001.html>

From greg at xiph.org  Wed Jul  5 08:06:33 2017
From: greg at xiph.org (Gregory Maxwell)
Date: Wed, 5 Jul 2017 08:06:33 +0000
Subject: [bitcoin-dev] Height based vs block time based thresholds
In-Reply-To: <201707050350.53122.luke@dashjr.org>
References: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
	<201707050350.53122.luke@dashjr.org>
Message-ID: <CAAS2fgTko+aszOReFX5Svo4h-qROzdU9+vZLSDoR97do6YJ_cQ@mail.gmail.com>

On Wed, Jul 5, 2017 at 3:50 AM, Luke Dashjr via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I've already opened a PR almost 2 weeks ago to do this and fix the other
> issues BIP 9 has. https://github.com/bitcoin/bips/pull/550
>
> It just needs your ACK to merge.

These proposals for gratuitous orphaning are reckless and coersive.
We have a professional obligation to first do no harm, and amplifying
orphaning which can otherwise easily be avoided violates it.

It is not anyones position to decide who does and doesn't need to be
"woken up" with avoidable finical harm, nor is it any of our right to
do so at the risk of monetary losses by any and all users users from
the resulting network instability.

It's one thing to argue that some disruption is strictly needed for
the sake of advancement, it's another to see yourself fit as judge,
jury, and executioner to any that does not jump at your command.
(which is exactly the tone I and at least some others extract from
your advocacy of these changes and similar activity around BIP148).

I for one oppose those changes strongly.

> Not having a mandatory signal turned out to be a serious bug in BIP 9,

I have seen no evidence or case for this.

From kekcoin at protonmail.com  Wed Jul  5 08:54:40 2017
From: kekcoin at protonmail.com (Kekcoin)
Date: Wed, 05 Jul 2017 04:54:40 -0400
Subject: [bitcoin-dev] Height based vs block time based thresholds
In-Reply-To: <CAAS2fgTko+aszOReFX5Svo4h-qROzdU9+vZLSDoR97do6YJ_cQ@mail.gmail.com>
References: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
	<201707050350.53122.luke@dashjr.org>
	<CAAS2fgTko+aszOReFX5Svo4h-qROzdU9+vZLSDoR97do6YJ_cQ@mail.gmail.com>
Message-ID: <akYjeiyeQP1gBjSOYOIbtnvgWVWjElJ065jNlZsDlbQ0TXoBlP9iJx2p9jOI4pKG5ltmPJsDPJ--rs8ruts6AiOgwZ-_dIfkT6b7hJwFb8A=@protonmail.com>

Luke's proposed changes to BIP8 (specifically, the FAILING state) seem designed to address the regression compared to BIP9 that there is no way to avoid activating a softfork that is shown to be suboptimal or flawed in some (serious enough) way - after deployment is well underway - without hardforking.
I agree with your principle but we should also look at the circumstances in which this mechanism would be beneficial vs. when it would cause harm (compared to BIP8 without this mechanism). The scenario this was designed for is "miners refusing to activate, on non-technical grounds, a widely desired upgrade" - in which case the "wakeup call" would be in users' hands, not anyone in particular.
Is there a hypothetical scenario in which the orphan risk outweighs the benefits of having this kind of upgrade mechanism that can (at deploy-time) be chosen to be optional by default with a deferred mechanism to make it mandatory? If so, is there any thought on how to realize the latter without the former?

Sent with [ProtonMail](https://protonmail.com) Secure Email.

> -------- Original Message --------
> Subject: Re: [bitcoin-dev] Height based vs block time based thresholds
> Local Time: July 5, 2017 8:06 AM
> UTC Time: July 5, 2017 8:06 AM
> From: bitcoin-dev at lists.linuxfoundation.org
> To: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
> On Wed, Jul 5, 2017 at 3:50 AM, Luke Dashjr via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> I"ve already opened a PR almost 2 weeks ago to do this and fix the other
>> issues BIP 9 has. https://github.com/bitcoin/bips/pull/550
>>
>> It just needs your ACK to merge.
> These proposals for gratuitous orphaning are reckless and coersive.
> We have a professional obligation to first do no harm, and amplifying
> orphaning which can otherwise easily be avoided violates it.
> It is not anyones position to decide who does and doesn"t need to be
> "woken up" with avoidable finical harm, nor is it any of our right to
> do so at the risk of monetary losses by any and all users users from
> the resulting network instability.
> It"s one thing to argue that some disruption is strictly needed for
> the sake of advancement, it"s another to see yourself fit as judge,
> jury, and executioner to any that does not jump at your command.
> (which is exactly the tone I and at least some others extract from
> your advocacy of these changes and similar activity around BIP148).
> I for one oppose those changes strongly.
>> Not having a mandatory signal turned out to be a serious bug in BIP 9,
> I have seen no evidence or case for this.
> _______________________________________________
> 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/20170705/afa1c3a5/attachment.html>

From john at seebitcoin.com  Wed Jul  5 09:18:36 2017
From: john at seebitcoin.com (John Hardy)
Date: Wed, 5 Jul 2017 09:18:36 +0000
Subject: [bitcoin-dev] The Nuclear Option: BIP148 + MR POWA
Message-ID: <BLUPR0301MB200297FEF1BF16D950BCF981EED40@BLUPR0301MB2002.namprd03.prod.outlook.com>

This idea is highly contentious as it would guarantee a viable chain of Bitcoin with SegWit activated whether BIP148 gained sufficient support or not. I am not necessarily advocating it - just putting it out for discussion. While the downside is that it could permanently split the network, the upside is that it could heap additional pressure on miners to follow the BIP148 chain and ensure a minimally disruptive upgrade. This is pure game theory.



MR POWA (Mining Reactive Proof of Work Addition) is a method to introduce an additional proof of work to a blockchain in response to a detected mining behaviour.



In the case of BIP148, the criteria for activation could be when the software detects a non-BIP148 compliant chain that is 144 blocks (24 hours) ahead of a BIP148 compliant chain.



At this stage the software would change its consensus rules (hard fork) to do two things:

  *   Lower the difficulty for existing PoW method (SHA256).

  *   Introduce a second POW method, such as Scrypt or Ethash, that is incompatible with SHA256 hardware but already has an established mining industry for altcoins.



The difficulty should be low, and blocks will initially be found much more quickly than every 10 minutes until the difficulty adjusts. Each method would have its own difficulty. It could be a requirement that POW methods alternate to neutralise attacks from the other chain.



This would guarantee SegWit activation. Anybody who is already running a BIP148 node could just as easily run a BIP148 + MR POWA node. This could not realistically be supported by Core and would have to be implemented in a grassroots movement, similar to BIP148.



Ideally, it would just force the miners to follow the BIP148 chain (or risk the value of their hardware being hurt) and the code would never be activated. MR POWA would mean BIP148 miners would no longer need to ?hold their nerve? as they would be guaranteed a viable chain and rewarded for their early support.


Regards,


John Hardy

john at seebitcoin.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170705/9b84daf9/attachment-0001.html>

From hozer at hozed.org  Wed Jul  5 14:02:08 2017
From: hozer at hozed.org (Troy Benjegerdes)
Date: Wed, 5 Jul 2017 14:02:08 +0000
Subject: [bitcoin-dev] The Nuclear Option: BIP148 + MR POWA
In-Reply-To: <BLUPR0301MB200297FEF1BF16D950BCF981EED40@BLUPR0301MB2002.namprd03.prod.outlook.com>
References: <BLUPR0301MB200297FEF1BF16D950BCF981EED40@BLUPR0301MB2002.namprd03.prod.outlook.com>
Message-ID: <20170705140208.GJ4885@hostname.unassigned>

The fastest way to triple Bitcoin capacity is to split the network into
two or three different blockchains. We encourage forks of software, why
are blockchains somehow different?

Yes, this is risky, and probably volatile.

I honestly don't expect lots of people with large amounts of money 
invested (exchanges, financial institutions, etc) to go along with 
something like this, and that say 90% of the wealth with stay concentrated
in whatever chain has the majority SHA256 hashpower.

But as a game-theory excercise to see who's theories actually work?

I highly encourage a real-world test of all these theories.

I would also highly advise finding a simple and robust difficulty adjustment
that occurs every block instead of bitcoin/litecoin's 2016 block use.

On Wed, Jul 05, 2017 at 09:18:36AM +0000, John Hardy via bitcoin-dev wrote:
> This idea is highly contentious as it would guarantee a viable chain of Bitcoin with SegWit activated whether BIP148 gained sufficient support or not. I am not necessarily advocating it - just putting it out for discussion. While the downside is that it could permanently split the network, the upside is that it could heap additional pressure on miners to follow the BIP148 chain and ensure a minimally disruptive upgrade. This is pure game theory.
> 
> 
> 
> MR POWA (Mining Reactive Proof of Work Addition) is a method to introduce an additional proof of work to a blockchain in response to a detected mining behaviour.
> 
> 
> 
> In the case of BIP148, the criteria for activation could be when the software detects a non-BIP148 compliant chain that is 144 blocks (24 hours) ahead of a BIP148 compliant chain.
> 
> 
> 
> At this stage the software would change its consensus rules (hard fork) to do two things:
> 
>   *   Lower the difficulty for existing PoW method (SHA256).
> 
>   *   Introduce a second POW method, such as Scrypt or Ethash, that is incompatible with SHA256 hardware but already has an established mining industry for altcoins.
> 
> 
> 
> The difficulty should be low, and blocks will initially be found much more quickly than every 10 minutes until the difficulty adjusts. Each method would have its own difficulty. It could be a requirement that POW methods alternate to neutralise attacks from the other chain.
> 
> 
> 
> This would guarantee SegWit activation. Anybody who is already running a BIP148 node could just as easily run a BIP148 + MR POWA node. This could not realistically be supported by Core and would have to be implemented in a grassroots movement, similar to BIP148.
> 
> 
> 
> Ideally, it would just force the miners to follow the BIP148 chain (or risk the value of their hardware being hurt) and the code would never be activated. MR POWA would mean BIP148 miners would no longer need to ?hold their nerve? as they would be guaranteed a viable chain and rewarded for their early support.
> 
> 
> Regards,
> 
> 
> John Hardy
> 
> john at seebitcoin.com
> 
> 

> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


From rhavar at protonmail.com  Wed Jul  5 13:52:53 2017
From: rhavar at protonmail.com (Rhavar)
Date: Wed, 05 Jul 2017 09:52:53 -0400
Subject: [bitcoin-dev] BIP proposal: No chaining off replaceable
	transactions
In-Reply-To: <ojfve0$jq6$1@blaine.gmane.org>
References: <uupN1N30M_M_-fb7bBfHgn2XnpTpRNWCP3BpFiHXDHQiWqUf4u3POgd58tpDZS5fQjSst59JaxFdIRb7qt9Hb8V9QHHKqe0YBAW0XnRBqiw=@protonmail.com>
	<ojfve0$jq6$1@blaine.gmane.org>
Message-ID: <AIK82sl0aj6Nb9p42__7yPriddfF7G2iz-2m5wSTkNSwYmbmUMBUpNbWRdzMnsyc6KQXBo152-aL8cPnp3ymhMB8x9aZRjI_dOb_ehOvbnE=@protonmail.com>

Thanks Andreas, that's actually a pretty good use-case I didn't think of.
Perhaps you could make the rule: "To spend from an unconfirmed BIP125 output, the transaction feerate needs to be higher than its unconfirmed parent's effective feerate."
It doesn't totally solve the problem, but I think in practice would do a good job (most of the problematic descendants tends to be low feerate sweeps). It would also preserve the ability for receivers to use CPFP if they wish.

-Ryan

> -------- Original Message --------
> Subject: Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions
> Local Time: July 4, 2017 6:50 AM
> UTC Time: July 4, 2017 11:50 AM
> From: bitcoin-dev at lists.linuxfoundation.org
> To: bitcoin-dev at lists.linuxfoundation.org
> Your BIP would take away the only way the *receiver* has to raise the
> fee: CPFP. And the receiver is arguably the more important party in this
> question. After all the sender has no real incentive for his payment to
> be confirmed; it"s receiver who has.
> On 07/02/2017 10:35 PM, Rhavar via bitcoin-dev wrote:
>> ==Abstract==
>>
>> BIP125 allows transactions to opt into replaceability with a primary use
>> case
>> of allowing users to increase the fees of unconfirming transactions,
>> helping create
>> a more efficient fee market place.
>>
>> However this goal is hindered when the receiver of a transaction spends
>> from the
>> unconfirmed output, which exposes the sender to the awkward position of
>> needing
>> to pick between needing to pay an effectively unbounded amount of money
>> as per the BIP125 rules, or not fee bump at all.
>>
>> This is especially problematic in the case of batched sends in which
>> there are
>> multiple independent receivers. In practice this means wallets and
>> services can not effectively low ball the fee of transactions, with the
>> intention of fee bumping due to the risk of the receiver spending or
>> sweeping it before it confirms.
>>
>> In order to support a healthy fee marketplace, this proposal aims to
>> increase
>> the utility of bip125 by making transactions that spend an unconfirmed
>> BIP125
>> output non-standard.
>>
>>
>> ==Summary==
>>
>> This policy specifies a max chain depth of 1 for any BIP125 transactions.
>>
>> ==Impact==
>>
>> Receivers of BIP125 transactions will need to wait until the transaction
>> has confirmed before spending from it. This will not be significantly
>> different
>> than it is currently as they receivers need to be monitoring for
>> replacements.
>>
>> If senders want to make further transactions before the BIP125
>> transaction confirms,
>> and need to utilize the change of the transaction: they will need to
>> replace the
>> transaction with a one that makes the other send in "pass through" style
>> or first
>> finalize the BIP125 transaction and then chain from the spend normally.
>>
>>
>> -Ryan
>>
>>
>>
>>
>> _______________________________________________
>> 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/20170705/69dc44cb/attachment.html>

From henning.kopp at uni-ulm.de  Wed Jul  5 14:26:53 2017
From: henning.kopp at uni-ulm.de (Henning Kopp)
Date: Wed, 5 Jul 2017 16:26:53 +0200
Subject: [bitcoin-dev] difficulty adjustment (was: The Nuclear Option:
 BIP148 + MR POWA)
In-Reply-To: <20170705140208.GJ4885@hostname.unassigned>
References: <BLUPR0301MB200297FEF1BF16D950BCF981EED40@BLUPR0301MB2002.namprd03.prod.outlook.com>
	<20170705140208.GJ4885@hostname.unassigned>
Message-ID: <20170705142653.GA15084@banane.informatik.uni-ulm.de>

Hi,

> I would also highly advise finding a simple and robust difficulty adjustment
> that occurs every block instead of bitcoin/litecoin's 2016 block use.

I also thought about this some time ago. But note that this implies
that forks grow with the same block frequency as the main chain. Thus
the longest chain rule becomes irrelevant, since all chains will have
the same length (in expectancy). Rather, the chain with most work is
the true one.

Best
Henning


On Wed, Jul 05, 2017 at 02:02:08PM +0000, Troy Benjegerdes via bitcoin-dev wrote:
> The fastest way to triple Bitcoin capacity is to split the network into
> two or three different blockchains. We encourage forks of software, why
> are blockchains somehow different?
> 
> Yes, this is risky, and probably volatile.
> 
> I honestly don't expect lots of people with large amounts of money 
> invested (exchanges, financial institutions, etc) to go along with 
> something like this, and that say 90% of the wealth with stay concentrated
> in whatever chain has the majority SHA256 hashpower.
> 
> But as a game-theory excercise to see who's theories actually work?
> 
> I highly encourage a real-world test of all these theories.
> 
> I would also highly advise finding a simple and robust difficulty adjustment
> that occurs every block instead of bitcoin/litecoin's 2016 block use.
> 
> On Wed, Jul 05, 2017 at 09:18:36AM +0000, John Hardy via bitcoin-dev wrote:
> > This idea is highly contentious as it would guarantee a viable chain of Bitcoin with SegWit activated whether BIP148 gained sufficient support or not. I am not necessarily advocating it - just putting it out for discussion. While the downside is that it could permanently split the network, the upside is that it could heap additional pressure on miners to follow the BIP148 chain and ensure a minimally disruptive upgrade. This is pure game theory.
> > 
> > 
> > 
> > MR POWA (Mining Reactive Proof of Work Addition) is a method to introduce an additional proof of work to a blockchain in response to a detected mining behaviour.
> > 
> > 
> > 
> > In the case of BIP148, the criteria for activation could be when the software detects a non-BIP148 compliant chain that is 144 blocks (24 hours) ahead of a BIP148 compliant chain.
> > 
> > 
> > 
> > At this stage the software would change its consensus rules (hard fork) to do two things:
> > 
> >   *   Lower the difficulty for existing PoW method (SHA256).
> > 
> >   *   Introduce a second POW method, such as Scrypt or Ethash, that is incompatible with SHA256 hardware but already has an established mining industry for altcoins.
> > 
> > 
> > 
> > The difficulty should be low, and blocks will initially be found much more quickly than every 10 minutes until the difficulty adjusts. Each method would have its own difficulty. It could be a requirement that POW methods alternate to neutralise attacks from the other chain.
> > 
> > 
> > 
> > This would guarantee SegWit activation. Anybody who is already running a BIP148 node could just as easily run a BIP148 + MR POWA node. This could not realistically be supported by Core and would have to be implemented in a grassroots movement, similar to BIP148.
> > 
> > 
> > 
> > Ideally, it would just force the miners to follow the BIP148 chain (or risk the value of their hardware being hurt) and the code would never be activated. MR POWA would mean BIP148 miners would no longer need to ?hold their nerve? as they would be guaranteed a viable chain and rewarded for their early support.
> > 
> > 
> > Regards,
> > 
> > 
> > John Hardy
> > 
> > john at seebitcoin.com
> > 
> > 
> 
> > _______________________________________________
> > 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
> 

-- 
Henning Kopp
Institute of Distributed Systems
Ulm University, Germany

Office: O27 - 3402
Phone: +49 731 50-24138
Web: http://www.uni-ulm.de/in/vs/~kopp

From hampus.sjoberg at gmail.com  Wed Jul  5 19:44:27 2017
From: hampus.sjoberg at gmail.com (=?UTF-8?Q?Hampus_Sj=C3=B6berg?=)
Date: Wed, 5 Jul 2017 21:44:27 +0200
Subject: [bitcoin-dev] Height based vs block time based thresholds
In-Reply-To: <201707050410.45217.luke@dashjr.org>
References: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
	<201707050350.53122.luke@dashjr.org>
	<00qcLaDJFDoC9D6644P_aLf7_n5B1pqCPj_c02QlqySsrJLsB6TZipXMD8L7l3lJcw5NoLP6dphCMruKJCIMkJUIDYbIw0iDd322vsNFmNw=@protonmail.ch>
	<201707050410.45217.luke@dashjr.org>
Message-ID: <CAFMkqK9ezq_AdOpeA08jpr9haHP_jEHaJaQ2KZC=yMy6UXaJyA@mail.gmail.com>

>From the PR change:

> Miners must continue setting the bit in LOCKED_IN phase so uptake is
visible and acknowledged. Blocks without the applicable bit set are invalid
during this period

Luke, it seems like the amendments to BIP8 make it drastically different to
how it first was designed to work.
It now looks more akin to BIP148, which was AFAICT not how BIP8 was
originally intended to work.
Perhaps this should be made into its own BIP instead, or make it so it's
possible to decide how the LOCKED_IN state should work when designing the
softfork.

Hampus

2017-07-05 6:10 GMT+02:00 Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> It's not pointless: it's a wake-up call for miners asleep "at the wheel",
> to
> ensure they upgrade in time. Not having a mandatory signal turned out to
> be a
> serious bug in BIP 9, and one which is fixed in BIP 148 (and remains a
> problem
> for BIP 149 as-is). Additionally, it makes the activation decisive and
> unambiguous: once the lock-in period is complete, there remains no
> question as
> to what the correct protocol rules are.
>
> It also enables deploying softforks as a MASF, and only upgrading them to
> UASF
> on an as-needed basis.
>
> Luke
>
>
> On Wednesday 05 July 2017 4:00:38 AM shaolinfry wrote:
> > Luke,
> > I previously explored an extra state to require signalling before
> > activation in an earlier draft of BIP8, but the overall impression I got
> > was that gratuitous orphaning was undesirable, so I dropped it. I
> > understand the motivation behind it (to ensure miners are upgraded), but
> > it's also rather pointless when miners can just fake signal. A properly
> > constructed soft fork is generally such that miners have to deliberately
> > do something invalid - they cannot be tricked into it... and miners can
> > always chose to do something invalid anyway.
> >
> > > -------- Original Message --------
> > > From: luke at dashjr.org
> > > To: bitcoin-dev at lists.linuxfoundation.org, shaolinfry
> > > <shaolinfry at protonmail.ch> I"ve already opened a PR almost 2 weeks ago
> > > to do this and fix the other issues BIP 9 has.
> > > https://github.com/bitcoin/bips/pull/550
> > > It just needs your ACK to merge.
> > >
> > > On Wednesday 05 July 2017 1:30:26 AM shaolinfry via bitcoin-dev wrote:
> > >> Some people have criticized BIP9"s blocktime based thresholds arguing
> > >> they are confusing (the first retarget after threshold). It is also
> > >> vulnerable to miners fiddling with timestamps in a way that could
> > >> prevent or delay activation - for example by only advancing the block
> > >> timestamp by 1 second you would never meet the threshold (although
> this
> > >> would come a the penalty of hiking the difficulty dramatically). On
> the
> > >> other hand, the exact date of a height based thresholds is hard to
> > >> predict a long time in advance due to difficulty fluctuations.
> However,
> > >> there is certainty at a given block height and it"s easy to monitor.
> If
> > >> there is sufficient interest, I would be happy to amend BIP8 to be
> > >> height based. I originally omitted height based thresholds in the
> > >> interests of simplicity of review - but now that the proposal has been
> > >> widely reviewed it would be a trivial amendment.
> _______________________________________________
> 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/20170705/31aaca40/attachment-0001.html>

From jtimon at jtimon.cc  Thu Jul  6 17:20:47 2017
From: jtimon at jtimon.cc (=?UTF-8?B?Sm9yZ2UgVGltw7Nu?=)
Date: Thu, 6 Jul 2017 19:20:47 +0200
Subject: [bitcoin-dev] Height based vs block time based thresholds
In-Reply-To: <CAFMkqK9ezq_AdOpeA08jpr9haHP_jEHaJaQ2KZC=yMy6UXaJyA@mail.gmail.com>
References: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
	<201707050350.53122.luke@dashjr.org>
	<00qcLaDJFDoC9D6644P_aLf7_n5B1pqCPj_c02QlqySsrJLsB6TZipXMD8L7l3lJcw5NoLP6dphCMruKJCIMkJUIDYbIw0iDd322vsNFmNw=@protonmail.ch>
	<201707050410.45217.luke@dashjr.org>
	<CAFMkqK9ezq_AdOpeA08jpr9haHP_jEHaJaQ2KZC=yMy6UXaJyA@mail.gmail.com>
Message-ID: <CABm2gDo0CdyXJkpMJ7dL82xJ0LuNSq6H7sHCC8Yt9RamvhF1YQ@mail.gmail.com>

I'm all for using height instead of time. That was my preference for
bip9 all along, but my arguments at the time apparently weren't
convincing.

Regarding luke's proposal, the only advantage I see is that it would
allow nodes that don't know a deployment that gets activated to issue
a warning, like bip9 always does when an unknown deployment is locked
in.

But there's a simpler way to do that which doesn't require to add
consensus rules as to what versionbits should be.
I'm honestly not worried about it being "coersive" and I don't think
it's inherently reckless (although used with short deployment times
like bip148 it can be IMO). But it adds more complexity to the
consensus rules, with something that could merely be "warning code".

You can just use a special bit in versionbits for nodes to get the warning.
My proposal doesn't guarantee that the warning will be signaled, for
example, if the miner that mines the block right after lock in doesn't
know about the deployment, he can't possibly know that he was supposed
to signal the warning bit, even if he has the best intentions. Miners
can also intentionally not signal it out of pure malice. But that's no
worse than the current form, when deployments activated by final date
instead of miner signaling never get a warning.

Shaolinfry had more concerns with my proposed modification, but I
think I answered all of them here:

https://github.com/bitcoin/bitcoin/pull/10462#issuecomment-306266218

The implementation of the proposal is there too. I'm happy to reopen
and rebase to simplify (#10464 was merged and there's at least 1
commit to squash).

> It also enables deploying softforks as a MASF, and only upgrading them to UASF
on an as-needed basis.

You can also do

consensus.vDeployments[Consensus::DEPLOYMENT_MASF].bit = 0;
consensus.vDeployments[Consensus::DEPLOYMENT_MASF].nStartHeight = 500000;
consensus.vDeployments[Consensus::DEPLOYMENT_MASF].nTimeoutHeight = 510000;
consensus.vDeployments[Consensus::DEPLOYMENT_MASF].lockinontimeout = false;

and "if needed", simply add the following at any time (before the new
nStartHeight, obviously):


consensus.vDeployments[Consensus::DEPLOYMENT_UASF].bit = 0;
consensus.vDeployments[Consensus::DEPLOYMENT_UASF].nStartHeight = 510000;
consensus.vDeployments[Consensus::DEPLOYMENT_UASF].nTimeoutHeight = 515000;
consensus.vDeployments[Consensus::DEPLOYMENT_UASF].lockinontimeout = true;


On Wed, Jul 5, 2017 at 9:44 PM, Hampus Sj?berg via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> From the PR change:
>
>> Miners must continue setting the bit in LOCKED_IN phase so uptake is
>> visible and acknowledged. Blocks without the applicable bit set are invalid
>> during this period
>
> Luke, it seems like the amendments to BIP8 make it drastically different to
> how it first was designed to work.
> It now looks more akin to BIP148, which was AFAICT not how BIP8 was
> originally intended to work.
> Perhaps this should be made into its own BIP instead, or make it so it's
> possible to decide how the LOCKED_IN state should work when designing the
> softfork.
>
> Hampus
>
> 2017-07-05 6:10 GMT+02:00 Luke Dashjr via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org>:
>>
>> It's not pointless: it's a wake-up call for miners asleep "at the wheel",
>> to
>> ensure they upgrade in time. Not having a mandatory signal turned out to
>> be a
>> serious bug in BIP 9, and one which is fixed in BIP 148 (and remains a
>> problem
>> for BIP 149 as-is). Additionally, it makes the activation decisive and
>> unambiguous: once the lock-in period is complete, there remains no
>> question as
>> to what the correct protocol rules are.
>>
>> It also enables deploying softforks as a MASF, and only upgrading them to
>> UASF
>> on an as-needed basis.
>>
>> Luke
>>
>>
>> On Wednesday 05 July 2017 4:00:38 AM shaolinfry wrote:
>> > Luke,
>> > I previously explored an extra state to require signalling before
>> > activation in an earlier draft of BIP8, but the overall impression I got
>> > was that gratuitous orphaning was undesirable, so I dropped it. I
>> > understand the motivation behind it (to ensure miners are upgraded), but
>> > it's also rather pointless when miners can just fake signal. A properly
>> > constructed soft fork is generally such that miners have to deliberately
>> > do something invalid - they cannot be tricked into it... and miners can
>> > always chose to do something invalid anyway.
>> >
>> > > -------- Original Message --------
>> > > From: luke at dashjr.org
>> > > To: bitcoin-dev at lists.linuxfoundation.org, shaolinfry
>> > > <shaolinfry at protonmail.ch> I"ve already opened a PR almost 2 weeks ago
>> > > to do this and fix the other issues BIP 9 has.
>> > > https://github.com/bitcoin/bips/pull/550
>> > > It just needs your ACK to merge.
>> > >
>> > > On Wednesday 05 July 2017 1:30:26 AM shaolinfry via bitcoin-dev wrote:
>> > >> Some people have criticized BIP9"s blocktime based thresholds arguing
>> > >> they are confusing (the first retarget after threshold). It is also
>> > >> vulnerable to miners fiddling with timestamps in a way that could
>> > >> prevent or delay activation - for example by only advancing the block
>> > >> timestamp by 1 second you would never meet the threshold (although
>> > >> this
>> > >> would come a the penalty of hiking the difficulty dramatically). On
>> > >> the
>> > >> other hand, the exact date of a height based thresholds is hard to
>> > >> predict a long time in advance due to difficulty fluctuations.
>> > >> However,
>> > >> there is certainty at a given block height and it"s easy to monitor.
>> > >> If
>> > >> there is sufficient interest, I would be happy to amend BIP8 to be
>> > >> height based. I originally omitted height based thresholds in the
>> > >> interests of simplicity of review - but now that the proposal has
>> > >> been
>> > >> widely reviewed it would be a trivial amendment.
>> _______________________________________________
>> 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
>

From eric at voskuil.org  Thu Jul  6 17:41:52 2017
From: eric at voskuil.org (Eric Voskuil)
Date: Thu, 6 Jul 2017 10:41:52 -0700
Subject: [bitcoin-dev] Height based vs block time based thresholds
In-Reply-To: <CABm2gDo0CdyXJkpMJ7dL82xJ0LuNSq6H7sHCC8Yt9RamvhF1YQ@mail.gmail.com>
References: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
	<201707050350.53122.luke@dashjr.org>
	<00qcLaDJFDoC9D6644P_aLf7_n5B1pqCPj_c02QlqySsrJLsB6TZipXMD8L7l3lJcw5NoLP6dphCMruKJCIMkJUIDYbIw0iDd322vsNFmNw=@protonmail.ch>
	<201707050410.45217.luke@dashjr.org>
	<CAFMkqK9ezq_AdOpeA08jpr9haHP_jEHaJaQ2KZC=yMy6UXaJyA@mail.gmail.com>
	<CABm2gDo0CdyXJkpMJ7dL82xJ0LuNSq6H7sHCC8Yt9RamvhF1YQ@mail.gmail.com>
Message-ID: <3248E9A6-F729-4EC2-85F7-E18FD9CA15F8@voskuil.org>

Just as an implementation consideration, time basis creates complexity. There are no other reasons to index by time, but many to index by height. The time-based activation window of BIP9 forces nodes to either index by time or scan the chain.

e

> On Jul 6, 2017, at 10:20 AM, Jorge Tim?n via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> 
> I'm all for using height instead of time. That was my preference for
> bip9 all along, but my arguments at the time apparently weren't
> convincing.
> 
> Regarding luke's proposal, the only advantage I see is that it would
> allow nodes that don't know a deployment that gets activated to issue
> a warning, like bip9 always does when an unknown deployment is locked
> in.
> 
> But there's a simpler way to do that which doesn't require to add
> consensus rules as to what versionbits should be.
> I'm honestly not worried about it being "coersive" and I don't think
> it's inherently reckless (although used with short deployment times
> like bip148 it can be IMO). But it adds more complexity to the
> consensus rules, with something that could merely be "warning code".
> 
> You can just use a special bit in versionbits for nodes to get the warning.
> My proposal doesn't guarantee that the warning will be signaled, for
> example, if the miner that mines the block right after lock in doesn't
> know about the deployment, he can't possibly know that he was supposed
> to signal the warning bit, even if he has the best intentions. Miners
> can also intentionally not signal it out of pure malice. But that's no
> worse than the current form, when deployments activated by final date
> instead of miner signaling never get a warning.
> 
> Shaolinfry had more concerns with my proposed modification, but I
> think I answered all of them here:
> 
> https://github.com/bitcoin/bitcoin/pull/10462#issuecomment-306266218
> 
> The implementation of the proposal is there too. I'm happy to reopen
> and rebase to simplify (#10464 was merged and there's at least 1
> commit to squash).
> 
>> It also enables deploying softforks as a MASF, and only upgrading them to UASF
> on an as-needed basis.
> 
> You can also do
> 
> consensus.vDeployments[Consensus::DEPLOYMENT_MASF].bit = 0;
> consensus.vDeployments[Consensus::DEPLOYMENT_MASF].nStartHeight = 500000;
> consensus.vDeployments[Consensus::DEPLOYMENT_MASF].nTimeoutHeight = 510000;
> consensus.vDeployments[Consensus::DEPLOYMENT_MASF].lockinontimeout = false;
> 
> and "if needed", simply add the following at any time (before the new
> nStartHeight, obviously):
> 
> 
> consensus.vDeployments[Consensus::DEPLOYMENT_UASF].bit = 0;
> consensus.vDeployments[Consensus::DEPLOYMENT_UASF].nStartHeight = 510000;
> consensus.vDeployments[Consensus::DEPLOYMENT_UASF].nTimeoutHeight = 515000;
> consensus.vDeployments[Consensus::DEPLOYMENT_UASF].lockinontimeout = true;
> 
> 
> On Wed, Jul 5, 2017 at 9:44 PM, Hampus Sj?berg via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> From the PR change:
>> 
>>> Miners must continue setting the bit in LOCKED_IN phase so uptake is
>>> visible and acknowledged. Blocks without the applicable bit set are invalid
>>> during this period
>> 
>> Luke, it seems like the amendments to BIP8 make it drastically different to
>> how it first was designed to work.
>> It now looks more akin to BIP148, which was AFAICT not how BIP8 was
>> originally intended to work.
>> Perhaps this should be made into its own BIP instead, or make it so it's
>> possible to decide how the LOCKED_IN state should work when designing the
>> softfork.
>> 
>> Hampus
>> 
>> 2017-07-05 6:10 GMT+02:00 Luke Dashjr via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org>:
>>> 
>>> It's not pointless: it's a wake-up call for miners asleep "at the wheel",
>>> to
>>> ensure they upgrade in time. Not having a mandatory signal turned out to
>>> be a
>>> serious bug in BIP 9, and one which is fixed in BIP 148 (and remains a
>>> problem
>>> for BIP 149 as-is). Additionally, it makes the activation decisive and
>>> unambiguous: once the lock-in period is complete, there remains no
>>> question as
>>> to what the correct protocol rules are.
>>> 
>>> It also enables deploying softforks as a MASF, and only upgrading them to
>>> UASF
>>> on an as-needed basis.
>>> 
>>> Luke
>>> 
>>> 
>>>> On Wednesday 05 July 2017 4:00:38 AM shaolinfry wrote:
>>>> Luke,
>>>> I previously explored an extra state to require signalling before
>>>> activation in an earlier draft of BIP8, but the overall impression I got
>>>> was that gratuitous orphaning was undesirable, so I dropped it. I
>>>> understand the motivation behind it (to ensure miners are upgraded), but
>>>> it's also rather pointless when miners can just fake signal. A properly
>>>> constructed soft fork is generally such that miners have to deliberately
>>>> do something invalid - they cannot be tricked into it... and miners can
>>>> always chose to do something invalid anyway.
>>>> 
>>>>> -------- Original Message --------
>>>>> From: luke at dashjr.org
>>>>> To: bitcoin-dev at lists.linuxfoundation.org, shaolinfry
>>>>> <shaolinfry at protonmail.ch> I"ve already opened a PR almost 2 weeks ago
>>>>> to do this and fix the other issues BIP 9 has.
>>>>> https://github.com/bitcoin/bips/pull/550
>>>>> It just needs your ACK to merge.
>>>>> 
>>>>>> On Wednesday 05 July 2017 1:30:26 AM shaolinfry via bitcoin-dev wrote:
>>>>>> Some people have criticized BIP9"s blocktime based thresholds arguing
>>>>>> they are confusing (the first retarget after threshold). It is also
>>>>>> vulnerable to miners fiddling with timestamps in a way that could
>>>>>> prevent or delay activation - for example by only advancing the block
>>>>>> timestamp by 1 second you would never meet the threshold (although
>>>>>> this
>>>>>> would come a the penalty of hiking the difficulty dramatically). On
>>>>>> the
>>>>>> other hand, the exact date of a height based thresholds is hard to
>>>>>> predict a long time in advance due to difficulty fluctuations.
>>>>>> However,
>>>>>> there is certainty at a given block height and it"s easy to monitor.
>>>>>> If
>>>>>> there is sufficient interest, I would be happy to amend BIP8 to be
>>>>>> height based. I originally omitted height based thresholds in the
>>>>>> interests of simplicity of review - but now that the proposal has
>>>>>> been
>>>>>> widely reviewed it would be a trivial amendment.
>>> _______________________________________________
>>> 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

From luke at dashjr.org  Thu Jul  6 20:43:28 2017
From: luke at dashjr.org (Luke Dashjr)
Date: Thu, 6 Jul 2017 20:43:28 +0000
Subject: [bitcoin-dev] Height based vs block time based thresholds
In-Reply-To: <CAAS2fgTko+aszOReFX5Svo4h-qROzdU9+vZLSDoR97do6YJ_cQ@mail.gmail.com>
References: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
	<201707050350.53122.luke@dashjr.org>
	<CAAS2fgTko+aszOReFX5Svo4h-qROzdU9+vZLSDoR97do6YJ_cQ@mail.gmail.com>
Message-ID: <201707062043.30569.luke@dashjr.org>

On Wednesday 05 July 2017 8:06:33 AM Gregory Maxwell via bitcoin-dev wrote:
> These proposals for gratuitous orphaning are reckless and coersive.
> We have a professional obligation to first do no harm, and amplifying
> orphaning which can otherwise easily be avoided violates it.

Nothing is "orphaned" unless miners are acting negligently or maliciously. 
Incentivising honest behaviour from miners is inherently part of Bitcoin's 
design, and these changes are necessary for both that and keeping the network 
secure. This doesn't do harm; it reduces risk of harm.

> It's one thing to argue that some disruption is strictly needed for
> the sake of advancement, it's another to see yourself fit as judge,
> jury, and executioner to any that does not jump at your command.
> (which is exactly the tone I and at least some others extract from
> your advocacy of these changes and similar activity around BIP148).

I don't appreciate the uncalled-for character assassination, and it doesn't 
belong on this mailing list.

> I for one oppose those changes strongly.
> 
> > Not having a mandatory signal turned out to be a serious bug in BIP 9,
> 
> I have seen no evidence or case for this.

Since you apparently have a drastically different opinion on this subject, I 
think it may be best to wait until after BIP148 to continue the discussion 
(thereby having more real-world information to work from).

Therefore, I have opened a new pull request with just the parts you seem to be 
objecting to removed. Please let us know if this version is satisfactory.

    https://github.com/bitcoin/bips/pull/551

Luke

From shaolinfry at protonmail.ch  Fri Jul  7 05:52:13 2017
From: shaolinfry at protonmail.ch (shaolinfry)
Date: Fri, 07 Jul 2017 01:52:13 -0400
Subject: [bitcoin-dev] Height based vs block time based thresholds
In-Reply-To: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
References: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
Message-ID: <q2ezd-tOTBF_3zLOedB36jYCuszrKYS-9BHS_Unle1NipWFTWX-aDwsfy5XrAB2D02SwojA4C_vDIyZa-VEh9IlQalF27HYG5C5KAP9096o=@protonmail.ch>

I have written a height based reference implementation as well as updated the BIP text in the following proposals

"lockinontimeout" was just an implementation detail to allow BIP8 the BIP9 implementation code. With the change to height based, we can dispense with it entirely.
So the two changes BIP8 brings is BIP9 modified to use height not time, and remove the veto failed state.
Code: https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip8-height
BIP: https://github.com/bitcoin/bips/compare/master...shaolinfry:bip8-height

> -------- Original Message --------
> Subject: [bitcoin-dev] Height based vs block time based thresholds
> Some people have criticized BIP9's blocktime based thresholds arguing they are confusing (the first retarget after threshold). It is also vulnerable to miners fiddling with timestamps in a way that could prevent or delay activation - for example by only advancing the block timestamp by 1 second you would never meet the threshold (although this would come a the penalty of hiking the difficulty dramatically).
> On the other hand, the exact date of a height based thresholds is hard to predict a long time in advance due to difficulty fluctuations. However, there is certainty at a given block height and it's easy to monitor.
> If there is sufficient interest, I would be happy to amend BIP8 to be height based. I originally omitted height based thresholds in the interests of simplicity of review - but now that the proposal has been widely reviewed it would be a trivial amendment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170707/0ab0e517/attachment-0001.html>

From jtimon at jtimon.cc  Fri Jul  7 09:51:16 2017
From: jtimon at jtimon.cc (=?UTF-8?B?Sm9yZ2UgVGltw7Nu?=)
Date: Fri, 7 Jul 2017 11:51:16 +0200
Subject: [bitcoin-dev] Height based vs block time based thresholds
In-Reply-To: <q2ezd-tOTBF_3zLOedB36jYCuszrKYS-9BHS_Unle1NipWFTWX-aDwsfy5XrAB2D02SwojA4C_vDIyZa-VEh9IlQalF27HYG5C5KAP9096o=@protonmail.ch>
References: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
	<q2ezd-tOTBF_3zLOedB36jYCuszrKYS-9BHS_Unle1NipWFTWX-aDwsfy5XrAB2D02SwojA4C_vDIyZa-VEh9IlQalF27HYG5C5KAP9096o=@protonmail.ch>
Message-ID: <CABm2gDqBE-sxB3j6WK9kW8Zp9GkEG1b3q=_iqJS+XkGzv7EXDQ@mail.gmail.com>

What if you want height based but lockinontimeout = false ?

On 7 Jul 2017 8:09 am, "shaolinfry via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I have written a height based reference implementation as well as updated
> the BIP text in the following proposals
>
> "lockinontimeout" was just an implementation detail to allow BIP8 the BIP9
> implementation code. With the change to height based, we can dispense with
> it entirely.
>
> So the two changes BIP8 brings is BIP9 modified to use height not time,
> and remove the veto failed state.
>
> Code: https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip8-
> height
> BIP: https://github.com/bitcoin/bips/compare/master...
> shaolinfry:bip8-height
>
>
> -------- Original Message --------
> Subject: [bitcoin-dev] Height based vs block time based thresholds
>
> Some people have criticized BIP9's blocktime based thresholds arguing they
> are confusing (the first retarget after threshold). It is also vulnerable
> to miners fiddling with timestamps in a way that could prevent or delay
> activation - for example by only advancing the block timestamp by 1 second
> you would never meet the threshold (although this would come a the penalty
> of hiking the difficulty dramatically).
>
> On the other hand, the exact date of a height based thresholds is hard to
> predict a long time in advance due to difficulty fluctuations. However,
> there is certainty at a given block height and it's easy to monitor.
>
> If there is sufficient interest, I would be happy to amend BIP8 to be
> height based. I originally omitted height based thresholds in the interests
> of simplicity of review - but now that the proposal has been widely
> reviewed it would be a trivial amendment.
>
>
>
>
> _______________________________________________
> 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/20170707/2b04553e/attachment.html>

From sergio.d.lerner at gmail.com  Fri Jul  7 22:25:12 2017
From: sergio.d.lerner at gmail.com (Sergio Demian Lerner)
Date: Fri, 7 Jul 2017 19:25:12 -0300
Subject: [bitcoin-dev] A Segwit2x BIP
Message-ID: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>

Hello,

Here is a BIP that matches the reference code that the Segwit2x group has
built and published a week ago.

This BIP and code satisfies the requests of a large part of the Bitcoin
community for a moderate increase in the Bitcoin non-witness block space
coupled with the activation of Segwit.

You can find the BIP draft in the following link:

https://github.com/SergioDemianLerner/BIPs/blob/master/BIP-draft-sergiolerner-segwit2x.mediawiki

Reference source was kindly provided by the Segwit2x group.

Best regards,
 Sergio.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170707/d7d45d57/attachment.html>

From lf-lists at mattcorallo.com  Fri Jul  7 22:44:21 2017
From: lf-lists at mattcorallo.com (Matt Corallo)
Date: Fri, 7 Jul 2017 18:44:21 -0400
Subject: [bitcoin-dev] A Segwit2x BIP
In-Reply-To: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
Message-ID: <93708933-fdea-cdfc-20fc-b18040b98110@mattcorallo.com>

This is horribly under-specified (ie not possible to implement from what
you've written, and your implementation doesn't match at all, last I heard).

> Specification

> The plain block size is defined as the serialized block size without
> witness programs.
> Deploy a modified BIP91 to activate Segwit. The only modification is
> that the signal "segsignal" is replaced by "segwit2x".

This is not a protocol change. I have no idea why you included it in the
"specification" section.

> If segwit2x (BIP91 signal) activates at block N, then block N+12960
> activates a new plain block size limit of 2 MB (2,000,000 bytes). In
> this case, at block N+12960 a hard-fork occurs.

This is not a hard fork, simply adding a new limit is a soft fork. You
appear to be confused - as originally written, AFAIR, Jeff's btc1 branch
did not increase the block size, your specification here matches that
original change, and does not increase the block size.

> The block that activates the hard-fork must have a plain block size
> greater than 1 MB.

There is no hard fork, and this would violate consensus rules. Not sure
what you mean. If you do add a hard fork to this BIP, you really need to
flip the hard fork bit.

> Any transaction with a non-witness serialized size exceeding 1,000,000
> is invalid.

This is far from sufficient to protect from DoS attacks, you really
should take a look through the mailing list archives and read some of
the old discussions on the issues here.

Matt

On 07/07/17 18:25, Sergio Demian Lerner via bitcoin-dev wrote:
> Hello,
> 
> Here is a BIP that matches the reference code that the Segwit2x group
> has built and published a week ago. 
> 
> This BIP and code satisfies the requests of a large part of the Bitcoin
> community for a moderate increase in the Bitcoin non-witness block space
> coupled with the activation of Segwit.
> 
> You can find the BIP draft in the following link:
> 
> https://github.com/SergioDemianLerner/BIPs/blob/master/BIP-draft-sergiolerner-segwit2x.mediawiki
> 
> Reference source was kindly provided by the Segwit2x group.
> 
> Best regards,
>  Sergio.
> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

From greg at xiph.org  Fri Jul  7 23:22:38 2017
From: greg at xiph.org (Gregory Maxwell)
Date: Fri, 7 Jul 2017 23:22:38 +0000
Subject: [bitcoin-dev] A Segwit2x BIP
In-Reply-To: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
Message-ID: <CAAS2fgRAdKFu8JqbmtAES3NkX2BK27LucSf=heZ2xyz30BKetw@mail.gmail.com>

On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello,
>
> Here is a BIP that matches the reference code that the Segwit2x group has
> built and published a week ago.

I'm happy to see that someone has begun writing a specification. But I
am appalled to see one just being written now for change it's authors
expect to be irreversibly applied to the network in less than 30 days.

The timeline of this proposal is recklessly short to such an extreme
level that we have never, to the best of my knowledge, seen a prior
proposal so hasty.  Nowhere does this specification provide
justification or assurance that this is at all safe.  The time line of
it violates the most minimal of responsible engineering practices, by
being shorter than even a fast development and release candidate
timeframe.   This proposal carries an extreme risk for parties to lose
money due to transaction reversals at two distinct points in time and
provides no proposed countermeasures to avoid these losses.

The proposal adds another gratuitous limit to the system: A maximum
transaction size where none existed before, yet this limit is almost
certainly too small to prevent actual DOS attacks while it is also
technically larger than any transaction that can be included today
(the largest possible transaction today is 1mb minus the block
overheads).  The maximum resource usage for maliciously crafted 1MB
transaction is enormous and permitting two of them greatly exacerbates
the existing vulnerability.

> Assuming the current transaction pattern is replicated in a 2 MB plain-sized block that is 100% filled with transactions, then the witness-serialized block would occupy 3.6 MB

But in a worst case the result would be 8MB, which this document fails
to mention.

> This is considered safe by many users, companies, miners and academics [2].

The claim that the document's [2] says that these increases are "safe"
is incorrect and is a matter which has been previously corrected by
the authors of the document:
https://www.reddit.com/r/btc/comments/626ud7/coauthor_of_the_paper_that_blockstream_core_keep/dflrshg/
.

The cited paper does an approximate best case analysis considering
only a couple of risk factors (in particular, block relay time, but
ignoring durability to dos attacks, robustness against state
intervention, and initial synchronization time) and concluded that 4MB
was the largest they could argue was safe. The paper goes on to then
argue that even if you crank Bitcoin's parameters to the maximum in
those dimensions that it doesn't result in a truly meaningful increase
in scalablity-- in effect, it's a weak argument against your proposal
and ones like it.

> Deploy a modified BIP91 to activate Segwit. The only modification is that the signal "segsignal" is replaced by "segwit2x".

This means that BIP-91 and your proposal are indistinguishable on the
network, because the string "segsignal" is merely a variable name used
in the software.

> If segwit2x (BIP91 signal) activates at block N,

The proposal is unable to distinguish itself from BIP-91. Does this
mean if segwit2x or BIP91 activates ?

> This reduces the fee pressure on users and companies creating on-chain transactions, matching market expectations and preventing further market disruption

Considering that we just spent the whole weekend with the mempool
having ~1 block or less worth of transactions most of the time, it
seems highly likely that just activating segwit will substantially
disrupt the fee market; to say nothing for the further doubling that
isn't even tempered by new wallet adoptions.  There seems to be no
consideration given to avoiding this disruption and preventing further
emergency events when the new capacity is eventually used and software
is again left unprepared for having to pay market fees.

> and buy time for more comprehensive solutions to be developed and tested

In effect, the document admits that it isn't a solution that
meaningfully improves the scale or scalablity but rather it's just a
bailout to temporarily lower/negate transaction fees.  It doesn't seem
to make any argument (or even acknowledge) that the risks and
disruption are worth its benefit, and it exacerbates those risks by
being the product of a closed process and having a timeline shorter
than basically any software update for production software (much less
the timeframe for any consensus update previously). Kudos for being
frank here, but it's not exactly selling itself.

It seems to me that the document doesn't really even make an effort to
justify the bailout at all and don't explain how it will result in
anything except an endless series of additional fee bailouts.

Moreover, it doesn't discuss any remediation against the replay
exposure that the proposed hardfork is sure to create. ( I can
guarantee to you, I will not adopt this hardfork; especially given
that is has been made completely clear that the terms of it were set
in its closed door meetings and the input of non-supporters was not
welcome. )

From greg at xiph.org  Fri Jul  7 23:25:32 2017
From: greg at xiph.org (Gregory Maxwell)
Date: Fri, 7 Jul 2017 23:25:32 +0000
Subject: [bitcoin-dev] A Segwit2x BIP
In-Reply-To: <93708933-fdea-cdfc-20fc-b18040b98110@mattcorallo.com>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
	<93708933-fdea-cdfc-20fc-b18040b98110@mattcorallo.com>
Message-ID: <CAAS2fgSH8tugh3gBYmMY-ZEzO6c=jZoMczTi7ifULxP9xJsEpQ@mail.gmail.com>

On Fri, Jul 7, 2017 at 10:44 PM, Matt Corallo via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> This is not a hard fork, simply adding a new limit is a soft fork. You
> appear to be confused - as originally written, AFAIR, Jeff's btc1 branch
> did not increase the block size, your specification here matches that
> original change, and does not increase the block size.

Indeed, their code previously did not increase the blocksize but it
was adjusted at the last minute to do so-- so it may actually do that
now. Because they don't appear to have implemented any tests for it, I
wouldn't be too surprised if it still didn't work at all but also
wouldn't be surprised if it did.

You are correct that the specification text appears to refer to the
prior change that did not. (In my response I just assumed that it
meant what they actually did-- good catch).

From luke at dashjr.org  Fri Jul  7 23:27:14 2017
From: luke at dashjr.org (Luke Dashjr)
Date: Fri, 7 Jul 2017 23:27:14 +0000
Subject: [bitcoin-dev] A Segwit2x BIP
In-Reply-To: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
Message-ID: <201707072327.15901.luke@dashjr.org>

> Maximum transaction size is kept, to maximize compatibility with current
> software and prevent algorithmic and data size DoS's.

IIRC, it is actually increased by ~81 bytes, and doesn't count witness data if 
on Segwit transactions (so in effect, nearly 4 MB transactions are possible). 
This probably doesn't make the hashing problem worse, however it should be 
made clear in the BIP.

> Assuming the current transaction pattern is replicated in a 2 MB
> plain-sized block that is 100% filled with transactions, then the
> witness-serialized block would occupy 3.6 MB [1]. This is considered safe
> by many users, companies, miners and academics [2].

Citations do not support the claim.

> The plain block size is defined as the serialized block size without
> witness programs.

This is deceptive and meaningless. There is no reason to *ever* refer to the 
size of the block serialised without witness programs. It is not a meaningful 
number.

> Deploy a modified BIP91 to activate Segwit. The only modification is that
> the signal "segsignal" is replaced by "segwit2x".

What is modified here? "segsignal" does not appear in the BIP 91 protocol at 
all...

> If segwit2x (BIP91 signal) activates at block N, then block N+12960
> activates a new plain block size limit of 2 MB (2,000,000 bytes). In this
> case, at block N+12960 a hard-fork occurs.

A "plain block size limit" of 2 MB would be a no-op. It would have literally 
no effect whatsoever on the network rules.

Furthermore, this does not match what btc1/Segwit2x currently implements at 
all. The actual implementation is: If Segwit (via deployment method) activates 
at block N, then block N+12960 activates a new weight limit of 8M (which 
corresponds to a size of up to 8,000,000 bytes).

> Any transaction with a non-witness serialized size exceeding 1,000,000 is
> invalid.

What is the rationale for excluding witness data from this measurement?

> In the short term, an increase is needed to continue to facilitate network
> growth, and buy time...

Actual network growth does not reflect a pattern that supports this claim.

> This reduces the fee pressure on users and companies creating on-chain
> transactions, matching market expectations and preventing further market
> disruption.

Larger block sizes is not likely to have a meaningful impact on fee pressure. 
Any expectations that do not match the reality are merely misguided, and 
should not be a basis for changing Bitcoin.

Luke

From greg at xiph.org  Fri Jul  7 23:38:06 2017
From: greg at xiph.org (Gregory Maxwell)
Date: Fri, 7 Jul 2017 23:38:06 +0000
Subject: [bitcoin-dev] A Segwit2x BIP
In-Reply-To: <201707072327.15901.luke@dashjr.org>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
	<201707072327.15901.luke@dashjr.org>
Message-ID: <CAAS2fgSLmVTB8aMU375YJsfr0LuPkg28X6NJ8e5vVZmyTwyvmQ@mail.gmail.com>

On Fri, Jul 7, 2017 at 11:27 PM, Luke Dashjr via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Larger block sizes is not likely to have a meaningful impact on fee pressure.
> Any expectations that do not match the reality are merely misguided, and
> should not be a basis for changing Bitcoin.

I think it's very clear that they will in the very short term
(https://anduck.net/bitcoin/fees/4320_blocks.php  note the rate drops
when demand falls below supply). But I agree with you if you mean a
somewhat longer term e.g. a year out.

From ZmnSCPxj at protonmail.com  Sat Jul  8 01:13:01 2017
From: ZmnSCPxj at protonmail.com (ZmnSCPxj)
Date: Fri, 07 Jul 2017 21:13:01 -0400
Subject: [bitcoin-dev] [BIP Proposal] Standard address format for timelocked
	funds
Message-ID: <VxtMcRFeh3Yr86KleeyK3BeZ9_KJVSmRtMgIdanwcEe23IrBwK0Q_ozC_EyxX6KHRcpePKgnaBk9KsY_i77k4Be3QEosXhUwbj561t4oJqw=@protonmail.com>

<pre>
BIP: ?
Title: Standard address format for timelocked funds
Author: ZmnSCPxj <ZmnSCPxj at protonmail.com>
Comments-Summary: ?
Comments-URI: ?
Status: ?
Type: ?
Created: 2017-07-01
License: CC0-1.0
</pre>
== Abstract ==
<code>OP_CHECKLOCKTIMEVERIFY</code> provides a method of
locking funds until a particular time arrives.
One potential use of this opcode is for a user to precommit
himself or herself to not spend funds until a particular
date, i.e. to hold the funds until a later date.
This proposal adds a format for specifying addresses that
precommit to timelocked funds, as well as specifying a
redemption code to redeem funds after the timelock has
passed.
This allows ordinary non-technical users to make use of
<code>OP_CHECKLOCKTIMEVERIFY</code> easily.
== Copyright ==
This BIP is released under CC0-1.0.
== Specification ==
This proposal provides formats for specifying an
address that locks funds until a specified date,
and a redemption code that allows the funds to be
swept on or after the specified date.
At minimum, wallet software supporting this BIP must
be capable of sweeping the redemption code on or after
the specified date.
In addition, the wallet software should support sending
funds to the timelocked address specified here.
Finally, wallet software may provide a command to create
a pair of timelocked address and redemption code.
Addresses and redemption codes are encoded using
[https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Bech32
Bech32 encoding].
=== Timelocked Address Format ===
The human-readable part of the address is composed of:
# The four characters <code>hodl</code>.
# A date, in <code>YYYYMMDD</code> form. For example,
the date August 1, 2017 is encoded as <code>20170801</code>.
# A network code, either <code>tb</code> for testnet,
or <code>bc</code> for Bitcoin mainnet.
The data part of the address is composed of:
# A version quintet (5 bits), which must be 0 for this
BIP.
# A public key hash, 32 quintets (160 bits). As is
usual for Bitcoin, this is big-endian.
This is to be interpreted as follows:
# The given date is the first day that the funds in
the given address may be redeemed.
# The funds are owned by whoever controls the private
key corresponding to the public key hash given.
=== Redemption Code ===
The human-readable part of the redemption code is
composed of:
# The four characters <code>hedl</code>.
# A date, in <code>YYYYMMDD</code> form.
# A network code, either <code>tb</code> for testnet,
or <code>bc</code> for Bitcoin mainnet.
The data part of the address is composed of:
# A version quintet (5 bits), which must be 0 for this
BIP.
# A private key, 52 quintets (260 bits). This is the
256-bit private key, prepended with 4 <code>0</code>
bits, in big-endian order. <!-- We could consider
some kind of mini private key instead if the security
is similar anyway. -->
This is to be interpreted as follows:
# The given date is the first day that the funds in
the given address may be redeemed.
# The private key unlocks the funds.
=== Lock Time Computation ===
Given a particular lock date <code>YYYYMMDD</code>, the
actual lock time is computed as follows:
# The day before the lock date is taken. For example,
if the lock date is <code>20180101</code> or
January 1, 2018, we take the date December 31, 2017.
# We take the time 1000h (10:00 AM, or 10 in the morning)
of the date from the above step.
This lock time is then translated to a
Unix epoch time, as per POSIX.1-2001 (which removes the
buggy day February 29, 2100 in previous POSIX revisions).
The translation should use, at minimum, unsigned 32-bit
numbers to represent the Unix epoch time.
The Unix epoch time shall then be interpreted as an
<code>nLockTime</code> value, as per standard Bitcoin.
Whether it is possible to represent dates past 2038
will depend on whether standard Bitcoin can represent
<code>nLockTime</code> values to represent dates past
2038.
Since <code>nLockTime</code> is an unsigned 32-bit
value, it should be possible to represent dates until
06:28:15 UTC+0 2106-02-07.
Future versions of Bitcoin should be able to support
<code>nLockTime</code> larger than unsigned 32-bit,
in order to allow even later dates.
The reason for using an earlier lock time than the
specified date is given in the Rationale section of
this BIP.
=== Payment to a Timelocked Address ===
An ordinary P2SH payment is used to provide funds to a
timelocked address.
The script below is used as the <code>redeemScript</code>
for the P2SH payment:
<timeout> OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_DUP OP_HASH160 <publickeyhash> OP_EQUALVERIFY OP_CHECKSIG
Once the <code>redeemScript</code> is derived, the hash is
determined, and an ordinary P2SH output with the below
<code>scriptPubKey</code> used:
OP_HASH160 <redeemScripthash> OP_EQUAL
In case of SegWit deployment, SegWit-compatible wallets
should be able to use P2SH, P2WSH, or P2SH-P2WSH, as per
the output they would normally use in that situation.
Obviously, a timelocked address has an equivalent
Bitcoin <code>3</code> (P2SH) address.
A simple service or software that translates from a
public timelocked address to a P2SH address can be
created that makes timelocking (but not redemption)
backwards compatible with wallets that do not support
this BIP.
This proposal recommends that wallets supporting payment
to P2PKH, P2SH, P2WPKH, and P2WSH Bitcoin addresses should
reuse the same interface for paying to such addresses as
paying into timelocked addresses of this proposal.
=== Redemption of a Timelocked Redemption Code ===
To sweep a timelocked redemption code after the timelock,
one must provide the given <code>redeemScript</code> as
part of the <code>scriptSig</code>, of all unspent
outputs that pay to the given <code>redeemScript</code>
hash.
When sweeping a timelocked redemption code, first the
wallet must extract the private key from the redemption
code, then derive the public key, the public key hash,
the <code>redeemScript</code>, and finally the
<code>redeemScript</code> hash.
Then, the wallet must find all unspent outputs that pay
to the <code>redeemScript</code> hash via P2SH (and, in the
case of SegWit deployment, via P2SH-P2WSH and P2WSH).
For each such output, the wallet then generates a
transaction input with the below <code>scriptSig</code>, as
per usual P2SH redemptions:
<signature> <pubkey> <redeemScript>
The wallet then outputs to an address it can control.
As the Script involved uses <code>OP_CHECKLOCKTIMEVERIFY</code>,
the <code>nSequence</code> must be 0 and the
<code>nLockTime</code> must be equal to the computed
lock time.
This implies that the transaction cannot be transmitted
(and the funds cannot be sweeped)
until after the given lock time.
The above procedure is roughly identical to sweeping an
ordinary, exported private key.
This proposal recommends that wallets supporting a sweep
function should reuse the same interface for sweeping
individual private keys (wallet import format) for sweeping
timelocked redemption codes.
== Motivation ==
A key motivation for this BIP is to allow easy use of
<code>OP_CHECKLOCKTIMEVERIFY</code> by end-users.
The below are expected use cases of this proposal:
# A user wants to purchase an amount of Bitcoin,
and subsequently wait for an amount of time before
cashing out.
The user fears that he or she may have "weak hands",
i.e. sell unfavorably on a temporary dip, and thus
commits the coins into a timelocked fund that can
only be opened after a specific date.
# A user wants to gift an amount of Bitcoins to
an infant or minor, and wants the fund to not be spent
on ill-advised purchases until the infant or minor
reaches the age of maturity.
# A user may wish to prepare some kind of monthly subsidy
or allowance to another user, and prepares a series of
timelocked addresses, redeemable at some set date on
each month, and provides the private redemption codes to
the beneficiary.
# A user may fear duress or ransom for a particular
future time horizon, and voluntarily impose a lock time
during which a majority of their funds cannot be spent.
== Rationale ==
While in principle, this proposal may be implemented as a
separate service or software, we should consider the long
time horizons that may be desired by users.
A user using a particular software to timelock a fund may
have concerns, for example, of specifying a timelock
18 years in the future for a gift or inheritance to a
newborn infant.
The software or service may no longer exist after 18 years,
unless the user himself or herself takes over maintenance
of that software or service.
By having a single standard for timelocked funds that is
shared and common among multiple implementations of Bitcoin
wallets, the user has some assurance that the redemption code
for the funds is still useable after 18 years.
Further, a publicly-accessible standard specifying how the
funds can be redeemed will allow technically-capable users
or beneficiaries to create software that can redeem the
timelocked fund.
This proposal provides a timelock at the granularity of a
day.
The expectation is that users will have long time
durations of months or years, so that the ability to
specify exact times, which would require specifying the
timezone, is unneeded.
The actual timeout used is 1000h of the day before the
human-readable date, so that timezones of UTC+14 will
definitely be able to redeem the money starting at
0000h of the human-readable date, local time (UTC+14).
Given the expectation that users will use long time
durations, the fact that timezones of UTC-12 will
actually be able to redeem the funds on 2200h UTC-12
time two days before can be considered an acceptable
error.
The human-readable date is formatted according to
[https://www.iso.org/iso-8601-date-and-time-format.html
ISO standard dates], with the dashes removed.
Dashes may prevent double-click selection, making
usability of these addresses less desirable.
<!--
We can consider something like 2021m12d11 instead,
which would be much more readable and understandable
to human users.
-->
The <code>bc</code> or <code>tb</code> is after the
date since the date is composed of digits and the bech32
separator itself is the digit <code>1</code>. One
simply needs to compare <code>hedlbc202111211...</code>
and <code>hedl20211121bc1...</code>.
A version quintet is added in case of a future
sociopolitical event that changes interpretation of
dates, or changes in scripting that would allow for more
efficient redemptions of timelocked funds (which would
change the <code>redeemScript</code> paid to), or changes
in the size and/or format of lock times, and so on.
Such changes are unlikely, so the version is a quintet in
the bech32 data part rather than a substring in the
human-readable part.
The public address format uses the <code>hodl</code> as
the start of the code, while the private key (the
redemption code) uses <code>hedl</code>.
This provides a simple mnemonic for users:
"Pay into the <code>hodl</code> code to hold your
coins until the given date.
After you've held the coins (on or after the given date)
use the <code>hedl</code> code to redeem the coins."
The obvious misspelling of "hodl" is a homage to the common
meme within the Bitcoin community.
<!-- The above misspelling may be corrected if it is considered
to be in bad taste. -->
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170707/05ada9ef/attachment-0001.html>

From erik at q32.com  Sat Jul  8 06:30:03 2017
From: erik at q32.com (Erik Aronesty)
Date: Sat, 8 Jul 2017 02:30:03 -0400
Subject: [bitcoin-dev] A Segwit2x BIP
In-Reply-To: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
Message-ID: <CAJowKg+E8kJFBPa_q-QMGffpv20hWCeNaH1YYGs3JKELcWejbw@mail.gmail.com>

- The BIP91 portion of the fork seems OK to me.  There are some issues with
timing, but since this is for miner coordination of segwit activation, and
has little to do with other network users, it could be included as an
option.   (I'm a fan of adding options;plugins, etc. to Bitcoin... some
others aren't.)

- This hard fork portion of the proposal is being deployed with "emergency"
speed... even though there is not an emergency on the network today that I
am aware of.   If enacted, it will certainly result in two chains - and
with no replay protection..  The results of this will be confusing - two
ledgers with many transactions appearing on both and others appearing only
on one.

- The BIP should be modified to provide evidence and justification for the
timeline that is consistent with the level of risk the network would bear
if it were enacted.

- The coercion used to drive production of this BIP is mired in a
misinterpretation of BIP9 and sets a precedent for Bitcoin that may
undermine the value prospect of all cryptocurrency in general.   For this
reason alone - even if all of the engineering concerns and timelines are
improved - even assigning this BIP a number could be considered
irresponsible.

- If you still want to code up a fork for the Bitcoin network, consider
starting with Luke's hard fork code and changing the rates of growth as
needed for your desired effect.   Also you might want to read this first
(code references are in there):
https://petertodd.org/2016/hardforks-after-the-segwit-blocksize-increase .
Plans are already underway for a hard fork, for reasons that have nothing
to do with block size, but could include a timeline for a block size growth
consistent with global average residential bandwidth growth.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170708/2ef7883f/attachment.html>

From btcdrak at gmail.com  Sat Jul  8 13:28:11 2017
From: btcdrak at gmail.com (Btc Drak)
Date: Sat, 8 Jul 2017 13:28:11 +0000
Subject: [bitcoin-dev] A Segwit2x BIP
In-Reply-To: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
Message-ID: <CADJgMzuCcJhoEbaGUv8QgaaL82+UiV6Q9Tbbti++J=Jg5B=sgg@mail.gmail.com>

I am utterly appalled by this proposal both technically, ethically, and by
the process which it has adopted. Hard forks require consensus from the
entire ecosystem in order to prevent a fork, funds loss, confusion and harm
to the robust guarantees of the Bitcoin system has thus far displayed.

I know this is a draft, but you are seeking reviews of a proposal that has
just a few weeks remaining before deployment (where "technical review" is
pointless because the is not actually open
<https://pastebin.com/kktB1kaw> unless
you are an approved member
<https://github.com/btc1/bitcoin/commit/1719c872b6624c37b0f2d94e7a4a2656fac4804a#diff-6a3371457528722a734f3c51d9238c13>),
making it totally unworkable and irresponsible. For example, exactly how
are other implementations supposed to adopt the BIP in such a short
timeframe? For all the talk of how important "alternative implementations"
are, how does this rash and rushed action promote an ecosystem of multiple
implementors? By encouraging fast upgrades, you are actually centralizing
the ecosystem even further.

The linked coded doesn't uniquely identify itself on the network by
user-agent, something all distinct implementations have done to date.

The draft BIP text looks like an afterthought and doesn't actually specify
the proposal in enough detail to implement from the text. By contrast for
example, BIP141 has a level of detail which allowed others to implement
segwit without looking at any reference code (which consequently results to
more confidence and testing of the specification all round). The Bitcoin
system has a market cap of over $40bn supported by a robust and reliable
network and your proposal is an offence to all Bitcoin has achieved because
due to it's the strong foundations.

I cannot not support this proposal in the current form and timeline, nor do
I support the coercion that has been used behind closed doors to try and
gain more support (not limited to, but including approaching company
investors to twist arms and veiled threats of blacklisting companies from
further funding/collaboration).

I think the best you can hope for this hard fork proposal is for it to be
quietly ignored.



On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hello,
>
> Here is a BIP that matches the reference code that the Segwit2x group has
> built and published a week ago.
>
> This BIP and code satisfies the requests of a large part of the Bitcoin
> community for a moderate increase in the Bitcoin non-witness block space
> coupled with the activation of Segwit.
>
> You can find the BIP draft in the following link:
>
> https://github.com/SergioDemianLerner/BIPs/blob/
> master/BIP-draft-sergiolerner-segwit2x.mediawiki
>
> Reference source was kindly provided by the Segwit2x group.
>
> Best regards,
>  Sergio.
>
> _______________________________________________
> 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/20170708/b3a2925a/attachment.html>

From sergio.d.lerner at gmail.com  Mon Jul 10 11:50:33 2017
From: sergio.d.lerner at gmail.com (Sergio Demian Lerner)
Date: Mon, 10 Jul 2017 08:50:33 -0300
Subject: [bitcoin-dev] A Segwit2x BIP
In-Reply-To: <A7FFF8F7-9806-44F1-B68F-F83C44893365@ob1.io>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
	<CADJgMzuCcJhoEbaGUv8QgaaL82+UiV6Q9Tbbti++J=Jg5B=sgg@mail.gmail.com>
	<A7FFF8F7-9806-44F1-B68F-F83C44893365@ob1.io>
Message-ID: <CAKzdR-oRdX-fXyc6womZOyYyfHUJZdgh92FUMM8pR_QDNiJfkQ@mail.gmail.com>

Thank you for all your comments. I will improve the BIP based on the
technical suggestions received.

On the subjective/political side that has slipped into this discussion.
Skip this part if not interested in politics.

Regarding the timeline, its certainly rather short, but also is the UASF
BIP 148 ultimatum.

If Bitcoin were a democracy and we had somehow a way to securely perform a
referendum, then this will solve easily. But neither is true. At least now.

More than 80% of the miners and many users are willing to go in the
Segwit2x direction. With the support and great talent of the Bitcoin Core
developers, Segwit2x activation will not cause any major disruptions.
Without Core, there will be a temporary split. Both sides will have to
hard-fork.

I want a Bitcoin united. But maybe a split of Bitcoin, each side with its
own vision, is not so bad.

On Sat, Jul 8, 2017 at 6:19 PM, Brian Hoffman <brian at ob1.io> wrote:

> I don't feel threatened by investors. You're full of shit btcdrak.
>
> Proofread your emails. You just declared support for segwit2x.
>
> On Jul 8, 2017, at 9:28 AM, Btc Drak via bitcoin-dev <bitcoin-dev at lists.
> linuxfoundation.org> wrote:
>
> I am utterly appalled by this proposal both technically, ethically, and by
> the process which it has adopted. Hard forks require consensus from the
> entire ecosystem in order to prevent a fork, funds loss, confusion and harm
> to the robust guarantees of the Bitcoin system has thus far displayed.
>
> I know this is a draft, but you are seeking reviews of a proposal that has
> just a few weeks remaining before deployment (where "technical review" is
> pointless because the is not actually open <https://pastebin.com/kktB1kaw> unless
> you are an approved member
> <https://github.com/btc1/bitcoin/commit/1719c872b6624c37b0f2d94e7a4a2656fac4804a#diff-6a3371457528722a734f3c51d9238c13>),
> making it totally unworkable and irresponsible. For example, exactly how
> are other implementations supposed to adopt the BIP in such a short
> timeframe? For all the talk of how important "alternative implementations"
> are, how does this rash and rushed action promote an ecosystem of multiple
> implementors? By encouraging fast upgrades, you are actually centralizing
> the ecosystem even further.
>
> The linked coded doesn't uniquely identify itself on the network by
> user-agent, something all distinct implementations have done to date.
>
> The draft BIP text looks like an afterthought and doesn't actually specify
> the proposal in enough detail to implement from the text. By contrast for
> example, BIP141 has a level of detail which allowed others to implement
> segwit without looking at any reference code (which consequently results to
> more confidence and testing of the specification all round). The Bitcoin
> system has a market cap of over $40bn supported by a robust and reliable
> network and your proposal is an offence to all Bitcoin has achieved because
> due to it's the strong foundations.
>
> I cannot not support this proposal in the current form and timeline, nor
> do I support the coercion that has been used behind closed doors to try and
> gain more support (not limited to, but including approaching company
> investors to twist arms and veiled threats of blacklisting companies from
> further funding/collaboration).
>
> I think the best you can hope for this hard fork proposal is for it to be
> quietly ignored.
>
>
>
> On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hello,
>>
>> Here is a BIP that matches the reference code that the Segwit2x group has
>> built and published a week ago.
>>
>> This BIP and code satisfies the requests of a large part of the Bitcoin
>> community for a moderate increase in the Bitcoin non-witness block space
>> coupled with the activation of Segwit.
>>
>> You can find the BIP draft in the following link:
>>
>> https://github.com/SergioDemianLerner/BIPs/blob/master/BIP-
>> draft-sergiolerner-segwit2x.mediawiki
>>
>> Reference source was kindly provided by the Segwit2x group.
>>
>> Best regards,
>>  Sergio.
>>
>> _______________________________________________
>> 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/20170710/a72aad85/attachment-0001.html>

From truthcoin at gmail.com  Mon Jul 10 16:50:21 2017
From: truthcoin at gmail.com (Paul Sztorc)
Date: Mon, 10 Jul 2017 12:50:21 -0400
Subject: [bitcoin-dev] Updating the Scaling Roadmap
Message-ID: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>


Summary
=========

In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few
crucial ways. One success was that it synchronized the entire Bitcoin
community, helping to bring finality to the (endless) conversations of
that time, and get everyone back to work. However, I feel that the Dec
7, 2015 roadmap is simply too old to serve this function any longer. We
should revise it: remove what has been accomplished, introduce new
innovations and approaches, and update deadlines and projections.


Why We Should Update the Roadmap
=================================

In a P2P system like Bitcoin, we lack authoritative info-sources (for
example, a "textbook" or academic journal), and as a result
conversations tend to have a problematic lack of progress. They do not
"accumulate", as everyone must start over. Ironically, the scaling
conversation _itself_ has a fatal O(n^2) scaling problem.

The roadmap helped solve these problems by being constant in size, and
subjecting itself to publication, endorsement, criticism, and so forth.
Despite the (unavoidable) nuance and complexity of each individual
opinion, it was at least globally known that X participants endorsed Y
set of claims.

Unfortunately, the Dec 2015 roadmap is now 19 months old -- it is quite
obsolete and replacing it is long overdue. For example, it highlights
older items (CSV, compact blocks, versionbits) as being _future_
improvements, and makes no mention of new high-likelihood improvements
(Schnorr) or mis-emphasizes them (LN). It even contains mistakes (SegWit
fraud proofs). To read the old roadmap properly, one must already be a
technical expert. For me, this defeats the entire point of having one in
the first place.

A new roadmap would be worth your attention, even if you didn't sign it,
because a refusal to sign would still be informative (and, therefore,
helpful)!

So, with that in mind, let me present a first draft. Obviously, I am
strongly open to edits and feedback, because I have no way of knowing
everyone's opinions. I admit that I am partially campaigning for my
Drivechain project, and also for this "scalability"/"capacity"
distinction...that's because I believe in both and think they are
helpful. But please feel free to suggest edits.

I emphasized concrete numbers, and concrete dates.

And I did NOT necessarily write it from my own point of view, I tried
earnestly to capture a (useful) community view. So, let me know how I did.

 ==== Beginning of New ("July 2017") Roadmap Draft ====

This document updates the previous roadmap [1] of Dec 2015. The older
statement endorsed a belief that "the community is ready to deliver on
its shared vision that addresses the needs of the system while upholding
its values".

That belief has not changed, but the shared vision has certainly grown
sharper over the last 18 months. Below is a list of technologies which
either increase Bitcoin's maximum tps rate ("capacity"), or which make
it easier to process a higher volume of transactions ("scalability").

First, over the past 18 months, the technical community has completed a
number of items [2] on the Dec 2015 roadmap. VersonBits (BIP 9) enables
Bitcoin to handle multiple soft fork upgrades at once. Compact Blocks
(BIP 152) allows for much faster block propagation, as does the FIBRE
Network [3]. Check Sequence Verify (BIP 112) allows trading partners to
mutually update an active transaction without writing it to the
blockchain (this helps to enable the Lightning Network).

Second, Segregated Witness (BIP 141), which reorganizes data in blocks
to handle signatures separately, has been completed and awaits
activation (multiple BIPS). It is estimated to increase capacity by a
factor of 2.2. It also improves scalability in many ways. First, SW
includes a fee-policy which encourages users to minimize their impact on
the UTXO set. Second, SW achieves linear scaling of sighash operations,
which prevents the network from crashing when large transactions are
broadcast. Third, SW provides an efficiency gain for everyone who is not
verifying signatures, as these no longer need to be downloaded or
stored. SegWit is an enabling technology for the Lightning Network,
script versioning (specifically Schnorr signatures), and has a number of
benefits which
are unrelated to capacity [4].

Third, the Lightning Network, which allows users to transact without
broadcasting to the network, is complete [5, 6] and awaits the
activation of SegWit. For those users who are able to make a single
on-chain transaction, it is estimated to increase both capacity and
scalability by a factor of ~1000 (although these capacity increases will
vary with usage patterns). LN also greatly improves transaction speed
and transaction privacy.

Fourth, Transaction Compression [7], observes that Bitcoin transaction
serialization is not optimized for storage or network communication. If
transactions were optimally compressed (as is possible today), this
would improve scalability, but not capacity, by roughly 20%, and in some
cases over 30%.

Fifth, Schnorr Signature Aggregation, which shrinks transactions by
allowing many transactions to have a single shared signature, has been
implemented [8] in draft form in libsecp256k1, and will likely be ready
by Q4 of 2016. One analysis [9] suggests that signature aggregation
would result in storage and bandwidth savings of at least 25%, which
would therefore increase scalability and capacity by a factor of 1.33.
The relative savings are even greater for multisignature transactions.

Sixth, drivechain [10], which allows bitcoins to be temporarily
offloaded to 'alternative' blockchain networks ("sidechains"), is
currently under peer review and may be usable by end of 2017. Although
it has no impact on scalability, it does allow users to opt-in to
greater capacity, by moving their BTC to a new network (although, they
will achieve less decentralization as a result). Individual drivechains
may have different security tradeoffs (for example, a greater reliance
on UTXO commitments, or MimbleWimble's shrinking block history) which
may give them individually greater scalability than mainchain Bitcoin.

Finally, the capacity improvements outlined above may not be sufficient.
If so, it may be necessary to use a hard fork to increase the blocksize
(and blockweight, sigops, etc) by a moderate amount. Such an increase
should take advantage of the existing research on hard forks, which is
substantial [11]. Specifically, there is some consensus that Spoonnet
[12] is the most attractive option for such a hardfork. There is
currently no consensus on a hard fork date, but there is a rough
consensus that one would require at least 6 months to coordinate
effectively, which would place it in the year 2018 at earliest.

The above are only a small sample of current scaling technologies. And
even an exhaustive list of scaling technologies, would itself only be a
small sample of total Bitcoin innovation (which is proceeding at
breakneck speed).

Signed,
<Names Here>

[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
[2] https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/
[3] http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/
[4] https://bitcoincore.org/en/2016/01/26/segwit-benefits/
[5]
http://lightning.community/release/software/lnd/lightning/2017/05/03/litening/
[6] https://github.com/ACINQ/eclair
[7] https://people.xiph.org/~greg/compacted_txn.txt
[8]
https://github.com/ElementsProject/secp256k1-zkp/blob/d78f12b04ec3d9f5744cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594
[9] https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/
[10] http://www.drivechain.info/
[11] https://bitcoinhardforkresearch.github.io/
[12]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html

 ==== End of Roadmap Draft ====

In short, please let me know:

1. If you agree that it would be helpful if the roadmap were updated.
2. To what extent, if any, you like this draft.
3. Edits you would make (specifically, I wonder about Drivechain
thoughts and Hard Fork thoughts, particularly how to phrase the Hard
Fork date).

Google Doc (if you're into that kind of thing):
https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNocmCq-jjBOQSVH-A/edit?usp=sharing

Cheers,
Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170710/60d2fe7d/attachment.sig>

From jtimon at jtimon.cc  Mon Jul 10 18:38:08 2017
From: jtimon at jtimon.cc (=?UTF-8?B?Sm9yZ2UgVGltw7Nu?=)
Date: Mon, 10 Jul 2017 20:38:08 +0200
Subject: [bitcoin-dev] A Segwit2x BIP
In-Reply-To: <CAKzdR-oRdX-fXyc6womZOyYyfHUJZdgh92FUMM8pR_QDNiJfkQ@mail.gmail.com>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
	<CADJgMzuCcJhoEbaGUv8QgaaL82+UiV6Q9Tbbti++J=Jg5B=sgg@mail.gmail.com>
	<A7FFF8F7-9806-44F1-B68F-F83C44893365@ob1.io>
	<CAKzdR-oRdX-fXyc6womZOyYyfHUJZdgh92FUMM8pR_QDNiJfkQ@mail.gmail.com>
Message-ID: <CABm2gDo0wgqkEufKn=Z8uAsi=_6fgE=0TS6Bcr21mg3xAX7Kyw@mail.gmail.com>

On Mon, Jul 10, 2017 at 1:50 PM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Regarding the timeline, its certainly rather short, but also is the UASF BIP
> 148 ultimatum.

This is correct. If you are trying to imply that makes the short
timeline here right, you are falling for a "tu quoque" fallacy.

> More than 80% of the miners and many users are willing to go in the Segwit2x
> direction.

There's no logical reason I can think of (and I've heard many attempts
at explaining it) for miners to consider segwit bad for Bitcoin but
segwitx2 harmless. But I don't see 80% hashrate support for bip141, so
your claim doesn't seem accurate for the segwit part, let alone the
more controversial hardfork part.

I read some people controlling mining pools that control 80% of the
hashrate signed a paper saying they would "support segwit
immediately". Either what I read wasn't true, or the signed paper is
just a proof of the signing pool operators word being something we
cannot trust.

So where does this 80% figure come from? How can we trust the source?

> I want a Bitcoin united. But maybe a split of Bitcoin, each side with its
> own vision, is not so bad.

It would be unfortunate to split the network into 2 coins only because
of lack of patience for deploying non-urgent consensus changes like a
size increase or disagreements about the right time schedule.
I think anything less than 1 year after release of tested code by some
implementation would be irresponsible for any hardfork, even a very
simple one.

From chris at suredbits.com  Tue Jul 11 16:03:45 2017
From: chris at suredbits.com (Chris Stewart)
Date: Tue, 11 Jul 2017 11:03:45 -0500
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
Message-ID: <CAGL6+mHQZ3UP10msk65OO+Uk0hn7j+dkmJap_M7FgWfSZaYYJQ@mail.gmail.com>

Concept ACK.

I think you are overstating the readiness of drivechains though. I think
the optimistic estimate for drivechains to be ready for bitcoin core is a
year out from today. More likely the date should be early 2018. Still a lot
of work to be done! :-)

Also I don't know if I would put a hard fork suggestion in the scaling map.
If drivechains are successful they should be viewed as the way we scale --
not hard forking the protocol. Do you still have capacity concerns if
drivechains are successful?

-Chris

On Mon, Jul 10, 2017 at 11:50 AM, Paul Sztorc via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

>
> Summary
> =========
>
> In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few
> crucial ways. One success was that it synchronized the entire Bitcoin
> community, helping to bring finality to the (endless) conversations of
> that time, and get everyone back to work. However, I feel that the Dec
> 7, 2015 roadmap is simply too old to serve this function any longer. We
> should revise it: remove what has been accomplished, introduce new
> innovations and approaches, and update deadlines and projections.
>
>
> Why We Should Update the Roadmap
> =================================
>
> In a P2P system like Bitcoin, we lack authoritative info-sources (for
> example, a "textbook" or academic journal), and as a result
> conversations tend to have a problematic lack of progress. They do not
> "accumulate", as everyone must start over. Ironically, the scaling
> conversation _itself_ has a fatal O(n^2) scaling problem.
>
> The roadmap helped solve these problems by being constant in size, and
> subjecting itself to publication, endorsement, criticism, and so forth.
> Despite the (unavoidable) nuance and complexity of each individual
> opinion, it was at least globally known that X participants endorsed Y
> set of claims.
>
> Unfortunately, the Dec 2015 roadmap is now 19 months old -- it is quite
> obsolete and replacing it is long overdue. For example, it highlights
> older items (CSV, compact blocks, versionbits) as being _future_
> improvements, and makes no mention of new high-likelihood improvements
> (Schnorr) or mis-emphasizes them (LN). It even contains mistakes (SegWit
> fraud proofs). To read the old roadmap properly, one must already be a
> technical expert. For me, this defeats the entire point of having one in
> the first place.
>
> A new roadmap would be worth your attention, even if you didn't sign it,
> because a refusal to sign would still be informative (and, therefore,
> helpful)!
>
> So, with that in mind, let me present a first draft. Obviously, I am
> strongly open to edits and feedback, because I have no way of knowing
> everyone's opinions. I admit that I am partially campaigning for my
> Drivechain project, and also for this "scalability"/"capacity"
> distinction...that's because I believe in both and think they are
> helpful. But please feel free to suggest edits.
>
> I emphasized concrete numbers, and concrete dates.
>
> And I did NOT necessarily write it from my own point of view, I tried
> earnestly to capture a (useful) community view. So, let me know how I did.
>
>  ==== Beginning of New ("July 2017") Roadmap Draft ====
>
> This document updates the previous roadmap [1] of Dec 2015. The older
> statement endorsed a belief that "the community is ready to deliver on
> its shared vision that addresses the needs of the system while upholding
> its values".
>
> That belief has not changed, but the shared vision has certainly grown
> sharper over the last 18 months. Below is a list of technologies which
> either increase Bitcoin's maximum tps rate ("capacity"), or which make
> it easier to process a higher volume of transactions ("scalability").
>
> First, over the past 18 months, the technical community has completed a
> number of items [2] on the Dec 2015 roadmap. VersonBits (BIP 9) enables
> Bitcoin to handle multiple soft fork upgrades at once. Compact Blocks
> (BIP 152) allows for much faster block propagation, as does the FIBRE
> Network [3]. Check Sequence Verify (BIP 112) allows trading partners to
> mutually update an active transaction without writing it to the
> blockchain (this helps to enable the Lightning Network).
>
> Second, Segregated Witness (BIP 141), which reorganizes data in blocks
> to handle signatures separately, has been completed and awaits
> activation (multiple BIPS). It is estimated to increase capacity by a
> factor of 2.2. It also improves scalability in many ways. First, SW
> includes a fee-policy which encourages users to minimize their impact on
> the UTXO set. Second, SW achieves linear scaling of sighash operations,
> which prevents the network from crashing when large transactions are
> broadcast. Third, SW provides an efficiency gain for everyone who is not
> verifying signatures, as these no longer need to be downloaded or
> stored. SegWit is an enabling technology for the Lightning Network,
> script versioning (specifically Schnorr signatures), and has a number of
> benefits which
> are unrelated to capacity [4].
>
> Third, the Lightning Network, which allows users to transact without
> broadcasting to the network, is complete [5, 6] and awaits the
> activation of SegWit. For those users who are able to make a single
> on-chain transaction, it is estimated to increase both capacity and
> scalability by a factor of ~1000 (although these capacity increases will
> vary with usage patterns). LN also greatly improves transaction speed
> and transaction privacy.
>
> Fourth, Transaction Compression [7], observes that Bitcoin transaction
> serialization is not optimized for storage or network communication. If
> transactions were optimally compressed (as is possible today), this
> would improve scalability, but not capacity, by roughly 20%, and in some
> cases over 30%.
>
> Fifth, Schnorr Signature Aggregation, which shrinks transactions by
> allowing many transactions to have a single shared signature, has been
> implemented [8] in draft form in libsecp256k1, and will likely be ready
> by Q4 of 2016. One analysis [9] suggests that signature aggregation
> would result in storage and bandwidth savings of at least 25%, which
> would therefore increase scalability and capacity by a factor of 1.33.
> The relative savings are even greater for multisignature transactions.
>
> Sixth, drivechain [10], which allows bitcoins to be temporarily
> offloaded to 'alternative' blockchain networks ("sidechains"), is
> currently under peer review and may be usable by end of 2017. Although
> it has no impact on scalability, it does allow users to opt-in to
> greater capacity, by moving their BTC to a new network (although, they
> will achieve less decentralization as a result). Individual drivechains
> may have different security tradeoffs (for example, a greater reliance
> on UTXO commitments, or MimbleWimble's shrinking block history) which
> may give them individually greater scalability than mainchain Bitcoin.
>
> Finally, the capacity improvements outlined above may not be sufficient.
> If so, it may be necessary to use a hard fork to increase the blocksize
> (and blockweight, sigops, etc) by a moderate amount. Such an increase
> should take advantage of the existing research on hard forks, which is
> substantial [11]. Specifically, there is some consensus that Spoonnet
> [12] is the most attractive option for such a hardfork. There is
> currently no consensus on a hard fork date, but there is a rough
> consensus that one would require at least 6 months to coordinate
> effectively, which would place it in the year 2018 at earliest.
>
> The above are only a small sample of current scaling technologies. And
> even an exhaustive list of scaling technologies, would itself only be a
> small sample of total Bitcoin innovation (which is proceeding at
> breakneck speed).
>
> Signed,
> <Names Here>
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2015-December/011865.html
> [2] https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/
> [3] http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/
> [4] https://bitcoincore.org/en/2016/01/26/segwit-benefits/
> [5]
> http://lightning.community/release/software/lnd/
> lightning/2017/05/03/litening/
> [6] https://github.com/ACINQ/eclair
> [7] https://people.xiph.org/~greg/compacted_txn.txt
> [8]
> https://github.com/ElementsProject/secp256k1-zkp/blob/
> d78f12b04ec3d9f5744cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594
> [9] https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/
> [10] http://www.drivechain.info/
> [11] https://bitcoinhardforkresearch.github.io/
> [12]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-February/013542.html
>
>  ==== End of Roadmap Draft ====
>
> In short, please let me know:
>
> 1. If you agree that it would be helpful if the roadmap were updated.
> 2. To what extent, if any, you like this draft.
> 3. Edits you would make (specifically, I wonder about Drivechain
> thoughts and Hard Fork thoughts, particularly how to phrase the Hard
> Fork date).
>
> Google Doc (if you're into that kind of thing):
> https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNoc
> mCq-jjBOQSVH-A/edit?usp=sharing
>
> Cheers,
> Paul
>
>
> _______________________________________________
> 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/20170711/8b9806dd/attachment-0001.html>

From pieter.wuille at gmail.com  Tue Jul 11 20:01:10 2017
From: pieter.wuille at gmail.com (Pieter Wuille)
Date: Tue, 11 Jul 2017 13:01:10 -0700
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <CAGL6+mHQZ3UP10msk65OO+Uk0hn7j+dkmJap_M7FgWfSZaYYJQ@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAGL6+mHQZ3UP10msk65OO+Uk0hn7j+dkmJap_M7FgWfSZaYYJQ@mail.gmail.com>
Message-ID: <CAPg+sBghOOcyRqtuAXhWQ=yA1nuqw8Xs+yrK9CTpRo4uc3773Q@mail.gmail.com>

On Jul 11, 2017 09:18, "Chris Stewart via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:

Concept ACK.

If drivechains are successful they should be viewed as the way we scale


I strongly disagree with that statement.

Drivechains, and several earlier sidechains ideas, are not a scalability
improvement, but merely enabling users to opt-in for another security model.

While obviously any future with wider adoption will need different
technologies that have different trade-offs, and anyone is free to choose
their security model, I don't think this particular one is interesting. In
terms of validation cost to auditors, it is as bad as just a capacity
increase on chain, while simultaneously adding the extra risk of miners
being able to vote to steal your money.

Cheers,

-- 
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/6c7b8145/attachment.html>

From truthcoin at gmail.com  Tue Jul 11 20:18:04 2017
From: truthcoin at gmail.com (Paul Sztorc)
Date: Tue, 11 Jul 2017 16:18:04 -0400
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <CAGL6+mHQZ3UP10msk65OO+Uk0hn7j+dkmJap_M7FgWfSZaYYJQ@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAGL6+mHQZ3UP10msk65OO+Uk0hn7j+dkmJap_M7FgWfSZaYYJQ@mail.gmail.com>
Message-ID: <f79b9693-b8a5-c496-9dd9-d74704855d0e@gmail.com>

Hi Chris,

On 7/11/2017 12:03 PM, Chris Stewart wrote:
> Concept ACK.
>
> I think you are overstating the readiness of drivechains though. I
> think the optimistic estimate for drivechains to be ready for bitcoin
> core is a year out from today. More likely the date should be early
> 2018. Still a lot of work to be done! :-)
It depends on interest, I think. What remains to be done is more easily
parallelized, and in some cases (eg smartphone wallets) there are
incentives for private individuals and businesses to hustle their part
out (merely for reasons of competitiveness).

> Also I don't know if I would put a hard fork suggestion in the scaling
> map. If drivechains are successful they should be viewed as the way we
> scale -- not hard forking the protocol. Do you still have capacity
> concerns if drivechains are successful?

I wrote the roadmap to try to be representative of a Core / developer
position. I am philosophically against hard forks, but HFs were in the
end of the previous roadmap so I felt it should stay. And, I felt that
if I decided to unilaterally remove it, it would be perceived as
excessive campaigning for Drivechain. And I also felt that to remove it,
when so many industry members recently put their weight behind a fast
hard fork, would be perceived as a reaction to that attempt, and would
then overwhelm the document with political polarization, for really no
benefit.

Paul

>
> -Chris
>
> On Mon, Jul 10, 2017 at 11:50 AM, Paul Sztorc via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
>
>     Summary
>     =========
>
>     In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few
>     crucial ways. One success was that it synchronized the entire Bitcoin
>     community, helping to bring finality to the (endless) conversations of
>     that time, and get everyone back to work. However, I feel that the Dec
>     7, 2015 roadmap is simply too old to serve this function any
>     longer. We
>     should revise it: remove what has been accomplished, introduce new
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/6b8452e0/attachment.html>

From truthcoin at gmail.com  Tue Jul 11 20:36:36 2017
From: truthcoin at gmail.com (Paul Sztorc)
Date: Tue, 11 Jul 2017 16:36:36 -0400
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <CAPg+sBghOOcyRqtuAXhWQ=yA1nuqw8Xs+yrK9CTpRo4uc3773Q@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAGL6+mHQZ3UP10msk65OO+Uk0hn7j+dkmJap_M7FgWfSZaYYJQ@mail.gmail.com>
	<CAPg+sBghOOcyRqtuAXhWQ=yA1nuqw8Xs+yrK9CTpRo4uc3773Q@mail.gmail.com>
Message-ID: <d53dc5d2-b761-53c3-3bb8-0d8d39cbda37@gmail.com>

Pieter,

I think that you have misrepresented Chris' view by taking it out of
context. His complete quote reads "If drivechains are successful they
should be viewed as the way we scale -- not hard forking the protocol."
Chris is comparing Drivechains/sidechains to a hard fork.

You went on to "disagree", but every point of contention you introduced
was something that would apply to both drivechain-sourced capacity and
hardfork-sourced capacity. Neither improves scalability, and both allow
users only the opportunity to select a different security model. If I
understand you, the point at which a security model does not become
"interesting" to you, would be the exact same point in the drivechain
and hardfork worlds. Both, at any rate, have the same effect on
"validation cost to auditors".

The only true difference is the "extra risk of miners being able to vote
to steal your money", but as I have pointed out on this mailing list
several times, I do not actually believe that there is any marginal risk
-- miners can already "vote to steal your money" in the double-spend and
ln-channel-theft contexts. I have also argued that the "risk" is
actually desirable in an opt-in context, because it puts the burden of
proof on miners/developers (to convince users that they should move over
to the sidechain). Since their sidechain coins cannot appreciate in
value relative to the mainchain coins, users would only opt-in if they
felt that they were sufficiently compensated for any and all risks.
Hence, it is difficult to list this item as a drawback when, to the
user, it is a strict improvement (at least, by any epistemological
standard that I can think of). If you have new objections to these
claims, I'm sure we would all benefit from hearing them, myself most of all.

Paul


On 7/11/2017 4:01 PM, Pieter Wuille wrote:
> On Jul 11, 2017 09:18, "Chris Stewart via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
>     Concept ACK.
>
>     If drivechains are successful they should be viewed as the way we
>     scale
>
>
> I strongly disagree with that statement.
>
> Drivechains, and several earlier sidechains ideas, are not a
> scalability improvement, but merely enabling users to opt-in for
> another security model.
>
> While obviously any future with wider adoption will need different
> technologies that have different trade-offs, and anyone is free to
> choose their security model, I don't think this particular one is
> interesting. In terms of validation cost to auditors, it is as bad as
> just a capacity increase on chain, while simultaneously adding the
> extra risk of miners being able to vote to steal your money.
>
> Cheers,
>
> -- 
> Pieter
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/3fa37fbd/attachment.html>

From adam.back at gmail.com  Tue Jul 11 16:49:57 2017
From: adam.back at gmail.com (Adam Back)
Date: Tue, 11 Jul 2017 17:49:57 +0100
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <CAGL6+mHQZ3UP10msk65OO+Uk0hn7j+dkmJap_M7FgWfSZaYYJQ@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAGL6+mHQZ3UP10msk65OO+Uk0hn7j+dkmJap_M7FgWfSZaYYJQ@mail.gmail.com>
Message-ID: <CALqxMTEEGg1Y03_3on1Ggjb_42UXbDcqL4sb0xZ-OTid+ThzAA@mail.gmail.com>

Separate from scale, there is utility to a hard-fork to fix wish-list
bugs that cant be reasonably fixed via soft-fork.  The spoonnet
proposal fixes a good number of interesting bugs.  Spoonnet and
several other HF research proposals can be found here
https://bitcoinhardforkresearch.github.io/  Part of the research on HF
is about safe deployment methods which is obviously the other main
consideration.  It seems to me likely that if the HF were to focus on
bug fixes, and not mix in new tradeoffs of security vs scale, it would
more easily reach consensus.

Adam

On 11 July 2017 at 17:03, Chris Stewart via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Concept ACK.
>
> I think you are overstating the readiness of drivechains though. I think the
> optimistic estimate for drivechains to be ready for bitcoin core is a year
> out from today. More likely the date should be early 2018. Still a lot of
> work to be done! :-)
>
> Also I don't know if I would put a hard fork suggestion in the scaling map.
> If drivechains are successful they should be viewed as the way we scale --
> not hard forking the protocol. Do you still have capacity concerns if
> drivechains are successful?
>
> -Chris
>
> On Mon, Jul 10, 2017 at 11:50 AM, Paul Sztorc via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>
>> Summary
>> =========
>>
>> In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few
>> crucial ways. One success was that it synchronized the entire Bitcoin
>> community, helping to bring finality to the (endless) conversations of
>> that time, and get everyone back to work. However, I feel that the Dec
>> 7, 2015 roadmap is simply too old to serve this function any longer. We
>> should revise it: remove what has been accomplished, introduce new
>> innovations and approaches, and update deadlines and projections.
>>
>>
>> Why We Should Update the Roadmap
>> =================================
>>
>> In a P2P system like Bitcoin, we lack authoritative info-sources (for
>> example, a "textbook" or academic journal), and as a result
>> conversations tend to have a problematic lack of progress. They do not
>> "accumulate", as everyone must start over. Ironically, the scaling
>> conversation _itself_ has a fatal O(n^2) scaling problem.
>>
>> The roadmap helped solve these problems by being constant in size, and
>> subjecting itself to publication, endorsement, criticism, and so forth.
>> Despite the (unavoidable) nuance and complexity of each individual
>> opinion, it was at least globally known that X participants endorsed Y
>> set of claims.
>>
>> Unfortunately, the Dec 2015 roadmap is now 19 months old -- it is quite
>> obsolete and replacing it is long overdue. For example, it highlights
>> older items (CSV, compact blocks, versionbits) as being _future_
>> improvements, and makes no mention of new high-likelihood improvements
>> (Schnorr) or mis-emphasizes them (LN). It even contains mistakes (SegWit
>> fraud proofs). To read the old roadmap properly, one must already be a
>> technical expert. For me, this defeats the entire point of having one in
>> the first place.
>>
>> A new roadmap would be worth your attention, even if you didn't sign it,
>> because a refusal to sign would still be informative (and, therefore,
>> helpful)!
>>
>> So, with that in mind, let me present a first draft. Obviously, I am
>> strongly open to edits and feedback, because I have no way of knowing
>> everyone's opinions. I admit that I am partially campaigning for my
>> Drivechain project, and also for this "scalability"/"capacity"
>> distinction...that's because I believe in both and think they are
>> helpful. But please feel free to suggest edits.
>>
>> I emphasized concrete numbers, and concrete dates.
>>
>> And I did NOT necessarily write it from my own point of view, I tried
>> earnestly to capture a (useful) community view. So, let me know how I did.
>>
>>  ==== Beginning of New ("July 2017") Roadmap Draft ====
>>
>> This document updates the previous roadmap [1] of Dec 2015. The older
>> statement endorsed a belief that "the community is ready to deliver on
>> its shared vision that addresses the needs of the system while upholding
>> its values".
>>
>> That belief has not changed, but the shared vision has certainly grown
>> sharper over the last 18 months. Below is a list of technologies which
>> either increase Bitcoin's maximum tps rate ("capacity"), or which make
>> it easier to process a higher volume of transactions ("scalability").
>>
>> First, over the past 18 months, the technical community has completed a
>> number of items [2] on the Dec 2015 roadmap. VersonBits (BIP 9) enables
>> Bitcoin to handle multiple soft fork upgrades at once. Compact Blocks
>> (BIP 152) allows for much faster block propagation, as does the FIBRE
>> Network [3]. Check Sequence Verify (BIP 112) allows trading partners to
>> mutually update an active transaction without writing it to the
>> blockchain (this helps to enable the Lightning Network).
>>
>> Second, Segregated Witness (BIP 141), which reorganizes data in blocks
>> to handle signatures separately, has been completed and awaits
>> activation (multiple BIPS). It is estimated to increase capacity by a
>> factor of 2.2. It also improves scalability in many ways. First, SW
>> includes a fee-policy which encourages users to minimize their impact on
>> the UTXO set. Second, SW achieves linear scaling of sighash operations,
>> which prevents the network from crashing when large transactions are
>> broadcast. Third, SW provides an efficiency gain for everyone who is not
>> verifying signatures, as these no longer need to be downloaded or
>> stored. SegWit is an enabling technology for the Lightning Network,
>> script versioning (specifically Schnorr signatures), and has a number of
>> benefits which
>> are unrelated to capacity [4].
>>
>> Third, the Lightning Network, which allows users to transact without
>> broadcasting to the network, is complete [5, 6] and awaits the
>> activation of SegWit. For those users who are able to make a single
>> on-chain transaction, it is estimated to increase both capacity and
>> scalability by a factor of ~1000 (although these capacity increases will
>> vary with usage patterns). LN also greatly improves transaction speed
>> and transaction privacy.
>>
>> Fourth, Transaction Compression [7], observes that Bitcoin transaction
>> serialization is not optimized for storage or network communication. If
>> transactions were optimally compressed (as is possible today), this
>> would improve scalability, but not capacity, by roughly 20%, and in some
>> cases over 30%.
>>
>> Fifth, Schnorr Signature Aggregation, which shrinks transactions by
>> allowing many transactions to have a single shared signature, has been
>> implemented [8] in draft form in libsecp256k1, and will likely be ready
>> by Q4 of 2016. One analysis [9] suggests that signature aggregation
>> would result in storage and bandwidth savings of at least 25%, which
>> would therefore increase scalability and capacity by a factor of 1.33.
>> The relative savings are even greater for multisignature transactions.
>>
>> Sixth, drivechain [10], which allows bitcoins to be temporarily
>> offloaded to 'alternative' blockchain networks ("sidechains"), is
>> currently under peer review and may be usable by end of 2017. Although
>> it has no impact on scalability, it does allow users to opt-in to
>> greater capacity, by moving their BTC to a new network (although, they
>> will achieve less decentralization as a result). Individual drivechains
>> may have different security tradeoffs (for example, a greater reliance
>> on UTXO commitments, or MimbleWimble's shrinking block history) which
>> may give them individually greater scalability than mainchain Bitcoin.
>>
>> Finally, the capacity improvements outlined above may not be sufficient.
>> If so, it may be necessary to use a hard fork to increase the blocksize
>> (and blockweight, sigops, etc) by a moderate amount. Such an increase
>> should take advantage of the existing research on hard forks, which is
>> substantial [11]. Specifically, there is some consensus that Spoonnet
>> [12] is the most attractive option for such a hardfork. There is
>> currently no consensus on a hard fork date, but there is a rough
>> consensus that one would require at least 6 months to coordinate
>> effectively, which would place it in the year 2018 at earliest.
>>
>> The above are only a small sample of current scaling technologies. And
>> even an exhaustive list of scaling technologies, would itself only be a
>> small sample of total Bitcoin innovation (which is proceeding at
>> breakneck speed).
>>
>> Signed,
>> <Names Here>
>>
>> [1]
>>
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
>> [2] https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/
>> [3] http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/
>> [4] https://bitcoincore.org/en/2016/01/26/segwit-benefits/
>> [5]
>>
>> http://lightning.community/release/software/lnd/lightning/2017/05/03/litening/
>> [6] https://github.com/ACINQ/eclair
>> [7] https://people.xiph.org/~greg/compacted_txn.txt
>> [8]
>>
>> https://github.com/ElementsProject/secp256k1-zkp/blob/d78f12b04ec3d9f5744cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594
>> [9] https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/
>> [10] http://www.drivechain.info/
>> [11] https://bitcoinhardforkresearch.github.io/
>> [12]
>>
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html
>>
>>  ==== End of Roadmap Draft ====
>>
>> In short, please let me know:
>>
>> 1. If you agree that it would be helpful if the roadmap were updated.
>> 2. To what extent, if any, you like this draft.
>> 3. Edits you would make (specifically, I wonder about Drivechain
>> thoughts and Hard Fork thoughts, particularly how to phrase the Hard
>> Fork date).
>>
>> Google Doc (if you're into that kind of thing):
>>
>> https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNocmCq-jjBOQSVH-A/edit?usp=sharing
>>
>> Cheers,
>> Paul
>>
>>
>> _______________________________________________
>> 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
>

From cryptaxe at gmail.com  Tue Jul 11 21:16:52 2017
From: cryptaxe at gmail.com (CryptAxe)
Date: Tue, 11 Jul 2017 14:16:52 -0700
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <CAPg+sBghOOcyRqtuAXhWQ=yA1nuqw8Xs+yrK9CTpRo4uc3773Q@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAGL6+mHQZ3UP10msk65OO+Uk0hn7j+dkmJap_M7FgWfSZaYYJQ@mail.gmail.com>
	<CAPg+sBghOOcyRqtuAXhWQ=yA1nuqw8Xs+yrK9CTpRo4uc3773Q@mail.gmail.com>
Message-ID: <78ce5fe7-f1bb-81c6-585c-c882d2d9b199@gmail.com>

If users can opt-in to another security model, why can't they opt-in to
another scaling model? The mainchain (Bitcoin) does not have to adopt
any of the changes made to a sidechain such as larger blocks for example.


On 07/11/2017 01:01 PM, Pieter Wuille via bitcoin-dev wrote:
> On Jul 11, 2017 09:18, "Chris Stewart via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
>     Concept ACK.
>
>     If drivechains are successful they should be viewed as the way we
>     scale
>
>
> I strongly disagree with that statement.
>
> Drivechains, and several earlier sidechains ideas, are not a
> scalability improvement, but merely enabling users to opt-in for
> another security model.
>
> While obviously any future with wider adoption will need different
> technologies that have different trade-offs, and anyone is free to
> choose their security model, I don't think this particular one is
> interesting. In terms of validation cost to auditors, it is as bad as
> just a capacity increase on chain, while simultaneously adding the
> extra risk of miners being able to vote to steal your money.
>
> Cheers,
>
> -- 
> Pieter
>
>
>
> _______________________________________________
> 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/20170711/1de23cb2/attachment.html>

From greg at xiph.org  Tue Jul 11 21:11:38 2017
From: greg at xiph.org (Gregory Maxwell)
Date: Tue, 11 Jul 2017 21:11:38 +0000
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
Message-ID: <CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>

I think it's great that people want to experiment with things like
drivechains/sidechains and what not, but their security model is very
distinct from Bitcoin's and, given the current highly centralized
mining ecosystem, arguably not very good.  So positioning them as a
major solution for the Bitcoin project is the wrong way to go. Instead
we should support people trying cool stuff, at their own risk.

So, given that although the vast majority of the things in the document
are things I've been supporting for months (Please see Note 1 way down
at the bottom) I cannot support your document.

I think you may have have missed how much work I put into what I published
before talking with people who actually work on the project to find out
what they wouldn't object to before publishing the prior document--
and how much I left out that I would have loved to have in; and why
I specifically held back from describing it as a roadmap or prompting
people to sign onto it (though they did of their own accord).

On a more meta-subject, I think grandly stated "top down" roadmaps
in highly collaborative development are of minimal utility at best and
actively misleading at worst. Fundamentally, it misunderstands the nature
of peer collaboration. It's kind of like asking for a roadmap for the
development of fusion power; individual practitioners have their own
roadmaps, but the collaboration of science does not.

Consider an example,

The Linux kernel is one of the largest and best funded open source
projects, which produces the most widely used operating system kernel
in the world and one of the most widely used pieces of software of all
time, and it produces _no_ roadmaps.

Quoting Andrew Morton, "Instead of a roadmap, there are technical
guidelines. Instead of a central resource allocation, there are
persons and companies who all have a stake in the further development
of the Linux kernel, quite independently from one another: People like
Linus Torvalds and I don?t plan the kernel evolution. We don?t sit
there and think up the roadmap for the next two years, then assign
resources to the various new features. That's because we don?t have
any resources. The resources are all owned by the various corporations
who use and contribute to Linux, as well as by the various independent
contributors out there. It's those people who own the resources who
decide."

Linus remarked, "I look at the current release and the next one, as I
don't think planning 10 years ahead is sane."

Yet the Linux kernel still has every advantage over us:  They have far
more contributing resources from far more sources, they have a fairly
centralized model and control over their own destiny because they have
a much more functional pathway to disagreement than we have in Bitcoin
for consensus rules.

IMO the way to do "roadmaps" in Bitcoin is to roadmap the finalization
and release process once the basic technology is done; because it's
only past that point that guarantees can really start being made.

But that isn't what your document does-- it names a lot of things which
are still various shades of research at this point (much of it research
I'm working on and strongly support, in fact--)

We can also talk in a visionary sense about the sorts of things we're
exploring, but it just isn't possible to nail down when they'll be
ready until they are: If it's not something the linux kernel can do,
it's not something we can do.  These are neat and existing ideas,
but not a roadmap.

At least not as a group. Individually contributing parties have a lot
more visibility and control into their own activities, and there is
virtue in forecasting at that level. Redhat, for example, has
roadmaps. They primarily deal with stabilization and support of
already existing technology that you could get in the raw from the
various upstream sources (fedora, kernel, etc.). (see for an example,
http://www.slideshare.net/albertspijkers/red-hat-enterprise-linux-roadmap
)

Separately, what we can do stably in Core is have timely reliable
releases.  Juniper made it 10 years with regular timed releases that
did not slip by more than IIRC three days and which were _all_ production
deployable (things changed later, but thats another story).

This was an incredible benefit to our customers, but the only way it was
possible was because _features_ were not guaranteed in a release.
If a feature failed during the final testing and it needed more than the
most trivial of fixes, it was _removed_ or disabled.  As soon as there
are multiple in-flight deliverables it becomes more important to be
timely over-all even that that significantly delays single deliverables.
This is effectively at odds with hard deadlines on functionality, even
before getting into the fact that for consensus features delivery in
software is irrelevant until activation which is a public election.
(E.g. we shipped segwit almost a year ago, but it still hasn't arrived
for users).

>From the perspective of Bitcoin I think what people are actually
asking for us to do is to (help) drive the Bitcoin Story-- the actual
technology and its timelines is usually not that relevant: if it were,
they'd be stepping up with resources to contribute to it. There are
many ways to do that, -- we don't have to use highly authoritarian
methods that wouldn't even work for the Linux kernel.

[And all these projects you listed, your help would be more than welcome!]

This can be done by a mixture of talking about research _as research_
not a done deal, and by moving discussions of non-research things to
where they're actually more forecastable.  98% of the public
discussion about segwit was before the pull request, -- there were
solid political reasons for this-- but it was the wrong timing.  On
the case of CSV and CLTV, the general public didn't hear about them
until they were merged -- pretty much-- and the timing then was much
more compatible with 'roadmapping' +/- activation uncertainty.

Some of this is driven by competitive pressure with things like
Ethereum or other altcoins (e.g. dash, god save us) that have a lot
lower commitment to engineering integrity or even logical consistency.
We can't compete with technobabble bullshit, and we shouldn't try and
as a side effect back ourselves into a corner where we're making
remarkable accomplishments but regarded as failures in payment
(because we either forecast it taking N years, which is the best we
could promise, or because we forecast the best we might achieve and it
was both still too long and the timeframe got missed).

One of the big screwups with segwit handling was people sticking
some random unrealistic date on it it which was done AFAIK,
by well meaning folks who took some random numbers from people
working on it for when they'd be done with the development-- not the
testing, not the integration, and certainly not deployment and published
it as The Date.  Then even though the development was actually done
by them, segwit was portrayed as massively delayed, because what
matters to the users is deployment-- which we can't control.

I see you've done this yourself with signature aggregation, sticking Q4 2016
right on it, which as far as I can tell is a figure that comes from mars.
(Well not quite mars, see Note 1)
Probably we'll have the research and an implementation done by then, but
with so much uncertainty around segwit activation, I doubt anyone can be
about when users will be able to use it (which is what they care about!)

It's also not really appropriate to ask people to sign onto stuff when they
can't even review it.  Perhaps the signature aggregation stuff is insecure,
patent encumbered, or practically useless... (It won't be but no one could
tell that from your post; because it doesn't even exist as a concrete proposal)

I think people would rightly protest about a number of these things-- especially
things like the the agg sigs and tx compaction, "wtf, I've not heard
of this. Who
are you to insist this goes into Bitcoin?"

In any case; I can repeat the same story for major RFCs, FWIW.  Collaborative
innovation is _very_ hard to stick to a tight schedule.  And road-maps
of totally prospective technology that no one has the actual authority to make
happen aren't a productive thing for the industry.

In a few weeks you'll start seeing articles on the major new things
coming in Bitcoin Core 0.15,
-- now that we can do, because the work is done, and the outcome is
very predictable. There are some awesome improvements around it-- ones
we can rally around; and know will be delivered for sure.


[  Note 1: I think it is important to disclose that several of the
items in this list appear to be more or less quoted out of my own
blockstream-internal descriptions of things we've been working on in
Bitcoin.

A while back Adam Back asked me to publish something which contained
significant chunks of this document more or less verbatim, and I
declined saying that I personally disagree with some of his points and
didn't think that Blockstream attempting to redirect the Bitcoin
project (esp towards drivechains) was appropriate-- along with my
(above) views on roadmaps (which I have included here a private email
thread on the subject). I feel it's important to disclose this, and
that the document was not otherwise created with the input of project
contributors (except Luke-Jr, apparently). I wasn't previously aware
that Adam had been working with Paul on this, had I been I would have
also encouraged people to be a little more transparent about it. ]

From greg at xiph.org  Tue Jul 11 21:31:29 2017
From: greg at xiph.org (Gregory Maxwell)
Date: Tue, 11 Jul 2017 21:31:29 +0000
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <f79b9693-b8a5-c496-9dd9-d74704855d0e@gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAGL6+mHQZ3UP10msk65OO+Uk0hn7j+dkmJap_M7FgWfSZaYYJQ@mail.gmail.com>
	<f79b9693-b8a5-c496-9dd9-d74704855d0e@gmail.com>
Message-ID: <CAAS2fgSEZDmgGBxB-ZNqC0NpWQCJSL9xnbaNQFud=sW0Fdgu8w@mail.gmail.com>

On Tue, Jul 11, 2017 at 8:18 PM, Paul Sztorc via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I wrote the roadmap to try to be representative of a Core / developer
> position.

A fine intention, but I've checked with many of the top contributors
and it sounds like the only regular developer you spoke with was
Luke-Jr.  Next time you seek to represent someone you might want to
try talking to them!

> I am philosophically against hard forks, but HFs were in the end
> of the previous roadmap so I felt it should stay. And, I felt that if I

I think the project is not philosophically against hardforks, at least
not in an absolute sense.

Part of the reason they were discussed in the capacity document was to
make it clear that I wasn't, and to invite other project members to
expose disagreement (though I'd mostly checked in advance...)

But these recently proposed ultra-hasty highly contentious changes,
that seem to be being suggested on shorter and shorter timeframes; I
do think the project is actually opposed to those in a very strong
sense.

But if you were instead to talk about things like fixing timewarp,
recovering header bits, etc. It would clearly be the other way.

At least at the moment computers and bandwidth are improving; I don't
think any regular developers are opposed to hardforks that change
capacity well tech improvements and protocol improvements have made it
obviously not much of a trade-off.

Personally, I wish the project had previously adopted a license that
requires derived works to not accept any block the derived-from work
wouldn't accept for at least two years, or otherwise the derivative
has to be clearly labeled not-bitcoin. :P

In any case, I think it's safe to say that people's opinions on
hardforks are complicated. And all the smoke right now with unusually
poorly executed proposals probably clouds clear thinking.

From greg at xiph.org  Tue Jul 11 21:40:28 2017
From: greg at xiph.org (Gregory Maxwell)
Date: Tue, 11 Jul 2017 21:40:28 +0000
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
Message-ID: <CAAS2fgTpBKnwHYt+GRJQ2ixjNCD1jYY6YVJ6OsSVeb71aYybQQ@mail.gmail.com>

On Tue, Jul 11, 2017 at 9:11 PM, Gregory Maxwell <greg at xiph.org> wrote:
> which I have included here a private email
> thread on the subject

To make it clear, since I munged the English on this: Most of my post
is just copied straight out of a private thread where I explained my
perspective on 'roadmaps' as they apply to projects like Bitcoin.

From pieter.wuille at gmail.com  Tue Jul 11 21:40:36 2017
From: pieter.wuille at gmail.com (Pieter Wuille)
Date: Tue, 11 Jul 2017 14:40:36 -0700
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <d53dc5d2-b761-53c3-3bb8-0d8d39cbda37@gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAGL6+mHQZ3UP10msk65OO+Uk0hn7j+dkmJap_M7FgWfSZaYYJQ@mail.gmail.com>
	<CAPg+sBghOOcyRqtuAXhWQ=yA1nuqw8Xs+yrK9CTpRo4uc3773Q@mail.gmail.com>
	<d53dc5d2-b761-53c3-3bb8-0d8d39cbda37@gmail.com>
Message-ID: <CAPg+sBjhKON4Mmg06pgpBgfp5xWT2b7xgoWwybsWbbuF9CNt_g@mail.gmail.com>

On Tue, Jul 11, 2017 at 1:36 PM, Paul Sztorc <truthcoin at gmail.com> wrote:
> Pieter,
>
> I think that you have misrepresented Chris' view by taking it out of
> context. His complete quote reads "If drivechains are successful they should
> be viewed as the way we scale -- not hard forking the protocol." Chris is
> comparing Drivechains/sidechains to a hard fork.

I apologize here; I didn't mean to misrepresent his viewpoint.

> You went on to "disagree", but every point of contention you introduced was
> something that would apply to both drivechain-sourced capacity and
> hardfork-sourced capacity. Neither improves scalability, and both allow
> users only the opportunity to select a different security model. If I
> understand you, the point at which a security model does not become
> "interesting" to you, would be the exact same point in the drivechain and
> hardfork worlds. Both, at any rate, have the same effect on "validation cost
> to auditors".

If you're talking about the extreme case where every full node in the
increased capacity single chain model corresponds to a node that
validates both chains and all transfers between them in the
drivechains, I agree. At that point they become nearly equivalent in
terms of ease of adoption, resource costs, and capacity.

However, I don't think that is a realistic expectation. When
considering drivechains as a capacity increase, I believe most people
think about a situation where there are many chains that give an
increased capacity combined, but not everyone verifies all of them.
This is what I meant with uninteresting security model, as it requires
increased miner trust for preventing the other chains' coins from
being illegally transferred to the chain you're operating on.

Regardless, people are free experiment and adopt such an approach. The
nice thing about it not being a hardfork is that it does not require
network-wide consensus to deploy. However, I don't think they offer a
security model that should be encouraged, and thus doesn't have a
place on a roadmap.

> Since their sidechain coins cannot appreciate in value relative
> to the mainchain coins, users would only opt-in if they felt that they were
> sufficiently compensated for any and all risks. Hence, it is difficult to
> list this item as a drawback when, to the user, it is a strict improvement
> (at least, by any epistemological standard that I can think of). If you have
> new objections to these claims, I'm sure we would all benefit from hearing
> them, myself most of all.

Am I right in summarizing your point here as "This approach cannot
hurt, because if it were insecure, people can choose to not use it."?
I'm not sure I agree with that, as network effects or misinformation
may push users beyond what is reasonable.

Cheers,

-- 
Pieter

From steven.charles.davis at gmail.com  Tue Jul 11 22:26:38 2017
From: steven.charles.davis at gmail.com (Steve Davis)
Date: Tue, 11 Jul 2017 17:26:38 -0500
Subject: [bitcoin-dev] Updating the Scaling Roadmap
Message-ID: <8BFBAD12-1ECC-4333-80CA-E62FC1FBF96B@gmail.com>

> I think it's great that people want to experiment with things like
> drivechains/sidechains and what not, but their security model is very
> distinct from Bitcoin?s

Agree that experimentation is great and that it is usually the case that the security model differs.

Isn?t it also true also that the security model for SegWit is distinct from that defined for the Bitcoin token?

It does not appear to be a "chain of digital signatures" as per the original definition? I do understand that the hash state is still respected at block level. I?m referring more to the token?s chain.

Any clarification appreciated.

Thanks,

/sd

From truthcoin at gmail.com  Tue Jul 11 22:17:19 2017
From: truthcoin at gmail.com (Paul Sztorc)
Date: Tue, 11 Jul 2017 18:17:19 -0400
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
Message-ID: <1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>

Hi Greg,


On 7/11/2017 5:11 PM, Gregory Maxwell wrote:
> I think it's great that people want to experiment with things like
> drivechains/sidechains and what not, but their security model is very
> distinct from Bitcoin's and, given the current highly centralized
> mining ecosystem, arguably not very good.  So positioning them as a
> major solution for the Bitcoin project is the wrong way to go. Instead
> we should support people trying cool stuff, at their own risk.
>
> So, given that although the vast majority of the things in the document
> are things I've been supporting for months (Please see Note 1 way down
> at the bottom) I cannot support your document.
Is this the only reason you do not support the document? If so I would
be happy to take out the section, if enough people share such a view.

As to your specific complaints, I have addressed both the security model
and the concept of mining centralization on this list in the recent
past. I would like to hear your responses to my claims, if you are
willing to share them. As for positioning DC as a major solution, it is
a little confusing because Luke-Jr and Adam back seem to feel it is at
least worth discussing on those terms (and I know of no reason why it
would not be discussed on those terms). The peer review here on
[bitcoin-dev] seemed to be moving forward without any serious
objections. And it seems unsportsmanlike for you to object, for reasons
which you keep only to yourself.


> On a more meta-subject, I think grandly stated "top down" roadmaps
> in highly collaborative development are of minimal utility at best 
I'm aiming for minimal utility.

> IMO the way to do "roadmaps" in Bitcoin is to roadmap the finalization
> and release process once the basic technology is done; because it's
> only past that point that guarantees can really start being made.
>
> But that isn't what your document does-- it names a lot of things which
> are still various shades of research at this point
I don't understand this at all. This document attempts to do exactly
what its predecessor did -- nothing more or less.

> This was an incredible benefit to our customers, but the only way it was
> possible was because _features_ were not guaranteed in a release.
No one is suggesting that features be guaranteed, either ever or in
releases.


> One of the big screwups with segwit handling was people sticking
> some random unrealistic date on it it which was done AFAIK,
> by well meaning folks who took some random numbers from people
> working on it for when they'd be done with the development-- not the
> testing, not the integration, and certainly not deployment and published
> it as The Date.  Then even though the development was actually done
> by them, segwit was portrayed as massively delayed, because what
> matters to the users is deployment-- which we can't control.
I really don't think they are related. For a start, software is almost
always delayed. An obvious second is that this entire scaling
conversation is polarized to the hilt and everyone that can be blamed
for something has been blamed for something.

No one likes to be held to a certain deadline, but this roadmap is just
about producing some clarity for people who do not do this 24/7.

> I see you've done this yourself with signature aggregation, sticking Q4 2016
> right on it, which as far as I can tell is a figure that comes from mars.
I asked Adam Back for it.

> It's also not really appropriate to ask people to sign onto stuff when they
> can't even review it.  Perhaps the signature aggregation stuff is insecure,
> patent encumbered, or practically useless... (It won't be but no one could
> tell that from your post; because it doesn't even exist as a concrete proposal)
Again, I think you're missing the point. If there is a problem with SA,
you can just suggest it be removed from the document.


> I think people would rightly protest about a number of these things-- especially
> things like the the agg sigs and tx compaction, "wtf, I've not heard
> of this. Who
> are you to insist this goes into Bitcoin?"
This is a very strange argument. I would consider it a benefit if people
learned from the document, and discovered things that they had not heard
of before.

There is no "insisting" of any kind.


> [  Note 1: I think it is important to disclose that several of the
> items in this list appear to be more or less quoted out of my own
> blockstream-internal descriptions of things we've been working on in
> Bitcoin.
> A while back Adam Back asked me to publish something which contained
> significant chunks of this document more or less verbatim, 
He probably showed you an earlier draft. But I wrote almost all of this
myself, and I can only recall 2 or 3 phrases (not even complete
sentences) included from Adam Back. And most of the phrases are
themselves just boring descriptions that I'm sure anyone could write.
Some phrases may have simply been taken from bitcoincore.org or
somewhere similar.

I am not exactly sure what you are insinuating but I encourage you to
clarify it.

> and I
> declined saying that I personally disagree with some of his points and
> didn't think that Blockstream attempting to redirect the Bitcoin
> project (esp towards drivechains) was appropriate-- along with my
> (above) views on roadmaps (which I have included here a private email
> thread on the subject). I feel it's important to disclose this, and
> that the document was not otherwise created with the input of project
> contributors (except Luke-Jr, apparently). I wasn't previously aware
> that Adam had been working with Paul on this, had I been I would have
> also encouraged people to be a little more transparent about it. ]
I really don't understand what you are disclosing. That Adam asked you
for feedback on the draft? And then, in the next sentence, that not
enough experts were asked for feedback on the draft? I'm legitimately
confused by this part.

As I stated, we can remove the drivechain section. But surely you can
appreciate how bizarre your position on roadmaps is. What exactly, did
you intended to create at [1]? Since it is described explicitly as "the
roadmap in Capacity increases for the Bitcoin system", have you been
disagreeing with it's characterization as a 'roadmap' this entire time?
One wonders why you haven't said anything until now.

[1] https://bitcoincore.org/en/2015/12/21/capacity-increase/

In my first email I list the benefits of having a roadmap. One benefit
is that, without one, it is likely that a large majority of outsiders
have almost no idea at all what is being worked on, what effect it will
have, or when it might be ready, or to whom/what they should turn to for
advice on such matters. Do you have a different way of addressing this
communication problem?

Paul


From contact at taoeffect.com  Tue Jul 11 22:41:18 2017
From: contact at taoeffect.com (Tao Effect)
Date: Tue, 11 Jul 2017 15:41:18 -0700
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
Message-ID: <A030CDEA-CB0F-40BF-9404-6BD091537BE1@taoeffect.com>

Dear Paul,

Drivechain has several issues that you've acknowledged but have not, IMO, adequately (at all really) addressed [1].

I think there are far safer solutions for scaling Bitcoin and integrating it with other chains than DC, which is again, a serious security risk to the whole network, as per [1].

Adopting DC would be an irreversible course of action, and one that in my opinion would unnecessarily damage not only other sidechains, but the main chain as well.

There is no rush, a proper solution is likely to present itself (I even have one that I'm toying with, but it's not quite ready yet for publication). I'm sure others are thinking similar thoughts too.

Kind regards,
Greg Slepak

[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.html>

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

> On Jul 11, 2017, at 3:17 PM, Paul Sztorc via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> 
> Hi Greg,
> 
> 
> On 7/11/2017 5:11 PM, Gregory Maxwell wrote:
>> I think it's great that people want to experiment with things like
>> drivechains/sidechains and what not, but their security model is very
>> distinct from Bitcoin's and, given the current highly centralized
>> mining ecosystem, arguably not very good.  So positioning them as a
>> major solution for the Bitcoin project is the wrong way to go. Instead
>> we should support people trying cool stuff, at their own risk.
>> 
>> So, given that although the vast majority of the things in the document
>> are things I've been supporting for months (Please see Note 1 way down
>> at the bottom) I cannot support your document.
> Is this the only reason you do not support the document? If so I would
> be happy to take out the section, if enough people share such a view.
> 
> As to your specific complaints, I have addressed both the security model
> and the concept of mining centralization on this list in the recent
> past. I would like to hear your responses to my claims, if you are
> willing to share them. As for positioning DC as a major solution, it is
> a little confusing because Luke-Jr and Adam back seem to feel it is at
> least worth discussing on those terms (and I know of no reason why it
> would not be discussed on those terms). The peer review here on
> [bitcoin-dev] seemed to be moving forward without any serious
> objections. And it seems unsportsmanlike for you to object, for reasons
> which you keep only to yourself.
> 
> 
>> On a more meta-subject, I think grandly stated "top down" roadmaps
>> in highly collaborative development are of minimal utility at best
> I'm aiming for minimal utility.
> 
>> IMO the way to do "roadmaps" in Bitcoin is to roadmap the finalization
>> and release process once the basic technology is done; because it's
>> only past that point that guarantees can really start being made.
>> 
>> But that isn't what your document does-- it names a lot of things which
>> are still various shades of research at this point
> I don't understand this at all. This document attempts to do exactly
> what its predecessor did -- nothing more or less.
> 
>> This was an incredible benefit to our customers, but the only way it was
>> possible was because _features_ were not guaranteed in a release.
> No one is suggesting that features be guaranteed, either ever or in
> releases.
> 
> 
>> One of the big screwups with segwit handling was people sticking
>> some random unrealistic date on it it which was done AFAIK,
>> by well meaning folks who took some random numbers from people
>> working on it for when they'd be done with the development-- not the
>> testing, not the integration, and certainly not deployment and published
>> it as The Date.  Then even though the development was actually done
>> by them, segwit was portrayed as massively delayed, because what
>> matters to the users is deployment-- which we can't control.
> I really don't think they are related. For a start, software is almost
> always delayed. An obvious second is that this entire scaling
> conversation is polarized to the hilt and everyone that can be blamed
> for something has been blamed for something.
> 
> No one likes to be held to a certain deadline, but this roadmap is just
> about producing some clarity for people who do not do this 24/7.
> 
>> I see you've done this yourself with signature aggregation, sticking Q4 2016
>> right on it, which as far as I can tell is a figure that comes from mars.
> I asked Adam Back for it.
> 
>> It's also not really appropriate to ask people to sign onto stuff when they
>> can't even review it.  Perhaps the signature aggregation stuff is insecure,
>> patent encumbered, or practically useless... (It won't be but no one could
>> tell that from your post; because it doesn't even exist as a concrete proposal)
> Again, I think you're missing the point. If there is a problem with SA,
> you can just suggest it be removed from the document.
> 
> 
>> I think people would rightly protest about a number of these things-- especially
>> things like the the agg sigs and tx compaction, "wtf, I've not heard
>> of this. Who
>> are you to insist this goes into Bitcoin?"
> This is a very strange argument. I would consider it a benefit if people
> learned from the document, and discovered things that they had not heard
> of before.
> 
> There is no "insisting" of any kind.
> 
> 
>> [  Note 1: I think it is important to disclose that several of the
>> items in this list appear to be more or less quoted out of my own
>> blockstream-internal descriptions of things we've been working on in
>> Bitcoin.
>> A while back Adam Back asked me to publish something which contained
>> significant chunks of this document more or less verbatim,
> He probably showed you an earlier draft. But I wrote almost all of this
> myself, and I can only recall 2 or 3 phrases (not even complete
> sentences) included from Adam Back. And most of the phrases are
> themselves just boring descriptions that I'm sure anyone could write.
> Some phrases may have simply been taken from bitcoincore.org <http://bitcoincore.org/> or
> somewhere similar.
> 
> I am not exactly sure what you are insinuating but I encourage you to
> clarify it.
> 
>> and I
>> declined saying that I personally disagree with some of his points and
>> didn't think that Blockstream attempting to redirect the Bitcoin
>> project (esp towards drivechains) was appropriate-- along with my
>> (above) views on roadmaps (which I have included here a private email
>> thread on the subject). I feel it's important to disclose this, and
>> that the document was not otherwise created with the input of project
>> contributors (except Luke-Jr, apparently). I wasn't previously aware
>> that Adam had been working with Paul on this, had I been I would have
>> also encouraged people to be a little more transparent about it. ]
> I really don't understand what you are disclosing. That Adam asked you
> for feedback on the draft? And then, in the next sentence, that not
> enough experts were asked for feedback on the draft? I'm legitimately
> confused by this part.
> 
> As I stated, we can remove the drivechain section. But surely you can
> appreciate how bizarre your position on roadmaps is. What exactly, did
> you intended to create at [1]? Since it is described explicitly as "the
> roadmap in Capacity increases for the Bitcoin system", have you been
> disagreeing with it's characterization as a 'roadmap' this entire time?
> One wonders why you haven't said anything until now.
> 
> [1] https://bitcoincore.org/en/2015/12/21/capacity-increase/ <https://bitcoincore.org/en/2015/12/21/capacity-increase/>
> 
> In my first email I list the benefits of having a roadmap. One benefit
> is that, without one, it is likely that a large majority of outsiders
> have almost no idea at all what is being worked on, what effect it will
> have, or when it might be ready, or to whom/what they should turn to for
> advice on such matters. Do you have a different way of addressing this
> communication problem?
> 
> Paul
> 
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/386bfc83/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/386bfc83/attachment-0001.sig>

From truthcoin at gmail.com  Tue Jul 11 22:49:19 2017
From: truthcoin at gmail.com (Paul Sztorc)
Date: Tue, 11 Jul 2017 18:49:19 -0400
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <CAPg+sBjhKON4Mmg06pgpBgfp5xWT2b7xgoWwybsWbbuF9CNt_g@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAGL6+mHQZ3UP10msk65OO+Uk0hn7j+dkmJap_M7FgWfSZaYYJQ@mail.gmail.com>
	<CAPg+sBghOOcyRqtuAXhWQ=yA1nuqw8Xs+yrK9CTpRo4uc3773Q@mail.gmail.com>
	<d53dc5d2-b761-53c3-3bb8-0d8d39cbda37@gmail.com>
	<CAPg+sBjhKON4Mmg06pgpBgfp5xWT2b7xgoWwybsWbbuF9CNt_g@mail.gmail.com>
Message-ID: <93a5f7e8-08ee-06a8-f638-b4e85814d598@gmail.com>

On 7/11/2017 5:40 PM, Pieter Wuille wrote:
> On Tue, Jul 11, 2017 at 1:36 PM, Paul Sztorc <truthcoin at gmail.com> wrote:
>> Pieter,
>>
>> I think that you have misrepresented Chris' view by taking it out of
>> context. His complete quote reads "If drivechains are successful they should
>> be viewed as the way we scale -- not hard forking the protocol." Chris is
>> comparing Drivechains/sidechains to a hard fork.
> I apologize here; I didn't mean to misrepresent his viewpoint.
I'm sure you did not intend to do so, of course.

>> You went on to "disagree", but every point of contention you introduced was
>> something that would apply to both drivechain-sourced capacity and
>> hardfork-sourced capacity. Neither improves scalability, and both allow
>> users only the opportunity to select a different security model. If I
>> understand you, the point at which a security model does not become
>> "interesting" to you, would be the exact same point in the drivechain and
>> hardfork worlds. Both, at any rate, have the same effect on "validation cost
>> to auditors".
> If you're talking about the extreme case where every full node in the
> increased capacity single chain model corresponds to a node that
> validates both chains and all transfers between them in the
> drivechains, I agree. At that point they become nearly equivalent in
> terms of ease of adoption, resource costs, and capacity.
>
> However, I don't think that is a realistic expectation. When
> considering drivechains as a capacity increase, I believe most people
> think about a situation where there are many chains that give an
> increased capacity combined, but not everyone verifies all of them.
> This is what I meant with uninteresting security model, as it requires
> increased miner trust for preventing the other chains' coins from
> being illegally transferred to the chain you're operating on.
I think I understand what you are saying, but in this case "it" [your
experience] isn't a different security model *for you*. Perhaps we
disagree on the significance of this qualification.

It seems to be me that your position puts you in danger of having to go
out and protect users from investing in insecure _Altcoins_. Probably,
in a world where altcoins were magically impossible, there would be an
even greater demand for Bitcoin capacity than there is in our
Altcoin-filled world (for a few reasons).

> Regardless, people are free experiment and adopt such an approach. The
> nice thing about it not being a hardfork is that it does not require
> network-wide consensus to deploy. However, I don't think they offer a
> security model that should be encouraged, and thus doesn't have a
> place on a roadmap.
I think this is reasonable. It is true that, if no one used drivechains
ever for anything, there would be no transactions offloaded to those
chain, and then no capacity freed up on the original mainchain.

However, though I think your logic is correct in general, I think in
this specific instance it would be somewhat unreasonable to ignore the
fact that, today, we have clear evidence that many people *are* in fact
chomping at the bit to literally leave this blockchain for one that is
almost identical save for a larger maxblocksize.


>> Since their sidechain coins cannot appreciate in value relative
>> to the mainchain coins, users would only opt-in if they felt that they were
>> sufficiently compensated for any and all risks. Hence, it is difficult to
>> list this item as a drawback when, to the user, it is a strict improvement
>> (at least, by any epistemological standard that I can think of). If you have
>> new objections to these claims, I'm sure we would all benefit from hearing
>> them, myself most of all.
> Am I right in summarizing your point here as "This approach cannot
> hurt, because if it were insecure, people can choose to not use it."?
> I'm not sure I agree with that, as network effects or misinformation
> may push users beyond what is reasonable.
Again, I think you may be right. However, users may be similarly misled
in the case of Altcoins (or in the case of investments in fiat
currency), and they may be misled in their use of all kinds of
cryptographic software, and in the clothes that they buy and all of
their other activities.

I would strongly support clear expectations, and constant reminders to
users that the security models are different. Perhaps, even, annoying
dialogue boxes that pop up when/if a user tries to move their funds to a
sidechain.

But, again, this (I think) is something that would *also* apply to a
hard fork. We cannot know if Pieter Wuille, for example, believes that a
given hard fork is "push[ing] users beyond what is reasonable" until we
ask him.

--Paul



From truthcoin at gmail.com  Tue Jul 11 22:57:12 2017
From: truthcoin at gmail.com (Paul Sztorc)
Date: Tue, 11 Jul 2017 18:57:12 -0400
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <A030CDEA-CB0F-40BF-9404-6BD091537BE1@taoeffect.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<A030CDEA-CB0F-40BF-9404-6BD091537BE1@taoeffect.com>
Message-ID: <08078429-089f-9315-2f76-a08121c5378c@gmail.com>

On 7/11/2017 6:41 PM, Tao Effect wrote:
> Dear Paul,
>
> Drivechain has several issues that you've acknowledged but have not,
> IMO, adequately (at all really) addressed [1].

I replied to your email at length, at [2]. You should read that email,
and then reply to it with your outstanding objections, if you still have
them (per the usual customs of a mailing list).

[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014609.html

> Adopting DC would be an irreversible course of action,

This is false -- it is easily reversible with a second soft fork.

Also, I would say to everyone that, (in my opinion as the OP) this
conversation will go off-topic if it veers exclusively into 'drivechain
review'.

Paul




From kanzure at gmail.com  Tue Jul 11 23:36:12 2017
From: kanzure at gmail.com (Bryan Bishop)
Date: Tue, 11 Jul 2017 18:36:12 -0500
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
Message-ID: <CABaSBax_yfA8Zb_sFhHh9Ap-qzMryA38i360LrrC7bt8viuvRA@mail.gmail.com>

I can't help but notice that I have read Greg's email before-- all the
way back in 2016. It would have been impossible for him to write a
reply to Paul's current email back then... but I also notice that Greg
did not indicate that he was copy-pasting until the very end (and even
then his aside at the end was sort of not the most clear it could have
been I think).

On Tue, Jul 11, 2017 at 5:17 PM, Paul Sztorc via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 7/11/2017 5:11 PM, Gregory Maxwell wrote:
>> [  Note 1: I think it is important to disclose that several of the
>> items in this list appear to be more or less quoted out of my own
>> blockstream-internal descriptions of things we've been working on in
>> Bitcoin.
>> A while back Adam Back asked me to publish something which contained
>> significant chunks of this document more or less verbatim,
[ snip ]
> I am not exactly sure what you are insinuating but I encourage you to
> clarify it.

I believe that's an artifact of a 2016 email. And the rest of it, for
that matter. See below.

>> and I
>> declined saying that I personally disagree with some of his points and
>> didn't think that Blockstream attempting to redirect the Bitcoin
>> project (esp towards drivechains) was appropriate-- along with my
>> (above) views on roadmaps (which I have included here a private email
>> thread on the subject). I feel it's important to disclose this, and
>> that the document was not otherwise created with the input of project
>> contributors (except Luke-Jr, apparently). I wasn't previously aware
>> that Adam had been working with Paul on this, had I been I would have
>> also encouraged people to be a little more transparent about it. ]
> I really don't understand what you are disclosing. That Adam asked you
> for feedback on the draft? And then, in the next sentence, that not
> enough experts were asked for feedback on the draft? I'm legitimately
> confused by this part.
>
> As I stated, we can remove the drivechain section. But surely you can
> appreciate how bizarre your position on roadmaps is. What exactly, did
> you intended to create at [1]? Since it is described explicitly as "the
> roadmap in Capacity increases for the Bitcoin system", have you been
> disagreeing with it's characterization as a 'roadmap' this entire time?
> One wonders why you haven't said anything until now.
>
> [1] https://bitcoincore.org/en/2015/12/21/capacity-increase/

The vast majority of Greg's email, including all the positiontext on
roadmaps was mostly text sent on 2016-11-04 to Adam Back, myself,
Wladimir, and others. Some of the other parts aren't, like the part
mentioning Blockstream.

Here is a commitment to a list of the recipients (for whatever good
such a commitment might do):
b1e575e15d86a5a5931ea0bc519701df4cc152f020f03cd7912074ce5c36260a

- Bryan
http://heybryan.org/
1 512 203 0507

From aj at erisian.com.au  Tue Jul 11 23:28:39 2017
From: aj at erisian.com.au (Anthony Towns)
Date: Wed, 12 Jul 2017 09:28:39 +1000
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
Message-ID: <20170711232839.GA5424@erisian.com.au>

On Mon, Jul 10, 2017 at 12:50:21PM -0400, Paul Sztorc via bitcoin-dev wrote:
> We should revise [the roadmap]: remove what has been accomplished, 
> introduce new innovations and approaches, and update deadlines 
> and projections.

Timelines have good and bad points (in this context, I'd generally call
projections good, deadlines bad :); people have interpreted the lack of
any clear timeline for a hardmark on the 2015 roadmap as no plan for a
hard fork at all; meanwhile the overly optimistic timeline for segwit
being "ready" in April or July last year has been interpreted as "ready
for use" and treated as a failure, when it didn't work out that way.

I think it would be helpful for the development community to have some
way of talking about timelines, for instance to be able to say "the
*minimum* timeline for a reasonable hard fork is 6 months for proposal
review, speculative analysis and initial coding, 3 months for concrete
proposal review and thorough testing, 3-6 months for consensus to develop
on whether to lock the proposed changes in as the new consensus, and
a further 6-24 months for wide scale deployment to occur before any
behavioural change to take actual effect".

Those numbers give a lead time of 18 to 38 months of engagement with the
developer community before it takes effect, as compared to the six month
timeline of the New York agreement. 18 months implies that a block size
increase would be *available* today if people wanting larger blocks had
engaged with the development community from January 2016 in the same
way that segwit was developed, rather than working in their own sandboxes.

That could have happened: the proposals in 

  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011995.html

from Dec 2015 could have been engaged with, and, optimistically, we could
have a non-controversial deployment of SpoonNet already if they had been.

It might be a good idea to actually engage with investors and businesses
on this: the point of the timelines above isn't to slow things down for
its own sake, it's that you need to take time in order to think through
the potential consequences of changes, and avoid unintended bad outcomes.
That seems like something that investors and businesses can understand,
and endorse up front -- and they could meaningfully do so simply by saying
"any hard-fork that does not go through each of the stages for at least
the minimum time will be treated as an altcoin rather than an upgrade
of bitcoin". But the process has to be "here is what it takes from a
technical POV to avoid fucking up bitcoin; does your company endorse
being responsible with other people's money despite the costs of doing
so?" If you're in a move-fast-and-break-things mode, the answer might
legitimately be "no", of course.

>  ==== Beginning of New ("July 2017") Roadmap Draft ====

I'd suggest dividing the activities into phases more clearly; maybe:

 - Already available to users:
     * version bits
     * compact block relay
     * FIBRE
     * CSV
     * better fee estimation

 - Awaiting consensus:
     * segregated witness

 - Active development / concrete specifications:
     * lightning network
     * light client mode for bitcoin core (PR#10794)

 - Draft proposals at experimental stage:
     * transaction compression? (or is this the already deployed stuff?)
     * schnorr sig aggregation
     * drivechain
     * spoonnet
     * mimblewimble
     * block size increases

 - Ideas that aren't even experiments yet
     * asicboost prevention

> There is
> currently no consensus on a hard fork date, but there is a rough
> consensus that one would require at least 6 months to coordinate
> effectively, which would place it in the year 2018 at earliest.

As above, it seems to me that 18 months of engagement is likely a bare
minimum amount of time for a robustly implemented hard fork (6 months is
almost exactly segwit2x's total timeline, from proposal in late May as
the New York Agreement to the new rules being available in mid-November,
and it doesn't look at all robust to me).  

Possibly if the existing features of spoonnet are already adequate,
you could cut that down by a few months. But realistically, that says
to me early 2019 at the absolute earliest, and if engagement with the
development process doesn't start tomorrow, later than that.

FWIW, here's a longer form draft of what I think hard fork guidelines
maybe could look like:

  https://gist.github.com/ajtowns/914cf2309822bff357cda4ab3f48a966

It's obviously blatantly contradictory with support of the NYA/segwit2x,
but at this point I think that's true of any process that's not just
a rephrasing of "move fast and break things".

> Google Doc (if you're into that kind of thing):
> https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNocmCq-jjBOQSVH-A/edit?usp=sharing

Publishing something like this as an informational BIP every year or
two seems like a good idea to me.

Instead of a "roadmap" (with the implication that there's a schedule
people might rely on and developers have to meet), maybe just have it as
a list of the current high impact scaling features being worked on --
where the purpose of publishing the list is to let people understand
how far various ideas have progressed currently, and focus attention on:

  - wider adoption of already deployed features, by users, exchanges,
    wallets, etc; eg segwit doesn't scale anything if no one uses it
  - achieving activation of implemented features
  - encouraging R&D on approaches that are currently still experimental
    in order to make them actually usable

In that case, there's no actual need for guessing at future dates;
just the current status is sufficient.

Documenting current roadblocks might also be valuable (eg, lightning and
signature aggregation and drivechains etc are kind-of stalled waiting
on segwit's activation, I think; for a brief point, segwit was stalled
waiting on compact blocks, etc). Might not be worthwhile updating the doc
regularly to keep track of what's a roadblock though.

(I think you could usefully generalise beyond scaling to just "high
impact features" really)

Cheers,
aj


From greg at xiph.org  Wed Jul 12 00:07:51 2017
From: greg at xiph.org (Gregory Maxwell)
Date: Wed, 12 Jul 2017 00:07:51 +0000
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
Message-ID: <CAAS2fgTsjfMGw6D_OxDthSrrdLEFx2skGedLAjTwz3yCQijyug@mail.gmail.com>

On Tue, Jul 11, 2017 at 10:17 PM, Paul Sztorc <truthcoin at gmail.com> wrote:
> I don't understand this at all. This document attempts to do exactly
> what its predecessor did -- nothing more or less.

That might be your impression, then you've misunderstood what I
intended-- What I wrote was carefully constructed as a personal view
of how things might work out. It never claimed to be a a project
roadmap. Though as usual, I work hard to propose things that I believe
will be successful... and people are free to adopt what they want.

And to the extent that it got taken that way I think it was an error
and that it has harmed progress in our community; and created more
confusion about control vs collaboration.

With perfect hindsight I wouldn't have posted it; especially since
we've learned that the demand for increased capacity from many people
was potentially less than completely earnest. (The whole, can't double
capacity until we quadruple it thing...)

> As to your specific complaints, I have addressed both the security model
and the concept of mining centralization on this list in the recent
past.

I don't agree that you have; but for the purpose of this thread
doesn't really matter if I (specifically) do or don't agree.  It's an
objective truth that many people do not yet believe these concerns
have been addressed.

> I really don't understand what you are disclosing. That Adam asked you
> for feedback on the draft? And then, in the next sentence, that not

That Adam asked me to write publish a new "roadmap" for Bitcoin as
you've done here, with particular features and descriptions, which I
declined; and explained why I didn't believe that was the right
approach.  And Adam worked with you on the document, and provided
content for it (which I then recognized in the post).

Set aside what you know to be true for a moment and consider how this
might look to an outsider who found out about it.  It could look a
like Blockstream was trying to influence the direction of Bitcoin by
laundering proposals through an apparently unaffiliated third party.
Doubly so considering who participated in your drafting and who didn't
(more below).

I don't think in actuality you did anything remotely improper
(ill-advised, perhaps, since your goal to speak for developers but you
didn't speak to them, IMO--) but I think transparency is essential to
avoid any appearance of misconduct.

> But surely you can
> appreciate how bizarre your position on roadmaps is. What exactly, did
> you intended to create at [1]? Since it is described explicitly as "the
> roadmap in Capacity increases for the Bitcoin system", have you been
> disagreeing with it's characterization as a 'roadmap' this entire time?
> One wonders why you haven't said anything until now.

I did--

As Bryan pointed out... with the exception of the intro and end and a
couple sentences in the middle my entire response to your post, with
the position on "roadmaps" was written a long time ago, specifically
to complain about and argue against that particular approach.

> In my first email I list the benefits of having a roadmap. One benefit
> is that, without one, it is likely that a large majority of outsiders
> have almost no idea at all what is being worked on, what effect it will
> have, or when it might be ready, or to whom/what they should turn to for
> advice on such matters. Do you have a different way of addressing this
> communication problem?

I think you may be mistaking a roadmap with "communications"-- people
taking about research they are exploring is great! and we should have
more of it.  But like with RedHat and kernel features, we can't really
roadmap things that are unresourced and currently just unimplemented
exploration or test code-- without seeing things which are more or
less done the community can't rightfully decide if they'd want to
support something or not.  Perhaps they'll be good things perhaps
awful-- the devil is in the details, and until an effort is fairly
mature, you cannot see the details.

There have, for example, been signature aggregation proposals in the
past that required address reuse (could only aggregate if they're
reused).  I would strongly oppose such a proposal, and I hope everyone
else here would too.  So if I were a third party looking at your
message, rather than the person who initially proposed the agg sig
thing you're talking about, I wouldn't know if I could love it or hate
it yet; and probably couldn't be expected to have much of an opinion
on it until there is a BIP and/or example implementation.

To the extent that a roadmap differs from communications in general,
it is in that it also implies things that none of us can promise
except for our own efforts; Completion of implementations, success of
experiments, adoption-- basically assuming a level of top down control
that doesn't exist in a wide public collaboration.

One of the great challenges in our industry is that we don't have
rings of communication: We don't have much in the way of semi-experts
to communicate to semi-semi-experts to communicate to media pundits to
communicate to the unwashed masses-- at each level closing the
inferential gap and explaining things in terms the audience
understands. We don't have things like LWN.   We'll get there, but it
it took the Linux world decades to build to what it has now. I think
various forces in the industry work against us-- e.g. we lose a mot of
mid tier technical people to the allure of striking it rich printing
money in their own altcoins.

It might be attractive to try to end-run the slow development
appropriate web of reliable communications by deploying high authority
edicts, but it ultimately can't work because it doesn't map to how
things are accomplished, not in true collaborative open source, and
certainly not in an effort whos value comes substantially from
decentralization. Doing so, I fear, creates a false understanding of
authority.

(It's a common misunderstanding, for example, that people do what I
want (for example); but in reality, I just try to avoid wasting my
time advocating things that I don't think other people are already
going to do; :) otherwise, if _I_ want something done I've got to do
it myself or horse trade for it, just like anyone else.)

One of the great things about general communications is anyone can do
it.  Of course, unless they're talking about their own work, they
can't promise any of it will be completely-- but that is always true.
 If someone wants some guarantee about work, they have to be willing
to get it done themselves (and, of course, if it's a consensus
feature-- that much is necessary, but still not sufficient to get a
guarantee).

[from your other reply]
>> A fine intention, but I've checked with many of the top contributors
>> and it sounds like the only regular developer you spoke with was
>> Luke-Jr.  Next time you seek to represent someone you might want to
>> try talking to them!
>
> That is false. I could provide a list of names but I'm really not sure
> what would be gained as result. You yourself admit that it is an
> excellent list of research, almost all which you support directly.
>
> So I think your only real objection is that I didn't talk to you
> specifically.

Come now, this is needlessly insulting. I would have made the same
comment if you had talked to me because you didn't talk to most/all of
Matt Corallo, Wladimir, Pieter Wuille, Alex Morcos, etc.... e.g. the
people doing most of the work of actually building the system.  Before
making that comment I went and checked with people to find out if only
I was left out.  Talking to Adam (who isn't involved in the project)
and Luke-jr (who is but is well known for frustratingly extreme
minority positions and also contracts for Blockstream sometimes) isn't
a great approach for the stated goal of speaking for developers!

From truthcoin at gmail.com  Wed Jul 12 00:21:09 2017
From: truthcoin at gmail.com (Paul Sztorc)
Date: Tue, 11 Jul 2017 20:21:09 -0400
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <D30D8852-EFF4-4AB3-9B97-53D622A1440A@taoeffect.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<A030CDEA-CB0F-40BF-9404-6BD091537BE1@taoeffect.com>
	<08078429-089f-9315-2f76-a08121c5378c@gmail.com>
	<D30D8852-EFF4-4AB3-9B97-53D622A1440A@taoeffect.com>
Message-ID: <a9ad2dd0-a949-643f-9375-a95015020066@gmail.com>

On 7/11/2017 7:12 PM, Tao Effect wrote:
> Paul,
>
> There is a difference between replying to an email, and addressing the
> issues that were brought up in it.
>
> I did read your reply, and I chose not to respond to it because it did
> not address anything I said.

In that case you should clarify, which is exactly what you are doing now.

>
> Here's an example:
>
>> It would not be accurate to say that miners have "total" control. Miners
>> do control the destination of withdrawals, but they do not control the
>> withdrawal-duration nor the withdrawal-frequency.
>>
>> So, if miners wish to 'steal' from a sidechain, they _can_ initiate a
>> theft, but they can not change the fact that their malfeasance will be
>> [a] obvious, and [b] on display for a long period of time.
>
> Here, you admit that the security of the sidechains allows miners to
> steal bitcoins, something they cannot do currently.

If that were the case, then DC would need to be a hard fork. It so
happens that it is *not* the case -- if users choose to deposit to an
anyone-can-spend output, then miners can take the Bitcoins, which *is*
something that miners can do currently.

>
> You next tried to equate three different types of theft, what you
> called "Classic Theft", "Channel Theft", and "Drivechain Theft", saying:
>
>> I do not think that any of the three stands out as being categorically
>> worse than the others
>
> To anyone who understands bitcoin, there is a very clear,
> unmistakeable difference between double-spending ("Classic Theft"),
> and *ownership* of the private key controlling the bitcoins.
>
> Similarly, to anyone who understands bitcoin, there is also a very
> clear, unmistakeable difference between censorship ("Channel Theft"),
> and *ownership* of the private key controlling the bitcoins.

I am not sure what you are disagreeing with. The three thefts involve
different attacker resources and behaviors, and in that way they are
different. But in all three cases the user has lost the BTC they would
have otherwise owned, and in that way they are not different.

And users are under no obligation to use DC, just as they are under no
obligation to open a LN channel (or use P2SH, etc).

>
> I am not sure how else to respond to that email, given that none of
> the issues were really addressed.
Other than your complaint about being freely given the option to upgrade
to software which will give you the option to freely opt-in to a
different security model that you can otherwise ignore, feel free to
bring up any other issues you feel need to be addressed.

> Drivechain is an unmistakeable weakening of Bitcoin's security
> guarantees. This you have not denied.
That is false. I do deny it. Per the logic of the soft fork, the
security properties are at best unchanged (as I think almost everyone
else on this list would acknowledge). And even for those users who
opt-in, I feel the risk of theft is low, as I explain in the very
passage you've quoted above.

And please try to avoid going off-topic -- this is supposed to be about
the idea of a new roadmap.

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/4b60c333/attachment.html>

From truthcoin at gmail.com  Tue Jul 11 22:27:56 2017
From: truthcoin at gmail.com (Paul Sztorc)
Date: Tue, 11 Jul 2017 18:27:56 -0400
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <CAAS2fgSEZDmgGBxB-ZNqC0NpWQCJSL9xnbaNQFud=sW0Fdgu8w@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAGL6+mHQZ3UP10msk65OO+Uk0hn7j+dkmJap_M7FgWfSZaYYJQ@mail.gmail.com>
	<f79b9693-b8a5-c496-9dd9-d74704855d0e@gmail.com>
	<CAAS2fgSEZDmgGBxB-ZNqC0NpWQCJSL9xnbaNQFud=sW0Fdgu8w@mail.gmail.com>
Message-ID: <e226ba27-5f5e-f4d5-8d2d-9b4206a27d05@gmail.com>

On 7/11/2017 5:31 PM, Gregory Maxwell wrote:
> On Tue, Jul 11, 2017 at 8:18 PM, Paul Sztorc via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> I wrote the roadmap to try to be representative of a Core / developer
>> position.
> A fine intention, but I've checked with many of the top contributors
> and it sounds like the only regular developer you spoke with was
> Luke-Jr.  Next time you seek to represent someone you might want to
> try talking to them!
That is false. I could provide a list of names but I'm really not sure
what would be gained as result. You yourself admit that it is an
excellent list of research, almost all which you support directly.

So I think your only real objection is that I didn't talk to you
specifically.

>> I am philosophically against hard forks, but HFs were in the end
>> of the previous roadmap so I felt it should stay. And, I felt that if I
> I think the project is not philosophically against hardforks, at least
> not in an absolute sense.
That is why I included them despite being personally against them.
> But if you were instead to talk about things like fixing timewarp,
> recovering header bits, etc. It would clearly be the other way.
It links to bitcoinhardforkresearch.github.io , which I assumed would
contain the hard fork wishlist somewhere, but perhaps it does not.

> In any case, I think it's safe to say that people's opinions on
> hardforks are complicated. And all the smoke right now with unusually
> poorly executed proposals probably clouds clear thinking.

Yes, of course. But is your position that if something is complicated we
should not try to clarify it?



From karljohan-alm at garage.co.jp  Wed Jul 12 01:22:59 2017
From: karljohan-alm at garage.co.jp (Karl Johan Alm)
Date: Wed, 12 Jul 2017 10:22:59 +0900
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
Message-ID: <CALJw2w5uh8y1EMJdJVDhuFs3NG7LeM8T5HzfLHp8kXN15ryrXw@mail.gmail.com>

On Wed, Jul 12, 2017 at 6:11 AM, Gregory Maxwell via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> IMO the way to do "roadmaps" in Bitcoin is to roadmap the finalization
> and release process once the basic technology is done; because it's
> only past that point that guarantees can really start being made.

Bitcoin development differs from Linux kernel development in a number
of obvious ways, such as the fact Bitcoin is being "patched in
flight". The current political situation over Bitcoin development is
also quite different, with scalability being a major concern for a lot
of users, and conflicting views leading to risky technical gambles.

Having *something* like a roadmap that gives the average user some
insights into what exactly is being planned for Bitcoin is very
desirable, arguably even necessary, in particular for the scaling
solutions. Putting deadlines and dates in would of course be highly
irresponsible, as no one can predict how much of their free time
volunteer developers will put into the project in advance (or whether
they will stick around for the next X months or stop being
contributors).

I think there is necessity for a document that describes the project
intentions for scaling solutions, but I don't think adding dates and
deadlines is appropriate. That may or may not be a roadmap. I imagine
such a document would be updated regularly as appropriate, which means
it may be less of a roadmap than the traditional kind.

From luke at dashjr.org  Wed Jul 12 01:06:14 2017
From: luke at dashjr.org (Luke Dashjr)
Date: Wed, 12 Jul 2017 01:06:14 +0000
Subject: [bitcoin-dev] A Segwit2x BIP
In-Reply-To: <CAKzdR-oRdX-fXyc6womZOyYyfHUJZdgh92FUMM8pR_QDNiJfkQ@mail.gmail.com>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
	<A7FFF8F7-9806-44F1-B68F-F83C44893365@ob1.io>
	<CAKzdR-oRdX-fXyc6womZOyYyfHUJZdgh92FUMM8pR_QDNiJfkQ@mail.gmail.com>
Message-ID: <201707120106.16951.luke@dashjr.org>

On Monday 10 July 2017 11:50:33 AM Sergio Demian Lerner via bitcoin-dev wrote:
> Regarding the timeline, its certainly rather short, but also is the UASF
> BIP 148 ultimatum.

BIP148 began with 8 months lead time, reduced to 5 months from popular request 
and technical considerations. There is nothing about BIP148 that compels an 
attempted hardfork 90 days later - that could just as well have been 18 
months.

> More than 80% of the miners and many users are willing to go in the
> Segwit2x direction. With the support and great talent of the Bitcoin Core
> developers, Segwit2x activation will not cause any major disruptions.

That's not true at all. Based on my observations, only approximately 20% of 
the community follow Core's technical lead without significant consideration 
of their own - and who knows if that would change if Core were to suggest 
clearly-unsafe block size increases, or attempted to force a hardfork against 
consensus. Even with Core's support, many people would oppose the hardfork 
attempt, and it would fail.

> Without Core, there will be a temporary split. Both sides will have to
> hard-fork.

Segwit2x's hardfork does not compel the remaining Bitcoin users to also 
hardfork.

> I want a Bitcoin united. But maybe a split of Bitcoin, each side with its
> own vision, is not so bad.

I concur, but I disagree your approach has any possibility of a united 
Bitcoin. The only way to get that today, would be to do Segwit+Drivechain, not 
Segwit+Hardfork.

Luke

From truthcoin at gmail.com  Wed Jul 12 01:40:32 2017
From: truthcoin at gmail.com (Paul Sztorc)
Date: Tue, 11 Jul 2017 21:40:32 -0400
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <CAAS2fgTsjfMGw6D_OxDthSrrdLEFx2skGedLAjTwz3yCQijyug@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<CAAS2fgTsjfMGw6D_OxDthSrrdLEFx2skGedLAjTwz3yCQijyug@mail.gmail.com>
Message-ID: <001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com>

Greg,

I would summarize your email as stating that: you regret writing the
first email, and regret the fact that it became a roadmap that everyone
signed. And that therefore it is obviously a concept NACK from you.

( That's pretty surprising to me, and I would expect others to find it
surprising as well. And I wonder whether you think we should take the
old one *down*, and why you would allow (?) so many other people to sign
it, etc. But I am not willing to press the issue. Some of your other
comments I also find confusing but there is little to be gained in
clarifying them. )

Generally, I still think that the roadmap was a helpful communication
device, which did more good than harm. And I am interested in hearing
what other people think.

Separately, and very important to me, is that you feel that there are
unresolved objections to drivechain's security model, which you decline
to share with me and/or the list. So I would hope that you instead
choose to share your thoughts (as is, presumably, the purpose of this list).

I will also respond to this:

>>> A fine intention, but I've checked with many of the top contributors
>>> and it sounds like the only regular developer you spoke with was
>>> Luke-Jr.  Next time you seek to represent someone you might want to
>>> try talking to them!
>> That is false. I could provide a list of names but I'm really not sure
>> what would be gained as result. You yourself admit that it is an
>> excellent list of research, almost all which you support directly.
>>
>> So I think your only real objection is that I didn't talk to you
>> specifically.
> Come now, this is needlessly insulting. I would have made the same
> comment if you had talked to me because you didn't talk to most/all of
> Matt Corallo, Wladimir, Pieter Wuille, Alex Morcos, etc.... e.g. the
> people doing most of the work of actually building the system.  Before
> making that comment I went and checked with people to find out if only
> I was left out.  Talking to Adam (who isn't involved in the project)
> and Luke-jr (who is but is well known for frustratingly extreme
> minority positions and also contracts for Blockstream sometimes) isn't

Let me try to explain my point of view. I did speak to several people,
in addition to the two names that I privately volunteered to you when
you asked me in a personal email earlier today. From my point of view
you had done no research (you failed to uncover any additional names),
used the information I volunteered to you against me (in the form of
false characterizations of negligent email writing!), and you also
suggested that, other than yourself and a few others, no one is
qualified even to write a first draft of a summary of present day
activities. This response is typical of the hostile review environment
which has existed in Bitcoin for years (I am more than used to it). If
instead of writing the first draft, I had written nothing, I would be
accused of being the ideas guy and/or "not contributing". You also
(rather rudely), put me in an awkward position, as the people who I
*did* ask now almost certainly prefer that I not reveal their names
(yet, a low name count is held as a strike against my competence).

Such are the perils of posting to bitcoin-dev! Let all be warned! : )

Paul




On 7/11/2017 8:07 PM, Gregory Maxwell wrote:
> On Tue, Jul 11, 2017 at 10:17 PM, Paul Sztorc <truthcoin at gmail.com> wrote:
>> I don't understand this at all. This document attempts to do exactly
>> what its predecessor did -- nothing more or less.
> That might be your impression, then you've misunderstood what I
> intended-- What I wrote was carefully constructed as a personal view
> of how things might work out. It never claimed to be a a project
> roadmap. Though as usual, I work hard to propose things that I believe
> will be successful... and people are free to adopt what they want.
>
> And to the extent that it got taken that way I think it was an error
> and that it has harmed progress in our community; and created more
> confusion about control vs collaboration.
>
> With perfect hindsight I wouldn't have posted it; especially since
> we've learned that the demand for increased capacity from many people
> was potentially less than completely earnest. (The whole, can't double
> capacity until we quadruple it thing...)
>
>> As to your specific complaints, I have addressed both the security model
> and the concept of mining centralization on this list in the recent
> past.
>
> I don't agree that you have; but for the purpose of this thread
> doesn't really matter if I (specifically) do or don't agree.  It's an
> objective truth that many people do not yet believe these concerns
> have been addressed.
>
>> I really don't understand what you are disclosing. That Adam asked you
>> for feedback on the draft? And then, in the next sentence, that not
> That Adam asked me to write publish a new "roadmap" for Bitcoin as
> you've done here, with particular features and descriptions, which I
> declined; and explained why I didn't believe that was the right
> approach.  And Adam worked with you on the document, and provided
> content for it (which I then recognized in the post).
>
> Set aside what you know to be true for a moment and consider how this
> might look to an outsider who found out about it.  It could look a
> like Blockstream was trying to influence the direction of Bitcoin by
> laundering proposals through an apparently unaffiliated third party.
> Doubly so considering who participated in your drafting and who didn't
> (more below).
>
> I don't think in actuality you did anything remotely improper
> (ill-advised, perhaps, since your goal to speak for developers but you
> didn't speak to them, IMO--) but I think transparency is essential to
> avoid any appearance of misconduct.
>
>> But surely you can
>> appreciate how bizarre your position on roadmaps is. What exactly, did
>> you intended to create at [1]? Since it is described explicitly as "the
>> roadmap in Capacity increases for the Bitcoin system", have you been
>> disagreeing with it's characterization as a 'roadmap' this entire time?
>> One wonders why you haven't said anything until now.
> I did--
>
> As Bryan pointed out... with the exception of the intro and end and a
> couple sentences in the middle my entire response to your post, with
> the position on "roadmaps" was written a long time ago, specifically
> to complain about and argue against that particular approach.
>
>> In my first email I list the benefits of having a roadmap. One benefit
>> is that, without one, it is likely that a large majority of outsiders
>> have almost no idea at all what is being worked on, what effect it will
>> have, or when it might be ready, or to whom/what they should turn to for
>> advice on such matters. Do you have a different way of addressing this
>> communication problem?
> I think you may be mistaking a roadmap with "communications"-- people
> taking about research they are exploring is great! and we should have
> more of it.  But like with RedHat and kernel features, we can't really
> roadmap things that are unresourced and currently just unimplemented
> exploration or test code-- without seeing things which are more or
> less done the community can't rightfully decide if they'd want to
> support something or not.  Perhaps they'll be good things perhaps
> awful-- the devil is in the details, and until an effort is fairly
> mature, you cannot see the details.
>
> There have, for example, been signature aggregation proposals in the
> past that required address reuse (could only aggregate if they're
> reused).  I would strongly oppose such a proposal, and I hope everyone
> else here would too.  So if I were a third party looking at your
> message, rather than the person who initially proposed the agg sig
> thing you're talking about, I wouldn't know if I could love it or hate
> it yet; and probably couldn't be expected to have much of an opinion
> on it until there is a BIP and/or example implementation.
>
> To the extent that a roadmap differs from communications in general,
> it is in that it also implies things that none of us can promise
> except for our own efforts; Completion of implementations, success of
> experiments, adoption-- basically assuming a level of top down control
> that doesn't exist in a wide public collaboration.
>
> One of the great challenges in our industry is that we don't have
> rings of communication: We don't have much in the way of semi-experts
> to communicate to semi-semi-experts to communicate to media pundits to
> communicate to the unwashed masses-- at each level closing the
> inferential gap and explaining things in terms the audience
> understands. We don't have things like LWN.   We'll get there, but it
> it took the Linux world decades to build to what it has now. I think
> various forces in the industry work against us-- e.g. we lose a mot of
> mid tier technical people to the allure of striking it rich printing
> money in their own altcoins.
>
> It might be attractive to try to end-run the slow development
> appropriate web of reliable communications by deploying high authority
> edicts, but it ultimately can't work because it doesn't map to how
> things are accomplished, not in true collaborative open source, and
> certainly not in an effort whos value comes substantially from
> decentralization. Doing so, I fear, creates a false understanding of
> authority.
>
> (It's a common misunderstanding, for example, that people do what I
> want (for example); but in reality, I just try to avoid wasting my
> time advocating things that I don't think other people are already
> going to do; :) otherwise, if _I_ want something done I've got to do
> it myself or horse trade for it, just like anyone else.)
>
> One of the great things about general communications is anyone can do
> it.  Of course, unless they're talking about their own work, they
> can't promise any of it will be completely-- but that is always true.
>  If someone wants some guarantee about work, they have to be willing
> to get it done themselves (and, of course, if it's a consensus
> feature-- that much is necessary, but still not sufficient to get a
> guarantee).
>
> [from your other reply]
>>> A fine intention, but I've checked with many of the top contributors
>>> and it sounds like the only regular developer you spoke with was
>>> Luke-Jr.  Next time you seek to represent someone you might want to
>>> try talking to them!
>> That is false. I could provide a list of names but I'm really not sure
>> what would be gained as result. You yourself admit that it is an
>> excellent list of research, almost all which you support directly.
>>
>> So I think your only real objection is that I didn't talk to you
>> specifically.
> Come now, this is needlessly insulting. I would have made the same
> comment if you had talked to me because you didn't talk to most/all of
> Matt Corallo, Wladimir, Pieter Wuille, Alex Morcos, etc.... e.g. the
> people doing most of the work of actually building the system.  Before
> making that comment I went and checked with people to find out if only
> I was left out.  Talking to Adam (who isn't involved in the project)
> and Luke-jr (who is but is well known for frustratingly extreme
> minority positions and also contracts for Blockstream sometimes) isn't
> a great approach for the stated goal of speaking for developers!




From kanzure at gmail.com  Wed Jul 12 02:48:38 2017
From: kanzure at gmail.com (Bryan Bishop)
Date: Tue, 11 Jul 2017 21:48:38 -0500
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<CAAS2fgTsjfMGw6D_OxDthSrrdLEFx2skGedLAjTwz3yCQijyug@mail.gmail.com>
	<001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com>
Message-ID: <CABaSBawY0P4GM-5dcyznLgTkAfm7qmDt-8BgMPWSCcvfRH-MHA@mail.gmail.com>

On Tue, Jul 11, 2017 at 8:40 PM, Paul Sztorc via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> it, etc. But I am not willing to press the issue. Some of your other
> comments I also find confusing but there is little to be gained in
> clarifying them. )

To me it looked as if I was reading an email that was making a bunch
of points about how bitcoin development can't be coordinated and how
things would be broken if it were to be coordinated ("high authority
edicts"). There was a lot of harm caused by calling that 2015 email a
roadmap. Somehow-- and there's no way to figure out how this happened
I guess- people started putting timeline commitments to different
features. But there's really no way to guarantee any of those
timelines. And I think it's very quick to reach the point of unethical
to advocate a perspective that there's guarantee to things will happen
according to that timeline in the standard bitcoin development model.
I think there's already such a huge amount of public misunderstanding
around how bitcoin development works that giving guarantees even as a
community would further increase the misunderstandings.

> Generally, I still think that the roadmap was a helpful communication
> device, which did more good than harm. And I am interested in hearing
> what other people think.

I think generally communicating about research directions and projects
is useful and valuable, and I don't see any disagreement about that in
itself from anyone in this thread. I recommend an abundance of caution
with regards to whether to call these efforts roadmaps.

>> Come now, this is needlessly insulting. I would have made the same
>> comment if you had talked to me because you didn't talk to most/all of
>> Matt Corallo, Wladimir, Pieter Wuille, Alex Morcos, etc.... e.g. the
>> people doing most of the work of actually building the system.  Before
>> making that comment I went and checked with people to find out if only
>> I was left out.  Talking to Adam (who isn't involved in the project)
>> and Luke-jr (who is but is well known for frustratingly extreme
>> minority positions and also contracts for Blockstream sometimes) isn't
>
> Let me try to explain my point of view. I did speak to several people,
> in addition to the two names that I privately volunteered to you when
> you had done no research (you failed to uncover any additional names),

Well I mean he did look at some of the people putting the most effort
into bitcoin development. Why would he start at the other end of the
list as a rough check..?

> suggested that, other than yourself and a few others, no one is
> qualified even to write a first draft of a summary of present day

Those suggestions were mixed with strong avocado that summaries are
good, coupled with recommendations that these aren't really roadmaps.
As to qualifying from where knowledge is sourced, yeah it seems like
talking with developers is a good idea, it seems everyone agrees with
that in this thread.

> activities. This response is typical of the hostile review environment
> which has existed in Bitcoin for years (I am more than used to it). If

Well, to the extent that criticism is being misinterpreted as hostile,
I have seen people get upset from basic security review because "why
were't we more friendly and just say OK instead of pointing out the
problems".

- Bryan
http://heybryan.org/
1 512 203 0507

From greg at xiph.org  Wed Jul 12 03:33:47 2017
From: greg at xiph.org (Gregory Maxwell)
Date: Wed, 12 Jul 2017 03:33:47 +0000
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<CAAS2fgTsjfMGw6D_OxDthSrrdLEFx2skGedLAjTwz3yCQijyug@mail.gmail.com>
	<001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com>
Message-ID: <CAAS2fgR3FQ-wSwGwK6PDD_nZKpnBDAtM=5-fvR-smDa48xjW4Q@mail.gmail.com>

On Wed, Jul 12, 2017 at 1:40 AM, Paul Sztorc <truthcoin at gmail.com> wrote:
> Separately, and very important to me, is that you feel that there are
> unresolved objections to drivechain's security model, which you decline
> to share with me and/or the list. So I would hope that you instead
> choose to share your thoughts (as is, presumably, the purpose of this list).

You've complained in this thread that Tao Effects' specific criticisms
were off-topic for the thread. I agree.

> Let me try to explain my point of view. I did speak to several people,

Yes, but apparently none of the most active developers or people
working on the proposals you named.  But you're fully entitled to
write about whatever you want while talking to whomever you want or
even without talking to anyone at all.

But, strategically it seems a little ill-advised.

For example, had you spoken to me I would have advised against the
dates offered for signature agg-- which would be more realistic for
publication of a complete proposal and implementation that the
community could finally have an opinion on, not for actual deployment;
and I probably would have discouraged highlighting compaction since we
haven't worked on that much since December due to other priorities.

(I also would have forwarded you my general concern about 'roadmaps'
as a communication tool.)

Maybe this could saved a bit of time and discussion, maybe not!

> used the information I volunteered to you against me (in the form of
> false characterizations of negligent email writing!), and you also

I apologize for causing you to feel anything was used against you.  I
don't support the roadmap-approach you propose here-- but my failure
to support it is definitionally non-personal according to the laws of
time and space: I wrote that opposition to other peoples similar
proposal some nine months ago, in private-- it has nothing to do with
you in a rather profound and physical sense.

To the extent that I criticize whom you talked to, it was intended to
be merely a remark on strategy: You yourself stated that "wrote the
roadmap to try to be representative of a Core / developer position",
but you didn't talk to the major developers or the authors of the
things you put on the roadmap--  there is /nothing improper/ or bad
about that... but I don't think it was good strategy. Feel free to
disagree, it was-- perhaps-- unsolicited advice.

It seems to me that your goal is creating more communication around
the clear set of obvious shared intentions; sounds great. Dressing it
as an official "roadmap" I think works counter to that purpose, and to
really be successful with the communications goal  I think it would be
best to go around privately polling major actors to find out what
they'd add or remove then take the intersection then spare everyone
the debate.  Not that debate isn't good, but we shouldn't shouldn't be
debating over an omnibus bill that needlessly ties things together,
people can debate each initiative on its own merits in its own
threads... the purpose was to communicate, right?  I do support that
goal, even though I don't think I support the current approach.

As before-- that is more unsolicited advice, feel free to ignore it.
Just keep in mind that no one owes anyone a response. I did take the
time to read and understand your message. I'm sorry that my response
isn't more to your liking. I'm thankful that you read and responded to
my reply.

Cheers,

From contact at taoeffect.com  Tue Jul 11 23:12:03 2017
From: contact at taoeffect.com (Tao Effect)
Date: Tue, 11 Jul 2017 16:12:03 -0700
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <08078429-089f-9315-2f76-a08121c5378c@gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<A030CDEA-CB0F-40BF-9404-6BD091537BE1@taoeffect.com>
	<08078429-089f-9315-2f76-a08121c5378c@gmail.com>
Message-ID: <D30D8852-EFF4-4AB3-9B97-53D622A1440A@taoeffect.com>

Paul,

There is a difference between replying to an email, and addressing the issues that were brought up in it.

I did read your reply, and I chose not to respond to it because it did not address anything I said.

Here's an example:

> It would not be accurate to say that miners have "total" control. Miners
> do control the destination of withdrawals, but they do not control the
> withdrawal-duration nor the withdrawal-frequency.
> 
> So, if miners wish to 'steal' from a sidechain, they _can_ initiate a
> theft, but they can not change the fact that their malfeasance will be
> [a] obvious, and [b] on display for a long period of time.

Here, you admit that the security of the sidechains allows miners to steal bitcoins, something they cannot do currently.

You next tried to equate three different types of theft, what you called "Classic Theft", "Channel Theft", and "Drivechain Theft", saying:

> I do not think that any of the three stands out as being categorically
> worse than the others

To anyone who understands bitcoin, there is a very clear, unmistakeable difference between double-spending ("Classic Theft"), and *ownership* of the private key controlling the bitcoins.

Similarly, to anyone who understands bitcoin, there is also a very clear, unmistakeable difference between censorship ("Channel Theft"), and *ownership* of the private key controlling the bitcoins.

The entire email was a very long-form way of admitting to all of the issues that were raised in the previous email, while making it sound like you had addressed the issues.

I am not sure how else to respond to that email, given that none of the issues were really addressed.

Drivechain is an unmistakeable weakening of Bitcoin's security guarantees. This you have not denied.

There is no reason to weaken Bitcoin's security in such a dramatic fashion. Better options are being worked on, they just take time.

Kind regards,
Greg Slepak

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

> On Jul 11, 2017, at 3:57 PM, Paul Sztorc <truthcoin at gmail.com <mailto:truthcoin at gmail.com>> wrote:
> 
> On 7/11/2017 6:41 PM, Tao Effect wrote:
>> Dear Paul,
>> 
>> Drivechain has several issues that you've acknowledged but have not,
>> IMO, adequately (at all really) addressed [1].
> 
> I replied to your email at length, at [2]. You should read that email,
> and then reply to it with your outstanding objections, if you still have
> them (per the usual customs of a mailing list).
> 
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014609.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014609.html>
> 
>> Adopting DC would be an irreversible course of action,
> 
> This is false -- it is easily reversible with a second soft fork.
> 
> Also, I would say to everyone that, (in my opinion as the OP) this
> conversation will go off-topic if it veers exclusively into 'drivechain
> review'.
> 
> Paul
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/3aef0c56/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/3aef0c56/attachment-0001.sig>

From ZmnSCPxj at protonmail.com  Wed Jul 12 08:30:31 2017
From: ZmnSCPxj at protonmail.com (ZmnSCPxj)
Date: Wed, 12 Jul 2017 04:30:31 -0400
Subject: [bitcoin-dev] [BIP Proposal] Standard address format for
	timelocked funds
In-Reply-To: <VxtMcRFeh3Yr86KleeyK3BeZ9_KJVSmRtMgIdanwcEe23IrBwK0Q_ozC_EyxX6KHRcpePKgnaBk9KsY_i77k4Be3QEosXhUwbj561t4oJqw=@protonmail.com>
References: <VxtMcRFeh3Yr86KleeyK3BeZ9_KJVSmRtMgIdanwcEe23IrBwK0Q_ozC_EyxX6KHRcpePKgnaBk9KsY_i77k4Be3QEosXhUwbj561t4oJqw=@protonmail.com>
Message-ID: <ST-p1uYWpwTa6RLgXAd5NLgZwt_rzJdxQaK2X5kp6gmjmj-uCw8VNANcfR3mAMBFV5D4j52TC6fX612pFWkrcg2jpjiDtLnGHyd6DQtt7Oo=@protonmail.com>

Good morning mailinglist,
I am saddened at the lack of attention to this BIP proposal. I know that it is not as interesting as the debates on where Bitcoin will go in the future and what needs to be prepared for even greater mainstream adoption, but I think my BIP proposal does have at least some value to long-term investors.
So far I have seen only a single public feedback:
https://www.reddit.com/r/Bitcoin/comments/6lzpvz/bip_hodl/djxzbvi/
Basically, the point in that feedback is mostly that the computed timelock should be UTC+0 0000h of the given human-readable date.
I would like to respectfully ask the mailing list about which option is best:
1. (current) Use the earliest timezone as of now, UTC+14 0000h of the given human-readable date. Pro: No matter where you are in the world, as soon as the given date arrives, the fund can be spent. Con: For most of the world, the fund can be spent on some time the day before, or even two days before for UTC-11 and UTC-12 timezones.
2. Use the standard timezone UTC+0 0000h of the given human-readable date. Pro: standard time. Con: for half of the world, the fund is not spendable until some time into the given date, for the other half, it will be spendable at an earlier date.
3. Allow indicating a timezone to the human-readable part. Pro: gives control over the user's expected local time. Con: additional field and effectively more control, need to handle also strange timezones that have 0.5 hour difference from UTC, need to encode positive and negative preferably without using + and -, as those may break double-click selection.
I hope to get some feedback from this list.
Regards,
ZmnSCPxj
-------- Original Message --------
Subject: [bitcoin-dev] [BIP Proposal] Standard address format for timelocked funds
Local Time: July 8, 2017 9:13 AM
UTC Time: July 8, 2017 1:13 AM
From: bitcoin-dev at lists.linuxfoundation.org
To: bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
<pre>
BIP: ?
Title: Standard address format for timelocked funds
Author: ZmnSCPxj <ZmnSCPxj at protonmail.com>
Comments-Summary: ?
Comments-URI: ?
Status: ?
Type: ?
Created: 2017-07-01
License: CC0-1.0
</pre>
== Abstract ==
<code>OP_CHECKLOCKTIMEVERIFY</code> provides a method of
locking funds until a particular time arrives.
One potential use of this opcode is for a user to precommit
himself or herself to not spend funds until a particular
date, i.e. to hold the funds until a later date.
This proposal adds a format for specifying addresses that
precommit to timelocked funds, as well as specifying a
redemption code to redeem funds after the timelock has
passed.
This allows ordinary non-technical users to make use of
<code>OP_CHECKLOCKTIMEVERIFY</code> easily.
== Copyright ==
This BIP is released under CC0-1.0.
== Specification ==
This proposal provides formats for specifying an
address that locks funds until a specified date,
and a redemption code that allows the funds to be
swept on or after the specified date.
At minimum, wallet software supporting this BIP must
be capable of sweeping the redemption code on or after
the specified date.
In addition, the wallet software should support sending
funds to the timelocked address specified here.
Finally, wallet software may provide a command to create
a pair of timelocked address and redemption code.
Addresses and redemption codes are encoded using
[https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Bech32
Bech32 encoding].
=== Timelocked Address Format ===
The human-readable part of the address is composed of:
# The four characters <code>hodl</code>.
# A date, in <code>YYYYMMDD</code> form. For example,
the date August 1, 2017 is encoded as <code>20170801</code>.
# A network code, either <code>tb</code> for testnet,
or <code>bc</code> for Bitcoin mainnet.
The data part of the address is composed of:
# A version quintet (5 bits), which must be 0 for this
BIP.
# A public key hash, 32 quintets (160 bits). As is
usual for Bitcoin, this is big-endian.
This is to be interpreted as follows:
# The given date is the first day that the funds in
the given address may be redeemed.
# The funds are owned by whoever controls the private
key corresponding to the public key hash given.
=== Redemption Code ===
The human-readable part of the redemption code is
composed of:
# The four characters <code>hedl</code>.
# A date, in <code>YYYYMMDD</code> form.
# A network code, either <code>tb</code> for testnet,
or <code>bc</code> for Bitcoin mainnet.
The data part of the address is composed of:
# A version quintet (5 bits), which must be 0 for this
BIP.
# A private key, 52 quintets (260 bits). This is the
256-bit private key, prepended with 4 <code>0</code>
bits, in big-endian order. <!-- We could consider
some kind of mini private key instead if the security
is similar anyway. -->
This is to be interpreted as follows:
# The given date is the first day that the funds in
the given address may be redeemed.
# The private key unlocks the funds.
=== Lock Time Computation ===
Given a particular lock date <code>YYYYMMDD</code>, the
actual lock time is computed as follows:
# The day before the lock date is taken. For example,
if the lock date is <code>20180101</code> or
January 1, 2018, we take the date December 31, 2017.
# We take the time 1000h (10:00 AM, or 10 in the morning)
of the date from the above step.
This lock time is then translated to a
Unix epoch time, as per POSIX.1-2001 (which removes the
buggy day February 29, 2100 in previous POSIX revisions).
The translation should use, at minimum, unsigned 32-bit
numbers to represent the Unix epoch time.
The Unix epoch time shall then be interpreted as an
<code>nLockTime</code> value, as per standard Bitcoin.
Whether it is possible to represent dates past 2038
will depend on whether standard Bitcoin can represent
<code>nLockTime</code> values to represent dates past
2038.
Since <code>nLockTime</code> is an unsigned 32-bit
value, it should be possible to represent dates until
06:28:15 UTC+0 2106-02-07.
Future versions of Bitcoin should be able to support
<code>nLockTime</code> larger than unsigned 32-bit,
in order to allow even later dates.
The reason for using an earlier lock time than the
specified date is given in the Rationale section of
this BIP.
=== Payment to a Timelocked Address ===
An ordinary P2SH payment is used to provide funds to a
timelocked address.
The script below is used as the <code>redeemScript</code>
for the P2SH payment:
<timeout> OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_DUP OP_HASH160 <publickeyhash> OP_EQUALVERIFY OP_CHECKSIG
Once the <code>redeemScript</code> is derived, the hash is
determined, and an ordinary P2SH output with the below
<code>scriptPubKey</code> used:
OP_HASH160 <redeemScripthash> OP_EQUAL
In case of SegWit deployment, SegWit-compatible wallets
should be able to use P2SH, P2WSH, or P2SH-P2WSH, as per
the output they would normally use in that situation.
Obviously, a timelocked address has an equivalent
Bitcoin <code>3</code> (P2SH) address.
A simple service or software that translates from a
public timelocked address to a P2SH address can be
created that makes timelocking (but not redemption)
backwards compatible with wallets that do not support
this BIP.
This proposal recommends that wallets supporting payment
to P2PKH, P2SH, P2WPKH, and P2WSH Bitcoin addresses should
reuse the same interface for paying to such addresses as
paying into timelocked addresses of this proposal.
=== Redemption of a Timelocked Redemption Code ===
To sweep a timelocked redemption code after the timelock,
one must provide the given <code>redeemScript</code> as
part of the <code>scriptSig</code>, of all unspent
outputs that pay to the given <code>redeemScript</code>
hash.
When sweeping a timelocked redemption code, first the
wallet must extract the private key from the redemption
code, then derive the public key, the public key hash,
the <code>redeemScript</code>, and finally the
<code>redeemScript</code> hash.
Then, the wallet must find all unspent outputs that pay
to the <code>redeemScript</code> hash via P2SH (and, in the
case of SegWit deployment, via P2SH-P2WSH and P2WSH).
For each such output, the wallet then generates a
transaction input with the below <code>scriptSig</code>, as
per usual P2SH redemptions:
<signature> <pubkey> <redeemScript>
The wallet then outputs to an address it can control.
As the Script involved uses <code>OP_CHECKLOCKTIMEVERIFY</code>,
the <code>nSequence</code> must be 0 and the
<code>nLockTime</code> must be equal to the computed
lock time.
This implies that the transaction cannot be transmitted
(and the funds cannot be sweeped)
until after the given lock time.
The above procedure is roughly identical to sweeping an
ordinary, exported private key.
This proposal recommends that wallets supporting a sweep
function should reuse the same interface for sweeping
individual private keys (wallet import format) for sweeping
timelocked redemption codes.
== Motivation ==
A key motivation for this BIP is to allow easy use of
<code>OP_CHECKLOCKTIMEVERIFY</code> by end-users.
The below are expected use cases of this proposal:
# A user wants to purchase an amount of Bitcoin,
and subsequently wait for an amount of time before
cashing out.
The user fears that he or she may have "weak hands",
i.e. sell unfavorably on a temporary dip, and thus
commits the coins into a timelocked fund that can
only be opened after a specific date.
# A user wants to gift an amount of Bitcoins to
an infant or minor, and wants the fund to not be spent
on ill-advised purchases until the infant or minor
reaches the age of maturity.
# A user may wish to prepare some kind of monthly subsidy
or allowance to another user, and prepares a series of
timelocked addresses, redeemable at some set date on
each month, and provides the private redemption codes to
the beneficiary.
# A user may fear duress or ransom for a particular
future time horizon, and voluntarily impose a lock time
during which a majority of their funds cannot be spent.
== Rationale ==
While in principle, this proposal may be implemented as a
separate service or software, we should consider the long
time horizons that may be desired by users.
A user using a particular software to timelock a fund may
have concerns, for example, of specifying a timelock
18 years in the future for a gift or inheritance to a
newborn infant.
The software or service may no longer exist after 18 years,
unless the user himself or herself takes over maintenance
of that software or service.
By having a single standard for timelocked funds that is
shared and common among multiple implementations of Bitcoin
wallets, the user has some assurance that the redemption code
for the funds is still useable after 18 years.
Further, a publicly-accessible standard specifying how the
funds can be redeemed will allow technically-capable users
or beneficiaries to create software that can redeem the
timelocked fund.
This proposal provides a timelock at the granularity of a
day.
The expectation is that users will have long time
durations of months or years, so that the ability to
specify exact times, which would require specifying the
timezone, is unneeded.
The actual timeout used is 1000h of the day before the
human-readable date, so that timezones of UTC+14 will
definitely be able to redeem the money starting at
0000h of the human-readable date, local time (UTC+14).
Given the expectation that users will use long time
durations, the fact that timezones of UTC-12 will
actually be able to redeem the funds on 2200h UTC-12
time two days before can be considered an acceptable
error.
The human-readable date is formatted according to
[https://www.iso.org/iso-8601-date-and-time-format.html
ISO standard dates], with the dashes removed.
Dashes may prevent double-click selection, making
usability of these addresses less desirable.
<!--
We can consider something like 2021m12d11 instead,
which would be much more readable and understandable
to human users.
-->
The <code>bc</code> or <code>tb</code> is after the
date since the date is composed of digits and the bech32
separator itself is the digit <code>1</code>. One
simply needs to compare <code>hedlbc202111211...</code>
and <code>hedl20211121bc1...</code>.
A version quintet is added in case of a future
sociopolitical event that changes interpretation of
dates, or changes in scripting that would allow for more
efficient redemptions of timelocked funds (which would
change the <code>redeemScript</code> paid to), or changes
in the size and/or format of lock times, and so on.
Such changes are unlikely, so the version is a quintet in
the bech32 data part rather than a substring in the
human-readable part.
The public address format uses the <code>hodl</code> as
the start of the code, while the private key (the
redemption code) uses <code>hedl</code>.
This provides a simple mnemonic for users:
"Pay into the <code>hodl</code> code to hold your
coins until the given date.
After you've held the coins (on or after the given date)
use the <code>hedl</code> code to redeem the coins."
The obvious misspelling of "hodl" is a homage to the common
meme within the Bitcoin community.
<!-- The above misspelling may be corrected if it is considered
to be in bad taste. -->
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/3d01edd5/attachment-0001.html>

From ZmnSCPxj at protonmail.com  Wed Jul 12 08:50:52 2017
From: ZmnSCPxj at protonmail.com (ZmnSCPxj)
Date: Wed, 12 Jul 2017 04:50:52 -0400
Subject: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
	Merge Mined drivechains
In-Reply-To: <CAGL6+mEeuhQp3TiLFOOAWO_wcRZXsfASKNT4364SSNzER6_xgw@mail.gmail.com>
References: <CAGL6+mHQ_vMc2JYVqwfP89WOZdUF2WDtWfh7ccL1PQve=nC+zQ@mail.gmail.com>
	<OozQK1_gWeExd5578AYH_dHnSKSvx63FJc2rIBBcaJF4f07qzsR8rr-ka5epwMFCjqDuidAWZiZqqlvn4xvSuUpDY0KkV014VQs6_E3Rp_A=@protonmail.com>
	<2f2e6b7c-2d47-518a-5a8f-0b5333607aac@gmail.com>
	<lYqi6yZAdUknHWs2DvSaM3h1tf3EVLngILZV9gbVBm5JVI96RvBGZaPBEFYNzt0QBkjdJ614BTsWjUkmuuqSd7RPFx-ihUL6SIXocqyW_ss=@protonmail.com>
	<98d35291-5948-cb06-c46a-9d209276cee2@gmail.com>
	<GDZ42AMqaETJGYZovJzkVZkxZE3UmCQ8q5fFTAajV6sX2LHFol6iEYahkY_sMrPv5m11lHZvuKXmD_PwXa5_S7x18vcP1FkQr0ZBROxj6HE=@protonmail.com>
	<CAGL6+mEeuhQp3TiLFOOAWO_wcRZXsfASKNT4364SSNzER6_xgw@mail.gmail.com>
Message-ID: <hvQJ5M9JSIbEjJuabefPJi_DBqDTTXYnJ1xEg7_rBozOBrI8WDzL6zwn9Zt7au5QHc3P3DPNYDBrsQCTkSB6lOFWPJ8UuY_W4GyIzQ-Qvfs=@protonmail.com>

>>In my scheme, if you read carefully through the pseudocode, a block list node is valid only if its block is valid.
>
>It seems this is a contradiction against the "blind" part of blind merge mining. How can a bitcoin blockchain node enforce this without tracking the sidechain?
From: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014668.html
>>>>2. When a sidechain-node wants to know the consensus, it downloads mainchain-blocks and looks for OP_RETURN's.
>>>>2.1. Starting with its genesis cons-pair hash (equivalent to the empty list) as the current cons-pair, it scans each OP_RETURN transaction.
>>>>2.1.1. If an OP_RETURN is 64-byte and has the parent cons-pair equal to the current cons-pair, look for the side block indicated and confirm its correctness. If correct, update the current cons-pair for the hash of the OP_RETURN data.
>>>>2.2. When reaching the latest mainchain block, the current cons-pair is now the sidecoin/altcoin latest block.
>>>>2.3. Note that if multiple OP_RETURN in a block match the current cons-pair, the first one is considered the correct chain. This property means that the sidechain/altchain can only have a chainsplit if the mainchain has a chainsplit.
It's the sidechain node which needs to learn about the sidechain blockchain anyway. So it's the one that does the checking of this.
For that matter, a mainchain miner can be bribed to commit to a random number rather than a valid h* block, and it will still lead all the sidechain nodes on a random chase to look for the indicated block.
>I'll follow your discussion with Paul about sidechain reorgs, but I think his proposal is more desirable -- it follows what actually happens in the bitcoin mining process where we *can* have chain splits when
>miners simultaneously find a block. Other miners will pick one of the two blocks to mine on top of and eventually one chain will become longer than the other. Therefore that chain will have it's block's
>orphaned and the miners/nodes following the dead chain will reorg on top of the longest chain.
In this paper: http://diyhpl.us/~bryan/papers2/bitcoin/On%20the%20instability%20of%20Bitcoin%20without%20the%20block%20reward%20-%202016.pdf
As far as I understood that paper, it means that if the block reward no longer exists, miners can profitably attempt to undercut any full blocks.
Sidechains do not have block rewards (unless the sidechain issues its own asset type that is separate from and not convertible to mainchain bitcoins).
Thus, to protect against undercutting attacks in the sidechain, we would need to ensure that the sidechain cannot be reorged without the mainchain (which currently still has a block reward) being reorged.
At least, this is my consideration. Perhaps the paper is wrong?
---
In any case, let me propose actual improvements to the OP_BRIBEVERIFY proposal:
1. Remove the necessity of coinbase commitments. The miner commits to the sidechain_id and h* in the transaction that pays the OP_BRIBEVERIFY anyway. That way the h* commitment occurs only once in the block, in the transaction that does the OP_BRIBEVERIFY. In addition, there is no need to impose particular ordering on the coinbase outputs, which would be problematic as pointed out by others, for example if the miner is interested only in merge mining for sidechain id #35 and nobody else.
2. When verifying a block, keep a set of sidechain ID's. When processing a transaction in that block with OP_BRIBEVERIFY, check if the sidechain ID is in that set. If not in that set, add it to that set and continue script processing. If already in the set, fail the script processing. This ensures that at most one OP_BRIBEVERIFY exists for each sidechain_id in a mainchain block.
3. Don't number sidechain_id from 0, 1, 2, 3..., because people will fight over the small numbers. Instead identify sidechains by, for example, the hash of their names or the hash of their genesis block or whatever. This allows true permissionless creation of sidechains, without some authority existing that centrally allocates sidechain ID's.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/be07f5d9/attachment.html>

From jacob.eliosoff at gmail.com  Wed Jul 12 07:27:32 2017
From: jacob.eliosoff at gmail.com (Jacob Eliosoff)
Date: Wed, 12 Jul 2017 03:27:32 -0400
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <a9ad2dd0-a949-643f-9375-a95015020066@gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<A030CDEA-CB0F-40BF-9404-6BD091537BE1@taoeffect.com>
	<08078429-089f-9315-2f76-a08121c5378c@gmail.com>
	<D30D8852-EFF4-4AB3-9B97-53D622A1440A@taoeffect.com>
	<a9ad2dd0-a949-643f-9375-a95015020066@gmail.com>
Message-ID: <CAAUaCyhdOJ3BxLd6QCqx19PxGDw5qM1YF5poZV8Jkp+RrmcR7A@mail.gmail.com>

Just a quick note in favor of an updated roadmap (some may object to that
label, but I think it's fine).  When you and your friends are planning your
weekly movie outing, it's very helpful to have someone who knows the group,
knows what films are playing, checks people's preferences, mails around
proposals, updates with corrections, keeps a list of choices for future
weeks, etc.  (Certainly not the same as imposing an agenda, except when the
coordinator gets pushy.)

Core veterans like those on this thread are well placed to compile (not
decree) such a document - basically an informed view of what looks likely
to get rough consensus, and in what order.  *Of course* some will dispute
the priorities etc, but it's my experience that if everyone virtuously
refrains from this kind of coordination effort, often the weekend rolls by
without a film.

Agreed that specific deadlines often create more problems than they solve,
but even without dates, clarifying priorities (eg, segwit before HF) is
still useful.

All this is aside from the fact that I have many criticisms of the "movies
chosen" so far and the criteria used to choose them - another thread
(basically, I support an interpretation of "consensus" that takes more note
of non-dev constituents).  The consensus-marshaling effort is still
important, and appreciated.


On Tue, Jul 11, 2017 at 8:21 PM, Paul Sztorc via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> And please try to avoid going off-topic -- this is supposed to be about
> the idea of a new roadmap.
>
> Paul
>
> _______________________________________________
> 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/20170712/516ee858/attachment.html>

From tomz at freedommail.ch  Wed Jul 12 09:02:51 2017
From: tomz at freedommail.ch (Tom Zander)
Date: Wed, 12 Jul 2017 11:02:51 +0200
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
Message-ID: <6345529.fq5kzMBjkQ@strawberry>

On Tuesday, 11 July 2017 23:11:38 CEST Gregory Maxwell via bitcoin-dev 
wrote:
> I think it's great that people want to experiment with things like
> drivechains/sidechains and what not, but their security model is very
> distinct from Bitcoin's and, given the current highly centralized
> mining ecosystem, arguably not very good.  So positioning them as a
> major solution for the Bitcoin project is the wrong way to go. Instead
> we should support people trying cool stuff, at their own risk.
>
> So, given that although the vast majority of the things in the document
> are things I've been supporting for months (Please see Note 1 way down
> at the bottom) I cannot support your document.

I?m thinking along the same lines, a industry wide roadmap makes very little 
sense.

Much like in Linux we have a lot of smaller groups doing their own thing, 
all working for the good of Linux as they see it, and implicitly, as they 
use it.
I think its safe to say that Linus would not want any say over the roadmap 
of Intel or Google or any other particpant in the Linux space.

I am in agreement with Gregory that we should reject a Bitcoin-wide scaling 
roadmap.

I do suggest that smalle groups publish their individual roadmaps, show what 
they are planning to work on in a place that people will find it (a website, 
not a mailinglist archive).

Those individual roadmaps then show what that group will work on, which 
helps their communication. It helps people talking about Bitcoin to the 
general public as well, and it helps people understand whom they would like 
to support financially or otherwise.
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

From tomz at freedommail.ch  Wed Jul 12 09:37:32 2017
From: tomz at freedommail.ch (Tom Zander)
Date: Wed, 12 Jul 2017 11:37:32 +0200
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <CALJw2w5uh8y1EMJdJVDhuFs3NG7LeM8T5HzfLHp8kXN15ryrXw@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<CALJw2w5uh8y1EMJdJVDhuFs3NG7LeM8T5HzfLHp8kXN15ryrXw@mail.gmail.com>
Message-ID: <1993137.zhoHNu5y1z@strawberry>

On Wednesday, 12 July 2017 03:22:59 CEST Karl Johan Alm via bitcoin-dev 
wrote:
> Bitcoin development differs from Linux kernel development in a number
> of obvious ways, such as the fact Bitcoin is being "patched in
> flight".

I've heard this before and it doesn't make any sense to me. Just like your 
Linux box needs a reboot to get a kernel upgrade, your node needs a restart 
to upgrade. Neither the (entire) internet will go down nor the (entire) 
Bitcoin network will go down as a result.

> Having *something* like a roadmap that gives the average user some
> insights into what exactly is being planned for Bitcoin is very
> desirable, arguably even necessary,

This is fine, and groups that do development should do this more structured 
than something like https://bitcoinhardforkresearch.github.io/

It just would not make any sense to have a roadmap for the *entire* industry 
as this would require you to decide what technical solution is better than 
another before either of them are fully researched.

Individual groups can have solutions that they believe is the best. And then 
we can let the market decide which one is to be actually activated.
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

From tomz at freedommail.ch  Wed Jul 12 08:15:50 2017
From: tomz at freedommail.ch (Tom Zander)
Date: Wed, 12 Jul 2017 10:15:50 +0200
Subject: [bitcoin-dev] A Segwit2x BIP
In-Reply-To: <CABm2gDo0wgqkEufKn=Z8uAsi=_6fgE=0TS6Bcr21mg3xAX7Kyw@mail.gmail.com>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
	<CAKzdR-oRdX-fXyc6womZOyYyfHUJZdgh92FUMM8pR_QDNiJfkQ@mail.gmail.com>
	<CABm2gDo0wgqkEufKn=Z8uAsi=_6fgE=0TS6Bcr21mg3xAX7Kyw@mail.gmail.com>
Message-ID: <7869651.CRYTeDpGy9@strawberry>

On Monday, 10 July 2017 20:38:08 CEST Jorge Tim?n via bitcoin-dev wrote:
> I think anything less than 1 year after release of tested code by some
> implementation would be irresponsible for any hardfork, even a very
> simple one.

Good news!

Code to support 2x (the hard fork part of the proposal) has been out and 
tested for much longer than that.
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

From roconnor at blockstream.io  Wed Jul 12 13:39:17 2017
From: roconnor at blockstream.io (Russell O'Connor)
Date: Wed, 12 Jul 2017 09:39:17 -0400
Subject: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
 Merge Mined drivechains
In-Reply-To: <hvQJ5M9JSIbEjJuabefPJi_DBqDTTXYnJ1xEg7_rBozOBrI8WDzL6zwn9Zt7au5QHc3P3DPNYDBrsQCTkSB6lOFWPJ8UuY_W4GyIzQ-Qvfs=@protonmail.com>
References: <CAGL6+mHQ_vMc2JYVqwfP89WOZdUF2WDtWfh7ccL1PQve=nC+zQ@mail.gmail.com>
	<OozQK1_gWeExd5578AYH_dHnSKSvx63FJc2rIBBcaJF4f07qzsR8rr-ka5epwMFCjqDuidAWZiZqqlvn4xvSuUpDY0KkV014VQs6_E3Rp_A=@protonmail.com>
	<2f2e6b7c-2d47-518a-5a8f-0b5333607aac@gmail.com>
	<lYqi6yZAdUknHWs2DvSaM3h1tf3EVLngILZV9gbVBm5JVI96RvBGZaPBEFYNzt0QBkjdJ614BTsWjUkmuuqSd7RPFx-ihUL6SIXocqyW_ss=@protonmail.com>
	<98d35291-5948-cb06-c46a-9d209276cee2@gmail.com>
	<GDZ42AMqaETJGYZovJzkVZkxZE3UmCQ8q5fFTAajV6sX2LHFol6iEYahkY_sMrPv5m11lHZvuKXmD_PwXa5_S7x18vcP1FkQr0ZBROxj6HE=@protonmail.com>
	<CAGL6+mEeuhQp3TiLFOOAWO_wcRZXsfASKNT4364SSNzER6_xgw@mail.gmail.com>
	<hvQJ5M9JSIbEjJuabefPJi_DBqDTTXYnJ1xEg7_rBozOBrI8WDzL6zwn9Zt7au5QHc3P3DPNYDBrsQCTkSB6lOFWPJ8UuY_W4GyIzQ-Qvfs=@protonmail.com>
Message-ID: <CAMZUoK==7OATOJ=46CYJWkq=WAXnJ8-JjvL25E1ijhnRbqj_Jg@mail.gmail.com>

On Wed, Jul 12, 2017 at 4:50 AM, ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

In any case, let me propose actual improvements to the OP_BRIBEVERIFY
> proposal:
>
> 1.  Remove the necessity of coinbase commitments.  The miner commits to
> the sidechain_id and h* in the transaction that pays the OP_BRIBEVERIFY
> anyway.  That way the h* commitment occurs only once in the block, in the
> transaction that does the OP_BRIBEVERIFY.  In addition, there is no need to
> impose particular ordering on the coinbase outputs, which would be
> problematic as pointed out by others, for example if the miner is
> interested only in merge mining for sidechain id #35 and nobody else.
>
> 2.  When verifying a block, keep a set of sidechain ID's.  When processing
> a transaction in that block with OP_BRIBEVERIFY, check if the sidechain ID
> is in that set.  If not in that set, add it to that set and continue script
> processing.  If already in the set, fail the script processing.  This
> ensures that at most one OP_BRIBEVERIFY exists for each sidechain_id in a
> mainchain block.
>

At this point can we eliminate the need to use the scripting system at all
and just use a special, currently non-standard, OP_RETURN output to hold
the sidechain_id and h* instead?  We can soft fork in a rule that at most
one such output can appear in a block per sidechain_id.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/d3ad9afc/attachment.html>

From dev at jonasschnelli.ch  Wed Jul 12 12:38:33 2017
From: dev at jonasschnelli.ch (Jonas Schnelli)
Date: Wed, 12 Jul 2017 14:38:33 +0200
Subject: [bitcoin-dev] A Segwit2x BIP
In-Reply-To: <7869651.CRYTeDpGy9@strawberry>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
	<CAKzdR-oRdX-fXyc6womZOyYyfHUJZdgh92FUMM8pR_QDNiJfkQ@mail.gmail.com>
	<CABm2gDo0wgqkEufKn=Z8uAsi=_6fgE=0TS6Bcr21mg3xAX7Kyw@mail.gmail.com>
	<7869651.CRYTeDpGy9@strawberry>
Message-ID: <4667A805-9C67-41A0-9A46-90C07CB2266A@jonasschnelli.ch>


> Code to support 2x (the hard fork part of the proposal) has been out and
> tested for much longer than that.

Tested? Where?
However, the hardfork part may be out there for a long time but  _is still broken_.

/jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/29aea872/attachment.sig>

From vitteaymeric at gmail.com  Wed Jul 12 15:41:15 2017
From: vitteaymeric at gmail.com (Aymeric Vitte)
Date: Wed, 12 Jul 2017 17:41:15 +0200
Subject: [bitcoin-dev] A Segwit2x BIP
In-Reply-To: <201707120106.16951.luke@dashjr.org>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
	<A7FFF8F7-9806-44F1-B68F-F83C44893365@ob1.io>
	<CAKzdR-oRdX-fXyc6womZOyYyfHUJZdgh92FUMM8pR_QDNiJfkQ@mail.gmail.com>
	<201707120106.16951.luke@dashjr.org>
Message-ID: <9f8c276d-2b9a-922e-a070-59a6f8e02563@gmail.com>



Le 12/07/2017 ? 03:06, Luke Dashjr via bitcoin-dev a ?crit :
> Even with Core's support, many people would oppose the hardfork 
> attempt, and it would fail.

Why with or without Core support are you sure that it will fail, what
can those that are opposing the hardfork attempt do (with or without
Core) and what does "fail" mean here in fact?

-- 
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms


From jtimon at jtimon.cc  Wed Jul 12 17:38:58 2017
From: jtimon at jtimon.cc (=?UTF-8?B?Sm9yZ2UgVGltw7Nu?=)
Date: Wed, 12 Jul 2017 19:38:58 +0200
Subject: [bitcoin-dev] A Segwit2x BIP
In-Reply-To: <7869651.CRYTeDpGy9@strawberry>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
	<CAKzdR-oRdX-fXyc6womZOyYyfHUJZdgh92FUMM8pR_QDNiJfkQ@mail.gmail.com>
	<CABm2gDo0wgqkEufKn=Z8uAsi=_6fgE=0TS6Bcr21mg3xAX7Kyw@mail.gmail.com>
	<7869651.CRYTeDpGy9@strawberry>
Message-ID: <CABm2gDqgve88eE4=dDD8FqGZQNNgRtOvXAhqSTWu_wy4zG+6Eg@mail.gmail.com>

On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:

On Monday, 10 July 2017 20:38:08 CEST Jorge Tim?n via bitcoin-dev wrote:
> I think anything less than 1 year after release of tested code by some
> implementation would be irresponsible for any hardfork, even a very
> simple one.

Good news!

Code to support 2x (the hard fork part of the proposal) has been out and
tested for much longer than that.


Not true. It's different code on top of segwit. The first attempt in btc1
(very recent) didn't even increased the size (because it changed the
meaningless "base size" without touching the weight limit. As for the
current code, I don't think it has been properly tested today, let alone
"for mucj longer than 1 year.
Anyway, I said, one year from tested release. Segwitx2 hasn't been
released, has it? If so, too late to discuss a bip imo, the bip may end up
being different from what has been released due to feedback (unless it is
ignored again, of course).


--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
_______________________________________________
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/20170712/a122e604/attachment-0001.html>

From chris at suredbits.com  Wed Jul 12 18:02:30 2017
From: chris at suredbits.com (Chris Stewart)
Date: Wed, 12 Jul 2017 13:02:30 -0500
Subject: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
 Merge Mined drivechains
In-Reply-To: <CAGL6+mHErvPbvKxrQkJ=DdTuzH-4Fsxh8JnnzVY16m2x6zeJFQ@mail.gmail.com>
References: <CAGL6+mHQ_vMc2JYVqwfP89WOZdUF2WDtWfh7ccL1PQve=nC+zQ@mail.gmail.com>
	<OozQK1_gWeExd5578AYH_dHnSKSvx63FJc2rIBBcaJF4f07qzsR8rr-ka5epwMFCjqDuidAWZiZqqlvn4xvSuUpDY0KkV014VQs6_E3Rp_A=@protonmail.com>
	<2f2e6b7c-2d47-518a-5a8f-0b5333607aac@gmail.com>
	<lYqi6yZAdUknHWs2DvSaM3h1tf3EVLngILZV9gbVBm5JVI96RvBGZaPBEFYNzt0QBkjdJ614BTsWjUkmuuqSd7RPFx-ihUL6SIXocqyW_ss=@protonmail.com>
	<98d35291-5948-cb06-c46a-9d209276cee2@gmail.com>
	<GDZ42AMqaETJGYZovJzkVZkxZE3UmCQ8q5fFTAajV6sX2LHFol6iEYahkY_sMrPv5m11lHZvuKXmD_PwXa5_S7x18vcP1FkQr0ZBROxj6HE=@protonmail.com>
	<CAGL6+mEeuhQp3TiLFOOAWO_wcRZXsfASKNT4364SSNzER6_xgw@mail.gmail.com>
	<hvQJ5M9JSIbEjJuabefPJi_DBqDTTXYnJ1xEg7_rBozOBrI8WDzL6zwn9Zt7au5QHc3P3DPNYDBrsQCTkSB6lOFWPJ8UuY_W4GyIzQ-Qvfs=@protonmail.com>
	<CAMZUoK==7OATOJ=46CYJWkq=WAXnJ8-JjvL25E1ijhnRbqj_Jg@mail.gmail.com>
	<CAGL6+mHErvPbvKxrQkJ=DdTuzH-4Fsxh8JnnzVY16m2x6zeJFQ@mail.gmail.com>
Message-ID: <CAGL6+mE9TF=LeNwN2a6Ky+B=jqmW=1HqGOj6bPq2G3Aq8+FZAw@mail.gmail.com>

Hi Russell/ZmnSCPxj,

I think you guys are right. The only problem I can see with it is
replaceability of the bribe transaction. If the 'Bribe' is the fee on the
transaction it isn't clear to me what the best way to replace/remove it is.

If we have the amount in the output (instead of the fee) we can construct a
contract like this

OP_IF <id> <hash> OP_BV OP_ELSE OP_DUP OP_HASH160 <pubkey hash>
OP_EQUALVERIFY OP_CHECKSIG OP_ENDIF

That way, if the miner does *not* include your bribe, he is *still*
incentived to include your redemption.

If we decide to only an OP_RETURN output, we can replace the 'bribe'
transaction with a transaction that double spends the prevout. Thus if your
'bribe' transaction is not included in a block, a miner can still include
your double spend transaction to refund yourself (and a miner gets to
collect his normal mining fee).

I'm not 100% sure if there are mempool policies that would reject this
double spend tx or not -- but I guess this is an implementation detail not
a high level design one.

Also if there is not a commitment in the coinbase transaction it may be
harder to search for drivechain commitments. I've been floating around the
idea of a 'drivechain commitment tx' so we could easily see where all of
the voting is happening for withdrawal transactions -- but that is very
much up in the air.

On Wed, Jul 12, 2017 at 1:00 PM, Chris Stewart <stewart.chris1234 at gmail.com>
wrote:

> Hi Russell/ZmnSCPxj,
>
> I think you guys are right. The only problem I can see with it is
> replaceability of the bribe transaction. If the 'Bribe' is the fee on the
> transaction it isn't clear to me what the best way to replace/remove it is.
>
> If we have the amount in the output (instead of the fee) we can construct
> a contract like this
>
> OP_IF <id> <hash> OP_BV OP_ELSE OP_DUP OP_HASH160 <pubkey hash>
> OP_EQUALVERIFY OP_CHECKSIG OP_ENDIF
>
> That way, if the miner does *not* include your bribe, he is *still*
> incentived to include your redemption.
>
> If we decide to only an OP_RETURN output, we can replace the 'bribe'
> transaction with a transaction that double spends the prevout. Thus if your
> 'bribe' transaction is not included in a block, a miner can still include
> your double spend transaction to refund yourself (and a miner gets to
> collect his normal mining fee).
>
> I'm not 100% sure if there are mempool policies that would reject this
> double spend tx or not -- but I guess this is an implementation detail not
> a high level design one.
>
> Also if there is not a commitment in the coinbase transaction it may be
> harder to search for drivechain commitments. I've been floating around the
> idea of a 'drivechain commitment tx' so we could easily see where all of
> the voting is happening for withdrawal transactions -- but that is very
> much up in the air.
>
> -Chris
>
> On Wed, Jul 12, 2017 at 8:39 AM, Russell O'Connor via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>
>>
>> On Wed, Jul 12, 2017 at 4:50 AM, ZmnSCPxj via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> In any case, let me propose actual improvements to the OP_BRIBEVERIFY
>>> proposal:
>>>
>>> 1.  Remove the necessity of coinbase commitments.  The miner commits to
>>> the sidechain_id and h* in the transaction that pays the OP_BRIBEVERIFY
>>> anyway.  That way the h* commitment occurs only once in the block, in the
>>> transaction that does the OP_BRIBEVERIFY.  In addition, there is no need to
>>> impose particular ordering on the coinbase outputs, which would be
>>> problematic as pointed out by others, for example if the miner is
>>> interested only in merge mining for sidechain id #35 and nobody else.
>>>
>>> 2.  When verifying a block, keep a set of sidechain ID's.  When
>>> processing a transaction in that block with OP_BRIBEVERIFY, check if the
>>> sidechain ID is in that set.  If not in that set, add it to that set and
>>> continue script processing.  If already in the set, fail the script
>>> processing.  This ensures that at most one OP_BRIBEVERIFY exists for each
>>> sidechain_id in a mainchain block.
>>>
>>
>> At this point can we eliminate the need to use the scripting system at
>> all and just use a special, currently non-standard, OP_RETURN output to
>> hold the sidechain_id and h* instead?  We can soft fork in a rule that at
>> most one such output can appear in a block per sidechain_id.
>>
>> _______________________________________________
>> 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/20170712/92171a60/attachment.html>

From chris at suredbits.com  Wed Jul 12 19:19:03 2017
From: chris at suredbits.com (Chris Stewart)
Date: Wed, 12 Jul 2017 14:19:03 -0500
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <D30D8852-EFF4-4AB3-9B97-53D622A1440A@taoeffect.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<A030CDEA-CB0F-40BF-9404-6BD091537BE1@taoeffect.com>
	<08078429-089f-9315-2f76-a08121c5378c@gmail.com>
	<D30D8852-EFF4-4AB3-9B97-53D622A1440A@taoeffect.com>
Message-ID: <CAGL6+mHNMF9-v_6_ruvvhOenXCCsVhoG3aHkGvioOb-a9fokCQ@mail.gmail.com>

Hi Greg,

>Here, you admit that the security of the sidechains allows miners to steal
bitcoins, something they cannot do currently.

If I put my coins in an anyone can spend output, a miner will take them.
They can do this today. I suggest you try it if you don't believe me :-).
You have to be more specific with contract types instead of generically
talking about 'all contracts ever'.

> Drivechain is an unmistakeable weakening of Bitcoin's security
guarantees. This you have not denied.

I think this is an unfair characterization. You have to opt into using
drivechains. Other outputs such as P2PKH/Multisig etc are unaffected by a
drivechain output. As Pieter Wuille stated earlier in this thread (and Paul
has stated all along), drivechain outputs have a different security model
than other contracts. Namely they are controlled by miners. I think we can
all agree this is unfortunate, but it is the current reality we live in. I
look forward to the day we can solve the 'ownership' problem so we can have
trustless interoperable blockchains, but that day is not today.

As a reminder, most users will not have to go through the drivechain
withdrawal process. Most withdrawals will be done via atomic swaps.

>There is no reason to weaken Bitcoin's security in such a dramatic
fashion. Better options are being worked on, they just take time.

Care to share? I'm unaware if there is.

>
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.html

Everyone should re-read this email though, this is something that could
happen. Paul's design makes it so that if this occurs it is *VERY* obvious.
I guess we can argue if there is any difference between an obvious robbery
vs a hidden robbery, but I think if we have to pick one or the other the
choice is clear to me. Other designs (that I'm aware of) for sidechains had
attack vectors that weren't so obvious.

-Chris



On Tue, Jul 11, 2017 at 6:12 PM, Tao Effect via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Paul,
>
> There is a difference between replying to an email, and addressing the
> issues that were brought up in it.
>
> I did read your reply, and I chose not to respond to it because it did not
> address anything I said.
>
> Here's an example:
>
> It would not be accurate to say that miners have "total" control. Miners
> do control the destination of withdrawals, but they do not control the
> withdrawal-duration nor the withdrawal-frequency.
>
> So, if miners wish to 'steal' from a sidechain, they _can_ initiate a
> theft, but they can not change the fact that their malfeasance will be
> [a] obvious, and [b] on display for a long period of time.
>
>
> Here, you admit that the security of the sidechains allows miners to steal
> bitcoins, something they cannot do currently.
>
> You next tried to equate three different types of theft, what you called
> "Classic Theft", "Channel Theft", and "Drivechain Theft", saying:
>
> I do not think that any of the three stands out as being categorically
> worse than the others
>
>
> To anyone who understands bitcoin, there is a very clear, unmistakeable
> difference between double-spending ("Classic Theft"), and *ownership* of
> the private key controlling the bitcoins.
>
> Similarly, to anyone who understands bitcoin, there is also a very clear,
> unmistakeable difference between censorship ("Channel Theft"), and
> *ownership* of the private key controlling the bitcoins.
>
> The entire email was a very long-form way of admitting to all of the
> issues that were raised in the previous email, while making it sound like
> you had addressed the issues.
>
> I am not sure how else to respond to that email, given that none of the
> issues were really addressed.
>
> Drivechain is an unmistakeable weakening of Bitcoin's security guarantees.
> This you have not denied.
>
> There is no reason to weaken Bitcoin's security in such a dramatic
> fashion. Better options are being worked on, they just take time.
>
> Kind regards,
> Greg Slepak
>
> --
> Please do not email me anything that you are not comfortable also sharing with
> the NSA.
>
> On Jul 11, 2017, at 3:57 PM, Paul Sztorc <truthcoin at gmail.com> wrote:
>
> On 7/11/2017 6:41 PM, Tao Effect wrote:
>
> Dear Paul,
>
> Drivechain has several issues that you've acknowledged but have not,
> IMO, adequately (at all really) addressed [1].
>
>
> I replied to your email at length, at [2]. You should read that email,
> and then reply to it with your outstanding objections, if you still have
> them (per the usual customs of a mailing list).
>
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-June/014609.html
>
> Adopting DC would be an irreversible course of action,
>
>
> This is false -- it is easily reversible with a second soft fork.
>
> Also, I would say to everyone that, (in my opinion as the OP) this
> conversation will go off-topic if it veers exclusively into 'drivechain
> review'.
>
> Paul
>
>
>
>
>
> _______________________________________________
> 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/20170712/828da31e/attachment-0001.html>

From contact at taoeffect.com  Wed Jul 12 19:24:28 2017
From: contact at taoeffect.com (Tao Effect)
Date: Wed, 12 Jul 2017 12:24:28 -0700
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <CAGL6+mHNMF9-v_6_ruvvhOenXCCsVhoG3aHkGvioOb-a9fokCQ@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<A030CDEA-CB0F-40BF-9404-6BD091537BE1@taoeffect.com>
	<08078429-089f-9315-2f76-a08121c5378c@gmail.com>
	<D30D8852-EFF4-4AB3-9B97-53D622A1440A@taoeffect.com>
	<CAGL6+mHNMF9-v_6_ruvvhOenXCCsVhoG3aHkGvioOb-a9fokCQ@mail.gmail.com>
Message-ID: <26FE0468-7049-4BE0-948F-D5E40FE2CBAC@taoeffect.com>

Dear Chris,

> I think this is an unfair characterization. You have to opt into using drivechains.

I have heard this nonsense repeated countless times in order to justify adopting Drivechain.

This is not how security works.

A child can "opt-in" to using a loaded gun, but is it a good idea to make it easy for them to do that?

No.

This is effectively the same thing Drivechains is doing.

It is a request to modify the Bitcoin protocol to make it easy for Bitcoin users to give their Bitcoins to miners.

Does that sound like a good idea to anyone?

If so, please leave, you are compromising Bitcoin's security.

Security is about making it difficult to shoot yourself in the face.

If I design a car that has a button that randomly causes the brakes to give out if pressed, is that a good idea? Can I justify pushing for such a "feature" just because it's "opt-in"?

No. That is fallacy.

It is not how secure systems are designed.

It is how *insecure* systems are designed.

> Care to share? I'm unaware if there is.


Sure, happy to, as soon as I have it written up in detail.

Kind regards,
Greg Slepak

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

> On Jul 12, 2017, at 12:19 PM, Chris Stewart <chris at suredbits.com <mailto:chris at suredbits.com>> wrote:
> 
> Hi Greg,
> 
> >Here, you admit that the security of the sidechains allows miners to steal bitcoins, something they cannot do currently.
> 
> If I put my coins in an anyone can spend output, a miner will take them. They can do this today. I suggest you try it if you don't believe me :-). You have to be more specific with contract types instead of generically talking about 'all contracts ever'.
> 
> > Drivechain is an unmistakeable weakening of Bitcoin's security guarantees. This you have not denied.
> 
> I think this is an unfair characterization. You have to opt into using drivechains. Other outputs such as P2PKH/Multisig etc are unaffected by a drivechain output. As Pieter Wuille stated earlier in this thread (and Paul has stated all along), drivechain outputs have a different security model than other contracts. Namely they are controlled by miners. I think we can all agree this is unfortunate, but it is the current reality we live in. I look forward to the day we can solve the 'ownership' problem so we can have trustless interoperable blockchains, but that day is not today.
> 
> As a reminder, most users will not have to go through the drivechain withdrawal process. Most withdrawals will be done via atomic swaps.
> 
> >There is no reason to weaken Bitcoin's security in such a dramatic fashion. Better options are being worked on, they just take time.
> 
> Care to share? I'm unaware if there is.
> 
> >https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.html>
> 
> Everyone should re-read this email though, this is something that could happen. Paul's design makes it so that if this occurs it is *VERY* obvious. I guess we can argue if there is any difference between an obvious robbery vs a hidden robbery, but I think if we have to pick one or the other the choice is clear to me. Other designs (that I'm aware of) for sidechains had attack vectors that weren't so obvious.
> 
> -Chris
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/f5dded92/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/f5dded92/attachment.sig>

From chris at suredbits.com  Wed Jul 12 19:34:54 2017
From: chris at suredbits.com (Chris Stewart)
Date: Wed, 12 Jul 2017 14:34:54 -0500
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <26FE0468-7049-4BE0-948F-D5E40FE2CBAC@taoeffect.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<A030CDEA-CB0F-40BF-9404-6BD091537BE1@taoeffect.com>
	<08078429-089f-9315-2f76-a08121c5378c@gmail.com>
	<D30D8852-EFF4-4AB3-9B97-53D622A1440A@taoeffect.com>
	<CAGL6+mHNMF9-v_6_ruvvhOenXCCsVhoG3aHkGvioOb-a9fokCQ@mail.gmail.com>
	<26FE0468-7049-4BE0-948F-D5E40FE2CBAC@taoeffect.com>
Message-ID: <CAGL6+mGEBhn3fjTN5APX3kQjEFjGsG_2LEL_LgXiPOP=xoAZuQ@mail.gmail.com>

Hi Greg,

The safest way to ensure everyone's protection to make sure *no one can do
anything*. Then we will ALL be safe ;).

>If so, please leave, you are compromising Bitcoin's security.

Ok, let's calm down.

>If I design a car that has a button that randomly causes the brakes to
give out if pressed, is that a good idea? Can I justify pushing for such a
"feature" just because it's "opt-in"?

It would be more like "should we allow a car on the road if we know
statistically that our brakes give out in every 1/100,000,000 cars"? There
is security risks with everything in life -- we need to quantify the risk
to see if it is worth taking. I think Paul has been pretty upfront about
the risks of his model. I think you did a good job of demonstrating it in
the email I cited too.

>It is how *insecure* systems are designed.

By your account bitcoin is already insecure then -- it allows anyone can
spend outputs that can be claimed by miners.

>Sure, happy to, as soon as I have it written up in detail.

I look forward to this!

-Chris

On Wed, Jul 12, 2017 at 2:24 PM, Tao Effect <contact at taoeffect.com> wrote:

> Dear Chris,
>
> I think this is an unfair characterization. You have to opt into using
> drivechains.
>
>
> I have heard this nonsense repeated countless times in order to justify
> adopting Drivechain.
>
> This is not how security works.
>
> A child can "opt-in" to using a loaded gun, but is it a good idea to make
> it easy for them to do that?
>
> No.
>
> This is effectively the same thing Drivechains is doing.
>
> It is a request to modify the Bitcoin protocol to make it easy for Bitcoin
> users to give their Bitcoins to miners.
>
> Does that sound like a good idea to anyone?
>
> If so, please leave, you are compromising Bitcoin's security.
>
> Security is about making it difficult to shoot yourself in the face.
>
> If I design a car that has a button that randomly causes the brakes to
> give out if pressed, is that a good idea? Can I justify pushing for such a
> "feature" just because it's "opt-in"?
>
> No. That is fallacy.
>
> It is not how secure systems are designed.
>
> It is how *insecure* systems are designed.
>
> Care to share? I'm unaware if there is.
>
>
> Sure, happy to, as soon as I have it written up in detail.
>
> Kind regards,
> Greg Slepak
>
> --
> Please do not email me anything that you are not comfortable also sharing with
> the NSA.
>
> On Jul 12, 2017, at 12:19 PM, Chris Stewart <chris at suredbits.com> wrote:
>
> Hi Greg,
>
> >Here, you admit that the security of the sidechains allows miners to
> steal bitcoins, something they cannot do currently.
>
> If I put my coins in an anyone can spend output, a miner will take them.
> They can do this today. I suggest you try it if you don't believe me :-).
> You have to be more specific with contract types instead of generically
> talking about 'all contracts ever'.
>
> > Drivechain is an unmistakeable weakening of Bitcoin's security
> guarantees. This you have not denied.
>
> I think this is an unfair characterization. You have to opt into using
> drivechains. Other outputs such as P2PKH/Multisig etc are unaffected by a
> drivechain output. As Pieter Wuille stated earlier in this thread (and Paul
> has stated all along), drivechain outputs have a different security model
> than other contracts. Namely they are controlled by miners. I think we can
> all agree this is unfortunate, but it is the current reality we live in. I
> look forward to the day we can solve the 'ownership' problem so we can have
> trustless interoperable blockchains, but that day is not today.
>
> As a reminder, most users will not have to go through the drivechain
> withdrawal process. Most withdrawals will be done via atomic swaps.
>
> >There is no reason to weaken Bitcoin's security in such a dramatic
> fashion. Better options are being worked on, they just take time.
>
> Care to share? I'm unaware if there is.
>
> >https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.
> html
>
> Everyone should re-read this email though, this is something that could
> happen. Paul's design makes it so that if this occurs it is *VERY* obvious.
> I guess we can argue if there is any difference between an obvious robbery
> vs a hidden robbery, but I think if we have to pick one or the other the
> choice is clear to me. Other designs (that I'm aware of) for sidechains had
> attack vectors that weren't so obvious.
>
> -Chris
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/8a7ab3dc/attachment-0001.html>

From contact at taoeffect.com  Wed Jul 12 19:42:49 2017
From: contact at taoeffect.com (Tao Effect)
Date: Wed, 12 Jul 2017 12:42:49 -0700
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <CAGL6+mGEBhn3fjTN5APX3kQjEFjGsG_2LEL_LgXiPOP=xoAZuQ@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<A030CDEA-CB0F-40BF-9404-6BD091537BE1@taoeffect.com>
	<08078429-089f-9315-2f76-a08121c5378c@gmail.com>
	<D30D8852-EFF4-4AB3-9B97-53D622A1440A@taoeffect.com>
	<CAGL6+mHNMF9-v_6_ruvvhOenXCCsVhoG3aHkGvioOb-a9fokCQ@mail.gmail.com>
	<26FE0468-7049-4BE0-948F-D5E40FE2CBAC@taoeffect.com>
	<CAGL6+mGEBhn3fjTN5APX3kQjEFjGsG_2LEL_LgXiPOP=xoAZuQ@mail.gmail.com>
Message-ID: <18A9E11A-07B2-48B4-B4E7-66A563A97A13@taoeffect.com>

> I think Paul has been pretty upfront about the risks of his model.

I think he has been rather misleading in his presentation of the risks.

He outlines them in a very technical manner, yes, but then goes on to promote them to lay people as if they're no big deal, which is completely misleading.

> By your account bitcoin is already insecure then -- it allows anyone can spend outputs that can be claimed by miners.

That is completely different.

It is disingenuous to say the two are remotely similar. The two situations have little-to-nothing in common.

In the present situation, anyone-can-spend outputs are used by probably less than 0.1% of users, and most software doesn't even allow for the possibility.

In Drivechain it's *encouraged-by-design*!

- Greg

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

> On Jul 12, 2017, at 12:34 PM, Chris Stewart <chris at suredbits.com <mailto:chris at suredbits.com>> wrote:
> 
> Hi Greg,
> 
> The safest way to ensure everyone's protection to make sure *no one can do anything*. Then we will ALL be safe ;).
> 
> >If so, please leave, you are compromising Bitcoin's security.
> 
> Ok, let's calm down.
> 
> >If I design a car that has a button that randomly causes the brakes to give out if pressed, is that a good idea? Can I justify pushing for such a "feature" just because it's "opt-in"?
> 
> It would be more like "should we allow a car on the road if we know statistically that our brakes give out in every 1/100,000,000 cars"? There is security risks with everything in life -- we need to quantify the risk to see if it is worth taking. I think Paul has been pretty upfront about the risks of his model. I think you did a good job of demonstrating it in the email I cited too.
> 
> >It is how *insecure* systems are designed.
> 
> By your account bitcoin is already insecure then -- it allows anyone can spend outputs that can be claimed by miners.
> 
> >Sure, happy to, as soon as I have it written up in detail.
> 
> I look forward to this!
> 
> -Chris
> 
> On Wed, Jul 12, 2017 at 2:24 PM, Tao Effect <contact at taoeffect.com <mailto:contact at taoeffect.com>> wrote:
> Dear Chris,
> 
>> I think this is an unfair characterization. You have to opt into using drivechains.
> 
> I have heard this nonsense repeated countless times in order to justify adopting Drivechain.
> 
> This is not how security works.
> 
> A child can "opt-in" to using a loaded gun, but is it a good idea to make it easy for them to do that?
> 
> No.
> 
> This is effectively the same thing Drivechains is doing.
> 
> It is a request to modify the Bitcoin protocol to make it easy for Bitcoin users to give their Bitcoins to miners.
> 
> Does that sound like a good idea to anyone?
> 
> If so, please leave, you are compromising Bitcoin's security.
> 
> Security is about making it difficult to shoot yourself in the face.
> 
> If I design a car that has a button that randomly causes the brakes to give out if pressed, is that a good idea? Can I justify pushing for such a "feature" just because it's "opt-in"?
> 
> No. That is fallacy.
> 
> It is not how secure systems are designed.
> 
> It is how *insecure* systems are designed.
> 
>> Care to share? I'm unaware if there is.
> 
> 
> Sure, happy to, as soon as I have it written up in detail.
> 
> Kind regards,
> Greg Slepak
> 
> --
> Please do not email me anything that you are not comfortable also sharing with the NSA.
> 
>> On Jul 12, 2017, at 12:19 PM, Chris Stewart <chris at suredbits.com <mailto:chris at suredbits.com>> wrote:
>> 
>> Hi Greg,
>> 
>> >Here, you admit that the security of the sidechains allows miners to steal bitcoins, something they cannot do currently.
>> 
>> If I put my coins in an anyone can spend output, a miner will take them. They can do this today. I suggest you try it if you don't believe me :-). You have to be more specific with contract types instead of generically talking about 'all contracts ever'.
>> 
>> > Drivechain is an unmistakeable weakening of Bitcoin's security guarantees. This you have not denied.
>> 
>> I think this is an unfair characterization. You have to opt into using drivechains. Other outputs such as P2PKH/Multisig etc are unaffected by a drivechain output. As Pieter Wuille stated earlier in this thread (and Paul has stated all along), drivechain outputs have a different security model than other contracts. Namely they are controlled by miners. I think we can all agree this is unfortunate, but it is the current reality we live in. I look forward to the day we can solve the 'ownership' problem so we can have trustless interoperable blockchains, but that day is not today.
>> 
>> As a reminder, most users will not have to go through the drivechain withdrawal process. Most withdrawals will be done via atomic swaps.
>> 
>> >There is no reason to weaken Bitcoin's security in such a dramatic fashion. Better options are being worked on, they just take time.
>> 
>> Care to share? I'm unaware if there is.
>> 
>> >https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.html>
>> 
>> Everyone should re-read this email though, this is something that could happen. Paul's design makes it so that if this occurs it is *VERY* obvious. I guess we can argue if there is any difference between an obvious robbery vs a hidden robbery, but I think if we have to pick one or the other the choice is clear to me. Other designs (that I'm aware of) for sidechains had attack vectors that weren't so obvious.
>> 
>> -Chris
>> 
>> 
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/3f3a9f44/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/3f3a9f44/attachment.sig>

From cryptaxe at gmail.com  Wed Jul 12 19:54:48 2017
From: cryptaxe at gmail.com (CryptAxe)
Date: Wed, 12 Jul 2017 12:54:48 -0700
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <18A9E11A-07B2-48B4-B4E7-66A563A97A13@taoeffect.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<A030CDEA-CB0F-40BF-9404-6BD091537BE1@taoeffect.com>
	<08078429-089f-9315-2f76-a08121c5378c@gmail.com>
	<D30D8852-EFF4-4AB3-9B97-53D622A1440A@taoeffect.com>
	<CAGL6+mHNMF9-v_6_ruvvhOenXCCsVhoG3aHkGvioOb-a9fokCQ@mail.gmail.com>
	<26FE0468-7049-4BE0-948F-D5E40FE2CBAC@taoeffect.com>
	<CAGL6+mGEBhn3fjTN5APX3kQjEFjGsG_2LEL_LgXiPOP=xoAZuQ@mail.gmail.com>
	<18A9E11A-07B2-48B4-B4E7-66A563A97A13@taoeffect.com>
Message-ID: <37ed4927-d13b-f34d-a13c-9aaa55ea426b@gmail.com>

Are we just pulling numbers out of thin air now? https://p2sh.info/
BIP16 for example is widely used. It would be difficult to find a single
wallet that doesn't support BIP16 I have no idea what you are talking about.


On 07/12/2017 12:42 PM, Tao Effect via bitcoin-dev wrote:
> ...
> In the present situation, anyone-can-spend outputs are used by
> probably less than 0.1% of users, and most software doesn't even allow
> for the possibility.
>
> In Drivechain it's *encouraged-by-design*!
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also
> sharing with the NSA.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/a11413d2/attachment-0001.html>

From cryptaxe at gmail.com  Wed Jul 12 22:07:47 2017
From: cryptaxe at gmail.com (CryptAxe)
Date: Wed, 12 Jul 2017 15:07:47 -0700
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <2AB8B976-5E62-4B1A-9B1B-0109EA4F606F@taoeffect.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<A030CDEA-CB0F-40BF-9404-6BD091537BE1@taoeffect.com>
	<08078429-089f-9315-2f76-a08121c5378c@gmail.com>
	<D30D8852-EFF4-4AB3-9B97-53D622A1440A@taoeffect.com>
	<CAGL6+mHNMF9-v_6_ruvvhOenXCCsVhoG3aHkGvioOb-a9fokCQ@mail.gmail.com>
	<26FE0468-7049-4BE0-948F-D5E40FE2CBAC@taoeffect.com>
	<CAGL6+mGEBhn3fjTN5APX3kQjEFjGsG_2LEL_LgXiPOP=xoAZuQ@mail.gmail.com>
	<18A9E11A-07B2-48B4-B4E7-66A563A97A13@taoeffect.com>
	<37ed4927-d13b-f34d-a13c-9aaa55ea426b@gmail.com>
	<2AB8B976-5E62-4B1A-9B1B-0109EA4F606F@taoeffect.com>
Message-ID: <c7ffff44-10f2-51c6-17d6-7f00b8c09c4f@gmail.com>

You guys are both right that it is a different security model, with the
important distinction that it is opt-in. What I disagree with about what
you said is only that we are encouraging more risky behavior by adding
consensus rules via softfork. There are additional risks with
drivechains, but not because of how the new consensus rules would be
added (it would be the same risk as the P2SH softfork).

What's been explained to me a few times is that the
anyone-can-spend-ness of new transaction types that depend on softforked
consensus rules are exponentially less risky to the point that it is
infeasible to steal them as blocks are added to the chain that activated
the soft fork. I believe that Luke-Jr and Lopp are both very good at
explaining this and I know that Lopp has actually done some research as
to the cost of stealing these outputs. I can't remember the link but you
might find that with a google. One of them might even chime in and
explain that I'm totally wrong again!

Sorry for being a bit heated in my last response.


On 07/12/2017 02:55 PM, Tao Effect wrote:

> That's a fair point, I confused anyone-can-spend with anyone-can-pay [1].
>
> Isn't it different in the case of P2SH and SegWit, don't full nodes
> validate the script?
>
> In other words, miners don't have complete control over the coins,
> full nodes keep a check on them.
>
> At least that was my understanding, and if that's not the case then it
> doesn't make sense to me why Pieter would earlier in this thread
> object to Drivechain on the grounds that it's a different security model.
>
> - Greg
>
> [1] https://steemit.com/bitcoin/@jl777/bitcoin-spinoff-fork-how-to-make-a-clean-fork-without-any-replay-attack-and-no-blockchain-visible-changes
>
>
> --
> Please do not email me anything that you are not comfortable also
> sharing with the NSA.
>
>> On Jul 12, 2017, at 12:54 PM, CryptAxe via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> Are we just pulling numbers out of thin air now? https://p2sh.info/
>> BIP16 for example is widely used. It would be difficult to find a
>> single wallet that doesn't support BIP16 I have no idea what you are
>> talking about.
>>
>>
>> On 07/12/2017 12:42 PM, Tao Effect via bitcoin-dev wrote:
>>> ...
>>> In the present situation, anyone-can-spend outputs are used by
>>> probably less than 0.1% of users, and most software doesn't even
>>> allow for the possibility.
>>>
>>> In Drivechain it's *encouraged-by-design*!
>>>
>>> - Greg
>>>
>>> --
>>> 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/c5024186/attachment.html>

From contact at taoeffect.com  Wed Jul 12 21:55:39 2017
From: contact at taoeffect.com (Tao Effect)
Date: Wed, 12 Jul 2017 14:55:39 -0700
Subject: [bitcoin-dev] Updating the Scaling Roadmap
In-Reply-To: <37ed4927-d13b-f34d-a13c-9aaa55ea426b@gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<A030CDEA-CB0F-40BF-9404-6BD091537BE1@taoeffect.com>
	<08078429-089f-9315-2f76-a08121c5378c@gmail.com>
	<D30D8852-EFF4-4AB3-9B97-53D622A1440A@taoeffect.com>
	<CAGL6+mHNMF9-v_6_ruvvhOenXCCsVhoG3aHkGvioOb-a9fokCQ@mail.gmail.com>
	<26FE0468-7049-4BE0-948F-D5E40FE2CBAC@taoeffect.com>
	<CAGL6+mGEBhn3fjTN5APX3kQjEFjGsG_2LEL_LgXiPOP=xoAZuQ@mail.gmail.com>
	<18A9E11A-07B2-48B4-B4E7-66A563A97A13@taoeffect.com>
	<37ed4927-d13b-f34d-a13c-9aaa55ea426b@gmail.com>
Message-ID: <2AB8B976-5E62-4B1A-9B1B-0109EA4F606F@taoeffect.com>

That's a fair point, I confused anyone-can-spend with anyone-can-pay [1].

Isn't it different in the case of P2SH and SegWit, don't full nodes validate the script?

In other words, miners don't have complete control over the coins, full nodes keep a check on them.

At least that was my understanding, and if that's not the case then it doesn't make sense to me why Pieter would earlier in this thread object to Drivechain on the grounds that it's a different security model.

- Greg

[1] https://steemit.com/bitcoin/@jl777/bitcoin-spinoff-fork-how-to-make-a-clean-fork-without-any-replay-attack-and-no-blockchain-visible-changes <https://steemit.com/bitcoin/@jl777/bitcoin-spinoff-fork-how-to-make-a-clean-fork-without-any-replay-attack-and-no-blockchain-visible-changes>

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

> On Jul 12, 2017, at 12:54 PM, CryptAxe via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> 
> Are we just pulling numbers out of thin air now? https://p2sh.info/ <https://p2sh.info/> BIP16 for example is widely used. It would be difficult to find a single wallet that doesn't support BIP16 I have no idea what you are talking about.
> 
> On 07/12/2017 12:42 PM, Tao Effect via bitcoin-dev wrote:
>> ...
>> In the present situation, anyone-can-spend outputs are used by probably less than 0.1% of users, and most software doesn't even allow for the possibility.
>> 
>> In Drivechain it's *encouraged-by-design*!
>> 
>> - Greg
>> 
>> --
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/a5ecbb2f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/a5ecbb2f/attachment-0001.sig>

From contact at taoeffect.com  Wed Jul 12 22:43:31 2017
From: contact at taoeffect.com (Tao Effect)
Date: Wed, 12 Jul 2017 15:43:31 -0700
Subject: [bitcoin-dev] Drivechain RfD -- Follow Up
In-Reply-To: <6764b8af-bb4c-615d-5af5-462127bbbe36@gmail.com>
References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com>
	<83671224-f6ff-16a9-81c0-20ab578aec9d@gmail.com>
	<AAC86547-7904-4475-9966-138130019567@taoeffect.com>
	<6764b8af-bb4c-615d-5af5-462127bbbe36@gmail.com>
Message-ID: <F2C3A9F4-07AB-41B9-B915-9E33EE313F9E@taoeffect.com>

Paul,

I'm assuming it's OK with you that I pick up from where we left off in the "Scaling Roadmap" thread [1], so as to be on-topic per your request. (For others reading, part of my reply to the previous email in this thread is here [2]).

For reference, I said:

> Isn't it different in the case of P2SH and SegWit, don't full nodes validate the script?
> 
> In other words, miners don't have complete control over the coins, full nodes keep a check on them.
> 
> At least that was my understanding, and if that's not the case then it doesn't make sense to me why Pieter would earlier in this thread object to Drivechain on the grounds that it's a different security model.


CryptAxe's response was in part:
> You guys are both right that it is a different security model, with the important distinction that it is opt-in. What I disagree with about what you said is only that we are encouraging more risky behavior by adding consensus rules via softfork. There are additional risks with drivechains, but not because of how the new consensus rules would be added (it would be the same risk as the P2SH softfork).


I am now looking closer again at step number 4 in the Drivechain specification [2]:

4. Everyone waits for a period of, say, 3 days. This gives everyone an opportunity to make sure the same WT^ is in both the Bitcoin coinbase and the Sidechain header. If they?re different, everyone has plenty of time to contact each other, figure out what is going on, and restart the process until its right.


It seems to me that where our disagreement lies is in this point.

The Drivechain spec seems to claim that its use of anyone-can-pay is the same as P2SH (and in later emails you reference SegWit as well). Is this really true?

The following suggests to me it isn't:

1. Pieter Wuille's email suggests he disagrees [4]

2. Per the question in [1], it's my understanding that P2SH transactions contain all of the information within themselves for full nodes to act as a check on miners mishandling the anyone-can-spend nature of P2SH transactions. However, that does not seem to be the case with WT^ transactions.


In P2SH txns, there is no need for anyone to, as the Drivechain spec says, "to contact each other, figure out what is going on". Everything just automatically works.


If the security of WT^ transactions could be brought up to actually be in line with the security of P2SH and SegWit transactions, then I would have far less to object to.

Kind regards,
Greg Slepak


[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014763.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014763.html>
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014745.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014745.html>
[3] http://www.truthcoin.info/blog/drivechain/ <http://www.truthcoin.info/blog/drivechain/>
[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014721.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014721.html>

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

> On Jun 19, 2017, at 9:04 AM, Paul Sztorc <truthcoin at gmail.com <mailto:truthcoin at gmail.com>> wrote:
> 
> Hi Greg,
> 
> Responses below:
> 
> On 6/18/2017 5:30 PM, Tao Effect wrote:
>> In Drivechain, 51% of miners have total control and ownership over all
>> of the sidechain coins.
> 
> It would not be accurate to say that miners have "total" control. Miners
> do control the destination of withdrawals, but they do not control the
> withdrawal-duration nor the withdrawal-frequency.
> 

[ ...snip.. ]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/d949a60c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/d949a60c/attachment.sig>

From truthcoin at gmail.com  Wed Jul 12 23:31:18 2017
From: truthcoin at gmail.com (Paul Sztorc)
Date: Wed, 12 Jul 2017 19:31:18 -0400
Subject: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
 Merge Mined drivechains
In-Reply-To: <hvQJ5M9JSIbEjJuabefPJi_DBqDTTXYnJ1xEg7_rBozOBrI8WDzL6zwn9Zt7au5QHc3P3DPNYDBrsQCTkSB6lOFWPJ8UuY_W4GyIzQ-Qvfs=@protonmail.com>
References: <CAGL6+mHQ_vMc2JYVqwfP89WOZdUF2WDtWfh7ccL1PQve=nC+zQ@mail.gmail.com>
	<OozQK1_gWeExd5578AYH_dHnSKSvx63FJc2rIBBcaJF4f07qzsR8rr-ka5epwMFCjqDuidAWZiZqqlvn4xvSuUpDY0KkV014VQs6_E3Rp_A=@protonmail.com>
	<2f2e6b7c-2d47-518a-5a8f-0b5333607aac@gmail.com>
	<lYqi6yZAdUknHWs2DvSaM3h1tf3EVLngILZV9gbVBm5JVI96RvBGZaPBEFYNzt0QBkjdJ614BTsWjUkmuuqSd7RPFx-ihUL6SIXocqyW_ss=@protonmail.com>
	<98d35291-5948-cb06-c46a-9d209276cee2@gmail.com>
	<GDZ42AMqaETJGYZovJzkVZkxZE3UmCQ8q5fFTAajV6sX2LHFol6iEYahkY_sMrPv5m11lHZvuKXmD_PwXa5_S7x18vcP1FkQr0ZBROxj6HE=@protonmail.com>
	<CAGL6+mEeuhQp3TiLFOOAWO_wcRZXsfASKNT4364SSNzER6_xgw@mail.gmail.com>
	<hvQJ5M9JSIbEjJuabefPJi_DBqDTTXYnJ1xEg7_rBozOBrI8WDzL6zwn9Zt7au5QHc3P3DPNYDBrsQCTkSB6lOFWPJ8UuY_W4GyIzQ-Qvfs=@protonmail.com>
Message-ID: <7e1d2d0a-d39b-2c97-c624-a6d0562f3843@gmail.com>

On 7/12/2017 4:50 AM, ZmnSCPxj wrote:
>
> >>In my scheme, if you read carefully through the pseudocode, a block
> list node is valid only if its block is valid.
> >
> >It seems this is a contradiction against the "blind" part of blind
> merge mining. How can a bitcoin blockchain node enforce this without
> tracking the sidechain?
>
> From:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014668.html
> >>>>2. When a sidechain-node wants to know the consensus, it downloads
> mainchain-blocks and looks for OP_RETURN's.
> >>>>2.1. Starting with its genesis cons-pair hash (equivalent to the
> empty list) as the current cons-pair, it scans each OP_RETURN transaction.
> >>>>2.1.1. If an OP_RETURN is 64-byte and has the parent cons-pair
> equal to the current cons-pair, look for the side block indicated and
> confirm its correctness. If correct, update the current cons-pair for
> the hash of the OP_RETURN data.
> >>>>2.2. When reaching the latest mainchain block, the current
> cons-pair is now the sidecoin/altcoin latest block.
> >>>>2.3. Note that if multiple OP_RETURN in a block match the current
> cons-pair, the first one is considered the correct chain. This
> property means that the sidechain/altchain can only have a chainsplit
> if the mainchain has a chainsplit.
>
> It's the sidechain node which needs to learn about the sidechain
> blockchain anyway.  So it's the one that does the checking of this.
>
> For that matter, a mainchain miner can be bribed to commit to a random
> number rather than a valid h* block, and it will still lead all the
> sidechain nodes on a random chase to look for the indicated block.

I do agree with this description. And I am not exactly comfortable with
it, but theoretically the random chase would serve no direct benefit to
any attacker (and thus be a ~purposeless use of attacker's money), and
empirically I do not recall anyone complaining about this happening in
Namecoin. And I think it is generally agreed that low-conf transactions
are of categorically lower reliability -- and therefore that we are
relatively less interested in taking care of users who want the
blockchain to provide them with...immediate gratification (for lack of a
better term).


> >I'll follow your discussion with Paul about sidechain reorgs, but I
> think his proposal is more desirable -- it follows what actually
> happens in the bitcoin mining process where we *can* have chain splits
> when
> >miners simultaneously find a block. Other miners will pick one of the
> two blocks to mine on top of and eventually one chain will become
> longer than the other. Therefore that chain will have it's block's
> >orphaned and the miners/nodes following the dead chain will reorg on
> top of the longest chain.
>
> In this paper:
> http://diyhpl.us/~bryan/papers2/bitcoin/On%20the%20instability%20of%20Bitcoin%20without%20the%20block%20reward%20-%202016.pdf
> <http://diyhpl.us/%7Ebryan/papers2/bitcoin/On%20the%20instability%20of%20Bitcoin%20without%20the%20block%20reward%20-%202016.pdf>
>
> As far as I understood that paper, it means that if the block reward
> no longer exists, miners can profitably attempt to undercut any full
> blocks.
>
> Sidechains do not have block rewards (unless the sidechain issues its
> own asset type that is separate from and not convertible to mainchain
> bitcoins).
>
> Thus, to protect against undercutting attacks in the sidechain, we
> would need to ensure that the sidechain cannot be reorged without the
> mainchain (which currently still has a block reward) being reorged.
>
> At least, this is my consideration.  Perhaps the paper is wrong?

Yes, it is a valid concern. I'm glad you brought this up. My view is
that there will be no undercutting attempts in the future, if Bitcoin is
popular enough and transactions are constantly arriving.

In short, the reason I feel that way is because miners will be both [1]
willing and [2] able, to maximize their fee income by imposing a
blocksize limit on themselves. They would do this by orphaning
non-compliants -- this would be something softfork-esque, but not
necessarily enforced by non-mining nodes as it is limited to miner
tx-acceptance policy.

Here is a link to a presentation of my thoughts on the issue:
https://www.youtube.com/watch?v=YErLEuOi3xU&list=PLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=4

As I say there, I believe that miners currently have no significant
reason to fee-maximize today, which is why we haven't seen this
behavior. (Also, someone would need to write the fee-maximization code
for this, and that not only would take time, but it would require a
person with a very complex intersection of skills.)

The paper you mention was written 1.5 months after my presentation was
recorded. My conclusion contradicts the first sentence of the last
paragraph of "3.1 Model of the system" which reads: "We also assume that
miners always have space to include all available transactions." In my
model miners do NOT always (or, really, ever) have space to include all
available transactions. And miners are happy that they do not, because
all of them make more total money as a result (both per block and overall).

I think the arguments of the presentation were original, so I would be
grateful to you if you offered me your thoughts on it.


> In any case, let me propose actual improvements to the OP_BRIBEVERIFY
> proposal:
>
> 1.  Remove the necessity of coinbase commitments.  The miner commits
> to the sidechain_id and h* in the transaction that pays the
> OP_BRIBEVERIFY anyway.  That way the h* commitment occurs only once in
> the block, in the transaction that does the OP_BRIBEVERIFY.  In
> addition, there is no need to impose particular ordering on the
> coinbase outputs, which would be problematic as pointed out by others,
> for example if the miner is interested only in merge mining for
> sidechain id #35 and nobody else.

I don't understand the word "anyway" in the second sentence. Is that a
summary of my proposal, or an assertion of yours. Because as it stands,
the bribe part is quite optional -- miners could just mine both chains
themselves, and then they would know which h* to include, paying
themselves the sidechain's tx fees. (Of course, under what you propose
here, miners could also mine it themselves, by placing it in an
OP_BRIBEVERIFY). However, if it is limited to a coinbase, then there is
at most only 1 hash to process every 10 minutes, which I think is desirable.

I like your idea as it is simpler. But a second concern I have is that
if a sidechain user wants to use SPV mode, the software will want to
know exactly where to find the sidechain headers. If they are always in
a known part of the coinbase, then the spv sidechain wallet knows where
to look.

Re: impose ordering on coinbase outputs, what do you think of a scheme
which searches index 1 for an OP RETURN, and if it finds something it
interprets that as the root hash of merkle tree of merged mined
sidechain h*'s ? If it doesn't find a hash commitment in index 1 it just
assumes that no sidechains were mined in this ~10 minute period.

> 2.  When verifying a block, keep a set of sidechain ID's.  When
> processing a transaction in that block with OP_BRIBEVERIFY, check if
> the sidechain ID is in that set.  If not in that set, add it to that
> set and continue script processing.  If already in the set, fail the
> script processing.  This ensures that at most one OP_BRIBEVERIFY
> exists for each sidechain_id in a mainchain block.
>
> 3.  Don't number sidechain_id from 0, 1, 2, 3..., because people will
> fight over the small numbers.  Instead identify sidechains by, for
> example, the hash of their names or the hash of their genesis block or
> whatever.  This allows true permissionless creation of sidechains,
> without some authority existing that centrally allocates sidechain ID's.

I am actually not in favor of permiessionless creation of sidechains,
because the sidechains can interfere with each other to a degree that
impacts their usefulness. We do not allow "permissionless creation of
transactions", because we do not allow invalid or double-spent
transactions. I feel the same logic should apply to the chains themselves.

Another youtube presenation about this:
https://www.youtube.com/watch?v=xGu0o8HH10U&list=PLw8-6ARlyVciMH79ZyLOpImsMug3LgNc4&index=1
(Much shorter) written post: http://www.truthcoin.info/blog/wise-contracts/

That said, I am fully in favor of forcing the sidechain's permanent
deposit address to be equal to some deterministic function of the sha256
hash of its version 0.1 release.

Paul


From truthcoin at gmail.com  Thu Jul 13 00:00:29 2017
From: truthcoin at gmail.com (Paul Sztorc)
Date: Wed, 12 Jul 2017 20:00:29 -0400
Subject: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
 Merge Mined drivechains
In-Reply-To: <CAGL6+mE9TF=LeNwN2a6Ky+B=jqmW=1HqGOj6bPq2G3Aq8+FZAw@mail.gmail.com>
References: <CAGL6+mHQ_vMc2JYVqwfP89WOZdUF2WDtWfh7ccL1PQve=nC+zQ@mail.gmail.com>
	<OozQK1_gWeExd5578AYH_dHnSKSvx63FJc2rIBBcaJF4f07qzsR8rr-ka5epwMFCjqDuidAWZiZqqlvn4xvSuUpDY0KkV014VQs6_E3Rp_A=@protonmail.com>
	<2f2e6b7c-2d47-518a-5a8f-0b5333607aac@gmail.com>
	<lYqi6yZAdUknHWs2DvSaM3h1tf3EVLngILZV9gbVBm5JVI96RvBGZaPBEFYNzt0QBkjdJ614BTsWjUkmuuqSd7RPFx-ihUL6SIXocqyW_ss=@protonmail.com>
	<98d35291-5948-cb06-c46a-9d209276cee2@gmail.com>
	<GDZ42AMqaETJGYZovJzkVZkxZE3UmCQ8q5fFTAajV6sX2LHFol6iEYahkY_sMrPv5m11lHZvuKXmD_PwXa5_S7x18vcP1FkQr0ZBROxj6HE=@protonmail.com>
	<CAGL6+mEeuhQp3TiLFOOAWO_wcRZXsfASKNT4364SSNzER6_xgw@mail.gmail.com>
	<hvQJ5M9JSIbEjJuabefPJi_DBqDTTXYnJ1xEg7_rBozOBrI8WDzL6zwn9Zt7au5QHc3P3DPNYDBrsQCTkSB6lOFWPJ8UuY_W4GyIzQ-Qvfs=@protonmail.com>
	<CAMZUoK==7OATOJ=46CYJWkq=WAXnJ8-JjvL25E1ijhnRbqj_Jg@mail.gmail.com>
	<CAGL6+mHErvPbvKxrQkJ=DdTuzH-4Fsxh8JnnzVY16m2x6zeJFQ@mail.gmail.com>
	<CAGL6+mE9TF=LeNwN2a6Ky+B=jqmW=1HqGOj6bPq2G3Aq8+FZAw@mail.gmail.com>
Message-ID: <7fc82c47-c03a-f489-55c2-b7d6830c1a74@gmail.com>

I still think it may be more inefficient, in equilibrium. (In other
words, in the future steady state of Bitcoin that includes LN or
something LN-like).

Assume there are N sidechains.

In the coinbase version:
1. There is some single event, per N, that causes nodes to notice that a
new sidechain has been created.
2. Per block, there are N hash commitments (32 bytes) and N instances of
the ratchet's block counter (2 bytes).
3. Per block, some node operator _may_ have BMMed the block, and a miner
therefore might want redeem an OP Bribe that pays BTC from a sidechain
node operator to the miner. But they are likely to negotiate the payment
through the Lightning Network (when this is possible).
4. Sidechains running in SPV mode know exactly where to find the
information they need in order to discover the "longest" chain.

In the OP RETURN version:
1. [same] There is some single event, per N, that causes nodes to notice
that a new sidechain has been created.
2. [+30 bytes (+more?)] Per block, there are N hash commitments (32
bytes) and also N prevBlockHashes (32 bytes). Also, to make this
transaction, someone needs to spend something in the UTXO set (or select
no inputs in a kind of 'hollow transaction'), whereas one coinbase will
always exist per block.
3. [same] No need for a new transaction.
4. [same?] Due to Rusty's soft fork rule of only one h* per sidechain
per block, sidechains need just a merkle tree path, but they don't
necessarily know where it is. They must store extra [?] data to help
them find the data's location?


On 7/12/2017 2:02 PM, Chris Stewart via bitcoin-dev wrote:
> Hi Russell/ZmnSCPxj,
>
> I think you guys are right. The only problem I can see with it is
> replaceability of the bribe transaction. If the 'Bribe' is the fee on
> the transaction it isn't clear to me what the best way to
> replace/remove it is.

I think that that is the purpose of Rusty's soft fork rule about only
including one per sidechain -- miners would have one "slot" per
sidechain, and they would therefore have an incentive to make the slot
count, and would be only selecting the highest fee txn to fill each slot.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/589abaa0/attachment.html>

From cryptaxe at gmail.com  Wed Jul 12 23:58:07 2017
From: cryptaxe at gmail.com (CryptAxe)
Date: Wed, 12 Jul 2017 16:58:07 -0700
Subject: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
 Merge Mined drivechains
In-Reply-To: <CAF5CFkg+mJQ75ps7f3Xa=j2eBDoNwFEdL-vFrFV5y_FqF3qGRA@mail.gmail.com>
References: <CAGL6+mHQ_vMc2JYVqwfP89WOZdUF2WDtWfh7ccL1PQve=nC+zQ@mail.gmail.com>
	<OozQK1_gWeExd5578AYH_dHnSKSvx63FJc2rIBBcaJF4f07qzsR8rr-ka5epwMFCjqDuidAWZiZqqlvn4xvSuUpDY0KkV014VQs6_E3Rp_A=@protonmail.com>
	<2f2e6b7c-2d47-518a-5a8f-0b5333607aac@gmail.com>
	<lYqi6yZAdUknHWs2DvSaM3h1tf3EVLngILZV9gbVBm5JVI96RvBGZaPBEFYNzt0QBkjdJ614BTsWjUkmuuqSd7RPFx-ihUL6SIXocqyW_ss=@protonmail.com>
	<98d35291-5948-cb06-c46a-9d209276cee2@gmail.com>
	<GDZ42AMqaETJGYZovJzkVZkxZE3UmCQ8q5fFTAajV6sX2LHFol6iEYahkY_sMrPv5m11lHZvuKXmD_PwXa5_S7x18vcP1FkQr0ZBROxj6HE=@protonmail.com>
	<CAGL6+mEeuhQp3TiLFOOAWO_wcRZXsfASKNT4364SSNzER6_xgw@mail.gmail.com>
	<hvQJ5M9JSIbEjJuabefPJi_DBqDTTXYnJ1xEg7_rBozOBrI8WDzL6zwn9Zt7au5QHc3P3DPNYDBrsQCTkSB6lOFWPJ8UuY_W4GyIzQ-Qvfs=@protonmail.com>
	<7e1d2d0a-d39b-2c97-c624-a6d0562f3843@gmail.com>
	<CAF5CFkg+mJQ75ps7f3Xa=j2eBDoNwFEdL-vFrFV5y_FqF3qGRA@mail.gmail.com>
Message-ID: <CAF5CFkiYXgNZAvHDBzWRzbPYGN3a3bi0-54R=tkOBqKmUoZv5g@mail.gmail.com>

In case anyone wants to do this, I added the CSidechainAddress class to the
mainchainBMM branch of the Drivechain project a long time ago. The only
purpose it serves right now is to show that sidechain deposit addresses can
start with a '4'. We could simply add the sha256 hash described by Paul to
a script with OP_RETURN at the front and make that the standard.

On Jul 12, 2017 4:47 PM, "Paul Sztorc via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:

On 7/12/2017 4:50 AM, ZmnSCPxj wrote:

...


That said, I am fully in favor of forcing the sidechain's permanent
deposit address to be equal to some deterministic function of the sha256
hash of its version 0.1 release.

Paul

_______________________________________________
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/20170712/908a011a/attachment.html>

From truthcoin at gmail.com  Thu Jul 13 00:26:56 2017
From: truthcoin at gmail.com (Paul Sztorc)
Date: Wed, 12 Jul 2017 20:26:56 -0400
Subject: [bitcoin-dev] Drivechain RfD -- Follow Up
In-Reply-To: <F2C3A9F4-07AB-41B9-B915-9E33EE313F9E@taoeffect.com>
References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com>
	<83671224-f6ff-16a9-81c0-20ab578aec9d@gmail.com>
	<AAC86547-7904-4475-9966-138130019567@taoeffect.com>
	<6764b8af-bb4c-615d-5af5-462127bbbe36@gmail.com>
	<F2C3A9F4-07AB-41B9-B915-9E33EE313F9E@taoeffect.com>
Message-ID: <117f6a96-6d90-778a-d87a-be72592e31c5@gmail.com>

The confusion below stems from his conflation of several different ideas.

I will try to explicitly clarify a distinction between several types of
user (or, "modes" of use if you prefer):

[DC#0] -- Someone who does not upgrade their Bitcoin software (and is
running, say, 0.13). However, they experience the effects of the new
rules which miners add (as per the soft fork[s] to add drivechain
functionality and individual drivechains).
[DC#1] -- Someone who always upgrades to the latest version of the
Bitcoin software, but otherwise has no interest in running/using sidechains.
[DC#2] -- Someone who upgrades to the latest Bitcoin version, and
decides to also become a full node of one or more sidechains, but who
ever actually uses the sidechains.
[DC#3] -- Someone who upgrades their software, runs sidechain full
nodes, and actively moves money to and from these.


On 7/12/2017 6:43 PM, Tao Effect wrote:
>
> I am now looking closer again at step number 4 in the Drivechain
> specification [2]:
>
>     4. Everyone waits for a period of, say, 3 days. This gives
>     everyone an opportunity to make sure the same WT^ is in both the
>     Bitcoin coinbase and the Sidechain header. If they?re different,
>     everyone has plenty of time to contact each other, figure out what
>     is going on, and restart the process until its right.
>
> It seems to me that where our disagreement lies is in this point.
> The Drivechain spec seems to claim that its use of anyone-can-pay is
> the same as P2SH (and in later emails you reference SegWit as well).
> Is this really true?
FYI that document is nearly two years old, and although it is still
overwhelmingly accurate, new optimizations allow us (I think) to push
the waiting period to several weeks and the total ACK counting period up
to several months.

[DC#0] Yes
[DC#1] Yes
[DC#2] Yes
[DC#3] Yes

Because if a node doesn't have the sidechain's information, it will just
assume every withdrawal is valid. This is comparable to someone who
still hasn't upgraded to support P2SH, in cases [DC#0] and [#1].

(And this is the main advantage of DC over extension blocks).


> 2. Per the question in [1], it's my understanding that P2SH
> transactions contain all of the information within themselves for full
> nodes to act as a check on miners mishandling the anyone-can-spend
> nature of P2SH transactions. However, that does not seem to be the
> case with WT^ transactions.
[DC#0] They do.
[DC#1] They do.
[DC#2] They do.
[DC#3] They do.

Again, from the perspective of a mainchain user, every withdrawal is valid.


> In P2SH txns, there is no need for anyone to, as the Drivechain spec
> says, "to contact each other, figure out what is going on". Everything
> just automatically works.
There is no *need* to this in Drivechain, either, for [DC#0] or [DC#1].

[DC#2] and [DC#3] would certainly have an interest in understanding what
is going on, but that has absolutely nothing whatsoever to do with
Bitcoin Core and so is off-topic for this mailing list.


> If the security of WT^ transactions could be brought up to actually be
> in line with the security of P2SH and SegWit transactions, then I
> would have far less to object to.
Somehow I doubt it.


Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/72bb7ebe/attachment-0001.html>

From dan at osc.co.cr  Wed Jul 12 06:17:24 2017
From: dan at osc.co.cr (Dan Libby)
Date: Tue, 11 Jul 2017 23:17:24 -0700
Subject: [bitcoin-dev] how to disable segwit in my build?
In-Reply-To: <CAAS2fgR3FQ-wSwGwK6PDD_nZKpnBDAtM=5-fvR-smDa48xjW4Q@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<CAAS2fgTsjfMGw6D_OxDthSrrdLEFx2skGedLAjTwz3yCQijyug@mail.gmail.com>
	<001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com>
	<CAAS2fgR3FQ-wSwGwK6PDD_nZKpnBDAtM=5-fvR-smDa48xjW4Q@mail.gmail.com>
Message-ID: <03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr>

Hi!

Up to now, I have purposefully been running bitcoin releases prior to
0.13.1 as a way to avoid the (possible) segwit activation, at least
until such time as I personally am comfortable with it.

At this time, I would like to have some of the more recent features, but
without the possibility that my node will activate segwit, until I
choose to.

As I understand it, there is not any user setting that can disable
segwit from activating on my node.  If there was, I would use it.
Please correct me if wrong.

I am here to ask what is the simplest code change (fewest LOC changed) I
can make to 0.14.2+ code that would disable segwit from activating and
keep my node acting just like a legacy node with regards to consensus
rules, even if/when the rest of the network activates segwit.

I think, more generally, the same question applies to most any Bip9
versionbits feature.

I'm not looking for reasons NOT to do it, only HOW to do it without
unwanted side-effects.  My first untested idea is just to change the
segwit nTimeout in chainparams.cpp to a date in the past.  But I figured
I should ask the experts first.   :-)

thanks.


ps: full disclosure:  I may be the only one who wants this, but if
successful, I do plan to release my changes in case someone else wishes
to run with status-quo consensus rules.



From contact at taoeffect.com  Thu Jul 13 01:15:46 2017
From: contact at taoeffect.com (Tao Effect)
Date: Wed, 12 Jul 2017 18:15:46 -0700
Subject: [bitcoin-dev] Drivechain RfD -- Follow Up
In-Reply-To: <117f6a96-6d90-778a-d87a-be72592e31c5@gmail.com>
References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com>
	<83671224-f6ff-16a9-81c0-20ab578aec9d@gmail.com>
	<AAC86547-7904-4475-9966-138130019567@taoeffect.com>
	<6764b8af-bb4c-615d-5af5-462127bbbe36@gmail.com>
	<F2C3A9F4-07AB-41B9-B915-9E33EE313F9E@taoeffect.com>
	<117f6a96-6d90-778a-d87a-be72592e31c5@gmail.com>
Message-ID: <42C03DFC-C358-4F8C-A088-735910CCC60E@taoeffect.com>

Paul,

> The confusion below stems from his conflation of several different ideas.

I'm right here, are you having a conversation with me or are you on a stage talking to an audience?

> FYI that document is nearly two years old, and although it is still overwhelmingly accurate, new optimizations allow us (I think) to push the waiting period to several weeks and the total ACK counting period up to several months.

What does that have to do with my question? The counting period, if I understood correctly, is something miners do, not full nodes.

Also, if the document is old and/or outdated, do you happen to have a link to a more update-to-date version of the spec? It would be helpful for review.

> Because if a node doesn't have the sidechain's information, it will just assume every withdrawal is valid. This is comparable to someone who still hasn't upgraded to support P2SH, in cases [DC#0] and [#1].

Right, for [DC#0] and [DC#1], but for [DC#2] an [DC#3] you marked it as "Yes" without substantiating why you did so.

> Again, from the perspective of a mainchain user, every withdrawal is valid.

And that is not how P2SH works.

> [DC#2] and [DC#3] would certainly have an interest in understanding what is going on, but that has absolutely nothing whatsoever to do with Bitcoin Core and so is off-topic for this mailing list.

How is that an answer to my question?

What does "[DC#2] and [DC#3] would certainly have an interest in understanding what is going on" mean?

In P2SH, all upgraded nodes will reject invalid P2SH transactions, period.

What exactly would [DC#2] and [DC#3] nodes do when faced with an invalid WT^ transaction ? invalid in the sense that it contains funds which miners are stealing?

Again, in P2SH miners cannot steal funds, because all full nodes have a fully automatic enforcement policy.

Kind regards,
Greg Slepak

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

> On Jul 12, 2017, at 5:26 PM, Paul Sztorc <truthcoin at gmail.com <mailto:truthcoin at gmail.com>> wrote:
> 
> The confusion below stems from his conflation of several different ideas.
> 
> I will try to explicitly clarify a distinction between several types of user (or, "modes" of use if you prefer):
> 
> [DC#0] -- Someone who does not upgrade their Bitcoin software (and is running, say, 0.13). However, they experience the effects of the new rules which miners add (as per the soft fork[s] to add drivechain functionality and individual drivechains).
> [DC#1] -- Someone who always upgrades to the latest version of the Bitcoin software, but otherwise has no interest in running/using sidechains.
> [DC#2] -- Someone who upgrades to the latest Bitcoin version, and decides to also become a full node of one or more sidechains, but who ever actually uses the sidechains.
> [DC#3] -- Someone who upgrades their software, runs sidechain full nodes, and actively moves money to and from these.
> 
> 
> On 7/12/2017 6:43 PM, Tao Effect wrote:
>> 
>> I am now looking closer again at step number 4 in the Drivechain specification [2]:
>> 
>> 4. Everyone waits for a period of, say, 3 days. This gives everyone an opportunity to make sure the same WT^ is in both the Bitcoin coinbase and the Sidechain header. If they?re different, everyone has plenty of time to contact each other, figure out what is going on, and restart the process until its right.
>> It seems to me that where our disagreement lies is in this point.
>> The Drivechain spec seems to claim that its use of anyone-can-pay is the same as P2SH (and in later emails you reference SegWit as well). Is this really true?
> FYI that document is nearly two years old, and although it is still overwhelmingly accurate, new optimizations allow us (I think) to push the waiting period to several weeks and the total ACK counting period up to several months.
> 
> [DC#0] Yes
> [DC#1] Yes
> [DC#2] Yes
> [DC#3] Yes
> 
> Because if a node doesn't have the sidechain's information, it will just assume every withdrawal is valid. This is comparable to someone who still hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
> 
> (And this is the main advantage of DC over extension blocks).
> 
> 
>> 2. Per the question in [1], it's my understanding that P2SH transactions contain all of the information within themselves for full nodes to act as a check on miners mishandling the anyone-can-spend nature of P2SH transactions. However, that does not seem to be the case with WT^ transactions.
> [DC#0] They do.
> [DC#1] They do.
> [DC#2] They do.
> [DC#3] They do.
> 
> Again, from the perspective of a mainchain user, every withdrawal is valid.
> 
> 
>> In P2SH txns, there is no need for anyone to, as the Drivechain spec says, "to contact each other, figure out what is going on". Everything just automatically works.
> There is no *need* to this in Drivechain, either, for [DC#0] or [DC#1].
> 
> [DC#2] and [DC#3] would certainly have an interest in understanding what is going on, but that has absolutely nothing whatsoever to do with Bitcoin Core and so is off-topic for this mailing list.
> 
> 
>> If the security of WT^ transactions could be brought up to actually be in line with the security of P2SH and SegWit transactions, then I would have far less to object to.
> Somehow I doubt it.
> 
> 
> Paul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/f6cbca08/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/f6cbca08/attachment.sig>

From kanzure at gmail.com  Thu Jul 13 01:38:24 2017
From: kanzure at gmail.com (Bryan Bishop)
Date: Wed, 12 Jul 2017 20:38:24 -0500
Subject: [bitcoin-dev] Fwd: [Lightning-dev] Lightning Developers Biweekly
	Meeting Announce
In-Reply-To: <87mv898cdz.fsf@rustcorp.com.au>
References: <87mv898cdz.fsf@rustcorp.com.au>
Message-ID: <CABaSBazG2HBiGoNf4JPWwzTssku6x5+D7nsXH=zTu3r6HXy6dQ@mail.gmail.com>

---------- Forwarded message ----------
From: Rusty Russell <rusty at blockstream.com>
Date: Wed, Jul 12, 2017 at 6:27 PM
Subject: [Lightning-dev] Lightning Developers Biweekly Meeting Announce
To: lightning-dev at lists.linuxfoundation.org


Hi all!

        Every two weeks we've been running an informal Google Hangout
for implementers of the Lightning spec; as the spec is starting to
freeze, we've decided to formalize it a bit which means opening access
to a wider audience.

        The call is at 20:00 UTC every two weeks on Monday: next call is
on the 24th July.  We'll be using #lightning-dev on freenode's IRC
servers to communicate as well: if you're working on the Lightning
protocol and want to attend, please send me a ping and I'll add you to
the invite.

        I'll produce an agenda (basically a list of outstanding PRs on
github) and minutes each week: I'll post the latter to the ML here.
The last one can be found:

        https://docs.google.com/document/d/1EbMxe_QZhpHo67eeiYHbJ-BvNKU1WhFd5WhJFeD9-DI/edit?usp=sharing

        The routine with the spec itself is that from now on all
non-spelling/typo changes will require a vote with no objections from
call participants, or any devs unable to make it can veto or defer by
emailing me in writing before the meeting.

Cheers!
Rusty.
_______________________________________________
Lightning-dev mailing list
Lightning-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


-- 
- Bryan
http://heybryan.org/
1 512 203 0507

From greg at xiph.org  Thu Jul 13 01:04:19 2017
From: greg at xiph.org (Gregory Maxwell)
Date: Thu, 13 Jul 2017 01:04:19 +0000
Subject: [bitcoin-dev] how to disable segwit in my build?
In-Reply-To: <03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<CAAS2fgTsjfMGw6D_OxDthSrrdLEFx2skGedLAjTwz3yCQijyug@mail.gmail.com>
	<001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com>
	<CAAS2fgR3FQ-wSwGwK6PDD_nZKpnBDAtM=5-fvR-smDa48xjW4Q@mail.gmail.com>
	<03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr>
Message-ID: <CAAS2fgR1aGOpVoLyGWtO=Q5XU04gBMBEQARPtxMe4WnwQ2CO5w@mail.gmail.com>

On Wed, Jul 12, 2017 at 6:17 AM, Dan Libby via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi!
>
> Up to now, I have purposefully been running bitcoin releases prior to
> 0.13.1 as a way to avoid the (possible) segwit activation, at least
> until such time as I personally am comfortable with it.

It is not simple to do so correctly, I couldn't tell you off the top
of my head; a number of things must be changed it isn't as simple as
disabling the activiation because of the segwit P2P changes.  Nor is
it a supported configuration. Even if it were now, it wouldn't be one
we'd continue to support in the future after segwit is active, as
we're likely to drop deployment/compat code.

Can you explain why you wish to do this?  It should have absolutely no
adverse impact on you-- if you don't use segwit, you don't use it-- it
may be the case that there is some confusion about the implications
that I could clear up for you... or suggest alternatives that might
achieve your goals.

Having a node that supports it won't make it more likely to activate,
you can mine without signaling segwit even on a node that supports it.
Your own transactions will not use segwit just because your node
supports it.

Effectively the only reason I'm aware of to intentionally not run with
segwit support beyond just not having upgraded yet, is a desire to try
to temporarily have as your tip block a block that was actively
stealing the segwit transactions of a third party. Which doesn't seem
either personally or publicly desirable; but I fully admit I may be
missing some good reason which I am not aware of.

From aj at erisian.com.au  Thu Jul 13 01:48:26 2017
From: aj at erisian.com.au (Anthony Towns)
Date: Thu, 13 Jul 2017 11:48:26 +1000
Subject: [bitcoin-dev] how to disable segwit in my build?
In-Reply-To: <03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<CAAS2fgTsjfMGw6D_OxDthSrrdLEFx2skGedLAjTwz3yCQijyug@mail.gmail.com>
	<001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com>
	<CAAS2fgR3FQ-wSwGwK6PDD_nZKpnBDAtM=5-fvR-smDa48xjW4Q@mail.gmail.com>
	<03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr>
Message-ID: <20170713014826.GA12388@erisian.com.au>

On Tue, Jul 11, 2017 at 11:17:24PM -0700, Dan Libby via bitcoin-dev wrote:
> At this time, I would like to have some of the more recent features, but
> without the possibility that my node will activate segwit, until I
> choose to.

I think that terminology isn't quite precise. I think your options are:

 - if you're a miner or run a mining pool, you can *signal* (or not
   signal) support for segwit activation; you do this by controlling
   the block version

 - if you're running a node, you can choose to *enforce* (or not
   enforce) the additional consensus rules associated with segwit

I think it's the latter you're talking about. "Activation" is different:
it's the collective action of the bitcoin ecosystem to start enforcing
the segwit consensus rules after a sufficient majority of miners are
signalling support. That's not something you as an individual can control.

If you want to disable enforcement of segwit rules, even if a majority of
mining power signal activation, you can change the code and recompile to
do so, for example by changing the nTimeout setting for DEPLOYMENT_SEGWIT
from 1510704000 (Nov 15 2017) to 1493596800 (May 1 2017, already expired).
This is probably a bad idea, in that it will cause you to risk accepting
blocks that nobody else in the network will accept, opening you up
to higher risk of double spends, and may cause you to be unable to
peer with segwit enabled nodes after segwit is activated if your node
is rejecting blocks with witness data because you think segwit is not
enabled while they think it is enabled. To avoid that you would also need
to stop setting the NODE_WITNESS p2p bit, which you might be able to do
by setting the nTimeout above to 0 instead of just a date in the past? I
believe a timeout of 0 gets treated as automatically FAILED. There might
be other complexities too though.

> I'm not looking for reasons NOT to do it, only HOW to do it without
> unwanted side-effects.

The unwanted side-effects are precisely the reasons not to do it. If you
don't understand what they are, you won't be able to avoid them. :)

Cheers,
aj


From truthcoin at gmail.com  Thu Jul 13 02:58:48 2017
From: truthcoin at gmail.com (Paul Sztorc)
Date: Wed, 12 Jul 2017 22:58:48 -0400
Subject: [bitcoin-dev] Drivechain RfD -- Follow Up
In-Reply-To: <42C03DFC-C358-4F8C-A088-735910CCC60E@taoeffect.com>
References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com>
	<83671224-f6ff-16a9-81c0-20ab578aec9d@gmail.com>
	<AAC86547-7904-4475-9966-138130019567@taoeffect.com>
	<6764b8af-bb4c-615d-5af5-462127bbbe36@gmail.com>
	<F2C3A9F4-07AB-41B9-B915-9E33EE313F9E@taoeffect.com>
	<117f6a96-6d90-778a-d87a-be72592e31c5@gmail.com>
	<42C03DFC-C358-4F8C-A088-735910CCC60E@taoeffect.com>
Message-ID: <3277f4ef-a250-d383-8b00-cb912eb19f8b@gmail.com>

I will repeat that Drivechain can sometimes be confusing because it is
different things to different people.

Here is my attempt to break it down into different modes:

[DC#0] -- Someone who does not upgrade their Bitcoin software (and is
running, say, 0.13). However, they experience the effects of the new
rules which miners add (as per the soft fork[s] to add drivechain
functionality and individual drivechains).
[DC#1] -- Someone who always upgrades to the latest version of the
Bitcoin software, but otherwise has no interest in running/using sidechains.
[DC#2] -- Someone who upgrades to the latest Bitcoin version, and
decides to also become a full node of one or more sidechains, but who
ever actually uses the sidechains.
[DC#3] -- Someone who upgrades their software, runs sidechain full
nodes, and actively moves money to and from these.

Greg is still conflating modes [DC#1] and [DC#3]. Specifically, he
equivocates on the team "steal", using it to mean two different things:
[a] spending an invalid transaction, and [b] a withdrawal that would not
match the report given by a sidechain node.

The two are quite different, see my comments below:


On 7/12/2017 9:15 PM, Tao Effect wrote:
>> FYI that document is nearly two years old, and although it is still
>> overwhelmingly accurate, new optimizations allow us (I think) to push
>> the waiting period to several weeks and the total ACK counting period
>> up to several months.
> What does that have to do with my question? The counting period, if I
> understood correctly, is something miners do, not full nodes.

Greg quoted a passage that contained an older parameter estimate of "a
few days", and I thought it would be helpful and informative if I
clarified that the parameter estimate had been updated to a new (more
secure) value.

In point of fact, he is wrong, because nodes do the counting. When
miners find a block, they can choose to move the counter up, down, or
not at all. But nodes do the counting.


> Also, if the document is old and/or outdated, do you happen to have a
> link to a more update-to-date version of the spec? It would be helpful
> for review.

As I stated above, the document is mostly accurate. There is no other
more up to date version.


>> Because if a node doesn't have the sidechain's information, it will
>> just assume every withdrawal is valid. This is comparable to someone
>> who still hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
>
> Right, for [DC#0] and [DC#1], but for [DC#2] an [DC#3] you marked it
> as "Yes" without substantiating why you did so.


Above, Greg omitted his original question. For reference, it was:

>  The Drivechain spec seems to claim that its use of anyone-can-pay is the same as P2SH

The answer is that both DC and P2SH use transactions which are 'always
valid' to some group of people (un-upgraded users) but which are
sometimes invalid to new users. So the only difference would be for
[DC#0] vs other versions, but this difference is trivial as miners will
censor invalid txns.

It is your classic soft fork situation.


>> Again, from the perspective of a mainchain user, every withdrawal is
>> valid.
> And that is not how P2SH works.

Again, keep in mind that Greg continually conflates two different things:
1. Whether the soft fork rules have been followed, and
2. Whether the WT^ submitted by a majority hashrate matches the one
calculated by sidechain nodes.

The first case is exactly equal to P2SH. Just as old nodes accept every
P2SH transaction, so too will [DC#0] users accept every WT^ transaction.

In the second case, it so happens that [DC#1], [DC#2], and [DC#3] would
also accept any WT^ *that followed the Drivechain rules*, even if they
did not like the outcome (because the outcome in question was
arbitrarily designated as a "theft" of funds -- again, see the second
case in the list above). In this way, it is exactly similar to P2SH
because nodes will accept *any* p2sh txn **that follows the p2sh
rules**, even if they don't "like" the specific script contained within
(for example, because it is a theft of "their" BitFinex funds, or a
donation to a political candidate they dislike, etc).


>> [DC#2] and [DC#3] would certainly have an interest in understanding
>> what is going on, but that has absolutely nothing whatsoever to do
>> with Bitcoin Core and so is off-topic for this mailing list.
> How is that an answer to my question?

Greg is, of course, not entitled to an answer to irrelevant questions --
just as he would not be entitled to an answer if he asked for my
favorite color or my home address. And such answers would needlessly
consume the mailing list's scarce time.


> What does "[DC#2] and [DC#3] would certainly have an interest in
> understanding what is going on" mean?

It is clear to me that, if we are not clear on the basics first, we
cannot hope to tackle anything intermediate. We will come back to this
after clearing up soft fork part.


> In P2SH, all upgraded nodes will reject invalid P2SH transactions, period.

In DC, all upgraded nodes will reject invalid DC transactions, period.


> What exactly would [DC#2] and [DC#3] nodes do when faced with an
> invalid WT^ transaction ? invalid in the sense that it contains funds
> which miners are stealing?

The [DC#2] and [DC#3] nodes would do exactly what the [DC#0] and [DC#1]
nodes do. This is what I mean by "every withdrawal is valid".


> Again, in P2SH miners cannot steal funds, because all full nodes have
> a fully automatic enforcement policy.

In DC, miners cannot steal funds, because all full nodes have a fully
automatic enforcement policy.

However, DC *allows* users to choose to place some of their BTC at the
relative mercy of the miners in creative ways, if they wish (as does
P2SH -- someone could write a script which donates funds to miners, and
then fund it... "paying" to that script). This is another example of
conflating [DC#1] and [DC#3].

Paul



>> On Jul 12, 2017, at 5:26 PM, Paul Sztorc <truthcoin at gmail.com
>> <mailto:truthcoin at gmail.com>> wrote:
>>
>> The confusion below stems from his conflation of several different ideas.
>>
>> I will try to explicitly clarify a distinction between several types
>> of user (or, "modes" of use if you prefer):
>>
>> [DC#0] -- Someone who does not upgrade their Bitcoin software (and is
>> running, say, 0.13). However, they experience the effects of the new
>> rules which miners add (as per the soft fork[s] to add drivechain
>> functionality and individual drivechains).
>> [DC#1] -- Someone who always upgrades to the latest version of the
>> Bitcoin software, but otherwise has no interest in running/using
>> sidechains.
>> [DC#2] -- Someone who upgrades to the latest Bitcoin version, and
>> decides to also become a full node of one or more sidechains, but who
>> ever actually uses the sidechains.
>> [DC#3] -- Someone who upgrades their software, runs sidechain full
>> nodes, and actively moves money to and from these.
>>
>>
>> On 7/12/2017 6:43 PM, Tao Effect wrote:
>>>
>>> I am now looking closer again at step number 4 in the Drivechain
>>> specification [2]:
>>>
>>>     4. Everyone waits for a period of, say, 3 days. This gives
>>>     everyone an opportunity to make sure the same WT^ is in both the
>>>     Bitcoin coinbase and the Sidechain header. If they?re different,
>>>     everyone has plenty of time to contact each other, figure out
>>>     what is going on, and restart the process until its right.
>>>
>>> It seems to me that where our disagreement lies is in this point.
>>> The Drivechain spec seems to claim that its use of anyone-can-pay is
>>> the same as P2SH (and in later emails you reference SegWit as well).
>>> Is this really true?
>> FYI that document is nearly two years old, and although it is still
>> overwhelmingly accurate, new optimizations allow us (I think) to push
>> the waiting period to several weeks and the total ACK counting period
>> up to several months.
>>
>> [DC#0] Yes
>> [DC#1] Yes
>> [DC#2] Yes
>> [DC#3] Yes
>>
>> Because if a node doesn't have the sidechain's information, it will
>> just assume every withdrawal is valid. This is comparable to someone
>> who still hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
>>
>> (And this is the main advantage of DC over extension blocks).
>>
>>
>>> 2. Per the question in [1], it's my understanding that P2SH
>>> transactions contain all of the information within themselves for
>>> full nodes to act as a check on miners mishandling the
>>> anyone-can-spend nature of P2SH transactions. However, that does not
>>> seem to be the case with WT^ transactions.
>> [DC#0] They do.
>> [DC#1] They do.
>> [DC#2] They do.
>> [DC#3] They do.
>>
>> Again, from the perspective of a mainchain user, every withdrawal is
>> valid.
>>
>>
>>> In P2SH txns, there is no need for anyone to, as the Drivechain spec
>>> says, "to contact each other, figure out what is going on".
>>> Everything just automatically works.
>> There is no *need* to this in Drivechain, either, for [DC#0] or [DC#1].
>>
>> [DC#2] and [DC#3] would certainly have an interest in understanding
>> what is going on, but that has absolutely nothing whatsoever to do
>> with Bitcoin Core and so is off-topic for this mailing list.
>>
>>
>>> If the security of WT^ transactions could be brought up to actually
>>> be in line with the security of P2SH and SegWit transactions, then I
>>> would have far less to object to.
>> Somehow I doubt it.
>>
>>
>> Paul
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/c2d0f02b/attachment-0001.html>

From sergio.d.lerner at gmail.com  Thu Jul 13 03:10:55 2017
From: sergio.d.lerner at gmail.com (Sergio Demian Lerner)
Date: Thu, 13 Jul 2017 00:10:55 -0300
Subject: [bitcoin-dev] A Segwit2x BIP
In-Reply-To: <CAAS2fgRAdKFu8JqbmtAES3NkX2BK27LucSf=heZ2xyz30BKetw@mail.gmail.com>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
	<CAAS2fgRAdKFu8JqbmtAES3NkX2BK27LucSf=heZ2xyz30BKetw@mail.gmail.com>
Message-ID: <CAKzdR-pkiWXuZKH1NLR_=OD+NUGxzOgX03beJ7pc1QGVdmg3VA@mail.gmail.com>

Some responses..

>
> The proposal adds another gratuitous limit to the system: A maximum
> transaction size where none existed before, yet this limit is almost
> certainly too small to prevent actual DOS attacks while it is also
> technically larger than any transaction that can be included today
> (the largest possible transaction today is 1mb minus the block
> overheads).  The maximum resource usage for maliciously crafted 1MB
> transaction is enormous and permitting two of them greatly exacerbates
> the existing vulnerability.
>
>
I think that limiting the maximum transaction size may not be the best
possible solution to the N^2 hashing problem, yet it is not a bad start.

There are several viable soft-forking solutions to it:

1- Soft-fork to perform periodic reductions in the maximum non-segwit
checksigs per input (down to 20)
2- Soft-fork to perform periodic reductions in the number of non-segwit
checksigs per transaction. (down to 5K)
3- Soft-fork to perform periodic reductions in the amount of data hashed by
non-segwit checksigs.

Regardless which one one picks, the soft-fork can be deployed with enough
time in advance to reduce the exposure. The risk is still low. Four years
have passed since I reported this vulnerability and yet nobody has
exploited it. The attack is highly anti-economical, yet every discussion
about the block size ends up citing this vulnerability.

,

> > Assuming the current transaction pattern is replicated in a 2 MB
> plain-sized block that is 100% filled with transactions, then the
> witness-serialized block would occupy 3.6 MB
>
> But in a worst case the result would be 8MB, which this document fails
> to mention.
>

I will mention this worst case in the BIP.

Even if artificially filling the witness space up to 8 MB is
anti-economical, Segwit exacerbates this problem because each witness byte
costs 1/4th of a non-witness byte, so the block bloat attack gets cheaper
than before. I think the guilt lies more in Segwit discount factor than in
the plain block size increase.
I would remove the discount factor altogether, and add a fixed (40 bytes)
discount for each input with respect to outputs (not for certain input
types), to incentivize the cleaning of the UTXO set. A discount for inputs
cannot be used to bloat an unlimited number of blocks, because for each
input the attacker needs to first create an output (without discount).
There is no need to incentivize removing the signatures from blocks,
because there is already an incentive to do so to save disk space.


>
> > Deploy a modified BIP91 to activate Segwit. The only modification is
> that the signal "segsignal" is replaced by "segwit2x".
>
> This means that BIP-91 and your proposal are indistinguishable on the
> network, because the string "segsignal" is merely a variable name used
> in the software.
>
> No, it is exposed to the rpc mining interface (getblocktemplate). It must
be redefined, even if it's not a consensus change.


>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170713/94c52265/attachment.html>

From sergio.d.lerner at gmail.com  Thu Jul 13 03:19:28 2017
From: sergio.d.lerner at gmail.com (Sergio Demian Lerner)
Date: Thu, 13 Jul 2017 00:19:28 -0300
Subject: [bitcoin-dev] A Segwit2x BIP
In-Reply-To: <CAKzdR-pkiWXuZKH1NLR_=OD+NUGxzOgX03beJ7pc1QGVdmg3VA@mail.gmail.com>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
	<CAAS2fgRAdKFu8JqbmtAES3NkX2BK27LucSf=heZ2xyz30BKetw@mail.gmail.com>
	<CAKzdR-pkiWXuZKH1NLR_=OD+NUGxzOgX03beJ7pc1QGVdmg3VA@mail.gmail.com>
Message-ID: <CAKzdR-oW9gq=pbCGSqehSR2cp2NP+4v82KGVwbV9TbNnzmQb2Q@mail.gmail.com>

Well, 40 bytes reduction per input is excessive too :)
But 30 bytes reduction will do fine.

On Thu, Jul 13, 2017 at 12:10 AM, Sergio Demian Lerner <
sergio.d.lerner at gmail.com> wrote:

> Some responses..
>
>>
>> The proposal adds another gratuitous limit to the system: A maximum
>> transaction size where none existed before, yet this limit is almost
>> certainly too small to prevent actual DOS attacks while it is also
>> technically larger than any transaction that can be included today
>> (the largest possible transaction today is 1mb minus the block
>> overheads).  The maximum resource usage for maliciously crafted 1MB
>> transaction is enormous and permitting two of them greatly exacerbates
>> the existing vulnerability.
>>
>>
> I think that limiting the maximum transaction size may not be the best
> possible solution to the N^2 hashing problem, yet it is not a bad start.
>
> There are several viable soft-forking solutions to it:
>
> 1- Soft-fork to perform periodic reductions in the maximum non-segwit
> checksigs per input (down to 20)
> 2- Soft-fork to perform periodic reductions in the number of non-segwit
> checksigs per transaction. (down to 5K)
> 3- Soft-fork to perform periodic reductions in the amount of data hashed
> by non-segwit checksigs.
>
> Regardless which one one picks, the soft-fork can be deployed with enough
> time in advance to reduce the exposure. The risk is still low. Four years
> have passed since I reported this vulnerability and yet nobody has
> exploited it. The attack is highly anti-economical, yet every discussion
> about the block size ends up citing this vulnerability.
>
> ,
>
>> > Assuming the current transaction pattern is replicated in a 2 MB
>> plain-sized block that is 100% filled with transactions, then the
>> witness-serialized block would occupy 3.6 MB
>>
>> But in a worst case the result would be 8MB, which this document fails
>> to mention.
>>
>
> I will mention this worst case in the BIP.
>
> Even if artificially filling the witness space up to 8 MB is
> anti-economical, Segwit exacerbates this problem because each witness byte
> costs 1/4th of a non-witness byte, so the block bloat attack gets cheaper
> than before. I think the guilt lies more in Segwit discount factor than in
> the plain block size increase.
> I would remove the discount factor altogether, and add a fixed (40 bytes)
> discount for each input with respect to outputs (not for certain input
> types), to incentivize the cleaning of the UTXO set. A discount for inputs
> cannot be used to bloat an unlimited number of blocks, because for each
> input the attacker needs to first create an output (without discount).
> There is no need to incentivize removing the signatures from blocks,
> because there is already an incentive to do so to save disk space.
>
>
>>
>> > Deploy a modified BIP91 to activate Segwit. The only modification is
>> that the signal "segsignal" is replaced by "segwit2x".
>>
>> This means that BIP-91 and your proposal are indistinguishable on the
>> network, because the string "segsignal" is merely a variable name used
>> in the software.
>>
>> No, it is exposed to the rpc mining interface (getblocktemplate). It must
> be redefined, even if it's not a consensus change.
>
>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170713/23535924/attachment.html>

From contact at taoeffect.com  Thu Jul 13 03:24:10 2017
From: contact at taoeffect.com (Tao Effect)
Date: Wed, 12 Jul 2017 20:24:10 -0700
Subject: [bitcoin-dev] Drivechain RfD -- Follow Up
In-Reply-To: <3277f4ef-a250-d383-8b00-cb912eb19f8b@gmail.com>
References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com>
	<83671224-f6ff-16a9-81c0-20ab578aec9d@gmail.com>
	<AAC86547-7904-4475-9966-138130019567@taoeffect.com>
	<6764b8af-bb4c-615d-5af5-462127bbbe36@gmail.com>
	<F2C3A9F4-07AB-41B9-B915-9E33EE313F9E@taoeffect.com>
	<117f6a96-6d90-778a-d87a-be72592e31c5@gmail.com>
	<42C03DFC-C358-4F8C-A088-735910CCC60E@taoeffect.com>
	<3277f4ef-a250-d383-8b00-cb912eb19f8b@gmail.com>
Message-ID: <3F1802B5-FDD5-4E4F-9A5D-238C5F83116F@taoeffect.com>

Dear Paul,

> In point of fact, he is wrong, because nodes do the counting. When miners find a block, they can choose to move the counter up, down, or not at all. But nodes do the counting.

I may very well have confused who counts what, but for this discussion on *theft* it's irrelevant, so I won't push further on this.

Let's move on to the theft.

> Again, keep in mind that Greg continually conflates two different things:
> 1. Whether the soft fork rules have been followed, and
> 2. Whether the WT^ submitted by a majority hashrate matches the one calculated by sidechain nodes.
> 
> The first case is exactly equal to P2SH. Just as old nodes accept every P2SH transaction, so too will [DC#0] users accept every WT^ transaction.

To be crystal clear: I am entirely uninterested in the un-upgraded nodes, what you call [DC#0].

They are irrelevant to my argument.

> In the second case, it so happens that [DC#1], [DC#2], and [DC#3] would also accept any WT^ *that followed the Drivechain rules*, even if they did not like the outcome (because the outcome in question was arbitrarily designated as a "theft" of funds -- again, see the second case in the list above). In this way, it is exactly similar to P2SH because nodes will accept *any* p2sh txn **that follows the p2sh rules**, even if they don't "like" the specific script contained within (for example, because it is a theft of "their" BitFinex funds, or a donation to a political candidate they dislike, etc).

This is false.

For miners to steal P2SH funds, the P2SH script would have to be coded to explicitly allow them to do it.

How many P2SH scripts are you aware of that are used for the purpose of facilitating such theft?

I know of none, and I bet there are none.

Whereas in DC, every single usage of DC allows miners to steal funds.

>> In P2SH, all upgraded nodes will reject invalid P2SH transactions, period.
> 
> In DC, all upgraded nodes will reject invalid DC transactions, period.

It appears you are playing games with the meaning of "invalid" here, so that sentence is invalid.

I was very clear what I meant by "invalid" in my email: WT^ transactions that represent miners stealing funds. Please stick to that and do not play word games.

> The [DC#2] and [DC#3] nodes would do exactly what the [DC#0] and [DC#1] nodes do. This is what I mean by "every withdrawal is valid".

So, here you are again re-affirming that WT^ transactions representing stolen funds are allowed in DC, and by tying them all together you are also affirming that the SPV proofs mentioned in DC are completely irrelevant / pointless / unused.

>> Again, in P2SH miners cannot steal funds, because all full nodes have a fully automatic enforcement policy.
> 
> In DC, miners cannot steal funds, because all full nodes have a fully automatic enforcement policy.
> 
> However, DC *allows* users to choose to place some of their BTC at the relative mercy of the miners in creative ways, if they wish (as does P2SH -- someone could write a script which donates funds to miners, and then fund it... "paying" to that script). This is another example of conflating [DC#1] and [DC#3].

So in the first sentence you say they "cannot steal funds", but everything else you've said, including the following paragraph, and your specification, indicates they can.

I've finally collected all my thoughts / concerns and have also summarized them in this document:

https://gist.github.com/taoeffect/9ff64cf78cf1408ec29f13ed39e534c9 <https://gist.github.com/taoeffect/9ff64cf78cf1408ec29f13ed39e534c9>

Kind regards,
Greg Slepak

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

> On Jul 12, 2017, at 7:58 PM, Paul Sztorc via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> 
> I will repeat that Drivechain can sometimes be confusing because it is different things to different people.
> 
> Here is my attempt to break it down into different modes:
> 
> [DC#0] -- Someone who does not upgrade their Bitcoin software (and is running, say, 0.13). However, they experience the effects of the new rules which miners add (as per the soft fork[s] to add drivechain functionality and individual drivechains).
> [DC#1] -- Someone who always upgrades to the latest version of the Bitcoin software, but otherwise has no interest in running/using sidechains.
> [DC#2] -- Someone who upgrades to the latest Bitcoin version, and decides to also become a full node of one or more sidechains, but who ever actually uses the sidechains.
> [DC#3] -- Someone who upgrades their software, runs sidechain full nodes, and actively moves money to and from these.
> 
> Greg is still conflating modes [DC#1] and [DC#3]. Specifically, he equivocates on the team "steal", using it to mean two different things: [a] spending an invalid transaction, and [b] a withdrawal that would not match the report given by a sidechain node.
> 
> The two are quite different, see my comments below:
> 
> 
> On 7/12/2017 9:15 PM, Tao Effect wrote:
>>> FYI that document is nearly two years old, and although it is still overwhelmingly accurate, new optimizations allow us (I think) to push the waiting period to several weeks and the total ACK counting period up to several months.
>> 
>> What does that have to do with my question? The counting period, if I understood correctly, is something miners do, not full nodes.
> 
> Greg quoted a passage that contained an older parameter estimate of "a few days", and I thought it would be helpful and informative if I clarified that the parameter estimate had been updated to a new (more secure) value.
> 
> In point of fact, he is wrong, because nodes do the counting. When miners find a block, they can choose to move the counter up, down, or not at all. But nodes do the counting.
> 
> 
>> Also, if the document is old and/or outdated, do you happen to have a link to a more update-to-date version of the spec? It would be helpful for review.
> 
> As I stated above, the document is mostly accurate. There is no other more up to date version.
> 
> 
>>> Because if a node doesn't have the sidechain's information, it will just assume every withdrawal is valid. This is comparable to someone who still hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
>> 
>> Right, for [DC#0] and [DC#1], but for [DC#2] an [DC#3] you marked it as "Yes" without substantiating why you did so.
> 
> 
> Above, Greg omitted his original question. For reference, it was:
> 
>>  The Drivechain spec seems to claim that its use of anyone-can-pay is the same as P2SH
> 
> The answer is that both DC and P2SH use transactions which are 'always valid' to some group of people (un-upgraded users) but which are sometimes invalid to new users. So the only difference would be for [DC#0] vs other versions, but this difference is trivial as miners will censor invalid txns.
> 
> It is your classic soft fork situation.
> 
> 
>>> Again, from the perspective of a mainchain user, every withdrawal is valid.
>> 
>> And that is not how P2SH works.
> 
> Again, keep in mind that Greg continually conflates two different things:
> 1. Whether the soft fork rules have been followed, and
> 2. Whether the WT^ submitted by a majority hashrate matches the one calculated by sidechain nodes.
> 
> The first case is exactly equal to P2SH. Just as old nodes accept every P2SH transaction, so too will [DC#0] users accept every WT^ transaction.
> 
> In the second case, it so happens that [DC#1], [DC#2], and [DC#3] would also accept any WT^ *that followed the Drivechain rules*, even if they did not like the outcome (because the outcome in question was arbitrarily designated as a "theft" of funds -- again, see the second case in the list above). In this way, it is exactly similar to P2SH because nodes will accept *any* p2sh txn **that follows the p2sh rules**, even if they don't "like" the specific script contained within (for example, because it is a theft of "their" BitFinex funds, or a donation to a political candidate they dislike, etc).
> 
> 
>>> [DC#2] and [DC#3] would certainly have an interest in understanding what is going on, but that has absolutely nothing whatsoever to do with Bitcoin Core and so is off-topic for this mailing list.
>> 
>> How is that an answer to my question?
> 
> Greg is, of course, not entitled to an answer to irrelevant questions -- just as he would not be entitled to an answer if he asked for my favorite color or my home address. And such answers would needlessly consume the mailing list's scarce time.
> 
> 
>> What does "[DC#2] and [DC#3] would certainly have an interest in understanding what is going on" mean?
> 
> It is clear to me that, if we are not clear on the basics first, we cannot hope to tackle anything intermediate. We will come back to this after clearing up soft fork part.
> 
> 
>> In P2SH, all upgraded nodes will reject invalid P2SH transactions, period.
> 
> In DC, all upgraded nodes will reject invalid DC transactions, period.
> 
> 
>> What exactly would [DC#2] and [DC#3] nodes do when faced with an invalid WT^ transaction ? invalid in the sense that it contains funds which miners are stealing?
> 
> The [DC#2] and [DC#3] nodes would do exactly what the [DC#0] and [DC#1] nodes do. This is what I mean by "every withdrawal is valid".
> 
> 
>> Again, in P2SH miners cannot steal funds, because all full nodes have a fully automatic enforcement policy.
> 
> In DC, miners cannot steal funds, because all full nodes have a fully automatic enforcement policy.
> 
> However, DC *allows* users to choose to place some of their BTC at the relative mercy of the miners in creative ways, if they wish (as does P2SH -- someone could write a script which donates funds to miners, and then fund it... "paying" to that script). This is another example of conflating [DC#1] and [DC#3].
> 
> Paul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/abb2b4f4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/abb2b4f4/attachment-0001.sig>

From federicotenga at gmail.com  Thu Jul 13 13:11:21 2017
From: federicotenga at gmail.com (Federico Tenga)
Date: Thu, 13 Jul 2017 15:11:21 +0200
Subject: [bitcoin-dev] how to disable segwit in my build?
In-Reply-To: <CAAS2fgR1aGOpVoLyGWtO=Q5XU04gBMBEQARPtxMe4WnwQ2CO5w@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<CAAS2fgTsjfMGw6D_OxDthSrrdLEFx2skGedLAjTwz3yCQijyug@mail.gmail.com>
	<001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com>
	<CAAS2fgR3FQ-wSwGwK6PDD_nZKpnBDAtM=5-fvR-smDa48xjW4Q@mail.gmail.com>
	<03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr>
	<CAAS2fgR1aGOpVoLyGWtO=Q5XU04gBMBEQARPtxMe4WnwQ2CO5w@mail.gmail.com>
Message-ID: <CAP=-fx6hju0NAa-HcYzivwNbJH0HXwUL=t7iD38XAK_Fwodjng@mail.gmail.com>

On 13 July 2017 at 03:04, Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

>
> Can you explain why you wish to do this?  It should have absolutely no
> adverse impact on you-- if you don't use segwit, you don't use it-- it
> may be the case that there is some confusion about the implications
> that I could clear up for you... or suggest alternatives that might
> achieve your goals.
>

I believe that a good reason not to wish your node to be segwit compliant
is to avoid having to deal with the extra bandwidth that segwit could
require.   Running a 0.14.2 node means being ok with >1MB blocks, in case
segwit is activated and widely used. Users not interested in segwit
transactions may prefer to keep the cost of their node lower.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170713/df014a46/attachment.html>

From hampus.sjoberg at gmail.com  Thu Jul 13 13:17:13 2017
From: hampus.sjoberg at gmail.com (=?UTF-8?Q?Hampus_Sj=C3=B6berg?=)
Date: Thu, 13 Jul 2017 15:17:13 +0200
Subject: [bitcoin-dev] Drivechain RfD -- Follow Up
In-Reply-To: <3277f4ef-a250-d383-8b00-cb912eb19f8b@gmail.com>
References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com>
	<83671224-f6ff-16a9-81c0-20ab578aec9d@gmail.com>
	<AAC86547-7904-4475-9966-138130019567@taoeffect.com>
	<6764b8af-bb4c-615d-5af5-462127bbbe36@gmail.com>
	<F2C3A9F4-07AB-41B9-B915-9E33EE313F9E@taoeffect.com>
	<117f6a96-6d90-778a-d87a-be72592e31c5@gmail.com>
	<42C03DFC-C358-4F8C-A088-735910CCC60E@taoeffect.com>
	<3277f4ef-a250-d383-8b00-cb912eb19f8b@gmail.com>
Message-ID: <CAFMkqK_2V+p0JmrAj5WSkEDWXWG4h4c1SzZ4mxEiZBwDpAHd4A@mail.gmail.com>

In softforks, I would argue that 100% of all nodes and miners need to
upgrade to the new rules.
This makes sure that trying to incorrectly spend an "AnyOneCanSpend" will
result in a hardfork, instead of a temporary (or permanent) chainsplit.

With drivechains, it seems like the current plan is to only let the nodes
that are interested in the drivechain validate the other chain, and not
necessarily 100% of the network.
I guess this could be any percentage of the network, which could lead to a
temporary/permanent chainsplit depending on how many percentage of the
miners are also validating the other chain (am I missing something here?).

I have no way to evaluate if this is an okay trade-off.
It seems like major disruption could very likely happen if say only 5% of
all fullnodes validate the drivechain.

To be fully secure, it seems like 100% of all nodes should also have a
fullnode for the drivechain as well...
This is one of the reasons I don't advocate sidechains/drivechains as a
scaling solution, it looks like it would have to the same outcome as a
blocksize increase on the mainchain, but with more complexity.
I think sidechains/drivechains could be useful for other things though.


Thanks for all your work so far Paul.
Hampus

2017-07-13 4:58 GMT+02:00 Paul Sztorc via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> I will repeat that Drivechain can sometimes be confusing because it is
> different things to different people.
>
> Here is my attempt to break it down into different modes:
>
> [DC#0] -- Someone who does not upgrade their Bitcoin software (and is
> running, say, 0.13). However, they experience the effects of the new rules
> which miners add (as per the soft fork[s] to add drivechain functionality
> and individual drivechains).
> [DC#1] -- Someone who always upgrades to the latest version of the Bitcoin
> software, but otherwise has no interest in running/using sidechains.
> [DC#2] -- Someone who upgrades to the latest Bitcoin version, and decides
> to also become a full node of one or more sidechains, but who ever actually
> uses the sidechains.
> [DC#3] -- Someone who upgrades their software, runs sidechain full nodes,
> and actively moves money to and from these.
>
> Greg is still conflating modes [DC#1] and [DC#3]. Specifically, he
> equivocates on the team "steal", using it to mean two different things: [a]
> spending an invalid transaction, and [b] a withdrawal that would not match
> the report given by a sidechain node.
>
> The two are quite different, see my comments below:
>
>
> On 7/12/2017 9:15 PM, Tao Effect wrote:
>
> FYI that document is nearly two years old, and although it is still
> overwhelmingly accurate, new optimizations allow us (I think) to push the
> waiting period to several weeks and the total ACK counting period up to
> several months.
>
> What does that have to do with my question? The counting period, if I
> understood correctly, is something miners do, not full nodes.
>
>
> Greg quoted a passage that contained an older parameter estimate of "a few
> days", and I thought it would be helpful and informative if I clarified
> that the parameter estimate had been updated to a new (more secure) value.
>
> In point of fact, he is wrong, because nodes do the counting. When miners
> find a block, they can choose to move the counter up, down, or not at all.
> But nodes do the counting.
>
>
> Also, if the document is old and/or outdated, do you happen to have a link
> to a more update-to-date version of the spec? It would be helpful for
> review.
>
>
> As I stated above, the document is mostly accurate. There is no other more
> up to date version.
>
>
> Because if a node doesn't have the sidechain's information, it will just
> assume every withdrawal is valid. This is comparable to someone who still
> hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
>
>
> Right, for [DC#0] and [DC#1], but for [DC#2] an [DC#3] you marked it as
> "Yes" without substantiating why you did so.
>
>
>
> Above, Greg omitted his original question. For reference, it was:
>
>  The Drivechain spec seems to claim that its use of anyone-can-pay is the same as P2SH
>
>
> The answer is that both DC and P2SH use transactions which are 'always
> valid' to some group of people (un-upgraded users) but which are sometimes
> invalid to new users. So the only difference would be for [DC#0] vs other
> versions, but this difference is trivial as miners will censor invalid txns.
>
> It is your classic soft fork situation.
>
>
> Again, from the perspective of a mainchain user, every withdrawal is valid.
>
> And that is not how P2SH works.
>
>
> Again, keep in mind that Greg continually conflates two different things:
> 1. Whether the soft fork rules have been followed, and
> 2. Whether the WT^ submitted by a majority hashrate matches the one
> calculated by sidechain nodes.
>
> The first case is exactly equal to P2SH. Just as old nodes accept every
> P2SH transaction, so too will [DC#0] users accept every WT^ transaction.
>
> In the second case, it so happens that [DC#1], [DC#2], and [DC#3] would
> also accept any WT^ *that followed the Drivechain rules*, even if they did
> not like the outcome (because the outcome in question was arbitrarily
> designated as a "theft" of funds -- again, see the second case in the list
> above). In this way, it is exactly similar to P2SH because nodes will
> accept *any* p2sh txn **that follows the p2sh rules**, even if they don't
> "like" the specific script contained within (for example, because it is a
> theft of "their" BitFinex funds, or a donation to a political candidate
> they dislike, etc).
>
>
> [DC#2] and [DC#3] would certainly have an interest in understanding what
> is going on, but that has absolutely nothing whatsoever to do with Bitcoin
> Core and so is off-topic for this mailing list.
>
> How is that an answer to my question?
>
>
> Greg is, of course, not entitled to an answer to irrelevant questions --
> just as he would not be entitled to an answer if he asked for my favorite
> color or my home address. And such answers would needlessly consume the
> mailing list's scarce time.
>
>
> What does "[DC#2] and [DC#3] would certainly have an interest in
> understanding what is going on" mean?
>
>
> It is clear to me that, if we are not clear on the basics first, we cannot
> hope to tackle anything intermediate. We will come back to this after
> clearing up soft fork part.
>
>
> In P2SH, all upgraded nodes will reject invalid P2SH transactions, period.
>
>
> In DC, all upgraded nodes will reject invalid DC transactions, period.
>
>
> What exactly would [DC#2] and [DC#3] nodes do when faced with an invalid
> WT^ transaction ? invalid in the sense that it contains funds which miners
> are stealing?
>
>
> The [DC#2] and [DC#3] nodes would do exactly what the [DC#0] and [DC#1]
> nodes do. This is what I mean by "every withdrawal is valid".
>
>
> Again, in P2SH miners cannot steal funds, because all full nodes have a
> fully automatic enforcement policy.
>
>
> In DC, miners cannot steal funds, because all full nodes have a fully
> automatic enforcement policy.
>
> However, DC *allows* users to choose to place some of their BTC at the
> relative mercy of the miners in creative ways, if they wish (as does P2SH
> -- someone could write a script which donates funds to miners, and then
> fund it... "paying" to that script). This is another example of conflating
> [DC#1] and [DC#3].
>
> Paul
>
>
>
>
> On Jul 12, 2017, at 5:26 PM, Paul Sztorc <truthcoin at gmail.com> wrote:
>
> The confusion below stems from his conflation of several different ideas.
>
> I will try to explicitly clarify a distinction between several types of
> user (or, "modes" of use if you prefer):
>
> [DC#0] -- Someone who does not upgrade their Bitcoin software (and is
> running, say, 0.13). However, they experience the effects of the new rules
> which miners add (as per the soft fork[s] to add drivechain functionality
> and individual drivechains).
> [DC#1] -- Someone who always upgrades to the latest version of the Bitcoin
> software, but otherwise has no interest in running/using sidechains.
> [DC#2] -- Someone who upgrades to the latest Bitcoin version, and decides
> to also become a full node of one or more sidechains, but who ever actually
> uses the sidechains.
> [DC#3] -- Someone who upgrades their software, runs sidechain full nodes,
> and actively moves money to and from these.
>
>
> On 7/12/2017 6:43 PM, Tao Effect wrote:
>
>
> I am now looking closer again at step number 4 in the Drivechain
> specification [2]:
>
> 4. Everyone waits for a period of, say, 3 days. This gives everyone an
> opportunity to make sure the same WT^ is in both the Bitcoin coinbase and
> the Sidechain header. If they?re different, everyone has plenty of time to
> contact each other, figure out what is going on, and restart the process
> until its right.
>
> It seems to me that where our disagreement lies is in this point.
> The Drivechain spec seems to claim that its use of anyone-can-pay is the
> same as P2SH (and in later emails you reference SegWit as well). Is this
> really true?
>
> FYI that document is nearly two years old, and although it is still
> overwhelmingly accurate, new optimizations allow us (I think) to push the
> waiting period to several weeks and the total ACK counting period up to
> several months.
>
> [DC#0] Yes
> [DC#1] Yes
> [DC#2] Yes
> [DC#3] Yes
>
> Because if a node doesn't have the sidechain's information, it will just
> assume every withdrawal is valid. This is comparable to someone who still
> hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
>
> (And this is the main advantage of DC over extension blocks).
>
>
> 2. Per the question in [1], it's my understanding that P2SH transactions
> contain all of the information within themselves for full nodes to act as a
> check on miners mishandling the anyone-can-spend nature of P2SH
> transactions. However, that does not seem to be the case with WT^
> transactions.
>
> [DC#0] They do.
> [DC#1] They do.
> [DC#2] They do.
> [DC#3] They do.
>
> Again, from the perspective of a mainchain user, every withdrawal is valid.
>
>
> In P2SH txns, there is no need for anyone to, as the Drivechain spec says,
> "to contact each other, figure out what is going on". Everything just
> automatically works.
>
> There is no *need* to this in Drivechain, either, for [DC#0] or [DC#1].
>
> [DC#2] and [DC#3] would certainly have an interest in understanding what
> is going on, but that has absolutely nothing whatsoever to do with Bitcoin
> Core and so is off-topic for this mailing list.
>
>
> If the security of WT^ transactions could be brought up to actually be in
> line with the security of P2SH and SegWit transactions, then I would have
> far less to object to.
>
> Somehow I doubt it.
>
>
> Paul
>
>
>
>
> _______________________________________________
> 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/20170713/e9634ea7/attachment-0001.html>

From hampus.sjoberg at gmail.com  Thu Jul 13 13:39:40 2017
From: hampus.sjoberg at gmail.com (=?UTF-8?Q?Hampus_Sj=C3=B6berg?=)
Date: Thu, 13 Jul 2017 15:39:40 +0200
Subject: [bitcoin-dev] how to disable segwit in my build?
In-Reply-To: <CAP=-fx6hju0NAa-HcYzivwNbJH0HXwUL=t7iD38XAK_Fwodjng@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<CAAS2fgTsjfMGw6D_OxDthSrrdLEFx2skGedLAjTwz3yCQijyug@mail.gmail.com>
	<001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com>
	<CAAS2fgR3FQ-wSwGwK6PDD_nZKpnBDAtM=5-fvR-smDa48xjW4Q@mail.gmail.com>
	<03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr>
	<CAAS2fgR1aGOpVoLyGWtO=Q5XU04gBMBEQARPtxMe4WnwQ2CO5w@mail.gmail.com>
	<CAP=-fx6hju0NAa-HcYzivwNbJH0HXwUL=t7iD38XAK_Fwodjng@mail.gmail.com>
Message-ID: <CAFMkqK9+pvRRtcOomo6is5t8xQ2gLmGb7XaGV80TOm-eO6ZoqA@mail.gmail.com>

> I believe that a good reason not to wish your node to be segwit compliant
is to avoid having to deal with the extra bandwidth that segwit could
require.   Running a 0.14.2 node means being ok with >1MB blocks, in case
segwit is activated and widely used. Users not interested in segwit
transactions may prefer to keep the cost of their node lower.

If the majority of the network decides to deploy SegWit, it would be in
your best interest to validate the SegWit transactions, because you might
will be downgraded to near-SPV node validation.
It would be okay to still run a "non-SegWit" node if there's no SegWit
transactions in the chain of transactions for your bitcoins, otherwise you
cannot fully verify the the ownership of your bitcoins.
I'm not sure the practicality of this in the long run, but it makes a case
for having an up-to-date non-SegWit node, although I think it's a bit of a
stretch.

Greetings
Hampus

2017-07-13 15:11 GMT+02:00 Federico Tenga via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> On 13 July 2017 at 03:04, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>
>> Can you explain why you wish to do this?  It should have absolutely no
>> adverse impact on you-- if you don't use segwit, you don't use it-- it
>> may be the case that there is some confusion about the implications
>> that I could clear up for you... or suggest alternatives that might
>> achieve your goals.
>>
>
> I believe that a good reason not to wish your node to be segwit compliant
> is to avoid having to deal with the extra bandwidth that segwit could
> require.   Running a 0.14.2 node means being ok with >1MB blocks, in case
> segwit is activated and widely used. Users not interested in segwit
> transactions may prefer to keep the cost of their node lower.
>
> _______________________________________________
> 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/20170713/17df3337/attachment.html>

From truthcoin at gmail.com  Thu Jul 13 15:39:00 2017
From: truthcoin at gmail.com (Paul Sztorc)
Date: Thu, 13 Jul 2017 11:39:00 -0400
Subject: [bitcoin-dev] Drivechain RfD -- Follow Up
In-Reply-To: <3F1802B5-FDD5-4E4F-9A5D-238C5F83116F@taoeffect.com>
References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com>
	<83671224-f6ff-16a9-81c0-20ab578aec9d@gmail.com>
	<AAC86547-7904-4475-9966-138130019567@taoeffect.com>
	<6764b8af-bb4c-615d-5af5-462127bbbe36@gmail.com>
	<F2C3A9F4-07AB-41B9-B915-9E33EE313F9E@taoeffect.com>
	<117f6a96-6d90-778a-d87a-be72592e31c5@gmail.com>
	<42C03DFC-C358-4F8C-A088-735910CCC60E@taoeffect.com>
	<3277f4ef-a250-d383-8b00-cb912eb19f8b@gmail.com>
	<3F1802B5-FDD5-4E4F-9A5D-238C5F83116F@taoeffect.com>
Message-ID: <02d9700e-e597-9c70-a007-e9c9e7504227@gmail.com>

Greg is still conflating two different usages of the word "theft":
1. Whether the soft fork rules have been followed, and
2. Whether the WT^ submitted by a majority hashrate matches the one
calculated by sidechain nodes.

In his message he claims to uniquely adopt definition #2, saying
(emphasis added):

> I was very clear what I meant by "invalid" in my email: WT^
> transactions that represent miners stealing funds. **Please stick to
> that** and do not play word games.

...however, he revokes that commitment below when it suits his purposes.

Since Greg's message is probably too confusing to be helpful, I will
first clarify both cases:

Case 1 -- soft fork rules -- all "invalid_1" txns are regarded as
"theft_1" and are rejected.
Case 2 -- sidechain's unique consensus rules -- all WT^ are accepted (if
these WT^ are valid_1 under the Case 1 rules), whether they match the
sidechain's reported WT^ or not (in other words, whether they are
valid_2 or not).

In Case 2, the mainchain accepts all WT^ transactions as "valid", in
that they can be included in a block, whether or not they are
"valid_2".  By design, sidechains make no effort to validate the rules
specific to each sidechain, just as they make no effort to validate the
rules of Altcoins. In this way, a WT^ transaction is comparable to
someone who is selling an Altcoin to purchase some Bitcoin -- Bitcoin
doesn't care how they got the Altcoin.


On 7/12/2017 11:24 PM, Tao Effect wrote:
> Dear Paul,
>
>> In point of fact, he is wrong, because nodes do the counting. When
>> miners find a block, they can choose to move the counter up, down, or
>> not at all. But nodes do the counting.
>
> I may very well have confused who counts what

To be clear: yes, Greg did get it confused.

And it is very important, because a neglect of the node-enforced rules
is a neglect of **both** theft_1 and theft_2 simultaneously, making it
easier to conflate the both of them as Greg is still doing.


>> In the second case, it so happens that [DC#1], [DC#2], and [DC#3]
>> would also accept any WT^ *that followed the Drivechain rules*, even
>> if they did not like the outcome (because the outcome in question was
>> arbitrarily designated as a "theft" of funds -- again, see the second
>> case in the list above). In this way, it is exactly similar to P2SH
>> because nodes will accept *any* p2sh txn **that follows the p2sh
>> rules**, even if they don't "like" the specific script contained
>> within (for example, because it is a theft of "their" BitFinex funds,
>> or a donation to a political candidate they dislike, etc).
>
> This is false.
>
> For miners to steal P2SH funds, the P2SH script would have to be coded
> to explicitly allow them to do it.
>
> How many P2SH scripts are you aware of that are used for the purpose
> of facilitating such theft?
>
> I know of none, and I bet there are none.


This is the instance I mentioned above -- despite committing to only
discussing theft_2, Greg has secretly switched back to theft_1, when he
talks about a "P2SH script...used for the purpose of facilitating theft".

Under theft_2, there is no way to infer the theft-ness of the
transaction from the script itself. For example, if someone made a
2-of-3 multisig with a third party escrow , and these funds were
"stolen", this would be an example of funds "stolen" from a P2SH under
"theft_2".

At which point Greg would angrily say that whoever wrote P2SH was
reckless and...allowed Bitcoins to be "stolen". Or perhaps he would
switch definitions yet again, and say that "that doesn't count as
theft". blah blah blah yada yada yada

It is true that moving from pre-P2SH to post-P2SH has not --yet--
enabled any theft_2 as a result. But P2SH has also failed to enable
sidechains. Sidechains logically must open the door to theft_2, else
they will regress to the undesirable cases of hard/evil fork (as I
explain in the spec). Empirically, we do not know how much theft_2 will
be enabled by drivechain. Theoretically, it is possible that there will
never be a theft_2 on drivechain.


>> The [DC#2] and [DC#3] nodes would do exactly what the [DC#0] and
>> [DC#1] nodes do. This is what I mean by "every withdrawal is valid".
>
> So, here you are again re-affirming that WT^ transactions representing
> stolen funds are allowed in DC, and by tying them all together you are
> also affirming that the SPV proofs mentioned in DC are completely
> irrelevant / pointless / unused.

I do not affirm the latter. The SPV proofs in DC are very important, as
they are what allow nodes to enforce the delayed withdrawal upon miners.
In fact, this is exactly what Greg admits to being confused about above.
He is correct that he is confused.

Experts including Adam Back (co-author of original sidechains paper, CEO
of Blockstream which started the sidechains conversation) have publicly
stated that they share my belief that this delayed withdrawal technique
is likely to mitigate the threat of theft_2. Greg S is free to hold a
different opinion.


>>> Again, in P2SH miners cannot steal funds, because all full nodes
>>> have a fully automatic enforcement policy.
>>
>> In DC, miners cannot steal funds, because all full nodes have a fully
>> automatic enforcement policy.
>>
>> However, DC *allows* users to choose to place some of their BTC at
>> the relative mercy of the miners in creative ways, if they wish (as
>> does P2SH -- someone could write a script which donates funds to
>> miners, and then fund it... "paying" to that script). This is another
>> example of conflating [DC#1] and [DC#3].
>
> So in the first sentence you say they "cannot steal funds", but
> everything else you've said, including the following paragraph, and
> your specification, indicates they can.

Greg did not specify which theft so I had to guess in the above case. 
Above, I refer to "theft_1", the [DC#0] style theft. As always, no one
can "steal_1" funds in that case.

The reason I assumed Greg was talking about theft_1 and not theft_2, is
because he mentioned P2SH and the fact that full nodes automatically
enforce the network's rules. Drivechain's rules impose a new format,
like P2SH, and have new rules which are automatically enforced by nodes.

Greg's style is basically to confuse two things, ask unclear questions
about them, and then try to discover "contradictions" in the mess that
follows. But it is all a function of his conflation of terminology and
nothing else.


> I've finally collected all my thoughts / concerns and have also
> summarized them in this document:
>
> https://gist.github.com/taoeffect/9ff64cf78cf1408ec29f13ed39e534c9

Given how little Greg understands, even after being hand-fed by me for
days and weeks, I admit a totally nonexistent interest in reading it.

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170713/0d4d25a4/attachment-0001.html>

From dan at osc.co.cr  Thu Jul 13 16:05:01 2017
From: dan at osc.co.cr (Dan Libby)
Date: Thu, 13 Jul 2017 09:05:01 -0700
Subject: [bitcoin-dev] how to disable segwit in my build?
In-Reply-To: <CAAS2fgR1aGOpVoLyGWtO=Q5XU04gBMBEQARPtxMe4WnwQ2CO5w@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<CAAS2fgTsjfMGw6D_OxDthSrrdLEFx2skGedLAjTwz3yCQijyug@mail.gmail.com>
	<001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com>
	<CAAS2fgR3FQ-wSwGwK6PDD_nZKpnBDAtM=5-fvR-smDa48xjW4Q@mail.gmail.com>
	<03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr>
	<CAAS2fgR1aGOpVoLyGWtO=Q5XU04gBMBEQARPtxMe4WnwQ2CO5w@mail.gmail.com>
Message-ID: <a09c16fc-528d-da3f-1ea2-18009c57af13@osc.co.cr>

On 07/12/2017 06:04 PM, Gregory Maxwell wrote:
> On Wed, Jul 12, 2017 at 6:17 AM, Dan Libby via bitcoin-dev

> It is not simple to do so correctly, I couldn't tell you off the top
> of my head; a number of things must be changed it isn't as simple as
> disabling the activiation because of the segwit P2P changes.  Nor is
> it a supported configuration. Even if it were now, it wouldn't be one
> we'd continue to support in the future after segwit is active, as
> we're likely to drop deployment/compat code.

I understand it is not in any way a supported configuration.

> Can you explain why you wish to do this?  It should have absolutely no
> adverse impact on you-- if you don't use segwit, you don't use it-- it
> may be the case that there is some confusion about the implications
> that I could clear up for you... or suggest alternatives that might
> achieve your goals.

Please lets not go into the weeds debating about my reasons.

I actually have nothing against segwit per-se, and think it is clever
tech.  I wish that it, or another malleability fix, had been baked in
from the start.  But it wasn't, and I dislike changing the consensus
rules except if critical flaws are found.


anyway, some of my reasons are:

I am content with status-quo consensus rules.

I see greatest long-term value in a fixed, unchanging set of rules
(though that is outside my control of course).

I have limited bandwidth and resources and prefer 1mb limit for that reason.

Prior to activation, I do not choose to signal for segwit in any way
shape or form.

I realize I could run a pre-segwit node forever, but would like to enjoy
more recent features and otherwise avoid bit-rot.

I am mule-headed and stubborn.  If network-wide activation should
happen, I will most likely upgrade to segwit at some point, but I intend
that point to be at my choosing, not because software defaults did it
for me.

I view it as a little bit of a personal challenge and experiment.

> Effectively the only reason I'm aware of to intentionally not run with
> segwit support beyond just not having upgraded yet, is a desire to try
> to temporarily have as your tip block a block that was actively
> stealing the segwit transactions of a third party. Which doesn't seem
> either personally or publicly desirable; but I fully admit I may be
> missing some good reason which I am not aware of.

no that thought did not enter my mind.  still not sure I fully grok it
in fact, but no matter.



-- 
Dan Libby

Open Source Consulting S.A.
Santa Ana, Costa Rica
http://osc.co.cr
phone: 011 506 2204 7018
Fax: 011 506 2223 7359

From dan at osc.co.cr  Thu Jul 13 16:13:04 2017
From: dan at osc.co.cr (Dan Libby)
Date: Thu, 13 Jul 2017 09:13:04 -0700
Subject: [bitcoin-dev] how to disable segwit in my build?
In-Reply-To: <20170713014826.GA12388@erisian.com.au>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<CAAS2fgTsjfMGw6D_OxDthSrrdLEFx2skGedLAjTwz3yCQijyug@mail.gmail.com>
	<001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com>
	<CAAS2fgR3FQ-wSwGwK6PDD_nZKpnBDAtM=5-fvR-smDa48xjW4Q@mail.gmail.com>
	<03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr>
	<20170713014826.GA12388@erisian.com.au>
Message-ID: <4a4d74b0-c55b-239d-5563-9c964ecd61b6@osc.co.cr>

On 07/12/2017 06:48 PM, Anthony Towns via bitcoin-dev wrote:

> I think that terminology isn't quite precise. I think your options are:
> 
>  - if you're a miner or run a mining pool, you can *signal* (or not
>    signal) support for segwit activation; you do this by controlling
>    the block version

I wish to NOT signal for segwit if mining.

>  - if you're running a node, you can choose to *enforce* (or not
>    enforce) the additional consensus rules associated with segwit

I wish to NOT enforce segwit consensus rules.

> 
> I think it's the latter you're talking about. "Activation" is different:
> it's the collective action of the bitcoin ecosystem to start enforcing
> the segwit consensus rules after a sufficient majority of miners are
> signalling support. That's not something you as an individual can control.

good point, thanks for clarifying.

> If you want to disable enforcement of segwit rules, even if a majority of
> mining power signal activation, you can change the code and recompile to
> do so, for example by changing the nTimeout setting for DEPLOYMENT_SEGWIT
> from 1510704000 (Nov 15 2017) to 1493596800 (May 1 2017, already expired).
> This is probably a bad idea, in that it will cause you to risk accepting
> blocks that nobody else in the network will accept, opening you up
> to higher risk of double spends, and may cause you to be unable to
> peer with segwit enabled nodes after segwit is activated if your node
> is rejecting blocks with witness data because you think segwit is not
> enabled while they think it is enabled. To avoid that you would also need
> to stop setting the NODE_WITNESS p2p bit, which you might be able to do
> by setting the nTimeout above to 0 instead of just a date in the past? I
> believe a timeout of 0 gets treated as automatically FAILED. There might
> be other complexities too though.

I've set the nTimeout to 0 already.  I will look into the NODE_WITNESS
p2p bit.

I think that logically, if coded correctly, my node would have no more
risks than any other legacy (pre-segwit) node on the network...

> 
>> I'm not looking for reasons NOT to do it, only HOW to do it without
>> unwanted side-effects.
> 
> The unwanted side-effects are precisely the reasons not to do it. If you
> don't understand what they are, you won't be able to avoid them. :)

fair enough.  But these are the same risks as running any pre-segwit
node, correct?    For example bitcoin-core 0.13.0, or any version of
btcd to date...


-- 
Dan Libby

Open Source Consulting S.A.
Santa Ana, Costa Rica
http://osc.co.cr
phone: 011 506 2204 7018
Fax: 011 506 2223 7359

From dan at osc.co.cr  Thu Jul 13 16:19:00 2017
From: dan at osc.co.cr (Dan Libby)
Date: Thu, 13 Jul 2017 09:19:00 -0700
Subject: [bitcoin-dev] how to disable segwit in my build?
In-Reply-To: <CAFMkqK9+pvRRtcOomo6is5t8xQ2gLmGb7XaGV80TOm-eO6ZoqA@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<CAAS2fgTsjfMGw6D_OxDthSrrdLEFx2skGedLAjTwz3yCQijyug@mail.gmail.com>
	<001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com>
	<CAAS2fgR3FQ-wSwGwK6PDD_nZKpnBDAtM=5-fvR-smDa48xjW4Q@mail.gmail.com>
	<03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr>
	<CAAS2fgR1aGOpVoLyGWtO=Q5XU04gBMBEQARPtxMe4WnwQ2CO5w@mail.gmail.com>
	<CAP=-fx6hju0NAa-HcYzivwNbJH0HXwUL=t7iD38XAK_Fwodjng@mail.gmail.com>
	<CAFMkqK9+pvRRtcOomo6is5t8xQ2gLmGb7XaGV80TOm-eO6ZoqA@mail.gmail.com>
Message-ID: <0be972b9-328c-394a-1e90-bd7a37642598@osc.co.cr>

On 07/13/2017 06:39 AM, Hampus Sj?berg via bitcoin-dev wrote:
>> I believe that a good reason not to wish your node to be segwit
> compliant is to avoid having to deal with the extra bandwidth that
> segwit could require.   Running a 0.14.2 node means being ok with >1MB
> blocks, in case segwit is activated and widely used. Users not
> interested in segwit transactions may prefer to keep the cost of their
> node lower.
> 
> If the majority of the network decides to deploy SegWit, it would be in
> your best interest to validate the SegWit transactions, because you
> might will be downgraded to near-SPV node validation.
> It would be okay to still run a "non-SegWit" node if there's no SegWit
> transactions in the chain of transactions for your bitcoins, otherwise
> you cannot fully verify the the ownership of your bitcoins.
> I'm not sure the practicality of this in the long run, but it makes a
> case for having an up-to-date non-SegWit node, although I think it's a
> bit of a stretch.

Right.  Well, if I never upgrade to segwit, then there seems little
(zero?) risk of having any segwit tx in my tx chain.

Thus this would be a way I could continue with a lower bandwidth cap and
also keep my coins "untainted", so to speak.

I'm not sure about it for the long run either.  more just something of
an experiment.

From jameson.lopp at gmail.com  Thu Jul 13 16:35:46 2017
From: jameson.lopp at gmail.com (Jameson Lopp)
Date: Thu, 13 Jul 2017 12:35:46 -0400
Subject: [bitcoin-dev] how to disable segwit in my build?
In-Reply-To: <0be972b9-328c-394a-1e90-bd7a37642598@osc.co.cr>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<CAAS2fgTsjfMGw6D_OxDthSrrdLEFx2skGedLAjTwz3yCQijyug@mail.gmail.com>
	<001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com>
	<CAAS2fgR3FQ-wSwGwK6PDD_nZKpnBDAtM=5-fvR-smDa48xjW4Q@mail.gmail.com>
	<03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr>
	<CAAS2fgR1aGOpVoLyGWtO=Q5XU04gBMBEQARPtxMe4WnwQ2CO5w@mail.gmail.com>
	<CAP=-fx6hju0NAa-HcYzivwNbJH0HXwUL=t7iD38XAK_Fwodjng@mail.gmail.com>
	<CAFMkqK9+pvRRtcOomo6is5t8xQ2gLmGb7XaGV80TOm-eO6ZoqA@mail.gmail.com>
	<0be972b9-328c-394a-1e90-bd7a37642598@osc.co.cr>
Message-ID: <CADL_X_cZc4K3k=JzVES7Jba6qqZwv0Lx7opCi8eL_GM5M01Y8A@mail.gmail.com>

On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On 07/13/2017 06:39 AM, Hampus Sj?berg via bitcoin-dev wrote:
> >> I believe that a good reason not to wish your node to be segwit
> > compliant is to avoid having to deal with the extra bandwidth that
> > segwit could require.   Running a 0.14.2 node means being ok with >1MB
> > blocks, in case segwit is activated and widely used. Users not
> > interested in segwit transactions may prefer to keep the cost of their
> > node lower.
> >
> > If the majority of the network decides to deploy SegWit, it would be in
> > your best interest to validate the SegWit transactions, because you
> > might will be downgraded to near-SPV node validation.
> > It would be okay to still run a "non-SegWit" node if there's no SegWit
> > transactions in the chain of transactions for your bitcoins, otherwise
> > you cannot fully verify the the ownership of your bitcoins.
> > I'm not sure the practicality of this in the long run, but it makes a
> > case for having an up-to-date non-SegWit node, although I think it's a
> > bit of a stretch.
>
> Right.  Well, if I never upgrade to segwit, then there seems little
> (zero?) risk of having any segwit tx in my tx chain.
>
>
If you mean you wish to avoid receiving UTXOs that have value that was at
one point previously encumbered by a SegWit output then no, you can't avoid
that. No more than you can currently avoid receiving BTC that were at one
point in time encumbered by a P2SH output.


> Thus this would be a way I could continue with a lower bandwidth cap and
> also keep my coins "untainted", so to speak.
>
> I'm not sure about it for the long run either.  more just something of
> an experiment.
> _______________________________________________
> 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/20170713/406a3f3b/attachment.html>

From truthcoin at gmail.com  Thu Jul 13 17:04:01 2017
From: truthcoin at gmail.com (Paul Sztorc)
Date: Thu, 13 Jul 2017 13:04:01 -0400
Subject: [bitcoin-dev] Drivechain RfD -- Follow Up
In-Reply-To: <CAFMkqK_2V+p0JmrAj5WSkEDWXWG4h4c1SzZ4mxEiZBwDpAHd4A@mail.gmail.com>
References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com>
	<83671224-f6ff-16a9-81c0-20ab578aec9d@gmail.com>
	<AAC86547-7904-4475-9966-138130019567@taoeffect.com>
	<6764b8af-bb4c-615d-5af5-462127bbbe36@gmail.com>
	<F2C3A9F4-07AB-41B9-B915-9E33EE313F9E@taoeffect.com>
	<117f6a96-6d90-778a-d87a-be72592e31c5@gmail.com>
	<42C03DFC-C358-4F8C-A088-735910CCC60E@taoeffect.com>
	<3277f4ef-a250-d383-8b00-cb912eb19f8b@gmail.com>
	<CAFMkqK_2V+p0JmrAj5WSkEDWXWG4h4c1SzZ4mxEiZBwDpAHd4A@mail.gmail.com>
Message-ID: <dd7bc896-e9f5-c8a2-aaf2-cdcfad43b44c@gmail.com>

Hello,


On 7/13/2017 9:17 AM, Hampus Sj?berg wrote:
> In softforks, I would argue that 100% of all nodes and miners need to
> upgrade to the new rules.
> This makes sure that trying to incorrectly spend an "AnyOneCanSpend"
> will result in a hardfork, instead of a temporary (or permanent)
> chainsplit.
>
> With drivechains, it seems like the current plan is to only let the
> nodes that are interested in the drivechain validate the other chain,
> and not necessarily 100% of the network.

Correct.


> I guess this could be any percentage of the network, which could lead
> to a temporary/permanent chainsplit depending on how many percentage
> of the miners are also validating the other chain (am I missing
> something here?).
> I have no way to evaluate if this is an okay trade-off.
> It seems like major disruption could very likely happen if say only 5%
> of all fullnodes validate the drivechain.


You are correct that some % of the network would be validating both
chains. However, if miners improperly withdraw from a sidechain, it --by
design-- does not lead to any chainsplit of any kind. Instead, the
sidechain in question just dies a painful death (notice that, if any
withdrawals are improper, it is quite as bad as if all of the sidechain
funds were withdrawn improperly -- this is because the sidechain would
instantly have a bunch of problems, including that it would be
something-like 'fractional reserve' which would lead to an immediate
bank run of withdrawals [none of which could have any real expectation
of success, in my view]).

In practice, a concern of mine is that people *would* try to turn a
sidechain-theft even into some kind of grand UASF-style campaign. I
would prefer for people not to do this. Then again, I do not hold this
preference unconditionally -- I see it as comparable to Bitcoin's
commitment to "the code is the spec". Which is to say that this
commitment is overwhelmingly held, but not dogmatically as in
exceptional cases such as theValue overflow incident [1].

I think that in such ambiguous cases, we must rely on [a] the miner's
desire to maximize the purchasing power of each Bitcoin, and [b] the
technical wisdom of Bitcoin's future leaders in helping miners to
achieve this goal.

[1] https://en.bitcoin.it/wiki/Value_overflow_incident


> To be fully secure, it seems like 100% of all nodes should also have a
> fullnode for the drivechain as well...

Perhaps, but this is exactly what I am trying to avoid. The design goal,
in some sense, is to have "half security", ie <100%. This is because the
only way to achieve "full" 100% security is with full enforcement of all
rules. Full enforcement of the rules, in turn, means either that we are
exactly where we are right now (where we only add compatible rules, aka
the traditional "soft fork") or we are [also] exactly where we are right
now (in that if we add an incompatible rule, it results in a "hard
fork"). I would like to build something new, which trades off on the
qualities of each, and therefore lies (intentionally) somewhere in between.


> This is one of the reasons I don't advocate sidechains/drivechains as
> a scaling solution, it looks like it would have to the same outcome as
> a blocksize increase on the mainchain, but with more complexity.

Keep in mind that, if some people leave the small chain (what you might
call the "Core" chain, although some disagree with summarizing it this
way) for some other chain, it does free up more space on this chain.

I'm not really sure the extent to which that "counts" as increasing
capacity.

Also, I agree that sc/dc do not help with "scalability", if that problem
is defined as "better technology" or as "how to do more with less".

Actually my full view is a little nuanced and it is here:
http://www.drivechain.info/faq/index.html#can-sidechains-really-help-with-scaling


> Thanks for all your work so far Paul.

You're welcome!

Paul




From sergio.d.lerner at gmail.com  Thu Jul 13 19:19:35 2017
From: sergio.d.lerner at gmail.com (Sergio Demian Lerner)
Date: Thu, 13 Jul 2017 16:19:35 -0300
Subject: [bitcoin-dev] A Segwit2x BIP
In-Reply-To: <CABm2gDqgve88eE4=dDD8FqGZQNNgRtOvXAhqSTWu_wy4zG+6Eg@mail.gmail.com>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
	<CAKzdR-oRdX-fXyc6womZOyYyfHUJZdgh92FUMM8pR_QDNiJfkQ@mail.gmail.com>
	<CABm2gDo0wgqkEufKn=Z8uAsi=_6fgE=0TS6Bcr21mg3xAX7Kyw@mail.gmail.com>
	<7869651.CRYTeDpGy9@strawberry>
	<CABm2gDqgve88eE4=dDD8FqGZQNNgRtOvXAhqSTWu_wy4zG+6Eg@mail.gmail.com>
Message-ID: <CAKzdR-p2F3HLnU7aV7U645mrCOQ5ye4CWSeyzeb0O0j815QAfA@mail.gmail.com>

The BIP has been updated.

Changes:
- The technical spec has been improved: now the block size increase is
specified in terms of weight and not in terms of bytes.
- The increase in the maximum block sigops after HF has been documented.
- Comments added about the worst case block size.

Happy weekend! And don't forget to start signaling something before block
475776 !  It's just 90 blocks away.
Bit 1 or 4,1 or whatever you wish, but please signal something.

To the moon!


On Wed, Jul 12, 2017 at 2:38 PM, Jorge Tim?n via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

>
>
> On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" <bitcoin-dev at lists.
> linuxfoundation.org> wrote:
>
> On Monday, 10 July 2017 20:38:08 CEST Jorge Tim?n via bitcoin-dev wrote:
> > I think anything less than 1 year after release of tested code by some
> > implementation would be irresponsible for any hardfork, even a very
> > simple one.
>
> Good news!
>
> Code to support 2x (the hard fork part of the proposal) has been out and
> tested for much longer than that.
>
>
> Not true. It's different code on top of segwit. The first attempt in btc1
> (very recent) didn't even increased the size (because it changed the
> meaningless "base size" without touching the weight limit. As for the
> current code, I don't think it has been properly tested today, let alone
> "for mucj longer than 1 year.
> Anyway, I said, one year from tested release. Segwitx2 hasn't been
> released, has it? If so, too late to discuss a bip imo, the bip may end up
> being different from what has been released due to feedback (unless it is
> ignored again, of course).
>
>
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> _______________________________________________
> 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/20170713/03b124d8/attachment.html>

From chris at suredbits.com  Thu Jul 13 20:22:02 2017
From: chris at suredbits.com (Chris Stewart)
Date: Thu, 13 Jul 2017 15:22:02 -0500
Subject: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
 Merge Mined drivechains
In-Reply-To: <7fc82c47-c03a-f489-55c2-b7d6830c1a74@gmail.com>
References: <CAGL6+mHQ_vMc2JYVqwfP89WOZdUF2WDtWfh7ccL1PQve=nC+zQ@mail.gmail.com>
	<OozQK1_gWeExd5578AYH_dHnSKSvx63FJc2rIBBcaJF4f07qzsR8rr-ka5epwMFCjqDuidAWZiZqqlvn4xvSuUpDY0KkV014VQs6_E3Rp_A=@protonmail.com>
	<2f2e6b7c-2d47-518a-5a8f-0b5333607aac@gmail.com>
	<lYqi6yZAdUknHWs2DvSaM3h1tf3EVLngILZV9gbVBm5JVI96RvBGZaPBEFYNzt0QBkjdJ614BTsWjUkmuuqSd7RPFx-ihUL6SIXocqyW_ss=@protonmail.com>
	<98d35291-5948-cb06-c46a-9d209276cee2@gmail.com>
	<GDZ42AMqaETJGYZovJzkVZkxZE3UmCQ8q5fFTAajV6sX2LHFol6iEYahkY_sMrPv5m11lHZvuKXmD_PwXa5_S7x18vcP1FkQr0ZBROxj6HE=@protonmail.com>
	<CAGL6+mEeuhQp3TiLFOOAWO_wcRZXsfASKNT4364SSNzER6_xgw@mail.gmail.com>
	<hvQJ5M9JSIbEjJuabefPJi_DBqDTTXYnJ1xEg7_rBozOBrI8WDzL6zwn9Zt7au5QHc3P3DPNYDBrsQCTkSB6lOFWPJ8UuY_W4GyIzQ-Qvfs=@protonmail.com>
	<CAMZUoK==7OATOJ=46CYJWkq=WAXnJ8-JjvL25E1ijhnRbqj_Jg@mail.gmail.com>
	<CAGL6+mHErvPbvKxrQkJ=DdTuzH-4Fsxh8JnnzVY16m2x6zeJFQ@mail.gmail.com>
	<CAGL6+mE9TF=LeNwN2a6Ky+B=jqmW=1HqGOj6bPq2G3Aq8+FZAw@mail.gmail.com>
	<7fc82c47-c03a-f489-55c2-b7d6830c1a74@gmail.com>
Message-ID: <CAGL6+mEepScU-ZjrprQZo4hN5J05pGd63CapHWc3XNVAf43s1g@mail.gmail.com>

I'm interested in hearing a reply from Russell/ZmnSCPxj in what they think
about lightning bribes. I hadn't given much thought about those while
writing my original BIP, but it does seem like my original BIP (minus the
fixed indexes in the coinbase output) fits this pretty well. If I
understand Paul correctly the OP_BV output will never hit the blockchain
then -- only the commitment in the coinbase transaction. This means no
extra data (if use lightning) has to be added to the blockchain *except*
the drivechain commitment (34 bytes in the coinbase tx vout). If this is
used for the vast majority bribes it may make the op code worth it.

In general though, I'm still unclear of what purpose the 'Ratchet' serves.
Can you either link to documentation about it or write something up quick?

-Chris

On Wed, Jul 12, 2017 at 7:00 PM, Paul Sztorc <truthcoin at gmail.com> wrote:

> I still think it may be more inefficient, in equilibrium. (In other words,
> in the future steady state of Bitcoin that includes LN or something
> LN-like).
>
> Assume there are N sidechains.
>
> In the coinbase version:
> 1. There is some single event, per N, that causes nodes to notice that a
> new sidechain has been created.
> 2. Per block, there are N hash commitments (32 bytes) and N instances of
> the ratchet's block counter (2 bytes).
> 3. Per block, some node operator _may_ have BMMed the block, and a miner
> therefore might want redeem an OP Bribe that pays BTC from a sidechain node
> operator to the miner. But they are likely to negotiate the payment through
> the Lightning Network (when this is possible).
> 4. Sidechains running in SPV mode know exactly where to find the
> information they need in order to discover the "longest" chain.
>
> In the OP RETURN version:
> 1. [same] There is some single event, per N, that causes nodes to notice
> that a new sidechain has been created.
> 2. [+30 bytes (+more?)] Per block, there are N hash commitments (32 bytes)
> and also N prevBlockHashes (32 bytes). Also, to make this transaction,
> someone needs to spend something in the UTXO set (or select no inputs in a
> kind of 'hollow transaction'), whereas one coinbase will always exist per
> block.
> 3. [same] No need for a new transaction.
> 4. [same?] Due to Rusty's soft fork rule of only one h* per sidechain per
> block, sidechains need just a merkle tree path, but they don't necessarily
> know where it is. They must store extra [?] data to help them find the
> data's location?
>
>
> On 7/12/2017 2:02 PM, Chris Stewart via bitcoin-dev wrote:
>
> Hi Russell/ZmnSCPxj,
>
> I think you guys are right. The only problem I can see with it is
> replaceability of the bribe transaction. If the 'Bribe' is the fee on the
> transaction it isn't clear to me what the best way to replace/remove it is.
>
>
> I think that that is the purpose of Rusty's soft fork rule about only
> including one per sidechain -- miners would have one "slot" per sidechain,
> and they would therefore have an incentive to make the slot count, and
> would be only selecting the highest fee txn to fill each slot.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170713/7914e30b/attachment.html>

From truthcoin at gmail.com  Thu Jul 13 20:45:13 2017
From: truthcoin at gmail.com (Paul Sztorc)
Date: Thu, 13 Jul 2017 16:45:13 -0400
Subject: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
 Merge Mined drivechains
In-Reply-To: <CAGL6+mEepScU-ZjrprQZo4hN5J05pGd63CapHWc3XNVAf43s1g@mail.gmail.com>
References: <CAGL6+mHQ_vMc2JYVqwfP89WOZdUF2WDtWfh7ccL1PQve=nC+zQ@mail.gmail.com>
	<2f2e6b7c-2d47-518a-5a8f-0b5333607aac@gmail.com>
	<lYqi6yZAdUknHWs2DvSaM3h1tf3EVLngILZV9gbVBm5JVI96RvBGZaPBEFYNzt0QBkjdJ614BTsWjUkmuuqSd7RPFx-ihUL6SIXocqyW_ss=@protonmail.com>
	<98d35291-5948-cb06-c46a-9d209276cee2@gmail.com>
	<GDZ42AMqaETJGYZovJzkVZkxZE3UmCQ8q5fFTAajV6sX2LHFol6iEYahkY_sMrPv5m11lHZvuKXmD_PwXa5_S7x18vcP1FkQr0ZBROxj6HE=@protonmail.com>
	<CAGL6+mEeuhQp3TiLFOOAWO_wcRZXsfASKNT4364SSNzER6_xgw@mail.gmail.com>
	<hvQJ5M9JSIbEjJuabefPJi_DBqDTTXYnJ1xEg7_rBozOBrI8WDzL6zwn9Zt7au5QHc3P3DPNYDBrsQCTkSB6lOFWPJ8UuY_W4GyIzQ-Qvfs=@protonmail.com>
	<CAMZUoK==7OATOJ=46CYJWkq=WAXnJ8-JjvL25E1ijhnRbqj_Jg@mail.gmail.com>
	<CAGL6+mHErvPbvKxrQkJ=DdTuzH-4Fsxh8JnnzVY16m2x6zeJFQ@mail.gmail.com>
	<CAGL6+mE9TF=LeNwN2a6Ky+B=jqmW=1HqGOj6bPq2G3Aq8+FZAw@mail.gmail.com>
	<7fc82c47-c03a-f489-55c2-b7d6830c1a74@gmail.com>
	<CAGL6+mEepScU-ZjrprQZo4hN5J05pGd63CapHWc3XNVAf43s1g@mail.gmail.com>
Message-ID: <918a1b0c-65e6-a67f-c0d5-c4e6170d2e70@gmail.com>

On 7/13/2017 4:22 PM, Chris Stewart wrote:
> In general though, I'm still unclear of what purpose the 'Ratchet'
> serves. Can you either link to documentation about it or write
> something up quick?
>
> -Chris

In Bitcoin, new coins are held for 100 blocks. One result of this is
that the coins can't be spent until there is at least 100 blocks worth
of evidence that they actually are in the longest chain, and are
unlikely to be orphaned.

In BMM, we are concerned about exactly this. For example, imagine that I
bribe you $20 to find my side:block (and, in that block I earn $20.50
worth of side:BTC tx fees), which you do. But then, moments later, you
(or some other miner) orphans the block! So I don't get my $20.50, but
you still keep my $20!

And yet, we want the mainchain to validate as little as possible about
each sidechain. We want a "light touch". So we force the h* to be
accompanied by the modulus of its sidechain block number (we call it
"BlockMod"). The sidechain has a new rule that requires h* to be
included AND that the BlockMod be accurate, in order for the sidechain
block to meet the "synthetic" difficulty requirement. The mainchain has
a new rule forcing each new BlockMod to be in range [-X000,+1] relative
to the old BlockMod (ie, "no skipping ahead, but you can reorg by
starting a new chain from up to a=-X000 blocks ago" ... likely values of
X might be 2 or 4). And finally, BMM has a new rule that the bribe isn't
paid unless the sidechain block in question has been buried by [for
example] 100 sidechain blocks.

Hope that helps,
Paul


From achow101-lists at achow101.com  Thu Jul 13 19:48:52 2017
From: achow101-lists at achow101.com (Andrew Chow)
Date: Thu, 13 Jul 2017 12:48:52 -0700
Subject: [bitcoin-dev] A Segwit2x BIP
In-Reply-To: <CAKzdR-p2F3HLnU7aV7U645mrCOQ5ye4CWSeyzeb0O0j815QAfA@mail.gmail.com>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
	<CAKzdR-oRdX-fXyc6womZOyYyfHUJZdgh92FUMM8pR_QDNiJfkQ@mail.gmail.com>
	<CABm2gDo0wgqkEufKn=Z8uAsi=_6fgE=0TS6Bcr21mg3xAX7Kyw@mail.gmail.com>
	<7869651.CRYTeDpGy9@strawberry>
	<CABm2gDqgve88eE4=dDD8FqGZQNNgRtOvXAhqSTWu_wy4zG+6Eg@mail.gmail.com>
	<CAKzdR-p2F3HLnU7aV7U645mrCOQ5ye4CWSeyzeb0O0j815QAfA@mail.gmail.com>
Message-ID: <15d3d788980.2780.1c2d389d777ac0f91cb66d796583d663@achow101.com>

What's special about block 475776?


On July 13, 2017 12:23:46 PM Sergio Demian Lerner via bitcoin-dev 
<bitcoin-dev at lists.linuxfoundation.org> wrote:

> The BIP has been updated.
>
> Changes:
> - The technical spec has been improved: now the block size increase is
> specified in terms of weight and not in terms of bytes.
> - The increase in the maximum block sigops after HF has been documented.
> - Comments added about the worst case block size.
>
> Happy weekend! And don't forget to start signaling something before block
> 475776 !  It's just 90 blocks away.
> Bit 1 or 4,1 or whatever you wish, but please signal something.
>
> To the moon!
>
>
> On Wed, Jul 12, 2017 at 2:38 PM, Jorge Tim?n via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>
>>
>> On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" <bitcoin-dev at lists.
>> linuxfoundation.org> wrote:
>>
>> On Monday, 10 July 2017 20:38:08 CEST Jorge Tim?n via bitcoin-dev wrote:
>> > I think anything less than 1 year after release of tested code by some
>> > implementation would be irresponsible for any hardfork, even a very
>> > simple one.
>>
>> Good news!
>>
>> Code to support 2x (the hard fork part of the proposal) has been out and
>> tested for much longer than that.
>>
>>
>> Not true. It's different code on top of segwit. The first attempt in btc1
>> (very recent) didn't even increased the size (because it changed the
>> meaningless "base size" without touching the weight limit. As for the
>> current code, I don't think it has been properly tested today, let alone
>> "for mucj longer than 1 year.
>> Anyway, I said, one year from tested release. Segwitx2 hasn't been
>> released, has it? If so, too late to discuss a bip imo, the bip may end up
>> being different from what has been released due to feedback (unless it is
>> ignored again, of course).
>>
>>
>> --
>> Tom Zander
>> Blog: https://zander.github.io
>> Vlog: https://vimeo.com/channels/tomscryptochannel
>> _______________________________________________
>> 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/20170713/0c5c6106/attachment-0001.html>

From cs at charlieshrem.com  Thu Jul 13 21:18:58 2017
From: cs at charlieshrem.com (Charlie 'Charles' Shrem)
Date: Thu, 13 Jul 2017 17:18:58 -0400
Subject: [bitcoin-dev] A Segwit2x BIP
In-Reply-To: <15d3d788980.2780.1c2d389d777ac0f91cb66d796583d663@achow101.com>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
	<CAKzdR-oRdX-fXyc6womZOyYyfHUJZdgh92FUMM8pR_QDNiJfkQ@mail.gmail.com>
	<CABm2gDo0wgqkEufKn=Z8uAsi=_6fgE=0TS6Bcr21mg3xAX7Kyw@mail.gmail.com>
	<7869651.CRYTeDpGy9@strawberry>
	<CABm2gDqgve88eE4=dDD8FqGZQNNgRtOvXAhqSTWu_wy4zG+6Eg@mail.gmail.com>
	<CAKzdR-p2F3HLnU7aV7U645mrCOQ5ye4CWSeyzeb0O0j815QAfA@mail.gmail.com>
	<15d3d788980.2780.1c2d389d777ac0f91cb66d796583d663@achow101.com>
Message-ID: <CAC787aPSRyJwgv4T3MhYrLRmAHuz0MuLRE5_K6teWYoiSnKnbQ@mail.gmail.com>

Andrew,

Block 475776 and block 477792 (July 26) are the last 2 difficulty
adjustment periods before Aug 1st.

Charlie

On Thu, Jul 13, 2017 at 3:48 PM, Andrew Chow via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> What's special about block 475776?
>
> On July 13, 2017 12:23:46 PM Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> The BIP has been updated.
>>
>> Changes:
>> - The technical spec has been improved: now the block size increase is
>> specified in terms of weight and not in terms of bytes.
>> - The increase in the maximum block sigops after HF has been documented.
>> - Comments added about the worst case block size.
>>
>> Happy weekend! And don't forget to start signaling something before block
>> 475776 !  It's just 90 blocks away.
>> Bit 1 or 4,1 or whatever you wish, but please signal something.
>>
>> To the moon!
>>
>>
>> On Wed, Jul 12, 2017 at 2:38 PM, Jorge Tim?n via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>>
>>>
>>> On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> On Monday, 10 July 2017 20:38:08 CEST Jorge Tim?n via bitcoin-dev wrote:
>>> > I think anything less than 1 year after release of tested code by some
>>> > implementation would be irresponsible for any hardfork, even a very
>>> > simple one.
>>>
>>> Good news!
>>>
>>> Code to support 2x (the hard fork part of the proposal) has been out and
>>> tested for much longer than that.
>>>
>>>
>>> Not true. It's different code on top of segwit. The first attempt in
>>> btc1 (very recent) didn't even increased the size (because it changed the
>>> meaningless "base size" without touching the weight limit. As for the
>>> current code, I don't think it has been properly tested today, let alone
>>> "for mucj longer than 1 year.
>>> Anyway, I said, one year from tested release. Segwitx2 hasn't been
>>> released, has it? If so, too late to discuss a bip imo, the bip may end up
>>> being different from what has been released due to feedback (unless it is
>>> ignored again, of course).
>>>
>>>
>>> --
>>> Tom Zander
>>> Blog: https://zander.github.io
>>> Vlog: https://vimeo.com/channels/tomscryptochannel
>>> _______________________________________________
>>> 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
>>
>>
> _______________________________________________
> 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/20170713/6321b907/attachment.html>

From dan at osc.co.cr  Thu Jul 13 21:58:04 2017
From: dan at osc.co.cr (Dan Libby)
Date: Thu, 13 Jul 2017 14:58:04 -0700
Subject: [bitcoin-dev] how to disable segwit in my build?
In-Reply-To: <CADL_X_cZc4K3k=JzVES7Jba6qqZwv0Lx7opCi8eL_GM5M01Y8A@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<CAAS2fgTsjfMGw6D_OxDthSrrdLEFx2skGedLAjTwz3yCQijyug@mail.gmail.com>
	<001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com>
	<CAAS2fgR3FQ-wSwGwK6PDD_nZKpnBDAtM=5-fvR-smDa48xjW4Q@mail.gmail.com>
	<03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr>
	<CAAS2fgR1aGOpVoLyGWtO=Q5XU04gBMBEQARPtxMe4WnwQ2CO5w@mail.gmail.com>
	<CAP=-fx6hju0NAa-HcYzivwNbJH0HXwUL=t7iD38XAK_Fwodjng@mail.gmail.com>
	<CAFMkqK9+pvRRtcOomo6is5t8xQ2gLmGb7XaGV80TOm-eO6ZoqA@mail.gmail.com>
	<0be972b9-328c-394a-1e90-bd7a37642598@osc.co.cr>
	<CADL_X_cZc4K3k=JzVES7Jba6qqZwv0Lx7opCi8eL_GM5M01Y8A@mail.gmail.com>
Message-ID: <4921ce4f-06bc-8ff1-4e70-5bd55d1ff5ca@osc.co.cr>

On 07/13/2017 09:35 AM, Jameson Lopp wrote:
> 
> 
> On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> 
>     On 07/13/2017 06:39 AM, Hampus Sj?berg via bitcoin-dev wrote:
>     >> I believe that a good reason not to wish your node to be segwit
>     > compliant is to avoid having to deal with the extra bandwidth that
>     > segwit could require.   Running a 0.14.2 node means being ok with >1MB
>     > blocks, in case segwit is activated and widely used. Users not
>     > interested in segwit transactions may prefer to keep the cost of their
>     > node lower.
>     >
>     > If the majority of the network decides to deploy SegWit, it would be in
>     > your best interest to validate the SegWit transactions, because you
>     > might will be downgraded to near-SPV node validation.
>     > It would be okay to still run a "non-SegWit" node if there's no SegWit
>     > transactions in the chain of transactions for your bitcoins, otherwise
>     > you cannot fully verify the the ownership of your bitcoins.
>     > I'm not sure the practicality of this in the long run, but it makes a
>     > case for having an up-to-date non-SegWit node, although I think it's a
>     > bit of a stretch.
> 
>     Right.  Well, if I never upgrade to segwit, then there seems little
>     (zero?) risk of having any segwit tx in my tx chain.
> 
> 
> If you mean you wish to avoid receiving UTXOs that have value that was
> at one point previously encumbered by a SegWit output then no, you can't
> avoid that. No more than you can currently avoid receiving BTC that were
> at one point in time encumbered by a P2SH output.

fair enough.  This actually wasn't an area I'd considered much before
Hampus brought it up.

I would like to understand it a bit better, as I think it applies
equally to any pre-segwit node, yes?   So let's say I am running 0.13.0
and someone sends me bitcoins to a P2PKH address, but that person
previously received them to a P2WPKH address.

If I understand correctly, my node will accept the incoming tx inputs
but obviously will not perform any segwit related validation, thus those
inputs are not fully validated.  I don't yet understand how my node
thinks they are valid at all given that it does not understand P2WPKH
address format, so either it doesn't need to, or P2WPKH is somehow
already valid.  I know this has all been discussed in the past, so if
someone can point me towards a document that explains it I'd be happy to
read that.

thanks!

From hampus.sjoberg at gmail.com  Thu Jul 13 22:50:32 2017
From: hampus.sjoberg at gmail.com (=?UTF-8?Q?Hampus_Sj=C3=B6berg?=)
Date: Fri, 14 Jul 2017 00:50:32 +0200
Subject: [bitcoin-dev] how to disable segwit in my build?
In-Reply-To: <4921ce4f-06bc-8ff1-4e70-5bd55d1ff5ca@osc.co.cr>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<CAAS2fgTsjfMGw6D_OxDthSrrdLEFx2skGedLAjTwz3yCQijyug@mail.gmail.com>
	<001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com>
	<CAAS2fgR3FQ-wSwGwK6PDD_nZKpnBDAtM=5-fvR-smDa48xjW4Q@mail.gmail.com>
	<03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr>
	<CAAS2fgR1aGOpVoLyGWtO=Q5XU04gBMBEQARPtxMe4WnwQ2CO5w@mail.gmail.com>
	<CAP=-fx6hju0NAa-HcYzivwNbJH0HXwUL=t7iD38XAK_Fwodjng@mail.gmail.com>
	<CAFMkqK9+pvRRtcOomo6is5t8xQ2gLmGb7XaGV80TOm-eO6ZoqA@mail.gmail.com>
	<0be972b9-328c-394a-1e90-bd7a37642598@osc.co.cr>
	<CADL_X_cZc4K3k=JzVES7Jba6qqZwv0Lx7opCi8eL_GM5M01Y8A@mail.gmail.com>
	<4921ce4f-06bc-8ff1-4e70-5bd55d1ff5ca@osc.co.cr>
Message-ID: <CAFMkqK-s=Xtg_40dMY7B3ecbOsjtcekHa6qFn2h8dVhuUMv=pw@mail.gmail.com>

> I would like to understand it a bit better, as I think it applies
equally to any pre-segwit node, yes?   So let's say I am running 0.13.0
and someone sends me bitcoins to a P2PKH address, but that person
previously received them to a P2WPKH address.

Yes, this applies to all non-SegWit nodes.

> If I understand correctly, my node will accept the incoming tx inputs
but obviously will not perform any segwit related validation, thus those
inputs are not fully validated.

Yes.
So you have two choices to be fully secure:
1. Validate using the new rules of the network (in other words, run a
SegWit node)
2. Avoid any chain of transaction that contains a SegWit transaction

> I don't yet understand how my node
thinks they are valid at all given that it does not understand P2WPKH
address format, so either it doesn't need to, or P2WPKH is somehow
already valid.

So how softforks often work is that you make the transaction appear to be
always spendable for old nodes, regardless if it really was spendable or
not. This will make sure it is a softfork, the update is backwards
compatible.
If it would be the other way around, if new rules that the node doesn't
understand would always be invalid, it would be hardfork, which is what
we're trying to avoid in the first place.

> so if
someone can point me towards a document that explains it I'd be happy to
read that.

See
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Backward_compatibility
So the witness program is encoded in a new format that old nodes do not
understand.
This means that for old nodes, a number >0 will be put on the stack. When
the script is done, it will be evaluated to true (because of >0) and be
counted as a valid spend.

https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki also
explains the new witness program more in detail (I left out some details in
my explanation).

Cheers
Hampus

2017-07-13 23:58 GMT+02:00 Dan Libby via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> On 07/13/2017 09:35 AM, Jameson Lopp wrote:
> >
> >
> > On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org
> > <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> >
> >     On 07/13/2017 06:39 AM, Hampus Sj?berg via bitcoin-dev wrote:
> >     >> I believe that a good reason not to wish your node to be segwit
> >     > compliant is to avoid having to deal with the extra bandwidth that
> >     > segwit could require.   Running a 0.14.2 node means being ok with
> >1MB
> >     > blocks, in case segwit is activated and widely used. Users not
> >     > interested in segwit transactions may prefer to keep the cost of
> their
> >     > node lower.
> >     >
> >     > If the majority of the network decides to deploy SegWit, it would
> be in
> >     > your best interest to validate the SegWit transactions, because you
> >     > might will be downgraded to near-SPV node validation.
> >     > It would be okay to still run a "non-SegWit" node if there's no
> SegWit
> >     > transactions in the chain of transactions for your bitcoins,
> otherwise
> >     > you cannot fully verify the the ownership of your bitcoins.
> >     > I'm not sure the practicality of this in the long run, but it
> makes a
> >     > case for having an up-to-date non-SegWit node, although I think
> it's a
> >     > bit of a stretch.
> >
> >     Right.  Well, if I never upgrade to segwit, then there seems little
> >     (zero?) risk of having any segwit tx in my tx chain.
> >
> >
> > If you mean you wish to avoid receiving UTXOs that have value that was
> > at one point previously encumbered by a SegWit output then no, you can't
> > avoid that. No more than you can currently avoid receiving BTC that were
> > at one point in time encumbered by a P2SH output.
>
> fair enough.  This actually wasn't an area I'd considered much before
> Hampus brought it up.
>
> I would like to understand it a bit better, as I think it applies
> equally to any pre-segwit node, yes?   So let's say I am running 0.13.0
> and someone sends me bitcoins to a P2PKH address, but that person
> previously received them to a P2WPKH address.
>
> If I understand correctly, my node will accept the incoming tx inputs
> but obviously will not perform any segwit related validation, thus those
> inputs are not fully validated.  I don't yet understand how my node
> thinks they are valid at all given that it does not understand P2WPKH
> address format, so either it doesn't need to, or P2WPKH is somehow
> already valid.  I know this has all been discussed in the past, so if
> someone can point me towards a document that explains it I'd be happy to
> read that.
>
> thanks!
> _______________________________________________
> 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/20170714/6adac594/attachment-0001.html>

From dan at osc.co.cr  Thu Jul 13 23:20:45 2017
From: dan at osc.co.cr (Dan Libby)
Date: Thu, 13 Jul 2017 16:20:45 -0700
Subject: [bitcoin-dev] how to disable segwit in my build?
In-Reply-To: <CAFMkqK-s=Xtg_40dMY7B3ecbOsjtcekHa6qFn2h8dVhuUMv=pw@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<CAAS2fgTsjfMGw6D_OxDthSrrdLEFx2skGedLAjTwz3yCQijyug@mail.gmail.com>
	<001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com>
	<CAAS2fgR3FQ-wSwGwK6PDD_nZKpnBDAtM=5-fvR-smDa48xjW4Q@mail.gmail.com>
	<03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr>
	<CAAS2fgR1aGOpVoLyGWtO=Q5XU04gBMBEQARPtxMe4WnwQ2CO5w@mail.gmail.com>
	<CAP=-fx6hju0NAa-HcYzivwNbJH0HXwUL=t7iD38XAK_Fwodjng@mail.gmail.com>
	<CAFMkqK9+pvRRtcOomo6is5t8xQ2gLmGb7XaGV80TOm-eO6ZoqA@mail.gmail.com>
	<0be972b9-328c-394a-1e90-bd7a37642598@osc.co.cr>
	<CADL_X_cZc4K3k=JzVES7Jba6qqZwv0Lx7opCi8eL_GM5M01Y8A@mail.gmail.com>
	<4921ce4f-06bc-8ff1-4e70-5bd55d1ff5ca@osc.co.cr>
	<CAFMkqK-s=Xtg_40dMY7B3ecbOsjtcekHa6qFn2h8dVhuUMv=pw@mail.gmail.com>
Message-ID: <5af10ca3-8b97-f227-c09f-901bbb6176c3@osc.co.cr>

Hampus, thanks for the explanation!

On 07/13/2017 03:50 PM, Hampus Sj?berg wrote:

> Yes.
> So you have two choices to be fully secure:
> 1. Validate using the new rules of the network (in other words, run a
> SegWit node)
> 2. Avoid any chain of transaction that contains a SegWit transaction

sounds good, though I'm unclear on how exactly to achieve (2) given that
any party I have ever transacted with (or otherwise knows an address of
mine) can send me coins at any time.  So it seems the only possible way
to be certain is to run a node that has never published an address to a
3rd party.  Is that accurate?

Another thing that could be done is to modify my own node so that it
actually rejects such tx, but then I have modified consensus rules
myself, thus defeating the goal of remaining with status-quo rules, and
anyway the rest of the network would accept the tx.  I guess the benefit
is that I could be certain of the remaining funds I have.

I suppose that it would be possible without modifying any rule to
construct a "certain balance" and an "uncertain balance".

I don't intend to do such modifications! just grasping for understanding.


> See
> https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Backward_compatibility
> So the witness program is encoded in a new format that old nodes do not
> understand.
> This means that for old nodes, a number >0 will be put on the stack.
> When the script is done, it will be evaluated to true (because of >0)
> and be counted as a valid spend.
> 
> https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki also
> explains the new witness program more in detail (I left out some details
> in my explanation).

I read the relevant parts, thanks!

From lvella at gmail.com  Thu Jul 13 23:19:12 2017
From: lvella at gmail.com (Lucas Clemente Vella)
Date: Thu, 13 Jul 2017 20:19:12 -0300
Subject: [bitcoin-dev] how to disable segwit in my build?
In-Reply-To: <4921ce4f-06bc-8ff1-4e70-5bd55d1ff5ca@osc.co.cr>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<CAAS2fgTsjfMGw6D_OxDthSrrdLEFx2skGedLAjTwz3yCQijyug@mail.gmail.com>
	<001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com>
	<CAAS2fgR3FQ-wSwGwK6PDD_nZKpnBDAtM=5-fvR-smDa48xjW4Q@mail.gmail.com>
	<03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr>
	<CAAS2fgR1aGOpVoLyGWtO=Q5XU04gBMBEQARPtxMe4WnwQ2CO5w@mail.gmail.com>
	<CAP=-fx6hju0NAa-HcYzivwNbJH0HXwUL=t7iD38XAK_Fwodjng@mail.gmail.com>
	<CAFMkqK9+pvRRtcOomo6is5t8xQ2gLmGb7XaGV80TOm-eO6ZoqA@mail.gmail.com>
	<0be972b9-328c-394a-1e90-bd7a37642598@osc.co.cr>
	<CADL_X_cZc4K3k=JzVES7Jba6qqZwv0Lx7opCi8eL_GM5M01Y8A@mail.gmail.com>
	<4921ce4f-06bc-8ff1-4e70-5bd55d1ff5ca@osc.co.cr>
Message-ID: <CAGCathxswTnEVtAkVmTr+udu_A2V+r4PXeHxkZSLV4uzDDEqPw@mail.gmail.com>

2017-07-13 18:58 GMT-03:00 Dan Libby via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> If I understand correctly, my node will accept the incoming tx inputs
> but obviously will not perform any segwit related validation, thus those
> inputs are not fully validated.  I don't yet understand how my node
> thinks they are valid at all given that it does not understand P2WPKH
> address format, so either it doesn't need to, or P2WPKH is somehow
> already valid.  I know this has all been discussed in the past, so if
> someone can point me towards a document that explains it I'd be happy to
> read that.
>

>From your perspective, the P2WPKH will look like a anyone-can-spend
transaction, thus, valid no matter who is spending. So, you would be
basically leaving the security of segwit transactions to those who actually
are interested in and using them. If your fork becomes popular, it would
decrease the security of Segwit transactions to something akin to the
security model of the Drivechain currently being discussed: only those
particularly interested in that particular sidechain (and segwit witness
could be loosely categorized into a sidechain) will be responsible to
prevent others from stealing funds from the anyone-can-spend transactions.

-- 
Lucas Clemente Vella
lvella at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170713/71992a34/attachment.html>

From tier.nolan at gmail.com  Fri Jul 14 09:03:58 2017
From: tier.nolan at gmail.com (Tier Nolan)
Date: Fri, 14 Jul 2017 10:03:58 +0100
Subject: [bitcoin-dev] how to disable segwit in my build?
In-Reply-To: <5af10ca3-8b97-f227-c09f-901bbb6176c3@osc.co.cr>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<CAAS2fgTsjfMGw6D_OxDthSrrdLEFx2skGedLAjTwz3yCQijyug@mail.gmail.com>
	<001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com>
	<CAAS2fgR3FQ-wSwGwK6PDD_nZKpnBDAtM=5-fvR-smDa48xjW4Q@mail.gmail.com>
	<03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr>
	<CAAS2fgR1aGOpVoLyGWtO=Q5XU04gBMBEQARPtxMe4WnwQ2CO5w@mail.gmail.com>
	<CAP=-fx6hju0NAa-HcYzivwNbJH0HXwUL=t7iD38XAK_Fwodjng@mail.gmail.com>
	<CAFMkqK9+pvRRtcOomo6is5t8xQ2gLmGb7XaGV80TOm-eO6ZoqA@mail.gmail.com>
	<0be972b9-328c-394a-1e90-bd7a37642598@osc.co.cr>
	<CADL_X_cZc4K3k=JzVES7Jba6qqZwv0Lx7opCi8eL_GM5M01Y8A@mail.gmail.com>
	<4921ce4f-06bc-8ff1-4e70-5bd55d1ff5ca@osc.co.cr>
	<CAFMkqK-s=Xtg_40dMY7B3ecbOsjtcekHa6qFn2h8dVhuUMv=pw@mail.gmail.com>
	<5af10ca3-8b97-f227-c09f-901bbb6176c3@osc.co.cr>
Message-ID: <CAE-z3OUdfgpfe30gTp8ptqxgpyLYys+feGA3Cx98d3z9gFtQdw@mail.gmail.com>

On Fri, Jul 14, 2017 at 12:20 AM, Dan Libby via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On 07/13/2017 03:50 PM, Hampus Sj?berg wrote:
> > 2. Avoid any chain of transaction that contains a SegWit transaction
>
> sounds good, though I'm unclear on how exactly to achieve (2) given that
> any party I have ever transacted with (or otherwise knows an address of
> mine) can send me coins at any time.  So it seems the only possible way
> to be certain is to run a node that has never published an address to a
> 3rd party.  Is that accurate?
>

You would also have to ensure that everyone you give your addresses to
follows the same rule.  As time passes, there would be fewer and fewer
people who have "clean" outputs.

>From the perspective of old nodes, segwit looks like lots of people are
transferring money to "anyone-can-spend" outputs.  This outputs are
completely unprotected.  Literally, anyone can spend them.  (In practice,
miners would spend them, since why would they include a transaction that
sends "free money" to someone else).

If you run an old node, then someone could send you a transaction that only
spends segwit outputs and you would think it is a valid payment.

Imagine that there are only 3 UTXOs (Alice, Bob and Carl have all the
Bitcoins).

UTXO-1:  Requires signature by Alice (legacy output)

UTXO-2: Anyone can pay (but is actually a segwit output that needs to be
signed by Bob)

UTXO-3: Anyone can pay (but is actually a segwit output that needs to be
signed by Carl)

Only Bob can spend UTXO-2, since it needs his signature.

Anyone could create a transaction that spends UTXO-2 and it would look good
to all legacy nodes.  It is an "anyone can spend" output after all.

However, if they submit the transaction to the miners, then it will be
rejected, because according to the new rules, it is invalid (it needs to be
signed by Bob).

Once a soft fork goes through, then all miners will enforce the new rules.

A miner who added the transaction to one of his blocks (since it is valid
under the old rules) would find that no other miners would accept his block
and he would get no fees for that block.  This means that all miners have
an incentive to upgrade once a soft fork activates.

His block would be accepted by legacy nodes, for a short while.  However,
since 95% of the miners are on the main chain, their chain (which rejects
his block) would end up the longest.

If you are running a legacy client when a soft fork comes in, then you can
be tricked with "zero confirm" transactions.  The transaction will look
good to you, but will be invalid under the new rules.  This makes your
client think you have received (a lot of) money, but in practice, the
transaction will not be accepted by the miners.


> Another thing that could be done is to modify my own node so that it
> actually rejects such tx, but then I have modified consensus rules
> myself, thus defeating the goal of remaining with status-quo rules, and
> anyway the rest of the network would accept the tx.  I guess the benefit
> is that I could be certain of the remaining funds I have.
>

If you wanted, you could mark any transaction that has a segwit looking
output as "dirty" and then all of its descendants as dirty.

However, pretty quickly, only a tiny fraction of all bitcoins would be
clean.

I suppose that it would be possible without modifying any rule to
> construct a "certain balance" and an "uncertain balance".
>

Right.

I think a reasonably compromise would be to assume that all transactions
buried more than a few hundred blocks deep are probably ok.  Only segwit
looking outputs would be marked as "uncertain".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170714/ed6c4875/attachment.html>

From hampus.sjoberg at gmail.com  Fri Jul 14 08:52:42 2017
From: hampus.sjoberg at gmail.com (=?UTF-8?Q?Hampus_Sj=C3=B6berg?=)
Date: Fri, 14 Jul 2017 10:52:42 +0200
Subject: [bitcoin-dev] how to disable segwit in my build?
In-Reply-To: <5af10ca3-8b97-f227-c09f-901bbb6176c3@osc.co.cr>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<CAAS2fgTsjfMGw6D_OxDthSrrdLEFx2skGedLAjTwz3yCQijyug@mail.gmail.com>
	<001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com>
	<CAAS2fgR3FQ-wSwGwK6PDD_nZKpnBDAtM=5-fvR-smDa48xjW4Q@mail.gmail.com>
	<03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr>
	<CAAS2fgR1aGOpVoLyGWtO=Q5XU04gBMBEQARPtxMe4WnwQ2CO5w@mail.gmail.com>
	<CAP=-fx6hju0NAa-HcYzivwNbJH0HXwUL=t7iD38XAK_Fwodjng@mail.gmail.com>
	<CAFMkqK9+pvRRtcOomo6is5t8xQ2gLmGb7XaGV80TOm-eO6ZoqA@mail.gmail.com>
	<0be972b9-328c-394a-1e90-bd7a37642598@osc.co.cr>
	<CADL_X_cZc4K3k=JzVES7Jba6qqZwv0Lx7opCi8eL_GM5M01Y8A@mail.gmail.com>
	<4921ce4f-06bc-8ff1-4e70-5bd55d1ff5ca@osc.co.cr>
	<CAFMkqK-s=Xtg_40dMY7B3ecbOsjtcekHa6qFn2h8dVhuUMv=pw@mail.gmail.com>
	<5af10ca3-8b97-f227-c09f-901bbb6176c3@osc.co.cr>
Message-ID: <CAFMkqK_epizUDe4+7v2AqoWnC4L1-OALETVG-PtD9CrWrfKf4g@mail.gmail.com>

> sounds good, though I'm unclear on how exactly to achieve (2) given that
any party I have ever transacted with (or otherwise knows an address of
mine) can send me coins at any time.  So it seems the only possible way
to be certain is to run a node that has never published an address to a
3rd party.  Is that accurate?

Yes, as soon as you receive new Bitcoins, there's a chance that they have
been in a SegWit transaction at some point.
I'm not sure if you can see the chain of transactions for an address in
bitcoin-cli, but if that is possible, you should be able to double check
the transaction types.

> Another thing that could be done is to modify my own node so that it
actually rejects such tx, but then I have modified consensus rules
myself, thus defeating the goal of remaining with status-quo rules, and
anyway the rest of the network would accept the tx.  I guess the benefit
is that I could be certain of the remaining funds I have.

Hmm yes, if you reject a such transaction, you'll hardfork the network.
If you ignore it in your wallet, you'll be safe, but you'll lose those
bitcoins ofc.
It's a difficult situation.

> I suppose that it would be possible without modifying any rule to
construct a "certain balance" and an "uncertain balance".

Should be possible.

> Hampus, thanks for the explanation!

You're welcome!
I personally very much like and want SegWit, but I respect people that
wants to maintain the status quo, it's what will make Bitcoin strong in the
long run.

Cheers
Hampus

2017-07-14 1:20 GMT+02:00 Dan Libby via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> Hampus, thanks for the explanation!
>
> On 07/13/2017 03:50 PM, Hampus Sj?berg wrote:
>
> > Yes.
> > So you have two choices to be fully secure:
> > 1. Validate using the new rules of the network (in other words, run a
> > SegWit node)
> > 2. Avoid any chain of transaction that contains a SegWit transaction
>
> sounds good, though I'm unclear on how exactly to achieve (2) given that
> any party I have ever transacted with (or otherwise knows an address of
> mine) can send me coins at any time.  So it seems the only possible way
> to be certain is to run a node that has never published an address to a
> 3rd party.  Is that accurate?
>
> Another thing that could be done is to modify my own node so that it
> actually rejects such tx, but then I have modified consensus rules
> myself, thus defeating the goal of remaining with status-quo rules, and
> anyway the rest of the network would accept the tx.  I guess the benefit
> is that I could be certain of the remaining funds I have.
>
> I suppose that it would be possible without modifying any rule to
> construct a "certain balance" and an "uncertain balance".
>
> I don't intend to do such modifications! just grasping for understanding.
>
>
> > See
> > https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Backward_
> compatibility
> > So the witness program is encoded in a new format that old nodes do not
> > understand.
> > This means that for old nodes, a number >0 will be put on the stack.
> > When the script is done, it will be evaluated to true (because of >0)
> > and be counted as a valid spend.
> >
> > https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki also
> > explains the new witness program more in detail (I left out some details
> > in my explanation).
>
> I read the relevant parts, thanks!
> _______________________________________________
> 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/20170714/817caf42/attachment-0001.html>

From erik at q32.com  Fri Jul 14 13:50:14 2017
From: erik at q32.com (Erik Aronesty)
Date: Fri, 14 Jul 2017 09:50:14 -0400
Subject: [bitcoin-dev] A Segwit2x BIP
In-Reply-To: <CAKzdR-p2F3HLnU7aV7U645mrCOQ5ye4CWSeyzeb0O0j815QAfA@mail.gmail.com>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
	<CAKzdR-oRdX-fXyc6womZOyYyfHUJZdgh92FUMM8pR_QDNiJfkQ@mail.gmail.com>
	<CABm2gDo0wgqkEufKn=Z8uAsi=_6fgE=0TS6Bcr21mg3xAX7Kyw@mail.gmail.com>
	<7869651.CRYTeDpGy9@strawberry>
	<CABm2gDqgve88eE4=dDD8FqGZQNNgRtOvXAhqSTWu_wy4zG+6Eg@mail.gmail.com>
	<CAKzdR-p2F3HLnU7aV7U645mrCOQ5ye4CWSeyzeb0O0j815QAfA@mail.gmail.com>
Message-ID: <CAJowKgKQhpYNsSmdUca7Fnzk=E8op+_Fb9rTkjiM_zBHe8Wcvw@mail.gmail.com>

While BIP91 is probably not terribly harmful, because the vast majority of
nodes and users are prepared for it - the hard fork portion of this BIP is
being deployed like an emergency patch or quick bug fix to the system.

Please consider updating the BIP to include some justification for the
urgency of the consensus change, and the reasons for not delaying until a
better engineered solution (spoonet, BIP103, etc.) can be deployed.


On Thu, Jul 13, 2017 at 3:19 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> The BIP has been updated.
>
> Changes:
> - The technical spec has been improved: now the block size increase is
> specified in terms of weight and not in terms of bytes.
> - The increase in the maximum block sigops after HF has been documented.
> - Comments added about the worst case block size.
>
> Happy weekend! And don't forget to start signaling something before block
> 475776 !  It's just 90 blocks away.
> Bit 1 or 4,1 or whatever you wish, but please signal something.
>
> To the moon!
>
>
> On Wed, Jul 12, 2017 at 2:38 PM, Jorge Tim?n via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>
>>
>> On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> On Monday, 10 July 2017 20:38:08 CEST Jorge Tim?n via bitcoin-dev wrote:
>> > I think anything less than 1 year after release of tested code by some
>> > implementation would be irresponsible for any hardfork, even a very
>> > simple one.
>>
>> Good news!
>>
>> Code to support 2x (the hard fork part of the proposal) has been out and
>> tested for much longer than that.
>>
>>
>> Not true. It's different code on top of segwit. The first attempt in btc1
>> (very recent) didn't even increased the size (because it changed the
>> meaningless "base size" without touching the weight limit. As for the
>> current code, I don't think it has been properly tested today, let alone
>> "for mucj longer than 1 year.
>> Anyway, I said, one year from tested release. Segwitx2 hasn't been
>> released, has it? If so, too late to discuss a bip imo, the bip may end up
>> being different from what has been released due to feedback (unless it is
>> ignored again, of course).
>>
>>
>> --
>> Tom Zander
>> Blog: https://zander.github.io
>> Vlog: https://vimeo.com/channels/tomscryptochannel
>> _______________________________________________
>> 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/20170714/d0e787a3/attachment.html>

From clark at clarkmoody.com  Fri Jul 14 18:43:37 2017
From: clark at clarkmoody.com (Clark Moody)
Date: Fri, 14 Jul 2017 13:43:37 -0500
Subject: [bitcoin-dev] A BIP proposal for conveniently referring to
 confirmed transactions
Message-ID: <CAHGSxGs8Dko1UeZbRLN0VEDfcV9t6fONv3_N48hV36wTzLwu1w@mail.gmail.com>

(copying from GitHub per jonasschnelli's request)

I can understand the desire to keep all reference strings to the nice
14-character version by keeping the data payload to 40 bits, but it
seems to place artificial limitations on the format (year 2048 & 8191
transactions). I also understand that this might be addressed with
Version 1 encoding. But current blocks are not that far from having
8191 transactions.

You could go with a variable-length encoding similar to Bitcoin's
variable ints and gain the benefit of having a format that will work
for very large blocks and the very far future.

Also, the Bech32 reference libraries allow encoding from byte arrays
into the base-5 arrays native to Bech32. It seems like bit-packing to
these 40 bits might be overkill. As an alternative you could have one
bit-packed byte to start:

# First two bits are the protocol version, supporting values 0-3
V = ((protocol version) & 0x03) << 6
# Next two bits are magic for the blockchain
# 0x00 = Bitcoin
# 0x01 = Testnet3
# 0x02 = Byte1 is another coin's magic code (gives 256 options)
# 0x03 = Byte1-2 is treated as the coin magic code (gives 65280 more options)
M = (magic & 0x03) << 4
# Next two bits are the byte length of the block reference
B = ((byte length of block reference) & 0x03) << 2
# Final two bits are the byte length of the transaction index
T = ((byte length of transaction index) & 0x03)
# Assemble into the first byte
Byte0 = V | M | B | T

This gives you up to 3 bytes for each block and transaction reference,
which is 16.7 M blocks, or year 2336, and 16.7 M transaction slots.

Data part: [Byte0][optional magic bytes 1-2][block reference bytes][tx
reference bytes]

So the shortest data part would have 3 bytes in it, with the reference
version 0 genesis coinbase transaction having data part 0x050000.

I know this is a departure from your vision, but it would be much more
flexible for the long term.


Clark

From veleslav.bips at protonmail.com  Sat Jul 15 05:00:18 2017
From: veleslav.bips at protonmail.com (=?UTF-8?B?0JLQtdC70LXRgdC70LDQsg==?=)
Date: Sat, 15 Jul 2017 01:00:18 -0400
Subject: [bitcoin-dev] A BIP proposal for conveniently referring to
	confirmed transactions
In-Reply-To: <CAHGSxGs8Dko1UeZbRLN0VEDfcV9t6fONv3_N48hV36wTzLwu1w@mail.gmail.com>
References: <CAHGSxGs8Dko1UeZbRLN0VEDfcV9t6fONv3_N48hV36wTzLwu1w@mail.gmail.com>
Message-ID: <lZP-dVzULojS1mKd11O3E6bt6AKqnajVj7BlDDSxgfCvuuo3jDHuTBVl7Tdl4EkXx3_LoPBmntx5FjtOVvYvEzeUo6ynbdGMXz1gOcIYOI0=@protonmail.com>

Hello Clark Moody,
Thank you for your review of our proposal.
For reference please see the pull request: https://github.com/bitcoin/bips/pull/555 and the proposed specification: https://github.com/veleslavs/bips/blob/Bech32_Encoded_TxRef/bip-XXXX-Bech32_Encoded_Transaction_Position_References.mediawiki. (I will inform the mailing if a BIP number is assigned and these become obsolete).
On variable length encodings:
We considered in-depth various variable length encodings; and found that for such short data-lengths they all came with a too-high overheard: especially when you design them to work correctly with 5-bit chunks. We will update the rational section of the BIP to include this comment.
Hence, we have proposed the concept of "Display Formats". Display Formats are individually tailored to a particular purpose and thus can be optimised to a much greater extent.
In the case there is a Hard-Fork that extends Bitcoin's Block Transaction Capacity over the 8191 of the provided display format, we will simply define a "Bitcoin Display Format 1". Considering the considerable disruption a Hard Fork causes; the creation of a secondary Display Format should not be of significant concern.
In the case there is a Drive-Chain style extension or other indirect extension to Bitcoin's transactional capacity; it makes no sense to try and define for an undefined format now. We will simply use a new Magic Value and create a tailored Display Format for the new system.
In the case that it is nearing Year 2048, I think that we will be in a far-better position to define a new format that suits the needs of the Bitcoin users than now.
Many thanks for your careful review, it is much appreciated,
? ?????????? ???????????,
????????
-------- Original Message --------
Subject: Re: [bitcoin-dev] A BIP proposal for conveniently referring to confirmed transactions
Local Time: July 15, 2017 1:43 AM
UTC Time: July 14, 2017 6:43 PM
From: bitcoin-dev at lists.linuxfoundation.org
To: bitcoin-dev at lists.linuxfoundation.org
(copying from GitHub per jonasschnelli"s request)
I can understand the desire to keep all reference strings to the nice
14-character version by keeping the data payload to 40 bits, but it
seems to place artificial limitations on the format (year 2048 & 8191
transactions). I also understand that this might be addressed with
Version 1 encoding. But current blocks are not that far from having
8191 transactions.
You could go with a variable-length encoding similar to Bitcoin"s
variable ints and gain the benefit of having a format that will work
for very large blocks and the very far future.
Also, the Bech32 reference libraries allow encoding from byte arrays
into the base-5 arrays native to Bech32. It seems like bit-packing to
these 40 bits might be overkill. As an alternative you could have one
bit-packed byte to start:
# First two bits are the protocol version, supporting values 0-3
V = ((protocol version) & 0x03) << 6
# Next two bits are magic for the blockchain
# 0x00 = Bitcoin
# 0x01 = Testnet3
# 0x02 = Byte1 is another coin"s magic code (gives 256 options)
# 0x03 = Byte1-2 is treated as the coin magic code (gives 65280 more options)
M = (magic & 0x03) << 4
# Next two bits are the byte length of the block reference
B = ((byte length of block reference) & 0x03) << 2
# Final two bits are the byte length of the transaction index
T = ((byte length of transaction index) & 0x03)
# Assemble into the first byte
Byte0 = V | M | B | T
This gives you up to 3 bytes for each block and transaction reference,
which is 16.7 M blocks, or year 2336, and 16.7 M transaction slots.
Data part: [Byte0][optional magic bytes 1-2][block reference bytes][tx
reference bytes]
So the shortest data part would have 3 bytes in it, with the reference
version 0 genesis coinbase transaction having data part 0x050000.
I know this is a departure from your vision, but it would be much more
flexible for the long term.
Clark
_______________________________________________
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/20170715/2f243c69/attachment-0001.html>

From tomz at freedommail.ch  Mon Jul 17 13:40:29 2017
From: tomz at freedommail.ch (Tom Zander)
Date: Mon, 17 Jul 2017 15:40:29 +0200
Subject: [bitcoin-dev] A BIP proposal for conveniently referring to
	confirmed transactions
In-Reply-To: <CAHGSxGs8Dko1UeZbRLN0VEDfcV9t6fONv3_N48hV36wTzLwu1w@mail.gmail.com>
References: <CAHGSxGs8Dko1UeZbRLN0VEDfcV9t6fONv3_N48hV36wTzLwu1w@mail.gmail.com>
Message-ID: <1695234.eLYGsKu2sb@strawberry>

On Friday, 14 July 2017 20:43:37 CEST Clark Moody via bitcoin-dev wrote:
> I can understand the desire to keep all reference strings to the nice
> 14-character version by keeping the data payload to 40 bits

I?m not so clear on this, to be honest.

What is the point of having a user-readable tx-reference?

In the actual blockchain you will still be using txid, and if you want to 
change that then a less readable but more compact format is useful because 
we want to optimize for space, not for human comprehention.

Another usecase I can come up with is you wanting to spend a specific output, 
or you reporting a specific tx as proof to a merchant (or tax office).

For any such usecases you sill need to actually provide a proof of holding 
the private keys and using a human-readable format just doesn?t seem to make 
much sense because a cryptographic proof of ownership is not going to be 
readable however hard you try.

Apologies for missing the point,
can you list one or two usecases that you can see this being used for?
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

From truthcoin at gmail.com  Mon Jul 17 17:13:30 2017
From: truthcoin at gmail.com (Paul Sztorc)
Date: Mon, 17 Jul 2017 13:13:30 -0400
Subject: [bitcoin-dev] Updating the Scaling Roadmap [Update]
In-Reply-To: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
Message-ID: <01194110-04f0-82f5-cd5e-0101822fa2b1@gmail.com>

Hello,

Last week I posted about updating the Core Scalability Roadmap.

I'm not sure what the future of it is, given that it was concept NACK'ed
by Greg Maxwell the author of the original roadmap, who said that he
regretted writing the first one.

Nonetheless, it was ACKed by everyone else that I heard from, except for
Tom Zander (who objected that it should be a specific project document,
not a "Bitcoin" document -- I sortof agree and decided to label it a
"Core" document -- whether or not anything happens with that label is up
to the community).

I therefore decided to:
1. Put the draft on GitHub [1]
2. Update it based on all of the week 1 feedback [2]
3. Add some spaces at the bottom for comments / expressions of interest [2]

However, without interest from the maintainers of bitcoincore.org
(specifically these [3, 4] pages and similar) the document will probably
be unable to gain traction.

Cheers,
Paul

[1] https://github.com/psztorc/btc-core-capacity-2/blob/master/draft.txt
[2]
https://github.com/psztorc/btc-core-capacity-2/commit/2b4f0ecc9015ee398ce0486ca5c3613e3b929c00
[3] https://bitcoincore.org/en/2015/12/21/capacity-increase/
[4] https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/


On 7/10/2017 12:50 PM, Paul Sztorc wrote:
> Summary
> =========
>
> In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few
> crucial ways. One success was that it synchronized the entire Bitcoin
> community, helping to bring finality to the (endless) conversations of
> that time, and get everyone back to work. However, I feel that the Dec
> 7, 2015 roadmap is simply too old to serve this function any longer. We
> should revise it: remove what has been accomplished, introduce new
> innovations and approaches, and update deadlines and projections.
>
>
> Why We Should Update the Roadmap
> =================================
>
> In a P2P system like Bitcoin, we lack authoritative info-sources (for
> example, a "textbook" or academic journal), and as a result
> conversations tend to have a problematic lack of progress. They do not
> "accumulate", as everyone must start over. Ironically, the scaling
> conversation _itself_ has a fatal O(n^2) scaling problem.
>
> The roadmap helped solve these problems by being constant in size, and
> subjecting itself to publication, endorsement, criticism, and so forth.
> Despite the (unavoidable) nuance and complexity of each individual
> opinion, it was at least globally known that X participants endorsed Y
> set of claims.
>
> Unfortunately, the Dec 2015 roadmap is now 19 months old -- it is quite
> obsolete and replacing it is long overdue. For example, it highlights
> older items (CSV, compact blocks, versionbits) as being _future_
> improvements, and makes no mention of new high-likelihood improvements
> (Schnorr) or mis-emphasizes them (LN). It even contains mistakes (SegWit
> fraud proofs). To read the old roadmap properly, one must already be a
> technical expert. For me, this defeats the entire point of having one in
> the first place.
>
> A new roadmap would be worth your attention, even if you didn't sign it,
> because a refusal to sign would still be informative (and, therefore,
> helpful)!
>
> So, with that in mind, let me present a first draft. Obviously, I am
> strongly open to edits and feedback, because I have no way of knowing
> everyone's opinions. I admit that I am partially campaigning for my
> Drivechain project, and also for this "scalability"/"capacity"
> distinction...that's because I believe in both and think they are
> helpful. But please feel free to suggest edits.
>
> I emphasized concrete numbers, and concrete dates.
>
> And I did NOT necessarily write it from my own point of view, I tried
> earnestly to capture a (useful) community view. So, let me know how I did.
>
>  ==== Beginning of New ("July 2017") Roadmap Draft ====
>
> This document updates the previous roadmap [1] of Dec 2015. The older
> statement endorsed a belief that "the community is ready to deliver on
> its shared vision that addresses the needs of the system while upholding
> its values".
>
> That belief has not changed, but the shared vision has certainly grown
> sharper over the last 18 months. Below is a list of technologies which
> either increase Bitcoin's maximum tps rate ("capacity"), or which make
> it easier to process a higher volume of transactions ("scalability").
>
> First, over the past 18 months, the technical community has completed a
> number of items [2] on the Dec 2015 roadmap. VersonBits (BIP 9) enables
> Bitcoin to handle multiple soft fork upgrades at once. Compact Blocks
> (BIP 152) allows for much faster block propagation, as does the FIBRE
> Network [3]. Check Sequence Verify (BIP 112) allows trading partners to
> mutually update an active transaction without writing it to the
> blockchain (this helps to enable the Lightning Network).
>
> Second, Segregated Witness (BIP 141), which reorganizes data in blocks
> to handle signatures separately, has been completed and awaits
> activation (multiple BIPS). It is estimated to increase capacity by a
> factor of 2.2. It also improves scalability in many ways. First, SW
> includes a fee-policy which encourages users to minimize their impact on
> the UTXO set. Second, SW achieves linear scaling of sighash operations,
> which prevents the network from crashing when large transactions are
> broadcast. Third, SW provides an efficiency gain for everyone who is not
> verifying signatures, as these no longer need to be downloaded or
> stored. SegWit is an enabling technology for the Lightning Network,
> script versioning (specifically Schnorr signatures), and has a number of
> benefits which
> are unrelated to capacity [4].
>
> Third, the Lightning Network, which allows users to transact without
> broadcasting to the network, is complete [5, 6] and awaits the
> activation of SegWit. For those users who are able to make a single
> on-chain transaction, it is estimated to increase both capacity and
> scalability by a factor of ~1000 (although these capacity increases will
> vary with usage patterns). LN also greatly improves transaction speed
> and transaction privacy.
>
> Fourth, Transaction Compression [7], observes that Bitcoin transaction
> serialization is not optimized for storage or network communication. If
> transactions were optimally compressed (as is possible today), this
> would improve scalability, but not capacity, by roughly 20%, and in some
> cases over 30%.
>
> Fifth, Schnorr Signature Aggregation, which shrinks transactions by
> allowing many transactions to have a single shared signature, has been
> implemented [8] in draft form in libsecp256k1, and will likely be ready
> by Q4 of 2016. One analysis [9] suggests that signature aggregation
> would result in storage and bandwidth savings of at least 25%, which
> would therefore increase scalability and capacity by a factor of 1.33.
> The relative savings are even greater for multisignature transactions.
>
> Sixth, drivechain [10], which allows bitcoins to be temporarily
> offloaded to 'alternative' blockchain networks ("sidechains"), is
> currently under peer review and may be usable by end of 2017. Although
> it has no impact on scalability, it does allow users to opt-in to
> greater capacity, by moving their BTC to a new network (although, they
> will achieve less decentralization as a result). Individual drivechains
> may have different security tradeoffs (for example, a greater reliance
> on UTXO commitments, or MimbleWimble's shrinking block history) which
> may give them individually greater scalability than mainchain Bitcoin.
>
> Finally, the capacity improvements outlined above may not be sufficient.
> If so, it may be necessary to use a hard fork to increase the blocksize
> (and blockweight, sigops, etc) by a moderate amount. Such an increase
> should take advantage of the existing research on hard forks, which is
> substantial [11]. Specifically, there is some consensus that Spoonnet
> [12] is the most attractive option for such a hardfork. There is
> currently no consensus on a hard fork date, but there is a rough
> consensus that one would require at least 6 months to coordinate
> effectively, which would place it in the year 2018 at earliest.
>
> The above are only a small sample of current scaling technologies. And
> even an exhaustive list of scaling technologies, would itself only be a
> small sample of total Bitcoin innovation (which is proceeding at
> breakneck speed).
>
> Signed,
> <Names Here>
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
> [2] https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/
> [3] http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/
> [4] https://bitcoincore.org/en/2016/01/26/segwit-benefits/
> [5]
> http://lightning.community/release/software/lnd/lightning/2017/05/03/litening/
> [6] https://github.com/ACINQ/eclair
> [7] https://people.xiph.org/~greg/compacted_txn.txt
> [8]
> https://github.com/ElementsProject/secp256k1-zkp/blob/d78f12b04ec3d9f5744cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594
> [9] https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/
> [10] http://www.drivechain.info/
> [11] https://bitcoinhardforkresearch.github.io/
> [12]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html
>
>  ==== End of Roadmap Draft ====
>
> In short, please let me know:
>
> 1. If you agree that it would be helpful if the roadmap were updated.
> 2. To what extent, if any, you like this draft.
> 3. Edits you would make (specifically, I wonder about Drivechain
> thoughts and Hard Fork thoughts, particularly how to phrase the Hard
> Fork date).
>
> Google Doc (if you're into that kind of thing):
> https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNocmCq-jjBOQSVH-A/edit?usp=sharing
>
> Cheers,
> Paul
>



From morcos at gmail.com  Mon Jul 17 18:49:22 2017
From: morcos at gmail.com (Alex Morcos)
Date: Mon, 17 Jul 2017 14:49:22 -0400
Subject: [bitcoin-dev] Updating the Scaling Roadmap [Update]
In-Reply-To: <01194110-04f0-82f5-cd5e-0101822fa2b1@gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<01194110-04f0-82f5-cd5e-0101822fa2b1@gmail.com>
Message-ID: <CAPWm=eVZQ5FM7AohEMocUobj4jhFvdb-Uc+DhAmSSFZ3_funrw@mail.gmail.com>

"it was ACKed by everyone else that I heard from"  - I don't think you
should read into that much.

I felt like this whole conversation was putting the cart before the horse.
You might very well have some good ideas in your roadmap update, to tell
you the truth, I didn't even read it.
But I don't think we should be taking relatively new/untested ideas such as
Drivechain and sticking them on a roadmap.  There is a tendency in this
community to hear about the latest and greatest idea and immediately fixate
on it as our salvation. I'm very happy that you are doing this work and
that others are researching a wide variety of ideas.  But please, lets be
conservative and flexible with how we evolve Bitcoin.  We don't even know
if or when we'll get segwit yet.


On Mon, Jul 17, 2017 at 1:13 PM, Paul Sztorc via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hello,
>
> Last week I posted about updating the Core Scalability Roadmap.
>
> I'm not sure what the future of it is, given that it was concept NACK'ed
> by Greg Maxwell the author of the original roadmap, who said that he
> regretted writing the first one.
>
> Nonetheless, it was ACKed by everyone else that I heard from, except for
> Tom Zander (who objected that it should be a specific project document,
> not a "Bitcoin" document -- I sortof agree and decided to label it a
> "Core" document -- whether or not anything happens with that label is up
> to the community).
>
> I therefore decided to:
> 1. Put the draft on GitHub [1]
> 2. Update it based on all of the week 1 feedback [2]
> 3. Add some spaces at the bottom for comments / expressions of interest [2]
>
> However, without interest from the maintainers of bitcoincore.org
> (specifically these [3, 4] pages and similar) the document will probably
> be unable to gain traction.
>
> Cheers,
> Paul
>
> [1] https://github.com/psztorc/btc-core-capacity-2/blob/master/draft.txt
> [2]
> https://github.com/psztorc/btc-core-capacity-2/commit/
> 2b4f0ecc9015ee398ce0486ca5c3613e3b929c00
> [3] https://bitcoincore.org/en/2015/12/21/capacity-increase/
> [4] https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
>
>
> On 7/10/2017 12:50 PM, Paul Sztorc wrote:
> > Summary
> > =========
> >
> > In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few
> > crucial ways. One success was that it synchronized the entire Bitcoin
> > community, helping to bring finality to the (endless) conversations of
> > that time, and get everyone back to work. However, I feel that the Dec
> > 7, 2015 roadmap is simply too old to serve this function any longer. We
> > should revise it: remove what has been accomplished, introduce new
> > innovations and approaches, and update deadlines and projections.
> >
> >
> > Why We Should Update the Roadmap
> > =================================
> >
> > In a P2P system like Bitcoin, we lack authoritative info-sources (for
> > example, a "textbook" or academic journal), and as a result
> > conversations tend to have a problematic lack of progress. They do not
> > "accumulate", as everyone must start over. Ironically, the scaling
> > conversation _itself_ has a fatal O(n^2) scaling problem.
> >
> > The roadmap helped solve these problems by being constant in size, and
> > subjecting itself to publication, endorsement, criticism, and so forth.
> > Despite the (unavoidable) nuance and complexity of each individual
> > opinion, it was at least globally known that X participants endorsed Y
> > set of claims.
> >
> > Unfortunately, the Dec 2015 roadmap is now 19 months old -- it is quite
> > obsolete and replacing it is long overdue. For example, it highlights
> > older items (CSV, compact blocks, versionbits) as being _future_
> > improvements, and makes no mention of new high-likelihood improvements
> > (Schnorr) or mis-emphasizes them (LN). It even contains mistakes (SegWit
> > fraud proofs). To read the old roadmap properly, one must already be a
> > technical expert. For me, this defeats the entire point of having one in
> > the first place.
> >
> > A new roadmap would be worth your attention, even if you didn't sign it,
> > because a refusal to sign would still be informative (and, therefore,
> > helpful)!
> >
> > So, with that in mind, let me present a first draft. Obviously, I am
> > strongly open to edits and feedback, because I have no way of knowing
> > everyone's opinions. I admit that I am partially campaigning for my
> > Drivechain project, and also for this "scalability"/"capacity"
> > distinction...that's because I believe in both and think they are
> > helpful. But please feel free to suggest edits.
> >
> > I emphasized concrete numbers, and concrete dates.
> >
> > And I did NOT necessarily write it from my own point of view, I tried
> > earnestly to capture a (useful) community view. So, let me know how I
> did.
> >
> >  ==== Beginning of New ("July 2017") Roadmap Draft ====
> >
> > This document updates the previous roadmap [1] of Dec 2015. The older
> > statement endorsed a belief that "the community is ready to deliver on
> > its shared vision that addresses the needs of the system while upholding
> > its values".
> >
> > That belief has not changed, but the shared vision has certainly grown
> > sharper over the last 18 months. Below is a list of technologies which
> > either increase Bitcoin's maximum tps rate ("capacity"), or which make
> > it easier to process a higher volume of transactions ("scalability").
> >
> > First, over the past 18 months, the technical community has completed a
> > number of items [2] on the Dec 2015 roadmap. VersonBits (BIP 9) enables
> > Bitcoin to handle multiple soft fork upgrades at once. Compact Blocks
> > (BIP 152) allows for much faster block propagation, as does the FIBRE
> > Network [3]. Check Sequence Verify (BIP 112) allows trading partners to
> > mutually update an active transaction without writing it to the
> > blockchain (this helps to enable the Lightning Network).
> >
> > Second, Segregated Witness (BIP 141), which reorganizes data in blocks
> > to handle signatures separately, has been completed and awaits
> > activation (multiple BIPS). It is estimated to increase capacity by a
> > factor of 2.2. It also improves scalability in many ways. First, SW
> > includes a fee-policy which encourages users to minimize their impact on
> > the UTXO set. Second, SW achieves linear scaling of sighash operations,
> > which prevents the network from crashing when large transactions are
> > broadcast. Third, SW provides an efficiency gain for everyone who is not
> > verifying signatures, as these no longer need to be downloaded or
> > stored. SegWit is an enabling technology for the Lightning Network,
> > script versioning (specifically Schnorr signatures), and has a number of
> > benefits which
> > are unrelated to capacity [4].
> >
> > Third, the Lightning Network, which allows users to transact without
> > broadcasting to the network, is complete [5, 6] and awaits the
> > activation of SegWit. For those users who are able to make a single
> > on-chain transaction, it is estimated to increase both capacity and
> > scalability by a factor of ~1000 (although these capacity increases will
> > vary with usage patterns). LN also greatly improves transaction speed
> > and transaction privacy.
> >
> > Fourth, Transaction Compression [7], observes that Bitcoin transaction
> > serialization is not optimized for storage or network communication. If
> > transactions were optimally compressed (as is possible today), this
> > would improve scalability, but not capacity, by roughly 20%, and in some
> > cases over 30%.
> >
> > Fifth, Schnorr Signature Aggregation, which shrinks transactions by
> > allowing many transactions to have a single shared signature, has been
> > implemented [8] in draft form in libsecp256k1, and will likely be ready
> > by Q4 of 2016. One analysis [9] suggests that signature aggregation
> > would result in storage and bandwidth savings of at least 25%, which
> > would therefore increase scalability and capacity by a factor of 1.33.
> > The relative savings are even greater for multisignature transactions.
> >
> > Sixth, drivechain [10], which allows bitcoins to be temporarily
> > offloaded to 'alternative' blockchain networks ("sidechains"), is
> > currently under peer review and may be usable by end of 2017. Although
> > it has no impact on scalability, it does allow users to opt-in to
> > greater capacity, by moving their BTC to a new network (although, they
> > will achieve less decentralization as a result). Individual drivechains
> > may have different security tradeoffs (for example, a greater reliance
> > on UTXO commitments, or MimbleWimble's shrinking block history) which
> > may give them individually greater scalability than mainchain Bitcoin.
> >
> > Finally, the capacity improvements outlined above may not be sufficient.
> > If so, it may be necessary to use a hard fork to increase the blocksize
> > (and blockweight, sigops, etc) by a moderate amount. Such an increase
> > should take advantage of the existing research on hard forks, which is
> > substantial [11]. Specifically, there is some consensus that Spoonnet
> > [12] is the most attractive option for such a hardfork. There is
> > currently no consensus on a hard fork date, but there is a rough
> > consensus that one would require at least 6 months to coordinate
> > effectively, which would place it in the year 2018 at earliest.
> >
> > The above are only a small sample of current scaling technologies. And
> > even an exhaustive list of scaling technologies, would itself only be a
> > small sample of total Bitcoin innovation (which is proceeding at
> > breakneck speed).
> >
> > Signed,
> > <Names Here>
> >
> > [1]
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2015-December/011865.html
> > [2] https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/
> > [3] http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/
> > [4] https://bitcoincore.org/en/2016/01/26/segwit-benefits/
> > [5]
> > http://lightning.community/release/software/lnd/
> lightning/2017/05/03/litening/
> > [6] https://github.com/ACINQ/eclair
> > [7] https://people.xiph.org/~greg/compacted_txn.txt
> > [8]
> > https://github.com/ElementsProject/secp256k1-zkp/blob/
> d78f12b04ec3d9f5744cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594
> > [9] https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/
> > [10] http://www.drivechain.info/
> > [11] https://bitcoinhardforkresearch.github.io/
> > [12]
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-February/013542.html
> >
> >  ==== End of Roadmap Draft ====
> >
> > In short, please let me know:
> >
> > 1. If you agree that it would be helpful if the roadmap were updated.
> > 2. To what extent, if any, you like this draft.
> > 3. Edits you would make (specifically, I wonder about Drivechain
> > thoughts and Hard Fork thoughts, particularly how to phrase the Hard
> > Fork date).
> >
> > Google Doc (if you're into that kind of thing):
> > https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNoc
> mCq-jjBOQSVH-A/edit?usp=sharing
> >
> > Cheers,
> > Paul
> >
>
>
> _______________________________________________
> 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/20170717/dc2b31ff/attachment-0001.html>

From pete at petertodd.org  Mon Jul 17 21:50:38 2017
From: pete at petertodd.org (Peter Todd)
Date: Mon, 17 Jul 2017 17:50:38 -0400
Subject: [bitcoin-dev] Updating the Scaling Roadmap [Update]
In-Reply-To: <CAPWm=eVZQ5FM7AohEMocUobj4jhFvdb-Uc+DhAmSSFZ3_funrw@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<01194110-04f0-82f5-cd5e-0101822fa2b1@gmail.com>
	<CAPWm=eVZQ5FM7AohEMocUobj4jhFvdb-Uc+DhAmSSFZ3_funrw@mail.gmail.com>
Message-ID: <20170717215038.GB8227@fedora-23-dvm>

On Mon, Jul 17, 2017 at 02:49:22PM -0400, Alex Morcos via bitcoin-dev wrote:
> "it was ACKed by everyone else that I heard from"  - I don't think you
> should read into that much.
> 
> I felt like this whole conversation was putting the cart before the horse.
> You might very well have some good ideas in your roadmap update, to tell
> you the truth, I didn't even read it.
> But I don't think we should be taking relatively new/untested ideas such as
> Drivechain and sticking them on a roadmap.  There is a tendency in this
> community to hear about the latest and greatest idea and immediately fixate
> on it as our salvation. I'm very happy that you are doing this work and
> that others are researching a wide variety of ideas.  But please, lets be
> conservative and flexible with how we evolve Bitcoin.  We don't even know
> if or when we'll get segwit yet.

Agreed!

A closely related example is my own Treechains work, which got a bunch of
excitement when I first published the idea. But would I have wanted it on a
roadmap? Hell no: sure enough, as it got more peer review others (and myself!)
found that it was going to be a harder than it initially looked to actually get
into production.

Drivechains is definitely in that situation right now.

Also don't forget that proper security peer review takes a *lot* of work. I
myself have a todo list item to respond to Paul's post on Drivechains, but I
need to spend a few days to do that and just haven't had the time (not to
mention that no-one is paying me to do general Bitcoin dev work right now).

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170717/86179a31/attachment.sig>

From truthcoin at gmail.com  Mon Jul 17 20:13:38 2017
From: truthcoin at gmail.com (Paul Sztorc)
Date: Mon, 17 Jul 2017 16:13:38 -0400
Subject: [bitcoin-dev] Updating the Scaling Roadmap [Update]
In-Reply-To: <CAPWm=eVZQ5FM7AohEMocUobj4jhFvdb-Uc+DhAmSSFZ3_funrw@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<01194110-04f0-82f5-cd5e-0101822fa2b1@gmail.com>
	<CAPWm=eVZQ5FM7AohEMocUobj4jhFvdb-Uc+DhAmSSFZ3_funrw@mail.gmail.com>
Message-ID: <f2711e5e-0ea3-d368-e3da-9673b8801b92@gmail.com>

On 7/17/2017 2:49 PM, Alex Morcos wrote:
> I felt like this whole conversation was putting the cart before the
> horse.
> You might very well have some good ideas in your roadmap update, to
> tell you the truth, I didn't even read it.

Fine, but, before the roadmap itself, I wrote exactly about why I
thought we should update it. Evidently you disagree with the horse, but
it is in front of the cart where it belongs.


> But I don't think we should be taking relatively new/untested ideas
> such as Drivechain and sticking them on a roadmap.

It isn't a "roadmap" anymore -- I changed it to a "forecast".

And I edited the drivechain part to emphasize only that mainchain space
would likely be freed as defectors leave for an alt-chain. The departing
individuals (ir hardcore LargeBlockers) will leave, despite a
security-model NACK from anyone here (in fact, it would probably only
encourage them). That leaves more space for those who remain.


> There is a tendency in this community to hear about the latest and
> greatest idea and immediately fixate on it as our salvation. ... But
> please, lets be conservative and flexible with how we evolve Bitcoin. 
> We don't even know if or when we'll get segwit yet.

Drivechain  (c. bitcointalk Feb 2014, blog Nov 2015) is actually much
older than "the" SegWit to which you refer.  As for being "conservative"
and "flexible", I have tried to do everything I know -- Scaling
conferences, in-person discussions, papers, posts, and presentations,
adding BMM, and posting here for additional peer review. I'm sure you
have lots of ideas about how it could be more conservative and/or
flexible, which I would love to hear.

But again I think people are getting hung up on the drivechain part --
it can be easily taken out, I just thought that, if the plan included
more overall flexibility for industry, then it would help deter network
splits and scaling drama.

Paul



> On Mon, Jul 17, 2017 at 1:13 PM, Paul Sztorc via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
>     Hello,
>
>     Last week I posted about updating the Core Scalability Roadmap.
>
>     I'm not sure what the future of it is, given that it was concept
>     NACK'ed
>     by Greg Maxwell the author of the original roadmap, who said that he
>     regretted writing the first one.
>
>     Nonetheless, it was ACKed by everyone else that I heard from,
>     except for
>     Tom Zander (who objected that it should be a specific project
>     document,
>     not a "Bitcoin" document -- I sortof agree and decided to label it a
>     "Core" document -- whether or not anything happens with that label
>     is up
>     to the community).
>
>     I therefore decided to:
>     1. Put the draft on GitHub [1]
>     2. Update it based on all of the week 1 feedback [2]
>     3. Add some spaces at the bottom for comments / expressions of
>     interest [2]
>
>     However, without interest from the maintainers of bitcoincore.org
>     <http://bitcoincore.org>
>     (specifically these [3, 4] pages and similar) the document will
>     probably
>     be unable to gain traction.
>
>     Cheers,
>     Paul
>
>     [1]
>     https://github.com/psztorc/btc-core-capacity-2/blob/master/draft.txt
>     <https://github.com/psztorc/btc-core-capacity-2/blob/master/draft.txt>
>     [2]
>     https://github.com/psztorc/btc-core-capacity-2/commit/2b4f0ecc9015ee398ce0486ca5c3613e3b929c00
>     <https://github.com/psztorc/btc-core-capacity-2/commit/2b4f0ecc9015ee398ce0486ca5c3613e3b929c00>
>     [3] https://bitcoincore.org/en/2015/12/21/capacity-increase/
>     <https://bitcoincore.org/en/2015/12/21/capacity-increase/>
>     [4] https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
>     <https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/>
>
>
>     On 7/10/2017 12:50 PM, Paul Sztorc wrote:
>     > Summary
>     > =========
>     >
>     > In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few
>     > crucial ways. One success was that it synchronized the entire
>     Bitcoin
>     > community, helping to bring finality to the (endless)
>     conversations of
>     > that time, and get everyone back to work. However, I feel that
>     the Dec
>     > 7, 2015 roadmap is simply too old to serve this function any
>     longer. We
>     > should revise it: remove what has been accomplished, introduce new
>     > innovations and approaches, and update deadlines and projections.
>     >
>     >
>     > Why We Should Update the Roadmap
>     > =================================
>     >
>     > In a P2P system like Bitcoin, we lack authoritative info-sources
>     (for
>     > example, a "textbook" or academic journal), and as a result
>     > conversations tend to have a problematic lack of progress. They
>     do not
>     > "accumulate", as everyone must start over. Ironically, the scaling
>     > conversation _itself_ has a fatal O(n^2) scaling problem.
>     >
>     > The roadmap helped solve these problems by being constant in
>     size, and
>     > subjecting itself to publication, endorsement, criticism, and so
>     forth.
>     > Despite the (unavoidable) nuance and complexity of each individual
>     > opinion, it was at least globally known that X participants
>     endorsed Y
>     > set of claims.
>     >
>     > Unfortunately, the Dec 2015 roadmap is now 19 months old -- it
>     is quite
>     > obsolete and replacing it is long overdue. For example, it
>     highlights
>     > older items (CSV, compact blocks, versionbits) as being _future_
>     > improvements, and makes no mention of new high-likelihood
>     improvements
>     > (Schnorr) or mis-emphasizes them (LN). It even contains mistakes
>     (SegWit
>     > fraud proofs). To read the old roadmap properly, one must
>     already be a
>     > technical expert. For me, this defeats the entire point of
>     having one in
>     > the first place.
>     >
>     > A new roadmap would be worth your attention, even if you didn't
>     sign it,
>     > because a refusal to sign would still be informative (and,
>     therefore,
>     > helpful)!
>     >
>     > So, with that in mind, let me present a first draft. Obviously, I am
>     > strongly open to edits and feedback, because I have no way of
>     knowing
>     > everyone's opinions. I admit that I am partially campaigning for my
>     > Drivechain project, and also for this "scalability"/"capacity"
>     > distinction...that's because I believe in both and think they are
>     > helpful. But please feel free to suggest edits.
>     >
>     > I emphasized concrete numbers, and concrete dates.
>     >
>     > And I did NOT necessarily write it from my own point of view, I
>     tried
>     > earnestly to capture a (useful) community view. So, let me know
>     how I did.
>     >
>     >  ==== Beginning of New ("July 2017") Roadmap Draft ====
>     >
>     > This document updates the previous roadmap [1] of Dec 2015. The
>     older
>     > statement endorsed a belief that "the community is ready to
>     deliver on
>     > its shared vision that addresses the needs of the system while
>     upholding
>     > its values".
>     >
>     > That belief has not changed, but the shared vision has certainly
>     grown
>     > sharper over the last 18 months. Below is a list of technologies
>     which
>     > either increase Bitcoin's maximum tps rate ("capacity"), or
>     which make
>     > it easier to process a higher volume of transactions
>     ("scalability").
>     >
>     > First, over the past 18 months, the technical community has
>     completed a
>     > number of items [2] on the Dec 2015 roadmap. VersonBits (BIP 9)
>     enables
>     > Bitcoin to handle multiple soft fork upgrades at once. Compact
>     Blocks
>     > (BIP 152) allows for much faster block propagation, as does the
>     FIBRE
>     > Network [3]. Check Sequence Verify (BIP 112) allows trading
>     partners to

>     > mutually update an active transaction without writing it to the
>     > blockchain (this helps to enable the Lightning Network).
>     >
>     > Second, Segregated Witness (BIP 141), which reorganizes data in
>     blocks
>     > to handle signatures separately, has been completed and awaits
>     > activation (multiple BIPS). It is estimated to increase capacity
>     by a
>     > factor of 2.2. It also improves scalability in many ways. First, SW
>     > includes a fee-policy which encourages users to minimize their
>     impact on
>     > the UTXO set. Second, SW achieves linear scaling of sighash
>     operations,
>     > which prevents the network from crashing when large transactions are
>     > broadcast. Third, SW provides an efficiency gain for everyone
>     who is not
>     > verifying signatures, as these no longer need to be downloaded or
>     > stored. SegWit is an enabling technology for the Lightning Network,
>     > script versioning (specifically Schnorr signatures), and has a
>     number of
>     > benefits which
>     > are unrelated to capacity [4].
>     >
>     > Third, the Lightning Network, which allows users to transact without
>     > broadcasting to the network, is complete [5, 6] and awaits the
>     > activation of SegWit. For those users who are able to make a single
>     > on-chain transaction, it is estimated to increase both capacity and
>     > scalability by a factor of ~1000 (although these capacity
>     increases will
>     > vary with usage patterns). LN also greatly improves transaction
>     speed
>     > and transaction privacy.
>     >
>     > Fourth, Transaction Compression [7], observes that Bitcoin
>     transaction
>     > serialization is not optimized for storage or network
>     communication. If
>     > transactions were optimally compressed (as is possible today), this
>     > would improve scalability, but not capacity, by roughly 20%, and
>     in some
>     > cases over 30%.
>     >
>     > Fifth, Schnorr Signature Aggregation, which shrinks transactions by
>     > allowing many transactions to have a single shared signature,
>     has been
>     > implemented [8] in draft form in libsecp256k1, and will likely
>     be ready
>     > by Q4 of 2016. One analysis [9] suggests that signature aggregation
>     > would result in storage and bandwidth savings of at least 25%, which
>     > would therefore increase scalability and capacity by a factor of
>     1.33.
>     > The relative savings are even greater for multisignature
>     transactions.
>     >
>     > Sixth, drivechain [10], which allows bitcoins to be temporarily
>     > offloaded to 'alternative' blockchain networks ("sidechains"), is
>     > currently under peer review and may be usable by end of 2017.
>     Although
>     > it has no impact on scalability, it does allow users to opt-in to
>     > greater capacity, by moving their BTC to a new network
>     (although, they
>     > will achieve less decentralization as a result). Individual
>     drivechains
>     > may have different security tradeoffs (for example, a greater
>     reliance
>     > on UTXO commitments, or MimbleWimble's shrinking block history)
>     which
>     > may give them individually greater scalability than mainchain
>     Bitcoin.
>     >
>     > Finally, the capacity improvements outlined above may not be
>     sufficient.
>     > If so, it may be necessary to use a hard fork to increase the
>     blocksize
>     > (and blockweight, sigops, etc) by a moderate amount. Such an
>     increase
>     > should take advantage of the existing research on hard forks,
>     which is
>     > substantial [11]. Specifically, there is some consensus that
>     Spoonnet
>     > [12] is the most attractive option for such a hardfork. There is
>     > currently no consensus on a hard fork date, but there is a rough
>     > consensus that one would require at least 6 months to coordinate
>     > effectively, which would place it in the year 2018 at earliest.
>     >
>     > The above are only a small sample of current scaling
>     technologies. And
>     > even an exhaustive list of scaling technologies, would itself
>     only be a
>     > small sample of total Bitcoin innovation (which is proceeding at
>     > breakneck speed).
>     >
>     > Signed,
>     > <Names Here>
>     >
>     > [1]
>     >
>     https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
>     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html>
>     > [2]
>     https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/
>     <https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/>
>     > [3] http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/
>     <http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/>
>     > [4] https://bitcoincore.org/en/2016/01/26/segwit-benefits/
>     <https://bitcoincore.org/en/2016/01/26/segwit-benefits/>
>     > [5]
>     >
>     http://lightning.community/release/software/lnd/lightning/2017/05/03/litening/
>     <http://lightning.community/release/software/lnd/lightning/2017/05/03/litening/>
>     > [6] https://github.com/ACINQ/eclair
>     <https://github.com/ACINQ/eclair>
>     > [7] https://people.xiph.org/~greg/compacted_txn.txt
>     <https://people.xiph.org/%7Egreg/compacted_txn.txt>
>     > [8]
>     >
>     https://github.com/ElementsProject/secp256k1-zkp/blob/d78f12b04ec3d9f5744cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594
>     <https://github.com/ElementsProject/secp256k1-zkp/blob/d78f12b04ec3d9f5744cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594>
>     > [9]
>     https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/
>     <https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/>
>     > [10] http://www.drivechain.info/
>     > [11] https://bitcoinhardforkresearch.github.io/
>     <https://bitcoinhardforkresearch.github.io/>
>     > [12]
>     >
>     https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html
>     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html>
>     >
>     >  ==== End of Roadmap Draft ====
>     >
>     > In short, please let me know:
>     >
>     > 1. If you agree that it would be helpful if the roadmap were
>     updated.
>     > 2. To what extent, if any, you like this draft.
>     > 3. Edits you would make (specifically, I wonder about Drivechain
>     > thoughts and Hard Fork thoughts, particularly how to phrase the Hard
>     > Fork date).
>     >
>     > Google Doc (if you're into that kind of thing):
>     >
>     https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNocmCq-jjBOQSVH-A/edit?usp=sharing
>     <https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNocmCq-jjBOQSVH-A/edit?usp=sharing>
>     >
>     > Cheers,
>     > Paul
>     >
>
>
>     _______________________________________________
>     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/20170717/5c86ddb8/attachment-0001.html>

From truthcoin at gmail.com  Mon Jul 17 22:04:49 2017
From: truthcoin at gmail.com (Paul Sztorc)
Date: Mon, 17 Jul 2017 18:04:49 -0400
Subject: [bitcoin-dev] Updating the Scaling Roadmap [Update]
In-Reply-To: <20170717214704.ksegcrdqf3zeslah@fedora-23-dvm>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<01194110-04f0-82f5-cd5e-0101822fa2b1@gmail.com>
	<20170717214704.ksegcrdqf3zeslah@fedora-23-dvm>
Message-ID: <292fa654-30e8-b55f-fbb6-7d47c3f08789@gmail.com>

On 7/17/2017 5:47 PM, David A. Harding wrote:
> On Mon, Jul 17, 2017 at 01:13:30PM -0400, Paul Sztorc via bitcoin-dev wrote:
>> However, without interest from the maintainers of bitcoincore.org
>> (specifically these [3, 4] pages and similar) the document will probably
>> be unable to gain traction.
>> [...]
>> [3] https://bitcoincore.org/en/2015/12/21/capacity-increase/
>> [4] https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
> The BitcoinCore.org maintainers are not psychic.  If you want your
> document to appear on the website, please open a PR.  If you would like
> help formatting your document for the website, please feel free to send
> me an email off list or open an issue[1] regarding the inadequacy of
> the site's readme.
I meant only to convey that the document would appear on bitcoincore.org
iff the PR were ultimately accepted. In other words, while it is up to
"the community of Core Contributors" in a philosophical sense, it is up
to the maintainers of BitcoinCore.org in a practical sense, because they
are the ones who ultimately decide if the standard has been met.

I think it is perfectly reasonable to keep site-updates narrowly
organized in the GitHub PR sphere (and to ignore everything else).

> [1] https://github.com/bitcoin-core/bitcoincore.org/issues/new
>
> Speaking as the instigator of [3] and the primary author of [4] (both
> originally published on Bitcoin.org), I'll point out that Maxwell's
> reply to you was a slightly rewritten version of a reply to me sent on 4
> November 2016 (as noted elsewhere in the thread and confirmed in my
> mailbox).  I include below my signature a complete copy of my reply to
> him (and CC'd to others).
>
> If I had followed through on my earlier plan to post a copy of Maxwell's
> reply on BitcoinCore.org (assuming Bitcoin Core contributors supported
> publishing it), you probably would've known that some Bitcoin Core
> contributors were resistant to roadmaps prior to you writing your
> proposed roadmap.  For that failure, and the time you may have wasted
> because of it, I offer you my apologies.
I appreciate you saying that. Thank you.

-Paul


> I will make opening a PR to BitcoinCore.org with his statement a priority 
> so that hopefully future confusion can be avoided.
>
> Sincerely,
>
> -Dave
>
> On Fri, Nov 04, 2016 at 07:17:11PM +0000, Gregory Maxwell wrote:
>> [...]
> I just wanted to say that I thought this was an amazing reply.  I was
> hoping that if I waited long enough to respond I might find something
> meaningful to add, but nothing has come to mind and I didn't want to
> leave the impression that your reply didn't merit a response.
>
> Maybe we can find a place on the website to post something like this so
> that we can link to it when other people ask for roadmaps and other
> commitments to future plans.
>
> Thanks!,
>
> -Dave




From simone.bronzini at chainside.net  Fri Jul 21 12:39:22 2017
From: simone.bronzini at chainside.net (Simone Bronzini)
Date: Fri, 21 Jul 2017 14:39:22 +0200
Subject: [bitcoin-dev] BIP proposal - multi-account key derivation hierarchy
 for multisig wallets
Message-ID: <5464f0d4-f1d3-d656-6162-ae6a66607265@chainside.net>

Maybe this has already been discussed, but I have not found anything online.

To the best of my knowledge, the only BIP which specifies a HD structure
for multisig wallets is BIP45. Unfortunately, when used in a
multi-account fashion, BIP45 gets very tricky very fast. In fact, one
has to either use a new master for every multisig account (hence having
to backup many master private keys) or use the same master for many
multisig accounts, resulting in deterministic but complex and
undesirable key reuse.
I would like to propose a new structure for multi-account multisig
wallets. This structure follows the derivation scheme of other proposals
(in particular BIP44 and BIP49) but adds a level to take into account
multisig accounts separation. In particular, the structure should be as
follows:

m/purpose'/coin_type'/account'/cosigner_index/change/address_index

In this case, a user can create many multisig accounts (each one will be
a different account number) and give his/her account's public derivation
to the cosigners. From this point on, the creation of a multisig P2SH
address will follow the same procedure as described in BIP45, with each
cosigner selecting his branch from the other cosigners' trees.

Would this proposal be acceptable as a BIP?

Simone Bronzini

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xB2E60C73.asc
Type: application/pgp-keys
Size: 15541 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170721/1d06fc55/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 898 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170721/1d06fc55/attachment.sig>

From majorkusanagibtc at gmail.com  Fri Jul 21 19:28:57 2017
From: majorkusanagibtc at gmail.com (Major Kusanagi)
Date: Fri, 21 Jul 2017 19:28:57 +0000
Subject: [bitcoin-dev] UTXO growth scaling solution proposal
Message-ID: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>

Hi all,

I have a scaling solution idea that I would be interested in getting some
feedback on. I?m new to the mailing list and have not been in the Bitcoin
space as long as some have been, so I don?t know if anyone has thought of
this idea.

Arguably the biggest scaling problem for Bitcoin is the unbounded UTXO
growth. Current scaling solutions like Segregated Witness, Lighting
Network, and larger blocks does not address this issue. As more and more
blocks are added to the block chain the size of the UTXO set that miners
have to maintain continues to grow. This is the case even if the block size
were to remain at 1 megabyte. There is no way out of solving this
fundamental scaling problem other then to limit the maximum size of the
UTXO set.

The following soft fork solution is proposed. Any UTXO that is not spent
within a set number of blocks is considered invalid. What this means for
miners and nodes in the Bitcoin network is that they only have to ever
store that set number of blocks. In others words the block chain will never
be larger then the set number of blocks and the size of the block chain is
capped.

But what this means for users is that bitcoins that have not been spent for
a long time are ?lost? forever. This proposed solution is likely a
difficult thing for Bitcoin users to accept. What Bitcoin users will
experience is that all of a sudden their bitcoins are spendable one moment
and the next moment they are not. The experience that they get is that all
of a sudden their old bitcoins are gone forever.

The solution can be improved by adding this new mechanism to Bitcoin, that
I will call luster. UTXO?s that are less then X blocks old has not lost any
luster and have a luster value of 1. As UTXO?s get older, the luster value
will continuously decrease until the UTXO?s become Z blocks old (where Z >
X), and has lost all it?s luster and have a luster value of 0. UTXO?s that
are in between X and Z blocks old have a luster value between 0 and 1. The
luster value is then used to compute the amount of bitcoins that must be
burned in order for a transaction with that UTXO to be included in a block.
So for example, a UTXO with a luster value of 0.5 must burn at least 50
percent of its bitcoin value, a UTXO with a luster value of 0.25 must burn
at least 75 percent of its bitcoin value, and a UTXO with a luster value of
0 must burn 100 percent of its bitcoin value. Thus the coins/UTXOs that
have a luster value of 0 means it has no monetary value, and it would be
safe for bitcoins nodes to drop those UTXOs from the set they maintain.

The idea is that coins that are continuously being used in Bitcoin economy
will never lose it?s luster. But coins that are old and not circulating
will start to lose its luster up until all luster is lost and they become
valueless. Or they reenter the economy and regains all its luster.

But at what point should coins start losing their luster? A goal would be
that we want to minimize the scenarios of when coins start losing their
luster. One reasonable answer is that coins should only starting losing its
luster after the lifespan of the average human. The idea being that a
person will eventually have to spend all his coins before he dies,
otherwise it will get lost anyways (assuming that only the dying person has
the ability to spend those coins). Otherwise there are few cases where a
person would never spend their bitcoins in there human life time. One
example is in the case of inheritance where a dying person does not want to
spend his remaining coins and have another person take them over. But with
this propose scaling solution, coins can be stilled inherited, but it would
have to be an on-chain inheritance. The longest lifespan of a human
currently is about 120 years old. So a blockchain that stores the last 150
years of history seems like one reasonable option.

Then the question of how large blocks should be is simply a matter of what
is the disk size requirement for a full node. For simplicity, assuming that
a block is created every 10 minute, the blockchain size in terabyte can be
express as the following.
blockSize MB * 6 * 24 * 365 * years /1000000 = blockchainSize TB

Example values:
blockSize = 1MB, years = 150 -> blockchainSize = 7.884 TB
blockSize = 2MB, years = 150 -> blockchainSize = 15.768 TB

So if we don?t want the block chain to be bigger then 8 TB, then we should
have a block size of 1 MB. If we don?t want the block chain to be bigger
then 16 TB, then we should have a block size of 2 MB and so on. The idea is
that base on how cheap disk space gets, we can adjust the target max block
chain size and the block size accordingly.

I believe that this proposal is a good solution to the UTXO growth problem.
The proposal being a soft fork is a big plus. It also keeps the block chain
size finite even if given a infinite amount of time. But there are other
things to considered, like how best should wallet software handle this? How
can this work with sidechains? More thought would need to be put into this.
But the fact is that if we want to make bitcoins last forever, we have the
accept unbounded UTXO growth, which is unscalable. So the only solution is
to limit UTXO growth, meaning bitcoins cannot last forever. This proposed
solution however does not prevent Bitcoin from lasting forever.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170721/e81b95b7/attachment-0001.html>

From jameson.lopp at gmail.com  Fri Jul 21 19:54:26 2017
From: jameson.lopp at gmail.com (Jameson Lopp)
Date: Fri, 21 Jul 2017 15:54:26 -0400
Subject: [bitcoin-dev] UTXO growth scaling solution proposal
In-Reply-To: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>
References: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>
Message-ID: <CADL_X_cbvWf0OqW0KChJDOXA=B-eedUZ98J7v9vTvZL1gHx8pQ@mail.gmail.com>

Sounds like demurrage to me, which has been implemented in other
cryptocurrencies such as Freicoin - http://freico.in/

While it's an interesting to apply this line of thinking from a scaling
perspective, I suspect most would find it untenable from a monetary policy
perspective.

You have touched on a scaling issue, the cost of node operation, that I
think is really the root cause of a lot of the debate. Thus even if your
proposal was implemented, we'd still have to solve the problem of finding a
consensus for CONOP.

I think you may have misapplied your logic to the total size of the
blockchain, however. Are you suggesting that pruning of the old UTXOs would
also enable pruning of old blocks from all nodes? Those things aren't
really related, plus someone would still have to keep old blocks around in
order to facilitate new nodes syncing from genesis.

- Jameson

On Fri, Jul 21, 2017 at 3:28 PM, Major Kusanagi via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi all,
>
> I have a scaling solution idea that I would be interested in getting some
> feedback on. I?m new to the mailing list and have not been in the Bitcoin
> space as long as some have been, so I don?t know if anyone has thought of
> this idea.
>
> Arguably the biggest scaling problem for Bitcoin is the unbounded UTXO
> growth. Current scaling solutions like Segregated Witness, Lighting
> Network, and larger blocks does not address this issue. As more and more
> blocks are added to the block chain the size of the UTXO set that miners
> have to maintain continues to grow. This is the case even if the block size
> were to remain at 1 megabyte. There is no way out of solving this
> fundamental scaling problem other then to limit the maximum size of the
> UTXO set.
>
> The following soft fork solution is proposed. Any UTXO that is not spent
> within a set number of blocks is considered invalid. What this means for
> miners and nodes in the Bitcoin network is that they only have to ever
> store that set number of blocks. In others words the block chain will never
> be larger then the set number of blocks and the size of the block chain is
> capped.
>
> But what this means for users is that bitcoins that have not been spent
> for a long time are ?lost? forever. This proposed solution is likely a
> difficult thing for Bitcoin users to accept. What Bitcoin users will
> experience is that all of a sudden their bitcoins are spendable one moment
> and the next moment they are not. The experience that they get is that all
> of a sudden their old bitcoins are gone forever.
>
> The solution can be improved by adding this new mechanism to Bitcoin, that
> I will call luster. UTXO?s that are less then X blocks old has not lost any
> luster and have a luster value of 1. As UTXO?s get older, the luster value
> will continuously decrease until the UTXO?s become Z blocks old (where Z >
> X), and has lost all it?s luster and have a luster value of 0. UTXO?s that
> are in between X and Z blocks old have a luster value between 0 and 1. The
> luster value is then used to compute the amount of bitcoins that must be
> burned in order for a transaction with that UTXO to be included in a block.
> So for example, a UTXO with a luster value of 0.5 must burn at least 50
> percent of its bitcoin value, a UTXO with a luster value of 0.25 must burn
> at least 75 percent of its bitcoin value, and a UTXO with a luster value of
> 0 must burn 100 percent of its bitcoin value. Thus the coins/UTXOs that
> have a luster value of 0 means it has no monetary value, and it would be
> safe for bitcoins nodes to drop those UTXOs from the set they maintain.
>
> The idea is that coins that are continuously being used in Bitcoin economy
> will never lose it?s luster. But coins that are old and not circulating
> will start to lose its luster up until all luster is lost and they become
> valueless. Or they reenter the economy and regains all its luster.
>
> But at what point should coins start losing their luster? A goal would be
> that we want to minimize the scenarios of when coins start losing their
> luster. One reasonable answer is that coins should only starting losing its
> luster after the lifespan of the average human. The idea being that a
> person will eventually have to spend all his coins before he dies,
> otherwise it will get lost anyways (assuming that only the dying person has
> the ability to spend those coins). Otherwise there are few cases where a
> person would never spend their bitcoins in there human life time. One
> example is in the case of inheritance where a dying person does not want to
> spend his remaining coins and have another person take them over. But with
> this propose scaling solution, coins can be stilled inherited, but it would
> have to be an on-chain inheritance. The longest lifespan of a human
> currently is about 120 years old. So a blockchain that stores the last 150
> years of history seems like one reasonable option.
>
> Then the question of how large blocks should be is simply a matter of what
> is the disk size requirement for a full node. For simplicity, assuming that
> a block is created every 10 minute, the blockchain size in terabyte can be
> express as the following.
> blockSize MB * 6 * 24 * 365 * years /1000000 = blockchainSize TB
>
> Example values:
> blockSize = 1MB, years = 150 -> blockchainSize = 7.884 TB
> blockSize = 2MB, years = 150 -> blockchainSize = 15.768 TB
>
> So if we don?t want the block chain to be bigger then 8 TB, then we should
> have a block size of 1 MB. If we don?t want the block chain to be bigger
> then 16 TB, then we should have a block size of 2 MB and so on. The idea is
> that base on how cheap disk space gets, we can adjust the target max block
> chain size and the block size accordingly.
>
> I believe that this proposal is a good solution to the UTXO growth
> problem. The proposal being a soft fork is a big plus. It also keeps the
> block chain size finite even if given a infinite amount of time. But there
> are other things to considered, like how best should wallet software handle
> this? How can this work with sidechains? More thought would need to be put
> into this. But the fact is that if we want to make bitcoins last forever,
> we have the accept unbounded UTXO growth, which is unscalable. So the only
> solution is to limit UTXO growth, meaning bitcoins cannot last forever.
> This proposed solution however does not prevent Bitcoin from lasting
> forever.
>
>
> _______________________________________________
> 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/20170721/6079164c/attachment.html>

From jlrubin at mit.edu  Fri Jul 21 19:52:45 2017
From: jlrubin at mit.edu (Jeremy)
Date: Fri, 21 Jul 2017 15:52:45 -0400
Subject: [bitcoin-dev] UTXO growth scaling solution proposal
In-Reply-To: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>
References: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>
Message-ID: <CAD5xwhiYfGcH6Bt2ESFAoR7pt9-vC1zXio3pk1X-h60m_QMqZQ@mail.gmail.com>

Hi Major,

I think that you'll enjoy Peter Todd's blogpost on TXO commitments[1]. It
has a better scalability improvement with fewer negative consequence.

Best,

Jeremy



[1] https://petertodd.org/2016/delayed-txo-commitments


--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

On Fri, Jul 21, 2017 at 3:28 PM, Major Kusanagi via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi all,
>
> I have a scaling solution idea that I would be interested in getting some
> feedback on. I?m new to the mailing list and have not been in the Bitcoin
> space as long as some have been, so I don?t know if anyone has thought of
> this idea.
>
> Arguably the biggest scaling problem for Bitcoin is the unbounded UTXO
> growth. Current scaling solutions like Segregated Witness, Lighting
> Network, and larger blocks does not address this issue. As more and more
> blocks are added to the block chain the size of the UTXO set that miners
> have to maintain continues to grow. This is the case even if the block size
> were to remain at 1 megabyte. There is no way out of solving this
> fundamental scaling problem other then to limit the maximum size of the
> UTXO set.
>
> The following soft fork solution is proposed. Any UTXO that is not spent
> within a set number of blocks is considered invalid. What this means for
> miners and nodes in the Bitcoin network is that they only have to ever
> store that set number of blocks. In others words the block chain will never
> be larger then the set number of blocks and the size of the block chain is
> capped.
>
> But what this means for users is that bitcoins that have not been spent
> for a long time are ?lost? forever. This proposed solution is likely a
> difficult thing for Bitcoin users to accept. What Bitcoin users will
> experience is that all of a sudden their bitcoins are spendable one moment
> and the next moment they are not. The experience that they get is that all
> of a sudden their old bitcoins are gone forever.
>
> The solution can be improved by adding this new mechanism to Bitcoin, that
> I will call luster. UTXO?s that are less then X blocks old has not lost any
> luster and have a luster value of 1. As UTXO?s get older, the luster value
> will continuously decrease until the UTXO?s become Z blocks old (where Z >
> X), and has lost all it?s luster and have a luster value of 0. UTXO?s that
> are in between X and Z blocks old have a luster value between 0 and 1. The
> luster value is then used to compute the amount of bitcoins that must be
> burned in order for a transaction with that UTXO to be included in a block.
> So for example, a UTXO with a luster value of 0.5 must burn at least 50
> percent of its bitcoin value, a UTXO with a luster value of 0.25 must burn
> at least 75 percent of its bitcoin value, and a UTXO with a luster value of
> 0 must burn 100 percent of its bitcoin value. Thus the coins/UTXOs that
> have a luster value of 0 means it has no monetary value, and it would be
> safe for bitcoins nodes to drop those UTXOs from the set they maintain.
>
> The idea is that coins that are continuously being used in Bitcoin economy
> will never lose it?s luster. But coins that are old and not circulating
> will start to lose its luster up until all luster is lost and they become
> valueless. Or they reenter the economy and regains all its luster.
>
> But at what point should coins start losing their luster? A goal would be
> that we want to minimize the scenarios of when coins start losing their
> luster. One reasonable answer is that coins should only starting losing its
> luster after the lifespan of the average human. The idea being that a
> person will eventually have to spend all his coins before he dies,
> otherwise it will get lost anyways (assuming that only the dying person has
> the ability to spend those coins). Otherwise there are few cases where a
> person would never spend their bitcoins in there human life time. One
> example is in the case of inheritance where a dying person does not want to
> spend his remaining coins and have another person take them over. But with
> this propose scaling solution, coins can be stilled inherited, but it would
> have to be an on-chain inheritance. The longest lifespan of a human
> currently is about 120 years old. So a blockchain that stores the last 150
> years of history seems like one reasonable option.
>
> Then the question of how large blocks should be is simply a matter of what
> is the disk size requirement for a full node. For simplicity, assuming that
> a block is created every 10 minute, the blockchain size in terabyte can be
> express as the following.
> blockSize MB * 6 * 24 * 365 * years /1000000 = blockchainSize TB
>
> Example values:
> blockSize = 1MB, years = 150 -> blockchainSize = 7.884 TB
> blockSize = 2MB, years = 150 -> blockchainSize = 15.768 TB
>
> So if we don?t want the block chain to be bigger then 8 TB, then we should
> have a block size of 1 MB. If we don?t want the block chain to be bigger
> then 16 TB, then we should have a block size of 2 MB and so on. The idea is
> that base on how cheap disk space gets, we can adjust the target max block
> chain size and the block size accordingly.
>
> I believe that this proposal is a good solution to the UTXO growth
> problem. The proposal being a soft fork is a big plus. It also keeps the
> block chain size finite even if given a infinite amount of time. But there
> are other things to considered, like how best should wallet software handle
> this? How can this work with sidechains? More thought would need to be put
> into this. But the fact is that if we want to make bitcoins last forever,
> we have the accept unbounded UTXO growth, which is unscalable. So the only
> solution is to limit UTXO growth, meaning bitcoins cannot last forever.
> This proposed solution however does not prevent Bitcoin from lasting
> forever.
>
>
> _______________________________________________
> 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/20170721/06525326/attachment-0001.html>

From lvella at gmail.com  Fri Jul 21 19:59:42 2017
From: lvella at gmail.com (Lucas Clemente Vella)
Date: Fri, 21 Jul 2017 16:59:42 -0300
Subject: [bitcoin-dev] UTXO growth scaling solution proposal
In-Reply-To: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>
References: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>
Message-ID: <CAGCathzWMVsmM1wO8eYAZmytEy1Q--ajdr0ssQHedaJWEPu0PA@mail.gmail.com>

2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> [...] But the fact is that if we want to make bitcoins last forever, we
> have the accept unbounded UTXO growth, which is unscalable. So the only
> solution is to limit UTXO growth, meaning bitcoins cannot last forever.
> This proposed solution however does not prevent Bitcoin from lasting
> forever.
>

Unless there is a logical contradiction in this phrasing, the proposed
solution does not improves scalability:
 - "Bitcoins lasting forever" implies "unscalable";
 - "not prevent Bitcoin from lasting forever" implies "Bitcoins lasting
forever";
 - Thus: "not prevent Bitcoin from lasting forever" implies "unscalable".

In practice, the only Bitcoin lost would be those whose owners forgot about
or has lost the keys, because everyone with a significant amount of
Bitcoins would always shift them around before it loses any luster (I
wouldn't bother to move my Bitcoins every 10 years). I don't know how to
estimate the percentage of UTXO is actually lost/forgotten, but I have the
opinion it isn't worth the hassle.

As a side note, your estimate talks about block size, which is determines
blockchain size, which can be "safely" pruned (if you are not considering
new nodes might want to join the network, in case the full history is
needed to be stored somewhere). But UTXO size, albeit related to the full
blockchain size, is the part that currently can not be safely pruned, so I
don't see the relevance of the analysis.

-- 
Lucas Clemente Vella
lvella at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170721/5f4564df/attachment.html>

From ethan.scruples at gmail.com  Fri Jul 21 20:17:39 2017
From: ethan.scruples at gmail.com (Moral Agent)
Date: Fri, 21 Jul 2017 16:17:39 -0400
Subject: [bitcoin-dev] UTXO growth scaling solution proposal
In-Reply-To: <CAGCathzWMVsmM1wO8eYAZmytEy1Q--ajdr0ssQHedaJWEPu0PA@mail.gmail.com>
References: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>
	<CAGCathzWMVsmM1wO8eYAZmytEy1Q--ajdr0ssQHedaJWEPu0PA@mail.gmail.com>
Message-ID: <CACiOHGxYGdaPTAt07HFFGPEDhRC4PM3FZKk8Cwc0RgDN74qQrw@mail.gmail.com>

If we have a problem with a UTXO set that is too large, seems like maybe
the fair way to approach it is to enforce a limit on the growth of the UTXO
set.

Miners would eventually be forced to generate blocks that are UTXO neutral
and would factor that into their algorithm for prioritizing transactions.
Users who wish to generate a lot of outputs would need to find a buddy with
lots of inputs to consolidate and create a tumble-bit with them. A market
would spring up that would charge people for creating UTXOs and pay them
for disposing of UTXOs.

On Fri, Jul 21, 2017 at 3:59 PM, Lucas Clemente Vella via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> 2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org>:
>
>> [...] But the fact is that if we want to make bitcoins last forever, we
>> have the accept unbounded UTXO growth, which is unscalable. So the only
>> solution is to limit UTXO growth, meaning bitcoins cannot last forever.
>> This proposed solution however does not prevent Bitcoin from lasting
>> forever.
>>
>
> Unless there is a logical contradiction in this phrasing, the proposed
> solution does not improves scalability:
>  - "Bitcoins lasting forever" implies "unscalable";
>  - "not prevent Bitcoin from lasting forever" implies "Bitcoins lasting
> forever";
>  - Thus: "not prevent Bitcoin from lasting forever" implies "unscalable".
>
> In practice, the only Bitcoin lost would be those whose owners forgot
> about or has lost the keys, because everyone with a significant amount of
> Bitcoins would always shift them around before it loses any luster (I
> wouldn't bother to move my Bitcoins every 10 years). I don't know how to
> estimate the percentage of UTXO is actually lost/forgotten, but I have the
> opinion it isn't worth the hassle.
>
> As a side note, your estimate talks about block size, which is determines
> blockchain size, which can be "safely" pruned (if you are not considering
> new nodes might want to join the network, in case the full history is
> needed to be stored somewhere). But UTXO size, albeit related to the full
> blockchain size, is the part that currently can not be safely pruned, so I
> don't see the relevance of the analysis.
>
> --
> Lucas Clemente Vella
> lvella at gmail.com
>
> _______________________________________________
> 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/20170721/6e75b99b/attachment.html>

From heater at gmail.com  Sat Jul 22 03:58:21 2017
From: heater at gmail.com (Zheming Lin)
Date: Sat, 22 Jul 2017 11:58:21 +0800
Subject: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network
 Upgrade Activated by Miners
In-Reply-To: <8999832B-BD81-415A-9CA5-0DE397A1A904@voskuil.org>
References: <A6AE8145-8C8A-44C2-88D3-8574D895AF6B@gmail.com>
	<CAAS2fgT=0k0NJWsO_TtBRTi2VqZtzuT1d1Sk+KZ2+2PUcA71tg@mail.gmail.com>
	<A5275580-0EA3-4021-8E4E-55E214BCEECB@gmail.com>
	<CADL_X_fdZG50HHb3iOePrzuOwU55tAqP80u3--xXEDWBKL7=jg@mail.gmail.com>
	<31040BE1-64ED-4D05-BCBE-E80BC7B9A182@gmail.com>
	<CADL_X_e0wuKTUbAiYyuDuk74+DQ98j1kkmBPz5c5RjU4R7RB3Q@mail.gmail.com>
	<95BB8EA8-31F6-4131-B557-A35342FA17A1@voskuil.org>
	<CAJowKgJE6+1nKFYngTRhS_X2z_tmLoxY__J_Aph6UHmAnR8tcQ@mail.gmail.com>
	<8999832B-BD81-415A-9CA5-0DE397A1A904@voskuil.org>
Message-ID: <CAJVXTPm2HZ989j3HiRXxJWoaT_r61ySF=v3xptdoyOUvhWPhqA@mail.gmail.com>

I think we should not switch to Proof of Stake system.

in Proof of Stake system, the one with more voting power tend to protect
their investment and that will stop others from competing with them. they
will use the voting power to make entering barrier, limiting the
competition is bad for bitcoin economy (I believe).

Miners are not centralized, they just grow bigger and be industrialized,
but there's still a lot of competition. The competition is the main
security model of bitcoin system.

When we are talking about "security" in bitcoin system, we are talking
about the probability that a transaction revert or change. We can not be
100% sure under 3 confirmations, but in 6 or more confirmations, we think
the cash received is safe and can't be taken away. That's the security
provided by bitcoin system.

Hard fork is not dangerous, when hard fork happens, people can wait for a
short time (like maintenance of a POS/CreditCard system). When the chain
with most hashrate wins (with high enough probability), we can then safely
assume that the longest chain can't be reverted.


Regards,
LIN Zheming
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170722/53d6b5eb/attachment.html>

From majorkusanagibtc at gmail.com  Sat Jul 22 06:43:45 2017
From: majorkusanagibtc at gmail.com (Major Kusanagi)
Date: Fri, 21 Jul 2017 23:43:45 -0700
Subject: [bitcoin-dev] UTXO growth scaling solution proposal
In-Reply-To: <CADL_X_cbvWf0OqW0KChJDOXA=B-eedUZ98J7v9vTvZL1gHx8pQ@mail.gmail.com>
References: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>
	<CADL_X_cbvWf0OqW0KChJDOXA=B-eedUZ98J7v9vTvZL1gHx8pQ@mail.gmail.com>
Message-ID: <CAAU88OqkgK9CcdmoR0K86-g6ncc4uAYOvdRatjsttWb29r9o=g@mail.gmail.com>

On Fri, Jul 21, 2017 at 12:54 PM, Jameson Lopp <jameson.lopp at gmail.com>
wrote:

> Sounds like demurrage to me, which has been implemented in other
> cryptocurrencies such as Freicoin - http://freico.in/
>

I don?t think it?s like demurrage in Freicoin at all. The purpose of the
proposal is to help Bitcoin scale, which is not the purpose of Freicoin?s
demurrage fee. Demurrage fee is not optional in Freicoin, and with this
proposal most users will likely never have to burn any coins at all given
how long it would take for bitcoins to lose their luster.



> While it's an interesting to apply this line of thinking from a scaling
> perspective, I suspect most would find it untenable from a monetary policy
> perspective.
>
> I don?t think most would find it untenable, because the proposal in
practice would not affect 99.9% of users because it is unlikely that coins
will ever get to the point where they start losing their luster.



> You have touched on a scaling issue, the cost of node operation, that I
> think is really the root cause of a lot of the debate. Thus even if your
> proposal was implemented, we'd still have to solve the problem of finding a
> consensus for CONOP.
>
> I believe with this proposal, finding a consensus for CONOP becomes a lot
less controversial. Because by putting a cap on the block chain size and
UTXO set, we know exactly how much disk space and RAM a node needs to run a
full node.



> I think you may have misapplied your logic to the total size of the
> blockchain, however. Are you suggesting that pruning of the old UTXOs would
> also enable pruning of old blocks from all nodes? Those things aren't
> really related, plus someone would still have to keep old blocks around in
> order to facilitate new nodes syncing from genesis.
>
> Sorry, let me clarify. I forgot to address the issue of how new nodes sync
the block chain. I mean to say that we should prune the old UTXOs along
with the old blocks. This would mean that we would have to create a
checkpoint every ~150 fifty years (base on my example) and node would drop
blocks older then those checkpoints.  This would mean new nodes would start
syncing from the checkpoint not the genesis block.



> - Jameson
>
> On Fri, Jul 21, 2017 at 3:28 PM, Major Kusanagi via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi all,
>>
>> I have a scaling solution idea that I would be interested in getting some
>> feedback on. I?m new to the mailing list and have not been in the Bitcoin
>> space as long as some have been, so I don?t know if anyone has thought of
>> this idea.
>>
>> Arguably the biggest scaling problem for Bitcoin is the unbounded UTXO
>> growth. Current scaling solutions like Segregated Witness, Lighting
>> Network, and larger blocks does not address this issue. As more and more
>> blocks are added to the block chain the size of the UTXO set that miners
>> have to maintain continues to grow. This is the case even if the block size
>> were to remain at 1 megabyte. There is no way out of solving this
>> fundamental scaling problem other then to limit the maximum size of the
>> UTXO set.
>>
>> The following soft fork solution is proposed. Any UTXO that is not spent
>> within a set number of blocks is considered invalid. What this means for
>> miners and nodes in the Bitcoin network is that they only have to ever
>> store that set number of blocks. In others words the block chain will never
>> be larger then the set number of blocks and the size of the block chain is
>> capped.
>>
>> But what this means for users is that bitcoins that have not been spent
>> for a long time are ?lost? forever. This proposed solution is likely a
>> difficult thing for Bitcoin users to accept. What Bitcoin users will
>> experience is that all of a sudden their bitcoins are spendable one moment
>> and the next moment they are not. The experience that they get is that all
>> of a sudden their old bitcoins are gone forever.
>>
>> The solution can be improved by adding this new mechanism to Bitcoin,
>> that I will call luster. UTXO?s that are less then X blocks old has not
>> lost any luster and have a luster value of 1. As UTXO?s get older, the
>> luster value will continuously decrease until the UTXO?s become Z blocks
>> old (where Z > X), and has lost all it?s luster and have a luster value of
>> 0. UTXO?s that are in between X and Z blocks old have a luster value
>> between 0 and 1. The luster value is then used to compute the amount of
>> bitcoins that must be burned in order for a transaction with that UTXO to
>> be included in a block. So for example, a UTXO with a luster value of 0.5
>> must burn at least 50 percent of its bitcoin value, a UTXO with a luster
>> value of 0.25 must burn at least 75 percent of its bitcoin value, and a
>> UTXO with a luster value of 0 must burn 100 percent of its bitcoin value.
>> Thus the coins/UTXOs that have a luster value of 0 means it has no monetary
>> value, and it would be safe for bitcoins nodes to drop those UTXOs from the
>> set they maintain.
>>
>> The idea is that coins that are continuously being used in Bitcoin
>> economy will never lose it?s luster. But coins that are old and not
>> circulating will start to lose its luster up until all luster is lost and
>> they become valueless. Or they reenter the economy and regains all its
>> luster.
>>
>> But at what point should coins start losing their luster? A goal would be
>> that we want to minimize the scenarios of when coins start losing their
>> luster. One reasonable answer is that coins should only starting losing its
>> luster after the lifespan of the average human. The idea being that a
>> person will eventually have to spend all his coins before he dies,
>> otherwise it will get lost anyways (assuming that only the dying person has
>> the ability to spend those coins). Otherwise there are few cases where a
>> person would never spend their bitcoins in there human life time. One
>> example is in the case of inheritance where a dying person does not want to
>> spend his remaining coins and have another person take them over. But with
>> this propose scaling solution, coins can be stilled inherited, but it would
>> have to be an on-chain inheritance. The longest lifespan of a human
>> currently is about 120 years old. So a blockchain that stores the last 150
>> years of history seems like one reasonable option.
>>
>> Then the question of how large blocks should be is simply a matter of
>> what is the disk size requirement for a full node. For simplicity, assuming
>> that a block is created every 10 minute, the blockchain size in terabyte
>> can be express as the following.
>> blockSize MB * 6 * 24 * 365 * years /1000000 = blockchainSize TB
>>
>> Example values:
>> blockSize = 1MB, years = 150 -> blockchainSize = 7.884 TB
>> blockSize = 2MB, years = 150 -> blockchainSize = 15.768 TB
>>
>> So if we don?t want the block chain to be bigger then 8 TB, then we
>> should have a block size of 1 MB. If we don?t want the block chain to be
>> bigger then 16 TB, then we should have a block size of 2 MB and so on. The
>> idea is that base on how cheap disk space gets, we can adjust the target
>> max block chain size and the block size accordingly.
>>
>> I believe that this proposal is a good solution to the UTXO growth
>> problem. The proposal being a soft fork is a big plus. It also keeps the
>> block chain size finite even if given a infinite amount of time. But there
>> are other things to considered, like how best should wallet software handle
>> this? How can this work with sidechains? More thought would need to be put
>> into this. But the fact is that if we want to make bitcoins last forever,
>> we have the accept unbounded UTXO growth, which is unscalable. So the only
>> solution is to limit UTXO growth, meaning bitcoins cannot last forever.
>> This proposed solution however does not prevent Bitcoin from lasting
>> forever.
>>
>>
>> _______________________________________________
>> 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/20170721/0e3b9978/attachment-0001.html>

From majorkusanagibtc at gmail.com  Sat Jul 22 06:45:54 2017
From: majorkusanagibtc at gmail.com (Major Kusanagi)
Date: Fri, 21 Jul 2017 23:45:54 -0700
Subject: [bitcoin-dev] UTXO growth scaling solution proposal
In-Reply-To: <CAGCathzWMVsmM1wO8eYAZmytEy1Q--ajdr0ssQHedaJWEPu0PA@mail.gmail.com>
References: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>
	<CAGCathzWMVsmM1wO8eYAZmytEy1Q--ajdr0ssQHedaJWEPu0PA@mail.gmail.com>
Message-ID: <CAAU88OrgczrCGZpeP5Q+_LQoFcbkV_-foops7fWmJXQ1VhCZ6w@mail.gmail.com>

On Fri, Jul 21, 2017 at 12:59 PM, Lucas Clemente Vella <lvella at gmail.com>
wrote:

> 2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org>:
>
>> [...] But the fact is that if we want to make bitcoins last forever, we
>> have the accept unbounded UTXO growth, which is unscalable. So the only
>> solution is to limit UTXO growth, meaning bitcoins cannot last forever.
>> This proposed solution however does not prevent Bitcoin from lasting
>> forever.
>>
>
> Unless there is a logical contradiction in this phrasing, the proposed
> solution does not improves scalability:
>  - "Bitcoins lasting forever" implies "unscalable";
>  - "not prevent Bitcoin from lasting forever" implies "Bitcoins lasting
> forever";
>  - Thus: "not prevent Bitcoin from lasting forever" implies "unscalable".
>

I made a distinction between lowercase bitcoin meaning the unit of account
in uppercase Bitcoin, the system as a whole. The proposal would make
bitcoins not last forever, which allows the Bitcoin system to scale better
and have a better chance of lasting forever.



> In practice, the only Bitcoin lost would be those whose owners forgot
> about or has lost the keys, because everyone with a significant amount of
> Bitcoins would always shift them around before it loses any luster (I
> wouldn't bother to move my Bitcoins every 10 years). I don't know how to
> estimate the percentage of UTXO is actually lost/forgotten, but I have the
> opinion it isn't worth the hassle.
>

Exactly. That?s the whole idea. Why bother have nodes store UTXO?s for lost
bitcoins? This proposal would essentially sanitize the UTXO set that nodes
keep track of and clear up wasted space.


As a side note, your estimate talks about block size, which is determines
> blockchain size, which can be "safely" pruned (if you are not considering
> new nodes might want to join the network, in case the full history is
> needed to be stored somewhere). But UTXO size, albeit related to the full
> blockchain size, is the part that currently can not be safely pruned, so I
> don't see the relevance of the analysis.
>
> I believe I?ve address this with the checkpoint mechanism in my reply to
Jameson.



> --
> Lucas Clemente Vella
> lvella at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170721/272df89a/attachment.html>

From federicotenga at gmail.com  Thu Jul 27 16:52:52 2017
From: federicotenga at gmail.com (Federico Tenga)
Date: Thu, 27 Jul 2017 18:52:52 +0200
Subject: [bitcoin-dev] [BIP Proposal] Standard address format for
 timelocked funds
In-Reply-To: <ST-p1uYWpwTa6RLgXAd5NLgZwt_rzJdxQaK2X5kp6gmjmj-uCw8VNANcfR3mAMBFV5D4j52TC6fX612pFWkrcg2jpjiDtLnGHyd6DQtt7Oo=@protonmail.com>
References: <VxtMcRFeh3Yr86KleeyK3BeZ9_KJVSmRtMgIdanwcEe23IrBwK0Q_ozC_EyxX6KHRcpePKgnaBk9KsY_i77k4Be3QEosXhUwbj561t4oJqw=@protonmail.com>
	<ST-p1uYWpwTa6RLgXAd5NLgZwt_rzJdxQaK2X5kp6gmjmj-uCw8VNANcfR3mAMBFV5D4j52TC6fX612pFWkrcg2jpjiDtLnGHyd6DQtt7Oo=@protonmail.com>
Message-ID: <CAP=-fx6xGHa=1BO6xKfjQ5pfWnRECtps+RQQp2oXYyZu5XjPxA@mail.gmail.com>

Hi ZmnSCPxj,

Few thoughts about your proposal:
1- I kinda like the idea and I would probably use it, but still I believe
it is a very limited use case and probably most wallet providers will not
be interested in supporting it.
2- Early adopters and people highly involved in the community may
appreciate the "hodl" part in the redemption code, but it could cause
confusion in normal users not understanding the reference.

Regarding the time-zone I think the best option is to stick the UTC
standard, using UTC+14 could be confusing since it is very unusual  and we
are not used to deal with it.



On 12 July 2017 at 10:30, ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Good morning mailinglist,
>
> I am saddened at the lack of attention to this BIP proposal.  I know that
> it is not as interesting as the debates on where Bitcoin will go in the
> future and what needs to be prepared for even greater mainstream adoption,
> but I think my BIP proposal does have at least some value to long-term
> investors.
>
> So far I have seen only a single public feedback:
>
> https://www.reddit.com/r/Bitcoin/comments/6lzpvz/bip_hodl/djxzbvi/
>
> Basically, the point in that feedback is mostly that the computed timelock
> should be UTC+0 0000h of the given human-readable date.
>
> I would like to respectfully ask the mailing list about which option is
> best:
>
> 1.  (current) Use the earliest timezone as of now, UTC+14 0000h of the
> given human-readable date.  Pro: No matter where you are in the world, as
> soon as the given date arrives, the fund can be spent.  Con: For most of
> the world, the fund can be spent on some time the day before, or even two
> days before for UTC-11 and UTC-12 timezones.
>
> 2.  Use the standard timezone UTC+0 0000h of the given human-readable
> date.  Pro: standard time.  Con: for half of the world, the fund is not
> spendable until some time into the given date, for the other half, it will
> be spendable at an earlier date.
>
> 3.  Allow indicating a timezone to the human-readable part.  Pro: gives
> control over the user's expected local time.  Con: additional field and
> effectively more control, need to handle also strange timezones that have
> 0.5 hour difference from UTC, need to encode positive and negative
> preferably without using + and -, as those may break double-click selection.
>
> I hope to get some feedback from this list.
>
> Regards,
> ZmnSCPxj
>
> -------- Original Message --------
> Subject: [bitcoin-dev] [BIP Proposal] Standard address format for
> timelocked funds
> Local Time: July 8, 2017 9:13 AM
> UTC Time: July 8, 2017 1:13 AM
> From: bitcoin-dev at lists.linuxfoundation.org
> To: bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
>
>
> <pre>
> BIP: ?
> Title: Standard address format for timelocked funds
> Author: ZmnSCPxj <ZmnSCPxj at protonmail.com>
> Comments-Summary: ?
> Comments-URI: ?
> Status: ?
> Type: ?
> Created: 2017-07-01
> License: CC0-1.0
> </pre>
>
> == Abstract ==
>
> <code>OP_CHECKLOCKTIMEVERIFY</code> provides a method of
> locking funds until a particular time arrives.
> One potential use of this opcode is for a user to precommit
> himself or herself to not spend funds until a particular
> date, i.e. to hold the funds until a later date.
>
> This proposal adds a format for specifying addresses that
> precommit to timelocked funds, as well as specifying a
> redemption code to redeem funds after the timelock has
> passed.
> This allows ordinary non-technical users to make use of
> <code>OP_CHECKLOCKTIMEVERIFY</code> easily.
>
> == Copyright ==
>
> This BIP is released under CC0-1.0.
>
> == Specification ==
>
> This proposal provides formats for specifying an
> address that locks funds until a specified date,
> and a redemption code that allows the funds to be
> swept on or after the specified date.
>
> At minimum, wallet software supporting this BIP must
> be capable of sweeping the redemption code on or after
> the specified date.
> In addition, the wallet software should support sending
> funds to the timelocked address specified here.
> Finally, wallet software may provide a command to create
> a pair of timelocked address and redemption code.
>
> Addresses and redemption codes are encoded using
> [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Bech32
> Bech32 encoding].
>
> === Timelocked Address Format ===
>
> The human-readable part of the address is composed of:
>
> # The four characters <code>hodl</code>.
> # A date, in <code>YYYYMMDD</code> form.  For example,
>   the date August 1, 2017 is encoded as <code>20170801</code>.
> # A network code, either <code>tb</code> for testnet,
>   or <code>bc</code> for Bitcoin mainnet.
>
> The data part of the address is composed of:
>
> # A version quintet (5 bits), which must be 0 for this
>   BIP.
> # A public key hash, 32 quintets (160 bits).  As is
>   usual for Bitcoin, this is big-endian.
>
> This is to be interpreted as follows:
>
> # The given date is the first day that the funds in
>   the given address may be redeemed.
> # The funds are owned by whoever controls the private
>   key corresponding to the public key hash given.
>
> === Redemption Code ===
>
> The human-readable part of the redemption code is
> composed of:
>
> # The four characters <code>hedl</code>.
> # A date, in <code>YYYYMMDD</code> form.
> # A network code, either <code>tb</code> for testnet,
>   or <code>bc</code> for Bitcoin mainnet.
>
> The data part of the address is composed of:
>
> # A version quintet (5 bits), which must be 0 for this
>   BIP.
> # A private key, 52 quintets (260 bits).  This is the
>   256-bit private key, prepended with 4 <code>0</code>
>   bits, in big-endian order.   <!-- We could consider
>   some kind of mini private key instead if the security
>   is similar anyway.  -->
>
> This is to be interpreted as follows:
>
> # The given date is the first day that the funds in
>   the given address may be redeemed.
> # The private key unlocks the funds.
>
> === Lock Time Computation ===
>
> Given a particular lock date <code>YYYYMMDD</code>, the
> actual lock time is computed as follows:
>
> # The day before the lock date is taken.  For example,
>   if the lock date is <code>20180101</code> or
>   January 1, 2018, we take the date December 31, 2017.
> # We take the time 1000h (10:00 AM, or 10 in the morning)
>   of the date from the above step.
>
> This lock time is then translated to a
> Unix epoch time, as per POSIX.1-2001 (which removes the
> buggy day February 29, 2100 in previous POSIX revisions).
> The translation should use, at minimum, unsigned 32-bit
> numbers to represent the Unix epoch time.
>
> The Unix epoch time shall then be interpreted as an
> <code>nLockTime</code> value, as per standard Bitcoin.
> Whether it is possible to represent dates past 2038
> will depend on whether standard Bitcoin can represent
> <code>nLockTime</code> values to represent dates past
> 2038.
> Since <code>nLockTime</code> is an unsigned 32-bit
> value, it should be possible to represent dates until
> 06:28:15 UTC+0 2106-02-07.
> Future versions of Bitcoin should be able to support
> <code>nLockTime</code> larger than unsigned 32-bit,
> in order to allow even later dates.
>
> The reason for using an earlier lock time than the
> specified date is given in the Rationale section of
> this BIP.
>
> === Payment to a Timelocked Address ===
>
> An ordinary P2SH payment is used to provide funds to a
> timelocked address.
>
> The script below is used as the <code>redeemScript</code>
> for the P2SH payment:
>
> <timeout> OP_CHECKLOCKTIMEVERIFY OP_DROP
> OP_DUP OP_HASH160 <publickeyhash> OP_EQUALVERIFY OP_CHECKSIG
>
> Once the <code>redeemScript</code> is derived, the hash is
> determined, and an ordinary P2SH output with the below
> <code>scriptPubKey</code> used:
>
> OP_HASH160 <redeemScripthash> OP_EQUAL
>
> In case of SegWit deployment, SegWit-compatible wallets
> should be able to use P2SH, P2WSH, or P2SH-P2WSH, as per
> the output they would normally use in that situation.
>
> Obviously, a timelocked address has an equivalent
> Bitcoin <code>3</code> (P2SH) address.
> A simple service or software that translates from a
> public timelocked address to a P2SH address can be
> created that makes timelocking (but not redemption)
> backwards compatible with wallets that do not support
> this BIP.
>
> This proposal recommends that wallets supporting payment
> to P2PKH, P2SH, P2WPKH, and P2WSH Bitcoin addresses should
> reuse the same interface for paying to such addresses as
> paying into timelocked addresses of this proposal.
>
> === Redemption of a Timelocked Redemption Code ===
>
> To sweep a timelocked redemption code after the timelock,
> one must provide the given <code>redeemScript</code> as
> part of the <code>scriptSig</code>, of all unspent
> outputs that pay to the given <code>redeemScript</code>
> hash.
>
> When sweeping a timelocked redemption code, first the
> wallet must extract the private key from the redemption
> code, then derive the public key, the public key hash,
> the <code>redeemScript</code>, and finally the
> <code>redeemScript</code> hash.
>
> Then, the wallet must find all unspent outputs that pay
> to the <code>redeemScript</code> hash via P2SH (and, in the
> case of SegWit deployment, via P2SH-P2WSH and P2WSH).
>
> For each such output, the wallet then generates a
> transaction input with the below <code>scriptSig</code>, as
> per usual P2SH redemptions:
>
> <signature> <pubkey> <redeemScript>
>
> The wallet then outputs to an address it can control.
>
> As the Script involved uses <code>OP_CHECKLOCKTIMEVERIFY</code>,
> the <code>nSequence</code> must be 0 and the
> <code>nLockTime</code> must be equal to the computed
> lock time.
> This implies that the transaction cannot be transmitted
> (and the funds cannot be sweeped)
> until after the given lock time.
>
> The above procedure is roughly identical to sweeping an
> ordinary, exported private key.
>
> This proposal recommends that wallets supporting a sweep
> function should reuse the same interface for sweeping
> individual private keys (wallet import format) for sweeping
> timelocked redemption codes.
>
> == Motivation ==
>
> A key motivation for this BIP is to allow easy use of
> <code>OP_CHECKLOCKTIMEVERIFY</code> by end-users.
>
> The below are expected use cases of this proposal:
>
> # A user wants to purchase an amount of Bitcoin,
> and subsequently wait for an amount of time before
> cashing out.
> The user fears that he or she may have "weak hands",
> i.e. sell unfavorably on a temporary dip, and thus
> commits the coins into a timelocked fund that can
> only be opened after a specific date.
> # A user wants to gift an amount of Bitcoins to
> an infant or minor, and wants the fund to not be spent
> on ill-advised purchases until the infant or minor
> reaches the age of maturity.
> # A user may wish to prepare some kind of monthly subsidy
> or allowance to another user, and prepares a series of
> timelocked addresses, redeemable at some set date on
> each month, and provides the private redemption codes to
> the beneficiary.
> # A user may fear duress or ransom for a particular
> future time horizon, and voluntarily impose a lock time
> during which a majority of their funds cannot be spent.
>
> == Rationale ==
>
> While in principle, this proposal may be implemented as a
> separate service or software, we should consider the long
> time horizons that may be desired by users.
> A user using a particular software to timelock a fund may
> have concerns, for example, of specifying a timelock
> 18 years in the future for a gift or inheritance to a
> newborn infant.
> The software or service may no longer exist after 18 years,
> unless the user himself or herself takes over maintenance
> of that software or service.
> By having a single standard for timelocked funds that is
> shared and common among multiple implementations of Bitcoin
> wallets, the user has some assurance that the redemption code
> for the funds is still useable after 18 years.
> Further, a publicly-accessible standard specifying how the
> funds can be redeemed will allow technically-capable users
> or beneficiaries to create software that can redeem the
> timelocked fund.
>
> This proposal provides a timelock at the granularity of a
> day.
> The expectation is that users will have long time
> durations of months or years, so that the ability to
> specify exact times, which would require specifying the
> timezone, is unneeded.
>
> The actual timeout used is 1000h of the day before the
> human-readable date, so that timezones of UTC+14 will
> definitely be able to redeem the money starting at
> 0000h of the human-readable date, local time (UTC+14).
> Given the expectation that users will use long time
> durations, the fact that timezones of UTC-12 will
> actually be able to redeem the funds on 2200h UTC-12
> time two days before can be considered an acceptable
> error.
>
> The human-readable date is formatted according to
> [https://www.iso.org/iso-8601-date-and-time-format.html
> ISO standard dates], with the dashes removed.
> Dashes may prevent double-click selection, making
> usability of these addresses less desirable.
> <!--
> We can consider something like 2021m12d11 instead,
> which would be much more readable and understandable
> to human users.
> -->
>
> The <code>bc</code> or <code>tb</code> is after the
> date since the date is composed of digits and the bech32
> separator itself is the digit <code>1</code>.  One
> simply needs to compare <code>hedlbc202111211...</code>
> and <code>hedl20211121bc1...</code>.
>
> A version quintet is added in case of a future
> sociopolitical event that changes interpretation of
> dates, or changes in scripting that would allow for more
> efficient redemptions of timelocked funds (which would
> change the <code>redeemScript</code> paid to), or changes
> in the size and/or format of lock times, and so on.
> Such changes are unlikely, so the version is a quintet in
> the bech32 data part rather than a substring in the
> human-readable part.
>
> The public address format uses the <code>hodl</code> as
> the start of the code, while the private key (the
> redemption code) uses <code>hedl</code>.
> This provides a simple mnemonic for users:
> "Pay into the <code>hodl</code> code to hold your
> coins until the given date.
> After you've held the coins (on or after the given date)
> use the <code>hedl</code> code to redeem the coins."
> The obvious misspelling of "hodl" is a homage to the common
> meme within the Bitcoin community.
> <!-- The above misspelling may be corrected if it is considered
> to be in bad taste.  -->
>
> _______________________________________________
> 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/20170727/45b458bf/attachment-0001.html>

From kanzure at gmail.com  Thu Jul 27 18:56:43 2017
From: kanzure at gmail.com (Bryan Bishop)
Date: Thu, 27 Jul 2017 13:56:43 -0500
Subject: [bitcoin-dev] Fwd: [Mimblewimble] proofs of position and UTXO set
	commitments
Message-ID: <CABaSBazdodBNWJ+q8AGhJ8xZ7F+BkWb=5yp9DCs4tHhVny28CA@mail.gmail.com>

---------- Forwarded message ----------
From: Bram Cohen <bram at bittorrent.com>
Date: Thu, Jul 27, 2017 at 1:21 PM
Subject: Re: [Mimblewimble] Switch to Blake2
To: Ignotus Peverell <igno.peverell at protonmail.com>
Cc: Bryan Bishop <kanzure at gmail.com>


I have quite a few thoughts about proofs of position. I gave a talk about
it which hopefully gets the points across if you go through all the Q&A:

https://www.youtube.com/watch?v=52FVkHlCh7Y

On Mon, Jul 24, 2017 at 12:12 PM, Ignotus Peverell <
igno.peverell at protonmail.com> wrote:

> Interesting, thanks for the link. Seems we arrived at similar conclusions
> regarding the hash function, with similar frustrations with respect to
> blake2b/2s.
>
> Funny that it's also for the same merkle set application. We ended up with
> a Merkle Mountain Range [1] instead of a Patricia tree. The MMR is
> append-only and makes pruning easy, which works well for MimbleWimble. You
> can navigate down the MMR with just the position the element was inserted
> at, so we just keep a simple index for that. Memory layout is great as a
> lot of it is immutable and sit close together, although the current impl
> doesn't leverage that too well yet. Wonder if Bram looked at MMRs? Patricia
> trees may make more sense for Bitcoin though.
>
> Proof of positions are cool, might look at that some more in the near
> future, when we're less busy implementing everything else ;-)
>
>
> - Igno
>
> [1] https://github.com/ignopeverell/grin/blob/master/doc/merkle.md
>
> -------- Original Message --------
> Subject: Re: [Mimblewimble] Switch to Blake2
> Local Time: July 24, 2017 6:44 PM
> UTC Time: July 24, 2017 6:44 PM
> From: kanzure at gmail.com
> To: Ignotus Peverell <igno.peverell at protonmail.com>, Bram Cohen <
> bram at bittorrent.com>, Bryan Bishop <kanzure at gmail.com>
>
> On Fri, Jul 21, 2017 at 1:12 PM, Ignotus Peverell <
> igno.peverell at protonmail.com> wrote:
>
>> So I'm considering a switch to the Blake2 [3] hash function.
>>
>
> Bram recently made some comments about blake a few weeks ago:
> http://diyhpl.us/wiki/transcripts/sf-bitcoin-meetup/2017-07-
> 08-bram-cohen-merkle-sets/
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507 <(512)%20203-0507>
>
>
>



-- 
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170727/46a00235/attachment.html>

From hozer at hozed.org  Fri Jul 14 21:11:07 2017
From: hozer at hozed.org (Troy Benjegerdes)
Date: Fri, 14 Jul 2017 21:11:07 -0000
Subject: [bitcoin-dev] how to disable segwit in my build?
In-Reply-To: <CAAS2fgR1aGOpVoLyGWtO=Q5XU04gBMBEQARPtxMe4WnwQ2CO5w@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<CAAS2fgTsjfMGw6D_OxDthSrrdLEFx2skGedLAjTwz3yCQijyug@mail.gmail.com>
	<001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com>
	<CAAS2fgR3FQ-wSwGwK6PDD_nZKpnBDAtM=5-fvR-smDa48xjW4Q@mail.gmail.com>
	<03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr>
	<CAAS2fgR1aGOpVoLyGWtO=Q5XU04gBMBEQARPtxMe4WnwQ2CO5w@mail.gmail.com>
Message-ID: <20170714210759.GP4885@hostname.unassigned>

On Thu, Jul 13, 2017 at 01:04:19AM +0000, Gregory Maxwell via bitcoin-dev wrote:
> On Wed, Jul 12, 2017 at 6:17 AM, Dan Libby via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Hi!
> >
> > Up to now, I have purposefully been running bitcoin releases prior to
> > 0.13.1 as a way to avoid the (possible) segwit activation, at least
> > until such time as I personally am comfortable with it.
> 
> It is not simple to do so correctly, I couldn't tell you off the top
> of my head; a number of things must be changed it isn't as simple as
> disabling the activiation because of the segwit P2P changes.  Nor is
> it a supported configuration. Even if it were now, it wouldn't be one
> we'd continue to support in the future after segwit is active, as
> we're likely to drop deployment/compat code.
 
And this attitude is why bitcoin-core is going to get dropped and,
hopefully, instead of just one code to rule them all, we will have
good specifications and multiple competing implementations.

> Can you explain why you wish to do this?  It should have absolutely no
> adverse impact on you-- if you don't use segwit, you don't use it-- it
> may be the case that there is some confusion about the implications
> that I could clear up for you... or suggest alternatives that might
> achieve your goals.

One of the significant adverse impacts of Segwit is the following:

https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L2861

When viewed on Github, less than one third of the consensus-critical
code is visible on-screen.

This is a maintenance and readability nightmare, in my opinion. There
are many good reasons why giving *users* the ability to firewall off
that code, maybe even with #ifdefs, as ugly as they are, would provide
some much better confidence that one is indeed, not running segwit.

I suspect it would help the community a great deal in comfort level
if this code were easier to read and used some type of coding standard
in which the default github view on the average browser shows all the
code without having a "hidden feature" that requires scrolling that
has no obvious UI indication you even need to scroll.