[bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

[bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

[Sergio Demian Lerner]

[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]

Since ScalingBitcoin is close, I think this is a good moment to publish our
proposal on drivechains. This BIP proposed the drivechain we'd like to use
in RSK (a.k.a. Rootstock) two-way pegged blockchain and see it implemented
in Bitcoin. Until that happens, we're using a federated approach.
I'm sure that adding risk-less Bitcoin extensibility through
sidechains/drivechains is what we all want, but it's of maximum importance
to decide which technology will leads us there.
We hope this work can also be the base of all other new 2-way-pegged
blockchains that can take Bitcoin the currency to new niches and test new
use cases, but cannot yet be realized because of current
limitations/protections.

The full BIP plus a reference implementation can be found here:

BIP (draft):
https://github.com/rootstock/bips/blob/master/BIP-R10.md

Code & Test cases:
https://github.com/rootstock/bitcoin/tree/op-count-acks_devel
(Note: Code is still unaudited)

As a summary, OP_COUNT_ACKS is a new segwit-based and soft-forked opcode
that counts acks and nacks tags in coinbase fields, and push the resulting
totals in the script stack.

The system was designed with the following properties in mind:

1. Interoperability with scripting system
2. Zero risk of invalidating a block
3. No additional computation during blockchain management and
re-organization
4. No change in Bitcoin security model
5. Bounded computation of poll results
6. Strong protection from DoS attacks
7. Minimum block space consumption
8. Zero risk of cross-secondary chain invalidation

Please see the BIP draft for a more-detailed explanation on how we achieve
these goals.

I'll be in ScalingBitcoin in less than a week and I'll be available to
discuss the design rationale, improvements, changes and ideas any of you
may have.

Truly yours,
Sergio Demian Lerner
Bitcoiner and RSK co-founder

[-- Attachment #2: Type: text/html, Size: 2363 bytes --]

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]

On Sun, Oct 02, 2016 at 12:49:08PM -0300, Sergio Demian Lerner via bitcoin-dev wrote:

I think your history of patenting(1) Bitcoin consensus relevant technology is
sufficient by itself to be extremely dubious of any proposals coming from you
or your colleagues; patents on Bitcoin consensus technology are a serious
threat to decentralization. Personally, I'm NACKing this proposal on that basis
alone.

You need to rectify this dangerous and unethical behavior in a convincing,
legally binding way. I'd suggest looking into Blockstream's patent pledges as a
way forward:

    https://www.blockstream.com/about/patent_pledge/

I see no reason to have any further discussion of your proposal until this is
rectified.

1) "AsicBoost is a patent-pending method to improve the efficiency and cost of Bitcoin mining by approximately 20%"
   http://www.asicboost.com/single-post/2016/03/24/AsicBoost-Press-Release

> Since ScalingBitcoin is close, I think this is a good moment to publish our
> proposal on drivechains. This BIP proposed the drivechain we'd like to use
> in RSK (a.k.a. Rootstock) two-way pegged blockchain and see it implemented

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

[Sergio Demian Lerner]

[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]

Peter, are you really going to try to down vote a decent free and
open-source proposal that benefits all the Bitcoin community including
you and your future children because a personal attack to me without any
logic or basis?

Is that the way you collaborate to improving Bitcoin?

I just can't believe it.

Let's open another thread elsewhere to discuss hardware and software
patents, and that particular one, if you wish, this is NOT the place.



On Sun, Oct 2, 2016 at 1:17 PM, Peter Todd <pete@petertodd.org> wrote:

> On Sun, Oct 02, 2016 at 12:49:08PM -0300, Sergio Demian Lerner via
> bitcoin-dev wrote:
>
> I think your history of patenting(1) Bitcoin consensus relevant technology
> is
> sufficient by itself to be extremely dubious of any proposals coming from
> you
> or your colleagues; patents on Bitcoin consensus technology are a serious
> threat to decentralization. Personally, I'm NACKing this proposal on that
> basis
> alone.
>
> You need to rectify this dangerous and unethical behavior in a convincing,
> legally binding way. I'd suggest looking into Blockstream's patent pledges
> as a
> way forward:
>
>     https://www.blockstream.com/about/patent_pledge/
>
> I see no reason to have any further discussion of your proposal until this
> is
> rectified.
>
> 1) "AsicBoost is a patent-pending method to improve the efficiency and
> cost of Bitcoin mining by approximately 20%"
>    http://www.asicboost.com/single-post/2016/03/24/AsicBoost-Press-Release
>
> > Since ScalingBitcoin is close, I think this is a good moment to publish
> our
> > proposal on drivechains. This BIP proposed the drivechain we'd like to
> use
> > in RSK (a.k.a. Rootstock) two-way pegged blockchain and see it
> implemented
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

