public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Russell O'Connor" <roconnor@blockstream.io>
To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS
Date: Sun, 2 Oct 2016 14:17:12 -0400	[thread overview]
Message-ID: <CAMZUoKmMT7=QMWNEQ+AerUi3yT7z5n3Onm26fH3631U2kSpHtw@mail.gmail.com> (raw)
In-Reply-To: <CAKzdR-rsy1m-H4fYFuCim5+YJi_C2kgjxymM8A7_nEuqsZoO+g@mail.gmail.com>

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

  parent reply	other threads:[~2016-10-02 18:17 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-02 15:49 [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS Sergio Demian Lerner
2016-10-02 16:17 ` Peter Todd
2016-10-02 17:00   ` Sergio Demian Lerner
2016-10-02 17:11     ` Peter Todd
2016-10-02 17:18       ` Andrew Johnson
2016-10-02 17:24         ` Peter Todd
2016-10-02 21:28         ` Luke Dashjr
2016-10-02 21:46           ` Russell O'Connor
2016-10-02 22:36             ` Sergio Demian Lerner
     [not found]               ` <CAMZUoKnE9VNnUHrDTtZOroBp=SC_eY1fEAsEOz=4b1=5v_wHaA@mail.gmail.com>
2016-10-02 23:00                 ` [bitcoin-dev] Fwd: " Russell O'Connor
     [not found]                 ` <CAKzdR-oxpDdXEcPTYtj6os58cVMgwoqyXvu5UMMQzD3QbvMtxA@mail.gmail.com>
2016-10-02 23:26                   ` [bitcoin-dev] " Russell O'Connor
2016-10-02 21:54           ` Russell O'Connor
2016-10-02 17:26       ` Sergio Demian Lerner
2016-10-02 17:34         ` Peter Todd
2016-10-02 18:17 ` Russell O'Connor [this message]
2016-10-24 17:37 ` Johnson Lau
2016-10-25 16:38   ` Sergio Demian Lerner
2016-10-25 17:45     ` Johnson Lau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMZUoKmMT7=QMWNEQ+AerUi3yT7z5n3Onm26fH3631U2kSpHtw@mail.gmail.com' \
    --to=roconnor@blockstream.io \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=sergio.d.lerner@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox