From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id E85D1C001E for ; Tue, 11 Jan 2022 03:43:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id C89B34099E for ; Tue, 11 Jan 2022 03:43:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-xlahilS-Eh for ; Tue, 11 Jan 2022 03:43:05 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp4.osuosl.org (Postfix) with ESMTPS id 8FA50409A6 for ; Tue, 11 Jan 2022 03:43:05 +0000 (UTC) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 20B3h2U5021777 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 10 Jan 2022 22:43:03 -0500 Received: by mail-lf1-f42.google.com with SMTP id br17so20470541lfb.6 for ; Mon, 10 Jan 2022 19:43:03 -0800 (PST) X-Gm-Message-State: AOAM532tFFYoTko7aN1/So6r42O0CopBKDtFbGxeXp+aEs8HNiMvr3X2 sz7TzaeZuhhOcpKjceRjNL/xYizQ/gwv58X3Q64= X-Google-Smtp-Source: ABdhPJz5bJa2yi4F38KmEAGHdLOVqEzUWK79Bp9l5aLbMi4jNU7+tmX6bQuCNaYZ+YC8PkeciK1mK8wxywxNcL6JA1w= X-Received: by 2002:a05:6512:31c7:: with SMTP id j7mr1828462lfe.363.1641872581818; Mon, 10 Jan 2022 19:43:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Date: Mon, 10 Jan 2022 19:42:50 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Peter Todd , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000017f8105d54640dc" Subject: Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2022 03:43:08 -0000 --000000000000017f8105d54640dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Peter, Thank you for your review and feedback. Apologies for the difficulties in reviewing. The branch linked from the BIP is not the latest, the branch in the PR is what should be considered https://github.com/bitcoin/bitcoin/pull/21702 for review and has more thorough well documented tests and test vectors. The version you reviewed should still be compatible with the current branch as there have not been any spec changes, though. I'm not sure what best practice is w.r.t. linking to BIPs and implementations given need to rebase and respond to feedback with changes. Appreciate any pointers on how to better solve this. For the time being, I will suggest an edit to point it to the PR, although I recognize this is not ideal. I understand your preference for a commit hash and can do one if it helps. For what it's worth, the taproot BIPs do not link to a reference implementation of Taproot so I'm not sure what best practice is considered these days. One note that is unfortunate in your review is that there is a discrepancy between the BIP and the implementation (the original reference or the current PR either) in that caching and DoS is not addressed. This was an explicit design goal of CTV and for it not to be mentioned in the BIP (and just the reference) is an oversight on my part to not aid reviewers more explicitly. Compounding this, I accepted a third-party PR to make the BIP more clear as to what is required to implement it that does not have caching (functional correctness), that exposes the issue if implemented by the BIP directly and not by the reference implementation. I have explained this in a review last year to pyskell on the PR that caching is required for non-DoS. I will add a note to the BIP about the importance of caching to avoid DoS as that should make third party implementers aware of the issue. That said, this is not a mis-considered part of CTV. The reference implementation is specifically designed to not have quadratic hashing and CTV is designed to be friendly to caching to avoid denial of service. It's just a part of the BIP that can be more clear. I will make a PR to more clearly describe how that should happen. ------ use cases ------ One thing that's not clear to me is the amount of work a BIP needs to do within itself to fully describe all applications and use cases. I don't think it's appropriate for most BIPs to do so, but in some cases it is a good idea. However, for CTV the applications actually are relatively fleshed out, just outside the BIP. Further, the availability of generic tooling through Sapio and it's examples has demonstrated how one might build a variety of applications. See rubin.io/advent21 for numerous worked examples. ## Congestion Controlled Transactions Generally, the existence of these transactions can be tracked using existing wallets if the transaction is seen in the mempool, it will be marked as "mine" and can even be marked as "trusted". See https://utxos.org/analysis/taxes/ which covers the legal obligations of senders with respect to payees under congestion control. Generally, a legally identifiable party such as an exchange sending a congestion control payment must retain and serve it to the user to prove that they made payment to the user. Users of said exchanges can either download a list of their transactions at the time of withdrawal or they can wait to see it e.g. in the mempool. This was also discussed at https://diyhpl.us/wiki/transcripts/ctv-bip-review-workshop/ where you can see notes/videos of what was discussed if the notes are hard to parse. Lightning specific wallets such as Muun and LND particularly plan to use CTV to batch-open a multitude of channels for users, using both congestion control and non-interactive batching. Channels have to be opened on-chain and if channels are to be the future so will on-chain opening of them. These wallets can be built out to track and receive these opening proofs. ## Wallet Vaults There exists at least 3 implementations of Vaults using CTV (one by me in C++, one by me in Sapio, another by Bryan Bishop in python), and there exist oracles as you mention for emulating it. ## Payment Channels Actually taking advantage of them is quite simple and has been discussed and reviewed with a number of independent lightning developers. You can see here a rudimentary implementation and description of how it can work https://rubin.io/bitcoin/2021/12/11/advent-14/. This is composable with any `impl Revokable` channel update specification so generalizes to Lightning. Of course, making it production grade requires a lot of work, but the concept is sound. ## CoinJoin CTV trees may mean more transactions, not less, but if feerates are not monotonic and CTV allows you to defer the utilization of chainspace. CTV CoinJoins also open the opportunity to cooperation through payment pools (which can be opened via a coinjoin), which saves further space. The opportunity to use embedded non-interactive channels (technically, this is a part of payment pools) also further decreases the urgency of getting a UTXO out. Lastly, while it is a slight privacy leak, CTV also allows coin-joiners of different fee-priority levels to batch together where previously they would not have incentive to (see https://utxos.org/analysis/batching_sim/). This does use overall less chainspace total than if it is not incentive compatible to batch together. While this is a slight privacy leak, it is not that large since the batches would otherwise be unable to join together (worse) and priority is still unlinked from the inputs. Further, priority already leaks through the observability of coins being spent anyways. # Covenant Design Trade-Offs and Risks The important part is the the covenant -- regardless of its length -- must be entirely known in advance. CTV is a fully enumerated non-recursive validation-only non-dynamic state covenant. This limits the types of issues that can arise. Useful links: https://medium.com/block-digest-mempool/my-worries-about-too-generalized-co= venants-5eff33affbb6 https://rubin.io/bitcoin/2021/12/04/advent-7/ -- @JeremyRubin On Mon, Jan 10, 2022 at 10:31 AM Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Mon, Jan 03, 2022 at 02:05:20AM +0000, Michael Folkson via bitcoin-dev > wrote: > > There have been a number of =E2=80=9Csoft signals=E2=80=9D, many expres= sing enthusiasm > for the speculated use cases of OP_CTV. Personally I share that enthusias= m > like I do with the prospect of curing cancer. But these soft signals seem > as if they are going to be used to attempt to justify an imminent > contentious soft fork attempt. The devil is in the details both with > regards to wording like =E2=80=9Creasonable parameters=E2=80=9D and the u= tility and safety > of a new opcode. Indeed if you share my concerns that there has not been > sufficient scrutiny and research on the long implications of this proposa= l > I encourage you to register a soft signal of =E2=80=9CNo=E2=80=9D on the = site like I have. > You can always change it to =E2=80=9CYes=E2=80=9D if and when you support= an imminent soft > fork activation attempt containing exclusively OP_CTV. Enabling covenants > on Bitcoin is a big step change with barely any existing research on the > topic and attempting to rush it through by the back door so soon after > Taproot activation should be resisted. To look at the ~200 lines of code > for the opcode exclusively (of course this should be done too) in a vacuu= m > without considering the broader implications is also incredibly > shortsighted. The only thing stopping a descent into Ethereum style seat = of > our pants consensus changes is community vigilance. If we ever lose that = we > lose the foundation of this industry. > > I have to second your objections. > > I spent a bit of time over the past week looking at the current state of > OP_CTV/BIP-0119, and I too think it's a premature idea with an > insufficient BIP > and reference implementation, that current lacks compelling use-cases > clearly > beneficial to all users. > > Remember that Bitcoin is a nearly $1 trillion network with tens of > millions of > users that has gotten to that point with careful, conservative engineerin= g. > Every change to the protocol poses risks to those users. Previous feature > upgrades to the Bitcoin protocol have always been done with the intent of > improving the protocol for everyone: CSV/segwit benefit all users via > Lightning, because we can reasonably all users to directly take advantage > of > those features. We expect _everyone_ to benefit from Taproot via improved > privacy. I don't think CTV in its current form makes that case > sufficiently, > and the technical details are lacking. > > > > As for some more detailed thoughts, for clarify, I'm referring to: > > > https://github.com/bitcoin/bips/blob/3693cdfd192dacdac89cd742f68cd1bb96bf= 7f7e/bip-0119.mediawiki > > https://github.com/JeremyRubin/bitcoin/tree/8f313d292e426a74d9ce28e5130bb= f0cd48f867e > > By no means is this a complete list of issues: > > # DoS Attacks > > Note how above I cited the git hashes to make it clear what exactly I'm > referring too: the fact that the reference implementation is listed as > https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify in the > BIP is > an immediate problem, as it's not clear what exactly is the specification= . > > This in turn matters quite a lot, because the BIP itself glosses over the > quite > serious DoS attack issues involved in adding more ways that opcodes can > hash > txs. Strong resistance to DoS attacks is a _mandatory_ aspect of all > Bitcoin > script proposals, so leaving those details to a mostly uncommented > reference > implementation without a clear discussion of those trade-offs is > insufficient. > > > # Use Cases > > As Folkson notes, these are barely fleshed out: > > ## Congestion Controlled Transactions > > While this section appears somewhat fleshed out, with even a simulation, = it > completely ignores the numerous practical issues like the need for > communication channels between wallets to inform them of the existence of > these > batches. It also raises an important question: who needs this? On-chain > transactions are clearly not the future of Bitcoin and this use-case will > likely impact a small % of users. > > > ## Wallet Vaults > > This use-case can be easily tested, even in production, right now with > additional "oracle" signers that simply verify the CTV rules have been > followed. > > > ## Payment Channels > > These use-cases sound promising. But they all need to be clearly fleshed > out as > actually taking advantage of them is quite complex. > > > ## CoinJoin > > > because participants agree on a single output which pays all > participants, > > which will be lower fee than before > > It is not clear how the fee will be lower, given that taking advantage of > CTV > means there are more transactions, not less. > > > # Covenant Design Trade-Offs and Risks > > > Covenants have historically been controversial given their potential fo= r > > fungibility risks -- coins could be minted which have a permanent > restriction > > on how they may or may not be spent or required to propagate metadata. > > Indeed, this is a significant risk with the potential to harm all Bitcoin > users. > > > In the CHECKTEMPLATEVERIFY approach, the covenants are severely > restricted to > > simple templates. The structure of CHECKTEMPLATEVERIFY template is such > that > > the outputs must be known exactly at the time of construction. Based on= a > > destructuring argument, it is only possible to create templates which > expand > > in a finite number of steps. Thus templated transactions are in theory = as > > safe as transactions which create all the inputs directly in this regar= d. > > The "finite" number of steps could be millions of transactions - > "infinitely > long" for any practical purpose. > > > # Test Vectors > > Currently the testing is poorly documented, without clear goals as to wha= t > edge > cases are actually being tested: > > https://github.com/JeremyRubin/bitcoin/commit/e026bae28a774d91effc32862d0= 246286c114c24 > > Also, we really need test _vectors_ rather than a Python test: for > consenus, > you want to write down explicitly the *data* in the form of serialized > transactions that is being fed into the consensus engine, to avoid > mistakes in > test coverage due to broken test harnesses. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000017f8105d54640dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Peter,