[-- Attachment #2: Type: text/html, Size: 2735 bytes --]

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]

On Sun, Oct 02, 2016 at 02:00:01PM -0300, Sergio Demian Lerner wrote:
> Peter, are you really going to try to down vote a decent free and
> open-source proposal that benefits all the Bitcoin community including
> you and your future children because a personal attack to me without any
> logic or basis?

I've suggested a way that you can rectify this situation so we can continue to
collaborate: Have Rootstock adopt a legally binding patent pledge/license. I'd
suggest you do as Blockstream has done and at minimum adopt the Defensive
Patent License (DPL); I personally will be doing so in the next week or two for
my own consulting company (I'm discussing exactly how to do so with my lawyer
right now).

If Rootstock is not planning on getting any patents for offensive purposes,
then there is no issue with doing so - the DPL in particular is designed in a
minimally intrusive way.

Please fix this issue so we can in fact continue to collaborate to improve
Bitcoin.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

[Andrew Johnson]

[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]

The purpose of this list is highly technical discussion, not political
disagreements.

Is this particular proposal encumbered by a licensing type, patent, or
pending patent which would preclude it from being used in the bitcoin
project?  If not, you're wildly off topic.

On Oct 2, 2016 12:11 PM, "Peter Todd via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sun, Oct 02, 2016 at 02:00:01PM -0300, Sergio Demian Lerner wrote:
> > Peter, are you really going to try to down vote a decent free and
> > open-source proposal that benefits all the Bitcoin community including
> > you and your future children because a personal attack to me without any
> > logic or basis?
>
> I've suggested a way that you can rectify this situation so we can
> continue to
> collaborate: Have Rootstock adopt a legally binding patent pledge/license.
> I'd
> suggest you do as Blockstream has done and at minimum adopt the Defensive
> Patent License (DPL); I personally will be doing so in the next week or
> two for
> my own consulting company (I'm discussing exactly how to do so with my
> lawyer
> right now).
>
> If Rootstock is not planning on getting any patents for offensive purposes,
> then there is no issue with doing so - the DPL in particular is designed
> in a
> minimally intrusive way.
>
> Please fix this issue so we can in fact continue to collaborate to improve
> Bitcoin.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 2387 bytes --]

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]

On Sun, Oct 02, 2016 at 12:18:08PM -0500, Andrew Johnson wrote:
> The purpose of this list is highly technical discussion, not political
> disagreements.
> 
> Is this particular proposal encumbered by a licensing type, patent, or
> pending patent which would preclude it from being used in the bitcoin
> project?  If not, you're wildly off topic.

I don't know if it is; that's the problem.

Given Sergio's prior behavior of attempting to use patents offensively, it's
perfectly reasonable to suspect that Rootstock does in fact intend to encumber
this proposal with patents. So the obvious thing to do, is for Rootstock to
give us all a legally binding guarantee that they will not be using patents
offensively, eliminating the problem and allowing us to return to productive
collaboration.

Remember that this kind of requirement is very common in standards bodies, e.g.
by having all companies contributing to the standards in question join a patent
pool, or by making legally binding pledges/licenses to ensure any patents they
hold can't be used offensively.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

[Luke Dashjr]

On Sunday, October 02, 2016 5:18:08 PM Andrew Johnson via bitcoin-dev wrote:
> Is this particular proposal encumbered by a licensing type, patent, or
> pending patent which would preclude it from being used in the bitcoin
> project?  If not, you're wildly off topic.

I think that's the concern: we don't - and *can't* - know. Pending patents are 
not publicly visible, as far as I am aware, and the BIP process does not 
(presently) require any patent disclosure.

Of course, it is entirely possible to voluntarily provide a disclosure of 
patents in the BIP (and ideally a free license to such patents, at least those 
for the BIP). This is an alternative possibility to resolve patent concerns if 
Rootstock is not prepared to adopt a defensive patent strategy in general 
(yet?).

On Sunday, October 02, 2016 6:17:12 PM Russell O'Connor via bitcoin-dev wrote:
> If I understand this BIP correctly, the values pushed onto the stack by the
> OP_COUNT_ACKS operation depends on the ack and nack counts relative to the
> block that this happens to be included in.
> 
> This isn't going to be acceptable.  The validity of a transaction should
> always be monotone in the sense that if a transaction was acceptable in a
> given block, it must always be acceptable in any subsequent block, with the
> only exception being if one of the transaction's inputs get double spent.

I don't know if it's possible to implement decentralised sidechains without 
"breaking" this rule. But I would argue that in this scenario, the only way it 
would become invalid is the equivalent of a double-spend... and therefore it 
may be acceptable in relation to this argument.

Luke

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 642 bytes --]

> But I would argue that in this scenario, the only way it
> would become invalid is the equivalent of a double-spend... and therefore
> it
> may be acceptable in relation to this argument.
>

The values returned by OP_COUNT_ACKS vary in their exact value depending on
which block this transaction ends up in.  While the proposed use of this
operation is somewhat less objectionable (although still objectionable to
me), nothing stops users from using OP_EQUALVERIFY and and causing their
transaction fluctuate between acceptable and unacceptable, with no party
doing anything like a double spend.  This is a major problem with the
proposal.

[-- Attachment #2: Type: text/html, Size: 928 bytes --]

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

[Sergio Demian Lerner]

[-- Attachment #1: Type: text/plain, Size: 1408 bytes --]

On Sun, Oct 2, 2016 at 6:46 PM, Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> But I would argue that in this scenario, the only way it
>> would become invalid is the equivalent of a double-spend... and therefore
>> it
>> may be acceptable in relation to this argument.
>>
>
> The values returned by OP_COUNT_ACKS vary in their exact value depending
> on which block this transaction ends up in.  While the proposed use of this
> operation is somewhat less objectionable (although still objectionable to
> me), nothing stops users from using OP_EQUALVERIFY and and causing their
> transaction fluctuate between acceptable and unacceptable, with no party
> doing anything like a double spend.  This is a major problem with the
> proposal.
>

Transactions that redeem an output containing (or referencing by means of
P2WSH) an OP_COUNT_ACKS are not broadcast by the network. That means that
the network cannot be DoS attacked by flooding with a transaction that will
not verify due to being too late.
The only parties that can include the redeem transaction are the miners
themselves.
Therefore I see no problem that an OP_COUNT_ACKS scriptSig transaction is
invalidated after the liveness times expires.
If there is no expiration, then polls can last forever and the system fails
to provide DoS protection for block validation since active polls can
accumulate forever.

[-- Attachment #2: Type: text/html, Size: 2124 bytes --]

[bitcoin-dev] Fwd: Re: Drivechain proposal using OP_COUNT_ACKS

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 1876 bytes --]

I forget to send to bitcoin-dev.

> A related problem is that if this transaction is reorged out during an
innocent reorg, one that doesn't involve a double spend, the transaction
may never get back in unless it occurs at exactly  the same height, which
is not guaranteed.
>
> This affects fungabity of coins generated from these transactions.
>
>
> On Oct 2, 2016 18:37, "Sergio Demian Lerner" <sergio.d.lerner@gmail.com>
wrote:
>>
>>
>>
>> On Sun, Oct 2, 2016 at 6:46 PM, Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>
>>>> But I would argue that in this scenario, the only way it
>>>> would become invalid is the equivalent of a double-spend... and
therefore it
>>>> may be acceptable in relation to this argument.
>>>
>>>
>>> The values returned by OP_COUNT_ACKS vary in their exact value
depending on which block this transaction ends up in.  While the proposed
use of this operation is somewhat less objectionable (although still
objectionable to me), nothing stops users from using OP_EQUALVERIFY and and
causing their transaction fluctuate between acceptable and unacceptable,
with no party doing anything like a double spend.  This is a major problem
with the proposal.
>>
>>
>> Transactions that redeem an output containing (or referencing by means
of P2WSH) an OP_COUNT_ACKS are not broadcast by the network. That means
that the network cannot be DoS attacked by flooding with a transaction that
will not verify due to being too late.
>> The only parties that can include the redeem transaction are the miners
themselves.
>> Therefore I see no problem that an OP_COUNT_ACKS scriptSig transaction
is invalidated after the liveness times expires.
>> If there is no expiration, then polls can last forever and the system
fails to provide DoS protection for block validation since active polls can
accumulate forever.
>>
>>
>>

[-- Attachment #2: Type: text/html, Size: 2357 bytes --]

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 2529 bytes --]

If someone uses OP_EQUALVERIFY after OP_COUNT_ACKS then the transaction
probably won't be able to be included at a different height.

On Oct 2, 2016 19:16, "Sergio Demian Lerner" <sergio.d.lerner@gmail.com>
wrote:

> It can be included at another block at a differnt height. It can be
> included anytime during the liveness period which starts 100 blocks later
> than the poll period ends. I'm reading the BIP now and it's true that this
> is not enterily clear. I will try to clarify.
>
>
> On Sun, Oct 2, 2016 at 7:58 PM, Russell O'Connor <roconnor@blockstream.io>
> wrote:
>
>> A related problem is that if this transaction is reorged out during an
>> innocent reorg, one that doesn't involve a double spend, the transaction
>> may never get back in unless it occurs at exactly  the same height, which
>> is not guaranteed.
>>
>> This affects fungabity of coins generated from these transactions.
>>
>> On Oct 2, 2016 18:37, "Sergio Demian Lerner" <sergio.d.lerner@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Sun, Oct 2, 2016 at 6:46 PM, Russell O'Connor via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>>
>>>> But I would argue that in this scenario, the only way it
>>>>> would become invalid is the equivalent of a double-spend... and
>>>>> therefore it
>>>>> may be acceptable in relation to this argument.
>>>>>
>>>>
>>>> The values returned by OP_COUNT_ACKS vary in their exact value
>>>> depending on which block this transaction ends up in.  While the proposed
>>>> use of this operation is somewhat less objectionable (although still
>>>> objectionable to me), nothing stops users from using OP_EQUALVERIFY and and
>>>> causing their transaction fluctuate between acceptable and unacceptable,
>>>> with no party doing anything like a double spend.  This is a major problem
>>>> with the proposal.
>>>>
>>>
>>> Transactions that redeem an output containing (or referencing by means
>>> of P2WSH) an OP_COUNT_ACKS are not broadcast by the network. That means
>>> that the network cannot be DoS attacked by flooding with a transaction that
>>> will not verify due to being too late.
>>> The only parties that can include the redeem transaction are the miners
>>> themselves.
>>> Therefore I see no problem that an OP_COUNT_ACKS scriptSig transaction
>>> is invalidated after the liveness times expires.
>>> If there is no expiration, then polls can last forever and the system
>>> fails to provide DoS protection for block validation since active polls can
>>> accumulate forever.
>>>
>>>
>>>
>>>
>

[-- Attachment #2: Type: text/html, Size: 4154 bytes --]

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 634 bytes --]

> I don't know if it's possible to implement decentralised sidechains without
> "breaking" this rule.
>

I haven't really been following the sidechain developements, but my
understanding was that redemption from a side chain would be two phase.
The person unpegging the funds provides a proof that they have locked the
funds on the side chain and are eligible to withdraw the funds, plus they
put up a bounty.  Then there is a time-locked period where others can
collect the bounty by providing a fraud proof, that the locked funds given
in the proof have actually been double spent.  This two phase system
doesn't violate this rule.

[-- Attachment #2: Type: text/html, Size: 944 bytes --]

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

[Sergio Demian Lerner]

[-- Attachment #1: Type: text/plain, Size: 2062 bytes --]

I'm not a lawyer, and my knowledge on patents is limited. I guess RSK WILL
endorse DPL or will make the required actions to make sure the things
developed by RSK remain free and open. This was not a priority until now,
but coding was. For me, coding always is the priority.

I will discuss prioritizing this with the team. Remember it took several
years to BlockStream to decide for DPL and not just publish everything as
they were doing. I suppose the decision it was not a simple one, involving
lawyers advise and all. I guess DPL needs to actually patent the things in
order to open them later, and patenting has a very high cost.

Give us time to decide which open source strategy is the best and cheaper
for RSK. At this point I can assert that RSK has not filed any patent not
is planing to.  This proposal is not encumbered by any patents, and
drivechains is actually not RSK's idea, but Paul Sztorc's.



On Sun, Oct 2, 2016 at 2:11 PM, Peter Todd <pete@petertodd.org> wrote:

> On Sun, Oct 02, 2016 at 02:00:01PM -0300, Sergio Demian Lerner wrote:
> > Peter, are you really going to try to down vote a decent free and
> > open-source proposal that benefits all the Bitcoin community including
> > you and your future children because a personal attack to me without any
> > logic or basis?
>
> I've suggested a way that you can rectify this situation so we can
> continue to
> collaborate: Have Rootstock adopt a legally binding patent pledge/license.
> I'd
> suggest you do as Blockstream has done and at minimum adopt the Defensive
> Patent License (DPL); I personally will be doing so in the next week or
> two for
> my own consulting company (I'm discussing exactly how to do so with my
> lawyer
> right now).
>
> If Rootstock is not planning on getting any patents for offensive purposes,
> then there is no issue with doing so - the DPL in particular is designed
> in a
> minimally intrusive way.
>
> Please fix this issue so we can in fact continue to collaborate to improve
> Bitcoin.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

[-- Attachment #2: Type: text/html, Size: 2709 bytes --]

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]

On Sun, Oct 02, 2016 at 02:26:18PM -0300, Sergio Demian Lerner wrote:
> I'm not a lawyer, and my knowledge on patents is limited. I guess RSK WILL
> endorse DPL or will make the required actions to make sure the things
> developed by RSK remain free and open. This was not a priority until now,
> but coding was. For me, coding always is the priority.
> 
> I will discuss prioritizing this with the team. Remember it took several
> years to BlockStream to decide for DPL and not just publish everything as
> they were doing. I suppose the decision it was not a simple one, involving
> lawyers advise and all. I guess DPL needs to actually patent the things in
> order to open them later, and patenting has a very high cost.
> 
> Give us time to decide which open source strategy is the best and cheaper
> for RSK. At this point I can assert that RSK has not filed any patent not
> is planing to.  This proposal is not encumbered by any patents, and
> drivechains is actually not RSK's idea, but Paul Sztorc's.

Thanks, please let us all know when this is done so we can continue our
collaborations constructively.

I'll likewise prioritise my own adoption of the DPL and will announce it on
this mailing list.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 2865 bytes --]

If I understand this BIP correctly, the values pushed onto the stack by the
OP_COUNT_ACKS operation depends on the ack and nack counts relative to the
block that this happens to be included in.

This isn't going to be acceptable.  The validity of a transaction should
always be monotone in the sense that if a transaction was acceptable in a
given block, it must always be acceptable in any subsequent block, with the
only exception being if one of the transaction's inputs get double spent.

The added check lock time and check sequence number operations were
carefully constructed to ensure this property.

On Sun, Oct 2, 2016 at 11:49 AM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Since ScalingBitcoin is close, I think this is a good moment to publish
> our proposal on drivechains. This BIP proposed the drivechain we'd like to
> use in RSK (a.k.a. Rootstock) two-way pegged blockchain and see it
> implemented in Bitcoin. Until that happens, we're using a federated
> approach.
> I'm sure that adding risk-less Bitcoin extensibility through
> sidechains/drivechains is what we all want, but it's of maximum importance
> to decide which technology will leads us there.
> We hope this work can also be the base of all other new 2-way-pegged
> blockchains that can take Bitcoin the currency to new niches and test new
> use cases, but cannot yet be realized because of current
> limitations/protections.
>
> The full BIP plus a reference implementation can be found here:
>
> BIP (draft):
> https://github.com/rootstock/bips/blob/master/BIP-R10.md
>
> Code & Test cases:
> https://github.com/rootstock/bitcoin/tree/op-count-acks_devel
> (Note: Code is still unaudited)
>
> As a summary, OP_COUNT_ACKS is a new segwit-based and soft-forked opcode
> that counts acks and nacks tags in coinbase fields, and push the resulting
> totals in the script stack.
>
> The system was designed with the following properties in mind:
>
> 1. Interoperability with scripting system
> 2. Zero risk of invalidating a block
> 3. No additional computation during blockchain management and
> re-organization
> 4. No change in Bitcoin security model
> 5. Bounded computation of poll results
> 6. Strong protection from DoS attacks
> 7. Minimum block space consumption
> 8. Zero risk of cross-secondary chain invalidation
>
> Please see the BIP draft for a more-detailed explanation on how we achieve
> these goals.
>
> I'll be in ScalingBitcoin in less than a week and I'll be available to
> discuss the design rationale, improvements, changes and ideas any of you
> may have.
>
> Truly yours,
> Sergio Demian Lerner
> Bitcoiner and RSK co-founder
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 3876 bytes --]

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

[Johnson Lau]

Some comments and questions

1. In the BIP you mentioned scriptSig 3 times, but I don't think you are really talking about scriptSig. Especially, segwit has aborted the use of scriptSig to fix malleability. From the context I guess you mean redeemScript (see BIP141)

2. It seems that 51% of miners may steal all money from the peg, right? But I think this is unavoidable for all 2-way-peg proposals. To make it safer you still need notaries.

3. Instead of using a OP_NOPx, I suggest you using an unused code such as 0xba. OP_NOPx should be reserved for some simple "VERIFY"-type codes that does not write to the stack.

4. I don't think you should simply replace "(witversion == 0)" with "((witversion == 0) || (witversion == 1))". There are only 16 available versions. It'd be exhausted very soon if we use a version for every new opcode. As a testing prototype this is fine, but the actual softfork should not waste a witversion this way. We need a better way to coordinate the use of new witness version. BIP114 suggests an additional field in the witness to indicate the script version (https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki)

5. It seems this is the first BIP in markdown format, not mediawiki (but this is allowed by BIP1)

6. The coinbase space is limited to 100 bytes and is already overloaded by many different purposes. I think any additional consensus critical message should go to a dummy scriptPubKey like the witness commitment. You may consider to  have a new OP_RETURN output like BIP141, with different magic bytes. However, please don't make this output mandatory (cf. witness commitment output is optional if the block does not have witness tx)

6a. "..........due to lack of space to include the proper ack tag in a block": this shouldn't happen if you use a OP_RETURN output

7.  "It can be the case that two different secondary blockchains specify the same transaction candidate, but **at least** one of them will clearly be unauthentic."

8. Question: is an ack-poll valid only for 1 transaction? When the transaction is confirmed, could full nodes prune the corresponding ack-poll data? (I think it has to be prunable after spending because ack-poll data is effectively UTXO data) 

9. No matter how you design a softfork, "Zero risk of invalidating a block" couldn't be true for any softfork. For example, even if a miner does not include any txs with OP_COUNT_ACKS, he may still build on top of blocks with invalid OP_COUNT_ACKS operations.

 ---- On Sun, 02 Oct 2016 23:49:08 +0800 Sergio Demian Lerner via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote ---- 
 > Since ScalingBitcoin is close, I think this is a good moment to publish our proposal on drivechains. This BIP proposed the drivechain we'd like to use in RSK (a.k.a. Rootstock) two-way pegged blockchain and see it implemented in Bitcoin. Until that happens, we're using a federated approach. 
 > I'm sure that adding risk-less Bitcoin extensibility through sidechains/drivechains is what we all want, but it's of maximum importance to decide which technology will leads us there.
 > We hope this work can also be the base of all other new 2-way-pegged blockchains that can take Bitcoin the currency to new niches and test new use cases, but cannot yet be realized because of current limitations/protections.
 > 
 > The full BIP plus a reference implementation can be found here:
 > 
 > BIP (draft):
 > https://github.com/rootstock/bips/blob/master/BIP-R10.md
 > 
 > Code & Test cases:
 > https://github.com/rootstock/bitcoin/tree/op-count-acks_devel
 > (Note: Code is still unaudited)
 > 
 > As a summary, OP_COUNT_ACKS is a new segwit-based and soft-forked opcode that counts acks and nacks tags in coinbase fields, and push the resulting totals in the script stack.
 > 
 > The system was designed with the following properties in mind:
 > 
 > 1. Interoperability with scripting system 
 > 2. Zero risk of invalidating a block
 > 3. No additional computation during blockchain management and re-organization
 > 4. No change in Bitcoin security model
 > 5. Bounded computation of poll results
 > 6. Strong protection from DoS attacks
 > 7. Minimum block space consumption
 > 8. Zero risk of cross-secondary chain invalidation
 > 
 > Please see the BIP draft for a more-detailed explanation on how we achieve these goals.
 > 
 > I'll be in ScalingBitcoin in less than a week and I'll be available to discuss the design rationale, improvements, changes and ideas any of you may have.
 > 
 > Truly yours, 
 > Sergio Demian Lerner
 > Bitcoiner and RSK co-founder
 >  
 >  _______________________________________________ 
 > bitcoin-dev mailing list 
 > bitcoin-dev@lists.linuxfoundation.org 
 > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 
 > 

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

[Sergio Demian Lerner]

[-- Attachment #1: Type: text/plain, Size: 7067 bytes --]

Responding between lines...

On Mon, Oct 24, 2016 at 2:37 PM, Johnson Lau <jl2012@xbt.hk> wrote:

> Some comments and questions
>
> 1. In the BIP you mentioned scriptSig 3 times, but I don't think you are
> really talking about scriptSig. Especially, segwit has aborted the use of
> scriptSig to fix malleability. From the context I guess you mean
> redeemScript (see BIP141)
>

You're right.I will change the naming asap.


>
> 2. It seems that 51% of miners may steal all money from the peg, right?
> But I think this is unavoidable for all 2-way-peg proposals. To make it
> safer you still need notaries.
>

Correct, that's inherently a technical limitation. However, there can be
many deterrents from miners stealing money (legal contracts,
mutual-assured-destruction states). Aslo as you mention, you can combine
OP_COUNT_ACK with notary sigantures as AND/OR or a more complex acknowledge
weight distribution.


>
> 3. Instead of using a OP_NOPx, I suggest you using an unused code such as
> 0xba. OP_NOPx should be reserved for some simple "VERIFY"-type codes that
> does not write to the stack.
>

Ok. I'm not sure, but if everyone agrees to it, I will. Also Segwit
versioning allows to create new opcode multiplexing opcodes, so I was
thinking about adding an "opcode index" to a more generic OP_OPERATE. But
that prevents using all NOP space, but prevents easily counting
OP_ACK_COUNT for checksig block limit.


> 4. I don't think you should simply replace "(witversion == 0)" with
> "((witversion == 0) || (witversion == 1))". There are only 16 available
> versions. It'd be exhausted very soon if we use a version for every new
> opcode. As a testing prototype this is fine, but the actual softfork should
> not waste a witversion this way. We need a better way to coordinate the use
> of new witness version. BIP114 suggests an additional field in the witness
> to indicate the script version (https://github.com/bitcoin/
> bips/blob/master/bip-0114.mediawiki)
>
> Good. But currently that version is not enforced, so this BIP cannot make
use of it. I can use (witversion == 1) but add the BIP114 version field so
that the next BIP can make use of it.



> 5. It seems this is the first BIP in markdown format, not mediawiki (but
> this is allowed by BIP1)
>

> 6. The coinbase space is limited to 100 bytes and is already overloaded by
> many different purposes. I think any additional consensus critical message
> should go to a dummy scriptPubKey like the witness commitment. You may
> consider to  have a new OP_RETURN output like BIP141, with different magic
> bytes. However, please don't make this output mandatory (cf. witness
> commitment output is optional if the block does not have witness tx)
>
> 6a. "..........due to lack of space to include the proper ack tag in a
> block": this shouldn't happen if you use a OP_RETURN output
>
> I'm not sure about this. The fact that the space for acknowledge and
proposal is short has been seen by other developers a benefit and not a
drawback. It prevent hundreds of sidechains to be offered, which might hurt
solo miners. 70 bytes allows for approximately 10 active polls.



> 7.  "It can be the case that two different secondary blockchains specify
> the same transaction candidate, but **at least** one of them will clearly
> be unauthentic."
>
> thnks.

8. Question: is an ack-poll valid only for 1 transaction? When the
> transaction is confirmed, could full nodes prune the corresponding ack-poll
> data? (I think it has to be prunable after spending because ack-poll data
> is effectively UTXO data)
>
> Yes, there is no ack-poll data stored except for the coinbase field cache,
which periodically cleans itself by using a FIFO approach.



> 9. No matter how you design a softfork, "Zero risk of invalidating a
> block" couldn't be true for any softfork. For example, even if a miner does
> not include any txs with OP_COUNT_ACKS, he may still build on top of blocks
> with invalid OP_COUNT_ACKS operations.
>
> I'm not sure. I assumed that transactions redeeming a script using
OP_COUNT_ACKS  would be non-standard, so the the problem you point out
would only happen if the block including the transaction would be mined
specifically for the purpose to defeat subsequent miners. A honest pre-fork
miner would never include a redeemScript that that verifies an
OP_COUNT_ACKS, since that transaction would never be received by the p2p
protocol (it could if the miner accepts non-standard txs by a different
channnel).

But I must check this in the BIP source code if OP_COUNT_ACKS is really
non-standard as I designed it to be.

(Thanks Jonhson Lau for taking the time to analyze the BIP.)

Sergio.



>  ---- On Sun, 02 Oct 2016 23:49:08 +0800 Sergio Demian Lerner via
> bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote ----
>  > Since ScalingBitcoin is close, I think this is a good moment to publish
> our proposal on drivechains. This BIP proposed the drivechain we'd like to
> use in RSK (a.k.a. Rootstock) two-way pegged blockchain and see it
> implemented in Bitcoin. Until that happens, we're using a federated
> approach.
>  > I'm sure that adding risk-less Bitcoin extensibility through
> sidechains/drivechains is what we all want, but it's of maximum importance
> to decide which technology will leads us there.
>  > We hope this work can also be the base of all other new 2-way-pegged
> blockchains that can take Bitcoin the currency to new niches and test new
> use cases, but cannot yet be realized because of current
> limitations/protections.
>  >
>  > The full BIP plus a reference implementation can be found here:
>  >
>  > BIP (draft):
>  > https://github.com/rootstock/bips/blob/master/BIP-R10.md
>  >
>  > Code & Test cases:
>  > https://github.com/rootstock/bitcoin/tree/op-count-acks_devel
>  > (Note: Code is still unaudited)
>  >
>  > As a summary, OP_COUNT_ACKS is a new segwit-based and soft-forked
> opcode that counts acks and nacks tags in coinbase fields, and push the
> resulting totals in the script stack.
>  >
>  > The system was designed with the following properties in mind:
>  >
>  > 1. Interoperability with scripting system
>  > 2. Zero risk of invalidating a block
>  > 3. No additional computation during blockchain management and
> re-organization
>  > 4. No change in Bitcoin security model
>  > 5. Bounded computation of poll results
>  > 6. Strong protection from DoS attacks
>  > 7. Minimum block space consumption
>  > 8. Zero risk of cross-secondary chain invalidation
>  >
>  > Please see the BIP draft for a more-detailed explanation on how we
> achieve these goals.
>  >
>  > I'll be in ScalingBitcoin in less than a week and I'll be available to
> discuss the design rationale, improvements, changes and ideas any of you
> may have.
>  >
>  > Truly yours,
>  > Sergio Demian Lerner
>  > Bitcoiner and RSK co-founder
>  >
>  >  _______________________________________________
>  > bitcoin-dev mailing list
>  > bitcoin-dev@lists.linuxfoundation.org
>  > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>  >
>
>
>

[-- Attachment #2: Type: text/html, Size: 9991 bytes --]

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

[Johnson Lau]

 >  3. Instead of using a OP_NOPx, I suggest you using an unused code such as 0xba. OP_NOPx should be reserved for some simple "VERIFY"-type codes that does not write to the stack.
 > 
 > Ok. I'm not sure, but if everyone agrees to it, I will. Also Segwit versioning allows to create new opcode multiplexing opcodes, so I was thinking about adding an "opcode index" to a more generic OP_OPERATE. But that prevents using all NOP space, but prevents easily counting OP_ACK_COUNT for checksig block limit.
 
The other reason not to touch NOPx is they are shared by SIGVERSION_BASE and SIGVERSION_WITNESS_V0. If we later decide to introduce new opcodes to legacy versions, we may still use this space.

And yes, I think you should keep OP_ACT_COUNT easily countable for block sigop limit.

 >  
 >  4. I don't think you should simply replace "(witversion == 0)" with "((witversion == 0) || (witversion == 1))". There are only 16 available versions. It'd be exhausted very soon if we use a version for every new opcode. As a testing prototype this is fine, but the actual softfork should not waste a witversion this way. We need a better way to coordinate the use of new witness version. BIP114 suggests an additional field in the witness to indicate the script version (https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki)
 >  
 > Good. But currently that version is not enforced, so this BIP cannot make use of it. I can use (witversion == 1) but add the BIP114 version field so that the next BIP can make use of it.
 
Probably BIP114 would never be deployed. I don't know. But I think we should try to move the script version to witness, as it is cheaper. The major witness version could be reserved for some fundamental changes in language.

  
 >  6. The coinbase space is limited to 100 bytes and is already overloaded by many different purposes. I think any additional consensus critical message should go to a dummy scriptPubKey like the witness commitment. You may consider to  have a new OP_RETURN output like BIP141, with different magic bytes. However, please don't make this output mandatory (cf. witness commitment output is optional if the block does not have witness tx)
 >  
 >  6a. "..........due to lack of space to include the proper ack tag in a block": this shouldn't happen if you use a OP_RETURN output
 >  
 > I'm not sure about this. The fact that the space for acknowledge and proposal is short has been seen by other developers a benefit and not a drawback. It prevent hundreds of sidechains to be offered, which might hurt solo miners. 70 bytes allows for approximately 10 active polls.

That's 1 active poll per minute on average, which sounds very small if it ever gets really popular. Have you made any forecast? I could foresee people have to bid for the coinbase space for their ack-poll, and they will yell at the devs asking for more poll space (well.....)

We used an OP_RETURN output for segwit as some miners wanted to retain the coinbase space for other purpose like advertisement.  Even if you want to set an artificial limit, you could still use an OP_RETURN output. It just means you will need a OP_COUNT_ACKS2 softfork when you want to expand the space.  Since polls are not fixed size, if an artificial limit is desired, maybe it makes more sense to limit the number of polls, instead of number of bytes.


 >  8. Question: is an ack-poll valid only for 1 transaction? When the transaction is confirmed, could full nodes prune the corresponding ack-poll data? (I think it has to be prunable after spending because ack-poll data is effectively UTXO data)
 >  
 > Yes, there is no ack-poll data stored except for the coinbase field cache, which periodically cleans itself by using a FIFO approach.
 
If the target tx of a ack-poll is never confirmed on the blockchain, I guess you need to keep the data of the poll forever?  It's like creating an unspendable and unprunable UTXO (just want you to clarify. People are spamming the UTXO already so your proposal won't make it worse anyway)
 
 >   9. No matter how you design a softfork, "Zero risk of invalidating a block" couldn't be true for any softfork. For example, even if a miner does not include any txs with OP_COUNT_ACKS, he may still build on top of blocks with invalid OP_COUNT_ACKS operations.
 >  
 > I'm not sure. I assumed that transactions redeeming a script using OP_COUNT_ACKS  would be non-standard, so the the problem you point out would only happen if the block including the transaction would be mined specifically for the purpose to defeat subsequent miners. A honest pre-fork miner would never include a redeemScript that that verifies an OP_COUNT_ACKS, since that transaction would never be received by the p2p protocol (it could if the miner accepts non-standard txs by a different channnel).   
 > 
 > But I must check this in the BIP source code if OP_COUNT_ACKS is really non-standard as I designed it to be.
 
It must be non-standard because witversion != 0 are non-standard already. I mean, you proposal is probably as safe as OP_CSV, but no one sold OP_CSV as "zero risk".

Johnson