Discussion:
Drivechain proposal using OP_COUNT_ACKS
(too old to reply)
Sergio Demian Lerner via bitcoin-dev
2016-10-02 15:49:08 UTC
Permalink
Raw Message
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
Peter Todd via bitcoin-dev
2016-10-02 16:17:17 UTC
Permalink
Raw Message
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
Post by Sergio Demian Lerner via bitcoin-dev
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
Sergio Demian Lerner via bitcoin-dev
2016-10-02 17:00:01 UTC
Permalink
Raw Message
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.
Post by Peter Todd via bitcoin-dev
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
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
Post by Sergio Demian Lerner via bitcoin-dev
Since ScalingBitcoin is close, I think this is a good moment to publish
our
Post by Sergio Demian Lerner via bitcoin-dev
proposal on drivechains. This BIP proposed the drivechain we'd like to
use
Post by Sergio Demian Lerner via bitcoin-dev
in RSK (a.k.a. Rootstock) two-way pegged blockchain and see it
implemented
--
Peter Todd via bitcoin-dev
2016-10-02 17:11:37 UTC
Permalink
Raw Message
Post by Sergio Demian Lerner via bitcoin-dev
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
Peter Todd via bitcoin-dev
2016-10-02 17:24:15 UTC
Permalink
Raw Message
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
Sergio Demian Lerner via bitcoin-dev
2016-10-02 17:26:18 UTC
Permalink
Raw Message
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.
Post by Peter Todd via bitcoin-dev
Post by Sergio Demian Lerner via bitcoin-dev
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.
--
Peter Todd via bitcoin-dev
2016-10-02 17:34:25 UTC
Permalink
Raw Message
Post by Sergio Demian Lerner via bitcoin-dev
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
Luke Dashjr via bitcoin-dev
2016-10-02 21:28:51 UTC
Permalink
Raw Message
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?).
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
Russell O'Connor via bitcoin-dev
2016-10-02 21:46:43 UTC
Permalink
Raw Message
Post by Luke Dashjr via bitcoin-dev
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.
Sergio Demian Lerner via bitcoin-dev
2016-10-02 22:36:29 UTC
Permalink
Raw Message
On Sun, Oct 2, 2016 at 6:46 PM, Russell O'Connor via bitcoin-dev <
Post by Luke Dashjr via bitcoin-dev
But I would argue that in this scenario, the only way it
Post by Luke Dashjr via bitcoin-dev
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.
Russell O'Connor via bitcoin-dev
2016-10-02 23:00:16 UTC
Permalink
Raw Message
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.
Post by Sergio Demian Lerner via bitcoin-dev
On Sun, Oct 2, 2016 at 6:46 PM, Russell O'Connor via bitcoin-dev <
Post by Russell O'Connor via bitcoin-dev
Post by Luke Dashjr via bitcoin-dev
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.
Post by Sergio Demian Lerner via bitcoin-dev
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.
Post by Sergio Demian Lerner via bitcoin-dev
The only parties that can include the redeem transaction are the miners
themselves.
Post by Sergio Demian Lerner via bitcoin-dev
Therefore I see no problem that an OP_COUNT_ACKS scriptSig transaction
is invalidated after the liveness times expires.
Post by Sergio Demian Lerner via bitcoin-dev
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.
Russell O'Connor via bitcoin-dev
2016-10-02 23:26:18 UTC
Permalink
Raw Message
If someone uses OP_EQUALVERIFY after OP_COUNT_ACKS then the transaction
probably won't be able to be included at a different height.
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.
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.
Post by Sergio Demian Lerner via bitcoin-dev
On Sun, Oct 2, 2016 at 6:46 PM, Russell O'Connor via bitcoin-dev <
Post by Luke Dashjr via bitcoin-dev
But I would argue that in this scenario, the only way it
Post by Luke Dashjr via bitcoin-dev
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.
Russell O'Connor via bitcoin-dev
2016-10-02 21:54:08 UTC
Permalink
Raw Message
Post by Luke Dashjr via bitcoin-dev
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.
Russell O'Connor via bitcoin-dev
2016-10-02 18:17:12 UTC
Permalink
Raw Message
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 <
Post by Sergio Demian Lerner via bitcoin-dev
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.
https://github.com/rootstock/bips/blob/master/BIP-R10.md
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.
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Johnson Lau via bitcoin-dev
2016-10-24 17:37:12 UTC
Permalink
Raw Message
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.
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.
https://github.com/rootstock/bips/blob/master/BIP-R10.md
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.
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Sergio Demian Lerner via bitcoin-dev
2016-10-25 16:38:59 UTC
Permalink
Raw Message
Responding between lines...
Post by Johnson Lau via bitcoin-dev
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.
Post by Johnson Lau via bitcoin-dev
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.
Post by Johnson Lau via bitcoin-dev
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.
Post by Johnson Lau via bitcoin-dev
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.
Post by Johnson Lau via bitcoin-dev
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.
Post by Johnson Lau via bitcoin-dev
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
Post by Johnson Lau via bitcoin-dev
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.
Post by Johnson Lau via bitcoin-dev
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.
Post by Johnson Lau via bitcoin-dev
---- On Sun, 02 Oct 2016 23:49:08 +0800 Sergio Demian Lerner via
Post by Sergio Demian Lerner via bitcoin-dev
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.
Post by Sergio Demian Lerner via bitcoin-dev
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.
Post by Sergio Demian Lerner via bitcoin-dev
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.
Post by Sergio Demian Lerner via bitcoin-dev
https://github.com/rootstock/bips/blob/master/BIP-R10.md
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.
Post by Sergio Demian Lerner via bitcoin-dev
1. Interoperability with scripting system
2. Zero risk of invalidating a block
3. No additional computation during blockchain management and
re-organization
Post by Sergio Demian Lerner via bitcoin-dev
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.
Post by Sergio Demian Lerner via bitcoin-dev
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.
Post by Sergio Demian Lerner via bitcoin-dev
Truly yours,
Sergio Demian Lerner
Bitcoiner and RSK co-founder
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Johnson Lau via bitcoin-dev
2016-10-25 17:45:20 UTC
Permalink
Raw Message
Post by Johnson Lau via bitcoin-dev
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.
Post by Johnson Lau via bitcoin-dev
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.
Post by Johnson Lau via bitcoin-dev
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.
Post by Johnson Lau via bitcoin-dev
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)
Post by Johnson Lau via bitcoin-dev
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

Loading...