Date: Tue, 13 Dec 2022 14:42:18 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Y5gCqsCaT0rVKrmX@erisian.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [bitcoin-dev] bitcoin-inquistion 23.0: evaluating soft forks on
	signet
Precedence: list

Hi *,

Bitcoin Inquisition 23.0 is tagged:

  https://github.com/bitcoin-inquisition/bitcoin/releases/tag/inq-v23.0

It includes support for BIP 118 (ANYPREVOUT) and BIP 119
(CHECKTEMPLATEVERIFY) on regtest and signet.

As previously discussed, the hope is that this will allow more
experimentation and building a greater understanding of the risks,
benefits, and tradeoffs of proposals like BIP 118 and BIP 119.

For an initial trial period, we've switched to mining 100% of blocks on
the default global signet using this patchset. However should a problem
occur (eg the node software crashing, or some unintended hard fork being
triggered), the signet miners are configured to automatically fall back to
using bitcoin core nodes to ensure that signet continues to be available.

In order to more reliably relay transactions using the new soft forks,
you may wish to manually connect to a node that supports these features;
you can do so by specifying:

  addnode=inquisition.bitcoin-signet.net
  addnode=phfrpeh47vpjvoi2dgpngfk6ynl7vbnxwekwtcpg3zancixnnjvq.b32.i2p

If you are trying to do experiments with signet and would like a
larger budget than the various faucets will give you, please join the
#bitcoin-signet IRC channel on Libera, and let us know. That applies
whether or not you're making use of inquisition-y features!

If you wish to enable these soft forks on a custom signet, you should mine
a block with version 0x60007600 (BIP 118) and/or version 0x60007700 (BIP
119), then monitor activation using `bitcoin-cli getdeploymentinfo`. The
inquisition node software should also correctly validate/relay CTV
transactions on the existing ctv signet (ctvsignet.com).

As one simple bit of experimentation, block rewards are currently being
sent to the address

  tb1pwzv7fv35yl7ypwj8w7al2t8apd6yf4568cs772qjwper74xqc99sk8x7tk

This is a taproot address with an ANYPREVOUT script path ("OP_1
OP_CHECKSIG"), which has an example spend splitting 1000 sBTC into 900
sBTC for Kalle's mining wallet and 100 sBTC into mine:

  https://mempool.space/signet/tx/2ba88276dee53abdff23258b7f5b8d41005c69f03dc9a5bb9d5cb7b7f41f3e45

Because this transaction was signed with an ANYPREVOUTANYSCRIPT|ALL
signature, that signature can be replayed with other utxos of that pubkey,
eg in the following transaction:

  https://mempool.space/signet/tx/ef8b3351def1163da97f51b8d2cba53c9671dfbd69ae4b1278506b9282bfbdea

That transaction was generated by setting up a watchonly wallet to
monitor that address:

  $ bitcoin-cli -signet createwallet testapo true false '' false true true
  $ bitcoin-cli -signet -rpcwallet=testapo importdescriptors '[{"desc":"addr(tb1pwzv7fv35yl7ypwj8w7al2t8apd6yf4568cs772qjwper74xqc99sk8x7tk)#30t3uj6k", "active":false, "timestamp":1670803200}]'

then manually putting together sufficient inputs to fund the required
signed outputs (with the excess going to fees, and hence back to the
original address since that's where mining payouts are being sent)
and adding the same witness data once for each input:

  $ (X=20; printf "020000000001%02x" $X;
     bitcoin-cli -signet -rpcwallet=testapo listunspent | jq -j '.[] | (.txid, " ", .vout, "\n")' | head -n$X |
       while read txid vout; do
         rtxid=$(echo $txid | sed 's/../& /g' | tr ' ' '\n' | tac | tr -d '\n');
         printf "%s%02x%06x00ffffffff" "$rtxid" "$vout";
       done;
       printf "0200046bf41400000016001481113cad52683679a83e76f76f84a4cfe36f750100e40b54020000001600141b94e6a88e7bfb3a552d6888b102c4f615dc2f56";
       for a in `seq 1 $X`; do
         printf "034189d888393f0c46872fbd002b3523cf58dd474ab86014096bdf69e5248cc06cd6f4b5a223053eb97a708b47ed1d25ad26be7f197536af86ad3389cb1d53a0e643c10251ac21c0624aa2e3277b1f5d667c5acc0ec58eccad8c8be7c7815e122d2b65127f8b0e28";
       done; 
       echo "00000000"
     )  | sed 's/^/["/;s/$/"]/' | bitcoin-cli -stdin -signet testmempoolaccept

That should be something anyone running an inquisition client can
duplicate (err, if you can handle the awesomeness of my shell one-liners);
though doing more than just testmempoolaccept will be naturally rate
limited as it spends 20 blocks worth of reward. There shouldn't be any
way of turning it into a profit, or much of a denial-of-service attack,
but if you find one, that's probably new information about BIP 118! (One
thing you could do is use it as a way of creating an excessively high
CPFP feerate, though without package relay, and on signet, that's probably
not terribly useful)

Finally, yes this is based on Bitcoin Core version 23.0 when 24.0.1
has just been released. The plan in general is to keep inquisition
focussed on released versions of core to minimise rebasing, and more
concretely, to start forward porting the current patches to that now
that it has been released, and possibly consider including support for
additional BIPs (ideas so far include: defining annex interpretation and
package rbf). Discussion of those ideas welcome (on list, on the repo,
or #bitcoin-signet or #bitcoin-contracting-primitives-wg are probably
good choices).

Links:
 - Original proposal: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
 - Wiki: https://github.com/bitcoin-inquisition/bitcoin/wiki
 - PRs: https://github.com/bitcoin-inquisition/bitcoin/pulls?q=is%3Apr
 - discussion about testing segwit on testnet:
    https://www.erisian.com.au/bitcoin-core-dev/log-2016-06-23.html#l-280

Cheers,
aj