Thank you= for your review and feedback.

Apologies for the difficulties in revi= ewing. The branch linked from the BIP is not the latest, the branch in the = PR is what should be considered=C2=A0https://github.com/bitcoin/bitcoin/pu= ll/21702 for review and has more thorough well documented tests and tes= t vectors. The version you reviewed should still be compatible with the cur= rent branch as there have not been any spec changes, though.

I'm not sure what best practice is w.= r.t. linking to BIPs and implementations given need to rebase and respond t= o feedback with changes. Appreciate any pointers on how to better solve thi= s. For the time being, I will suggest an edit to point it to the PR, althou= gh I recognize this is not ideal. I understand your preference for a commit= hash and can do one if it helps. For = what it's worth, the taproot BIPs do not link to a reference implementa= tion of Taproot so I'm not sure what best practice is considered these = days.

One note t= hat is unfortunate in your review is that there is a discrepancy=C2=A0betwe= en the BIP and the implementation (the original reference or the current PR= either) in that caching and DoS is not addressed. This was an explicit des= ign goal of CTV and for it not to be mentioned in the BIP (and just the ref= erence) is an oversight on my part to not aid reviewers more explicitly. Co= mpounding this, I accepted a third-party PR to make the BIP more clear as t= o what is required to implement it that does not have caching (functional c= orrectness), that exposes the issue if implemented by the BIP directly and = not by the reference implementation. I have explained this in a review last year to pyskell on the PR that caching is requi= red for non-DoS. I will add a note to the BIP about the importance of cachi= ng to avoid DoS as that should make third party implementers aware of the i= ssue.

That said, this is not a mis-considered=C2=A0part of CTV. The r= eference implementation is specifically designed to not have quadratic hash= ing and CTV is designed to be friendly to caching to avoid denial of servic= e. It's just a part of the BIP that can be more clear. I will make a PR= to more clearly describe how that should happen.

------
use cases
-= -----

One thing that's not clear to me is the amount of work a BI= P needs to do within itself to fully describe all applications and use case= s. I don't think it's appropriate for most BIPs to do so,=C2=A0but = in some cases it is a good idea. However, for CTV the applications actually= are relatively fleshed out, just outside the BIP. Further, the availabilit= y of generic tooling through Sapio and it's examples has demonstrated h= ow one might build a variety of applications. See rubin.io/advent21 for numerous worked exa= mples.


## Congestion Controlled Transactions

Generally, the existence of these transac= tions can be tracked using existing wallets if the transaction is seen in t= he mempool, it will be marked as "mine" and can even be marked as= "trusted". See https://utxos.org/analysis/taxes/ which covers the legal= obligations of senders with respect to payees under congestion control. Ge= nerally, a legally identifiable party such as an exchange sending a congest= ion control payment must retain and serve it to the user to prove that they= made payment to the user. Users of said exchanges can either download a li= st of their transactions at the time of withdrawal or they can wait to see = it e.g. in the mempool. This was also discussed at=C2=A0https://diyhpl.us/wiki= /transcripts/ctv-bip-review-workshop/ where you can see notes/videos of= what was discussed if the notes are hard to parse.

Lightning specific wallets such as Muun and LND = particularly plan to use CTV to batch-open a multitude of channels for user= s, using both congestion control and non-interactive batching. Channels hav= e to be opened on-chain and if channels are to be the future so will on-cha= in opening of them. These wallets can be built out to track and receive the= se opening proofs.

## Wallet Vaults

There exists at least 3 implementations of Vaults usin= g CTV (one by=C2=A0me in C++, one by me in Sapio, another by Bryan Bishop i= n python), and there exist oracles as you mention for emulating it.

## Payment = Channels

Actually taking advantage of them is quite simple and has been d= iscussed and reviewed with a number of independent lightning developers.=C2= =A0

You can see here a rudimentary implementation and description of how i= t can work=C2=A0https://rubin.io/bitcoin/2021/12/11/advent-14/.
=

This is composable with any `i= mpl Revokable` channel update specification so generalizes to Lightning.

Of course, making it produc= tion grade requires a lot of work, but the concept is sound.


## CoinJoin


CTV trees may mean more transactions, not les= s, but if feerates are not monotonic and CTV allows you to defer the utiliz= ation of chainspace.

CTV = CoinJoins also open the opportunity to cooperation through payment pools (w= hich can be opened via a coinjoin), which saves further space.

The opportunity to use embedded non-i= nteractive channels (technically, this is a part of payment pools) also fur= ther decreases the urgency of getting a UTXO out.

Lastly, while it is a slight privacy leak, CTV als= o allows coin-joiners of different fee-priority levels to batch together wh= ere previously they would not have incentive to (see https://utxos.org/analysis= /batching_sim/). This does use overall less chainspace total=C2=A0than = if it is not incentive compatible to batch together. While this is a slight= privacy leak, it is not that large since the batches would otherwise be un= able to join together (worse) and priority is still unlinked from the input= s. Further, priority already leaks through the observability of coins being= spent anyways.=C2=A0


# Covenant Design Trade-Offs and Risks

The important part is the the c= ovenant -- regardless of its length -- must be entirely known in advance. C= TV is a fully enumerated non-recursive validation-only non-dynamic state co= venant. This limits the types of issues that can arise.

Useful links:
https://medium.com/block-digest-mempool/my-worries-about-too-generali= zed-covenants-5eff33affbb6
https://rubin.io/bitcoin/2021/12/04/advent-7/
=



On Mon, Jan 10, 2022 at 10:31 AM Peter Todd via bitcoin-dev <bitcoin-de= v@lists.linuxfoundation.org> wrote:
On Mon= , Jan 03, 2022 at 02:05:20AM +0000, Michael Folkson via bitcoin-dev wrote:<= br> > There have been a number of =E2=80=9Csoft signals=E2=80=9D, many expre= ssing enthusiasm for the speculated use cases of OP_CTV. Personally I share= that enthusiasm like I do with the prospect of curing cancer. But these so= ft signals seem as if they are going to be used to attempt to justify an im= minent contentious soft fork attempt. The devil is in the details both with= regards to wording like =E2=80=9Creasonable parameters=E2=80=9D and the ut= ility and safety of a new opcode. Indeed if you share my concerns that ther= e has not been sufficient scrutiny and research on the long implications of= this proposal I encourage you to register a soft signal of =E2=80=9CNo=E2= =80=9D on the site like I have. You can always change it to =E2=80=9CYes=E2= =80=9D if and when you support an imminent soft fork activation attempt con= taining exclusively OP_CTV. Enabling covenants on Bitcoin is a big step cha= nge with barely any existing research on the topic and attempting to rush i= t through by the back door so soon after Taproot activation should be resis= ted. To look at the ~200 lines of code for the opcode exclusively (of cours= e this should be done too) in a vacuum without considering the broader impl= ications is also incredibly shortsighted. The only thing stopping a descent= into Ethereum style seat of our pants consensus changes is community vigil= ance. If we ever lose that we lose the foundation of this industry.

I have to second your objections.

I spent a bit of time over the past week looking at the current state of OP_CTV/BIP-0119, and I too think it's a premature idea with an insuffic= ient BIP
and reference implementation, that current lacks compelling use-cases clear= ly
beneficial to all users.

Remember that Bitcoin is a nearly $1 trillion network with tens of millions= of
users that has gotten to that point with careful, conservative engineering.=
Every change to the protocol poses risks to those users. Previous feature upgrades to the Bitcoin protocol have always been done with the intent of improving the protocol for everyone: CSV/segwit benefit all users via
Lightning, because we can reasonably all users to directly take advantage o= f
those features. We expect _everyone_ to benefit from Taproot via improved privacy. I don't think CTV in its current form makes that case sufficie= ntly,
and the technical details are lacking.



As for some more detailed thoughts, for clarify, I'm referring to:

http= s://github.com/bitcoin/bips/blob/3693cdfd192dacdac89cd742f68cd1bb96bf7f7e/b= ip-0119.mediawiki
https://github.c= om/JeremyRubin/bitcoin/tree/8f313d292e426a74d9ce28e5130bbf0cd48f867e
By no means is this a complete list of issues:

# DoS Attacks

Note how above I cited the git hashes to make it clear what exactly I'm=
referring too: the fact that the reference implementation is listed as
https://github.com/JeremyRubin/bitcoi= n/tree/checktemplateverify in the BIP is
an immediate problem, as it's not clear what exactly is the specificati= on.

This in turn matters quite a lot, because the BIP itself glosses over the q= uite
serious DoS attack issues involved in adding more ways that opcodes can has= h
txs. Strong resistance to DoS attacks is a _mandatory_ aspect of all Bitcoi= n
script proposals, so leaving those details to a mostly uncommented referenc= e
implementation without a clear discussion of those trade-offs is insufficie= nt.


# Use Cases

As Folkson notes, these are barely fleshed out:

## Congestion Controlled Transactions

While this section appears somewhat fleshed out, with even a simulation, it=
completely ignores the numerous practical issues like the need for
communication channels between wallets to inform them of the existence of t= hese
batches. It also raises an important question: who needs this? On-chain
transactions are clearly not the future of Bitcoin and this use-case will likely impact a small % of users.


## Wallet Vaults

This use-case can be easily tested, even in production, right now with
additional "oracle" signers that simply verify the CTV rules have= been
followed.


## Payment Channels

These use-cases sound promising. But they all need to be clearly fleshed ou= t as
actually taking advantage of them is quite complex.


## CoinJoin

> because participants agree on a single output which pays all participa= nts,
> which will be lower fee than before

It is not clear how the fee will be lower, given that taking advantage of C= TV
means there are more transactions, not less.


# Covenant Design Trade-Offs and Risks

> Covenants have historically been controversial given their potential f= or
> fungibility risks -- coins could be minted which have a permanent rest= riction
> on how they may or may not be spent or required to propagate metadata.=

Indeed, this is a significant risk with the potential to harm all Bitcoin users.

> In the CHECKTEMPLATEVERIFY approach, the covenants are severely restri= cted to
> simple templates. The structure of CHECKTEMPLATEVERIFY template is suc= h that
> the outputs must be known exactly at the time of construction. Based o= n a
> destructuring argument, it is only possible to create templates which = expand
> in a finite number of steps. Thus templated transactions are in theory= as
> safe as transactions which create all the inputs directly in this rega= rd.

The "finite" number of steps could be millions of transactions - = "infinitely
long" for any practical purpose.


# Test Vectors

Currently the testing is poorly documented, without clear goals as to what = edge
cases are actually being tested:
https://github= .com/JeremyRubin/bitcoin/commit/e026bae28a774d91effc32862d0246286c114c24

Also, we really need test _vectors_ rather than a Python test: for consenus= ,
you want to write down explicitly the *data* in the form of serialized
transactions that is being fed into the consensus engine, to avoid mistakes= in
test coverage due to broken test harnesses.

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000017f8105d54640dc--