Re: [bitcoin-dev] Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks

[ZmnSCPxj via bitcoin-dev]

Good morning aj,

> On Tue, Mar 22, 2022 at 05:37:03AM +, ZmnSCPxj via bitcoin-dev wrote:
>
> > Subject: Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks
>
> (Have you considered applying a jit or some other compression algorithm
> to your emails?)
>
> > Microcode For Bitcoin SCRIPT
> >
> > =
> >
> > I propose:
> >
> > -   Define a generic, low-level language (the "RISC language").
>
> This is pretty much what Simplicity does, if you optimise the low-level
> language to minimise the number of primitives and maximise the ability
> to apply tooling to reason about it, which seem like good things for a
> RISC language to optimise.
>
> > -   Define a mapping from a specific, high-level language to
> > the above language (the microcode).
> >
> > -   Allow users to sacrifice Bitcoins to define a new microcode.
>
> I think you're defining "the microcode" as the "mapping" here.

Yes.

>
> This is pretty similar to the suggestion Bram Cohen was making a couple
> of months ago:
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019722.html
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019773.html
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019803.html
>
> I believe this is done in chia via the block being able to
> include-by-reference prior blocks' transaction generators:
>
> ] transactions_generator_ref_list: List[uint32]: A list of block heights of 
> previous generators referenced by this block's generator.
>
> -   https://docs.chia.net/docs/05block-validation/block_format
>
> (That approach comes at the cost of not being able to do full validation
> if you're running a pruning node. The alternative is to effectively
> introduce a parallel "utxo" set -- where you're mapping the "sacrificed"
> BTC as the nValue and instead of just mapping it to a scriptPubKey for
> a later spend, you're permanently storing the definition of the new
> CISC opcode)
>
>

Yes, the latter is basically what microcode is.

> > We can then support a "RISC" language that is composed of
> > general instructions, such as arithmetic, SECP256K1 scalar
> > and point math, bytevector concatenation, sha256 midstates,
> > bytevector bit manipulation, transaction introspection, and
> > so on.
>
> A language that includes instructions for each operation we can think
> of isn't very "RISC"... More importantly it gets straight back to the
> "we've got a new zk system / ECC curve / ... that we want to include,
> let's do a softfork" problem you were trying to avoid in the first place.

`libsecp256k1` can run on purely RISC machines like ARM, so saying that a 
"RISC" set of opcodes cannot implement some arbitrary ECC curve, when the 
instruction set does not directly support that ECC curve, seems incorrect.

Any new zk system / ECC curve would have to be implementable in C++, so if you 
have micro-operations that would be needed for it, such as XORing two 
multi-byte vectors together, multiplying multi-byte precision numbers, etc., 
then any new zk system or ECC curve would be implementable in microcode.
For that matter, you could re-write `libsecp256k1` there.

> > Then, the user creates a new transaction where one of
> > the outputs contains, say, 1.0 Bitcoins (exact required
> > value TBD),
>
> Likely, the "fair" price would be the cost of introducing however many
> additional bytes to the utxo set that it would take to represent your
> microcode, and the cost it would take to run jit(your microcode script)
> if that were a validation function. Both seem pretty hard to manage.
>
> "Ideally", I think you'd want to be able to say "this old microcode
> no longer has any value, let's forget it, and instead replace it with
> this new microcode that is much better" -- that way nodes don't have to
> keep around old useless data, and you've reduced the cost of introducing
> new functionality.

Yes, but that invites "I accidentally the smart contract" behavior.

> Additionally, I think it has something of a tragedy-of-the-commons
> problem: whoever creates the microcode pays the cost, but then anyone
> can use it and gain the benefit. That might even end up creating
> centralisation pressure: if you design a highly decentralised L2 system,
> it ends up expensive because people can't coordinate to pay for the
> new microcode that would make it cheaper; but if you design a highly
> centralised L2 system, you can just pay for the microcode yourself and
> make it even cheaper.

The same "tragedy of the commons" applies to FOSS.
"whoever creates the FOSS pays the cost, but then anyone can use it and gain 
the benefit"
This seems like an argument against releasing a FOSS node software.

Remember, microcode is software too, and copying software does not have a 
tragedy of the commons --- the main point of a tragedy of the commons is that 
the commons is *degraded* by the use but nobody has incentive to maintain 

Re: [bitcoin-dev] Speedy Trial

[Anthony Towns via bitcoin-dev]

On Thu, Mar 17, 2022 at 03:04:32PM +0100, Jorge Timón via bitcoin-dev wrote:
> On Tue, Mar 15, 2022 at 4:45 PM Anthony Towns  wrote:
> > On Fri, Mar 11, 2022 at 02:04:29PM +, Jorge Timón via bitcoin-dev wrote:
> > People opposed to having taproot transactions in their chain had over
> > three years to do that coordination before an activation method was merged
> > [0], and then an additional seven months after the activation method was 
> > merged before taproot enforcement began [1].
> >
> > [0] 2018-01-23 was the original proposal, 2021-04-15 was when speedy
> > trial activation parameters for mainnet and testnet were merged.
> > [1] 2021-11-14
> People may be opposed only to the final version, but not the initial
> one or the fundamental concept.
> Please, try to think of worse case scenarios.

I mean, I've already spent a lot of time thinking through these worst
cast scenarios, including the ones you bring up. Maybe I've come up with
wrong or suboptimal conclusions about it, and I'm happy to discuss that,
but it's a bit hard to avoid taking offense at the suggestion that I
haven't even thought about it.

In the case of taproot, the final substantive update to the BIP was PR#982
merged on 2020-08-27 -- so even if you'd only been opposed to the changes
in the final version (32B pubkeys perhaps?) you'd have had 1.5 months to
raise those concerns before the code implementing taproot was merged,
and 6 months to raise those concerns before activation parameters were
set. If you'd been following the discussion outside of the code and BIP
text, in the case of 32B pubkeys, you'd have had an additional 15 months
from the time the idea was proposed on 2019-05-22 (or 2019-05-29 if you
only follow optech's summaries) until it was included in the BIP.

> Perhaps there's no opposition until after activation code has been
> released and miners are already starting to signal.
> Perhaps at that moment a reviewer comes and points out a fatal flaw.

Perhaps there's no opposition until the change has been deployed and in
wide use for 30 years. Aborting activation isn't the be-all and end-all
of addressing problems with a proposal, and it's not going to be able to
deal with every problem. For any problems that can be found before the
change is deployed and in use, you want to find them while the proposal
is being discussed.



More broadly, what I don't think you're getting is that *any* method you
can use to abort/veto/revert an activation that's occuring via BIP8 (with
or without mandatory activation), can also be used to abort/veto/revert
a speedy trial activation.

Speedy trial simply changes two things: it allows a minority (~10%)
of hashpower to abort the activation; and it guarantees a "yes" or "no"
answer within three months, while with BIP343 you initially don't know
when within a ~1 year period activation will occur.

If you're part of an (apparent) minority trying to abort/veto/reject
activation, this gives you an additional option: if you can get support
from ~10% of hashpower, you can force an initial "no" answer within
three months, at which point many of the people who were ignoring your
arguments up until then may be willing to reconsider them.

For example, I think Mark Friedenbach's concerns about unhashed pubkeys
and quantum resistance don't make sense, and (therefore) aren't widely
held; but if 10% of blocks during taproot's speedy trial had included a
tagline indicating otherwise and prevented activation, that would have
been pretty clear objective evidence that the concern was more widely
held than I thought, and might be worth reconsidering. Likewise, there
could have somehow been other problems that somehow were being ignored,
that could have similarly been reprioritised in the same way.

That's not the way that you *want* things to work -- ideally people
should be raising the concerns beforehand, and they should be taken
seriously and fixed or addressed beforehand. That did happen with Mark's
concerns -- heck, I raised it as a question ~6 hours after Greg's original
taproot proposal -- and it's directly addressed in the rationale section
of BIP341.

But in the worst case; maybe that doesn't happen. Maybe bitcoin-dev and
other places are somehow being censored, or sensible critics are being
demonised and ignored. The advantage of a hashrate veto here is that it's
hard to fake and hard to censor -- whereas with mailing list messages and
the like, it's both easy to fake (setup sockpuppets and pay troll farms)
and easy to censor (ban/moderate people for spamming say). So as a last
ditch "we've been censored, please take us seriously" method of protest,
it seems worthwhile to have to me.

(Of course, a 90% majority might *still* choose to not take the concerns
of the 10% minority seriously, and just continue to ignore the concern
and followup with an immediate mandatory activation. But if that's what
happening, you can't stop it; you can't only choose whether you want to
be a part of it, or 

Re: [bitcoin-dev] bitcoin scripting and lisp

[Anthony Towns via bitcoin-dev]

On Wed, Mar 16, 2022 at 02:54:05PM +, ZmnSCPxj via bitcoin-dev wrote:
> My point is that in the past we were willing to discuss the complicated 
> crypto math around cross-input sigagg in order to save bytes, so it seems to 
> me that cross-input compression of puzzles/solutions at least merits a 
> discussion, since it would require a lot less heavy crypto math, and *also* 
> save bytes.

Maybe it would be; but it's not something I was intending to bring up in
this thread.

Chia allows any coin spend to reference any output created in the
same block, and potentially any other input in the same block, and
automatically aggregates all signatures in a block; that's all pretty
neat, but trying to do all that in bitcoin in step one doesn't seem smart.

> > > > I /think/ the compression hook would be to allow you to have the puzzles
> > > > be (re)generated via another lisp program if that was more efficient
> > > > than just listing them out. But I assume it would be turtles, err,
> > > > lisp all the way down, no special C functions like with jets.
> > > > Eh, you could use Common LISP or a recent-enough RnRS Scheme to write a 
> > > > cryptocurrency node software, so "special C function" seems to 
> > > > overprivilege C...
> > Jets are "special" in so far as they are costed differently at the
> > consensus level than the equivalent pure/jetless simplicity code that
> > they replace. Whether they're written in C or something else isn't the
> > important part.
> > By comparison, generating lisp code with lisp code in chia doesn't get
> > special treatment.
> Hmm, what exactly do you mean here?

This is going a bit into the weeds...

> If I have a shorter piece of code that expands to a larger piece of code 
> because metaprogramming, is it considered the same cost as the larger piece 
> of code (even if not all parts of the larger piece of code are executed, e.g. 
> branches)?

Chia looks at the problem differently to bitcoin. In bitcoin each
transaction includes a set of inputs, and each of those inputs contains
both a reference to a utxo which has a scriptPubKey, and a solution for
the scriptPubKey called the scriptSig. In chia, each block contains a
list of coins (~utxos) that are being spent, each of which has a hash
of its puzzle (~scriptPubKey) which must be solved; each block then
contains a lisp program that will produce all the transaction info,
namely coin (~utxo id), puzzle reveal (~witness program) and solution
(~witness stack); then to verify the block, you need to check the coins
exist, the puzzle reveals all match the corresponding coin's puzzle,
that the puzzle+solution executes successfully, and that the assertions
that get returned by all the puzzle+solutions are all consistent.

> Or is the cost simply proportional to the number of operations actually 
> executed?

AIUI, the cost is the sum of the size of the program, as well as how
much compute and memory is used to run the program.

In comparison, the cost for an input with tapscript is the size of that
input; memory usage has a fixed maximum (1000 elements in the
stack/altstack, and 520 bytes per element); and compute resources are
limited according to the size of the input.

> It seems to me that lisp-generating-lisp compression would reduce the cost of 
> bytes transmitted, but increase the CPU load (first the metaprogram runs, and 
> *then* the produced program runs).

In chia, you're always running the metaprogram, it may just be that that
program is the equivalent of:

   stuff = lambda: [("hello", "world"), ("hello", "Z-man")]

which doesn't seem much better than just saying:

   stuff = [("hello", "world"), ("hello", "Z-man")]

The advantage is that you could construct a block template optimiser
that rewrites the program to:

   def stuff():
   h = "hello"
   return [(h, "world"), (h, "Z-man")]

which for large values of "hello" may be worthwhile (and the standard
puzzle in chia is large enough at that that might well be worthwhile at
~227 bytes, since it implements taproot/graftroot logic from scratch).

> Over in that thread, we seem to have largely split jets into two types:
> * Consensus-critical jets which need a softfork but reduce the weight of the 
> jetted code (and which are invisible to pre-softfork nodes).
> * Non-consensus-critical jets which only need relay change and reduces bytes 
> sent, but keeps the weight of the jetted code.
> It seems to me that lisp-generating-lisp compression would roughly fall into 
> the "non-consensus-critical jets", roughly.

It could do; but the way it's used in chia is consensus-critical. 

I'm not 100% sure how costing works in chia, but I believe a block
template optimiser as above might allow miners to fit more transactions
in their block and therefore collect more transaction fees. That makes
the block packing problem harder though, since it means your transaction
is "cheaper" if it's more similar to other transactions in the block. I
don't think it's relevant today 

Re: [bitcoin-dev] Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks

[Anthony Towns via bitcoin-dev]

On Tue, Mar 22, 2022 at 05:37:03AM +, ZmnSCPxj via bitcoin-dev wrote:
> Subject: Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks

(Have you considered applying a jit or some other compression algorithm
to your emails?)

> Microcode For Bitcoin SCRIPT
> 
> I propose:
> * Define a generic, low-level language (the "RISC language").

This is pretty much what Simplicity does, if you optimise the low-level
language to minimise the number of primitives and maximise the ability
to apply tooling to reason about it, which seem like good things for a
RISC language to optimise.

> * Define a mapping from a specific, high-level language to
>   the above language (the microcode).
> * Allow users to sacrifice Bitcoins to define a new microcode.

I think you're defining "the microcode" as the "mapping" here.

This is pretty similar to the suggestion Bram Cohen was making a couple
of months ago:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019722.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019773.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019803.html

I believe this is done in chia via the block being able to
include-by-reference prior blocks' transaction generators:

] transactions_generator_ref_list: List[uint32]: A list of block heights of 
previous generators referenced by this block's generator.
  - https://docs.chia.net/docs/05block-validation/block_format

(That approach comes at the cost of not being able to do full validation
if you're running a pruning node. The alternative is to effectively
introduce a parallel "utxo" set -- where you're mapping the "sacrificed"
BTC as the nValue and instead of just mapping it to a scriptPubKey for
a later spend, you're permanently storing the definition of the new
CISC opcode)

> We can then support a "RISC" language that is composed of
> general instructions, such as arithmetic, SECP256K1 scalar
> and point math, bytevector concatenation, sha256 midstates,
> bytevector bit manipulation, transaction introspection, and
> so on.

A language that includes instructions for each operation we can think
of isn't very "RISC"... More importantly it gets straight back to the
"we've got a new zk system / ECC curve / ... that we want to include,
let's do a softfork" problem you were trying to avoid in the first place.

> Then, the user creates a new transaction where one of
> the outputs contains, say, 1.0 Bitcoins (exact required
> value TBD),

Likely, the "fair" price would be the cost of introducing however many
additional bytes to the utxo set that it would take to represent your
microcode, and the cost it would take to run jit(your microcode script)
if that were a validation function. Both seem pretty hard to manage.

"Ideally", I think you'd want to be able to say "this old microcode
no longer has any value, let's forget it, and instead replace it with
this new microcode that is much better" -- that way nodes don't have to
keep around old useless data, and you've reduced the cost of introducing
new functionality.

Additionally, I think it has something of a tragedy-of-the-commons
problem: whoever creates the microcode pays the cost, but then anyone
can use it and gain the benefit. That might even end up creating
centralisation pressure: if you design a highly decentralised L2 system,
it ends up expensive because people can't coordinate to pay for the
new microcode that would make it cheaper; but if you design a highly
centralised L2 system, you can just pay for the microcode yourself and
make it even cheaper.

This approach isn't very composable -- if there's a clever opcode
defined in one microcode spec, and another one in some other microcode,
the only way to use both of them in the same transaction is to burn 1
BTC to define a new microcode that includes both of them.

> We want to be able to execute the defined microcode
> faster than expanding an `OP_`-code SCRIPT to a
> `UOP_`-code SCRIPT and having an interpreter loop
> over the `UOP_`-code SCRIPT.
>
> We can use LLVM.

We've not long ago gone to the effort of removing openssl as a consensus
critical dependency; and likewise previously removed bdb.  Introducing a
huge new dependency to the definition of consensus seems like an enormous
step backwards.

This would also mean we'd be stuck at the performance of whatever version
of llvm we initially adopted, as any performance improvements introduced
in later llvm versions would be a hard fork.

> On the other hand, LLVM bugs are compiler bugs and
> the same bugs can hit the static compiler `cc`, too,

"Well, you could hit Achilles in the heel, so really, what's the point
of trying to be invulnerable anywhere else?"

> Then we put a pointer to this compiled function to a
> 256-long array of functions, where the array index is
> the `OP_` code.

That's a 256-long array of functions for each microcode, which increases
the "microcode-utxo" database 

[bitcoin-dev] Pleb.fi/miami2022 Invitation + CTV Meeting #7 postponement

[Jeremy Rubin via bitcoin-dev]

Devs,

I warmly invite you to join for pleb.fi/miami2022 if you are interested to
participate. It will be April 4th and 5th near miami.

The focus of this pleb.fi event will be the ins and outs of building
bitcoin stuff in rust with a focus on Sapio and a hackathon.

As the CTV Meeting overlaps with the programming for pleb.fi, regrettably I
will be unable to host it.

We'll resume with meeting #7 at the time meeting #8 would be otherwise.

Best,

Jeremy

--
@JeremyRubin 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] CTV BIP Meeting #6 Notes on Sapio Studio Tutorial

[Jeremy Rubin via bitcoin-dev]

Devs,

Tutorial: https://rubin.io/bitcoin/2022/03/22/sapio-studio-btc-dev-mtg-6/
Meeting Logs:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020157.html

Summary:

The 6th CTV meeting was a Sapio Studio tutorial. Sapio Studio is a Bitcoin
Wallet / IDE for playing with Bitcoin Smart Contracts. It is clearly "Alpha
Software", but gets better and better!

The tutorial primarily covers setting up Sapio Studio and then using it to
create an instance of a Bitcoin Vault similar to the variety James O'Beirne
shared recently on this list.

Participants had trouble with:

1) Build System Stuff
2) Passing in Valid Arguments
3) Minrelay Fees
4) Minor GUI bugs in the software

But overall, the software was able to be used successfully similar to the
screenshots in the tutorial, including restarting and resuming a session,
recompiling with effect updates (essentially a form of multisig enforced
recursive covenant which can be made compatible with arbitrary covenant
upgrades), and more.

Based on the meeting, there are some clear areas of improvement needed to
make this GUI more intuitive that will be incorporated in the coming weeks.

Best,

Jeremy

--
@JeremyRubin 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] mempool transaction witness-replacement

[darosior via bitcoin-dev]

Hi Larry,


Thanks for bringing this up. I'm curious to know if this is helpful for pinning 
as long as you have a way to
statically analyze Script to prevent witness stuffing [0]. I agree it *could* 
still be useful for miners, but
subject to all the complications of RBF.

> An advantage of this mempool-accept policy change is that it's
> miner-incentive compatible (miners would prefer to mine a transaction
> with a higher feerate).

There is more to be "miner-incentive compatible" than increasing feerate. For 
instance, the latest RBF
discussions made the miner incentive to maximize absolute fees more well known. 
I think the same goes for
witness replacement: if you don't have as many MBs of transaction you are 
comfortable with in your mempool,
you don't want it to shrink further.


Antoine

[0] See the 'Malleability' section of https://bitcoin.sipa.be/miniscript/. Note 
however this currently only
applies to third party malleability (in pinning attacks the aversary is 
internal to the contract). On the
other hand Miniscript already allows you to get the maximum satisfaction 
size, so you can cover for the worst
case scenario already.

--- Original Message ---

Le mardi 22 mars 2022 à 8:04 PM, Larry Ruane via bitcoin-dev 
 a écrit :

> Greetings list,
>
> This is my first time posting here.
>
> Question for you:
>
> Should the Bitcoin Core mempool replace an existing transaction with one
>
> that has the same txid (having the same effect, same spends and outputs)
>
> but a sufficiently smaller witness (different wtxid) and thus a higher
>
> feerate? This is what https://github.com/bitcoin/bitcoin/pull/24007
>
> proposes, and I'd like to get opinions on two questions:
>
> 1. Is this a beneficial change? Specifically, is anyone creating an
>
> application that would broadcast transactions with the same txid but
>
> different witnesses as an earlier transaction?
>
> 2. If this change has benefit, what should be considered a sufficiently
>
> better feerate or reduction in witness size?
>
> An advantage of this mempool-accept policy change is that it's
>
> miner-incentive compatible (miners would prefer to mine a transaction
>
> with a higher feerate). But there is of course a code complexity cost,
>
> and transaction-relay DoS concern.
>
> Being miner-incentive compatible is good, but is that sufficient
>
> justification for merging? I'm posting to the mailing list in hopes that
>
> there are use-cases that we (the PR authors) aren't aware of. Please
>
> reply here or on the PR if you can think of any.
>
> A perhaps subtle advantage: This PR may provide a defense against a
>
> mempool pinning attack: if you have a transaction shared with other
>
> parties, and one of them broadcasts the transaction with a bloated
>
> witness (thus intentionally reducing the feerate in hopes of delaying
>
> or preventing confirmation), you currently have no way to change it.
>
> If there is an application out there that uses same-txid-different-witness
>
> transactions shared between counterparties, this PR would help make
>
> those applications safe.
>
> Question 2 gets at a DoS tradeoff: If the new transaction may have
>
> only a very slightly smaller witness, an attacker might re-broadcast it
>
> many times, consuming a lot of relay bandwidth, and CPU to update
>
> the mempool. On the other hand, if the new transaction must have a much
>
> smaller witness, then it wouldn't be possible to replace a transaction with
>
> a beneficially-smaller one.
>
> This could be a per-node setting, but it's desirable for the node
>
> network to largely agree on relay policies (although a configuration
>
> option might be useful for testing and experimentation).
>
> Background:
>
> Bip125 (Replace-by-fee) allows an incoming transaction to replace one
>
> or more existing conflicting transactions if certain DoS-mitigation
>
> conditions are met:
>
> https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md
>
> Witness-replacement is similar to RBF, but differs in a few ways:
>
> - RBF rule 4 requires an absolute fee increase, which is not possible if
>
> the txid isn't changing (since the inputs, outputs, and amounts must be
>
> the same). So if transaction witness-replacement (same txid but different
>
> wtxid) is allowed, it can't be considered just a special case of an RBF,
>
> although it may have some similar policies (and for the same reasons).
>
> - With witness-replacement, it's not necessary to evict mempool
>
> descendant transactions because their inputs' txid references to their
>
> parent (who is being replaced) remain valid.
>
> - The new transaction replaces exactly one existing transaction since
>
> the inputs are the same. (In general, with RBF, the new transaction may
>
> conflict-out multiple existing mempool transactions, namely, all that
>
> spend the same outputs as the new transaction.)
>
> - RBF requires the original transaction to signal replaceability
>
> (rule 1). 

[bitcoin-dev] mempool transaction witness-replacement

[Larry Ruane via bitcoin-dev]

Greetings list,

This is my first time posting here.

Question for you:

Should the Bitcoin Core mempool replace an existing transaction with one
that has the same txid (having the same effect, same spends and outputs)
but a sufficiently smaller witness (different wtxid) and thus a higher
feerate? This is what https://github.com/bitcoin/bitcoin/pull/24007
proposes, and I'd like to get opinions on two questions:

1. Is this a beneficial change? Specifically, is anyone creating an
application that would broadcast transactions with the same txid but
different witnesses as an earlier transaction?

2. If this change has benefit, what should be considered a sufficiently
better feerate or reduction in witness size?

An advantage of this mempool-accept policy change is that it's
miner-incentive compatible (miners would prefer to mine a transaction
with a higher feerate). But there is of course a code complexity cost,
and transaction-relay DoS concern.

Being miner-incentive compatible is good, but is that sufficient
justification for merging? I'm posting to the mailing list in hopes that
there are use-cases that we (the PR authors) aren't aware of. Please
reply here or on the PR if you can think of any.

A perhaps subtle advantage: This PR may provide a defense against a
mempool pinning attack: if you have a transaction shared with other
parties, and one of them broadcasts the transaction with a bloated
witness (thus intentionally reducing the feerate in hopes of delaying
or preventing confirmation), you currently have no way to change it.
If there is an application out there that uses same-txid-different-witness
transactions shared between counterparties, this PR would help make
those applications safe.

Question 2 gets at a DoS tradeoff: If the new transaction may have
only a very slightly smaller witness, an attacker might re-broadcast it
many times, consuming a lot of relay bandwidth, and CPU to update
the mempool. On the other hand, if the new transaction must have a much
smaller witness, then it wouldn't be possible to replace a transaction with
a beneficially-smaller one.

This could be a per-node setting, but it's desirable for the node
network to largely agree on relay policies (although a configuration
option might be useful for testing and experimentation).

Background:

Bip125 (Replace-by-fee) allows an incoming transaction to replace one
or more existing conflicting transactions if certain DoS-mitigation
conditions are met:

https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md

Witness-replacement is similar to RBF, but differs in a few ways:

- RBF rule 4 requires an absolute fee increase, which is not possible if
the txid isn't changing (since the inputs, outputs, and amounts must be
the same). So if transaction witness-replacement (same txid but different
wtxid) is allowed, it can't be considered just a special case of an RBF,
although it may have some similar policies (and for the same reasons).

- With witness-replacement, it's not necessary to evict mempool
descendant transactions because their inputs' txid references to their
parent (who is being replaced) remain valid.

- The new transaction replaces exactly one existing transaction since
the inputs are the same. (In general, with RBF, the new transaction may
conflict-out multiple existing mempool transactions, namely, all that
spend the same outputs as the new transaction.)

- RBF requires the original transaction to signal replaceability
(rule 1). This is so that recipients are warned that their payment may
disappear if the transaction is replaced. But signaling isn't required
by witness-replacement since the outputs can't change (the descendants
remain valid).

Thanks for your time!

Larry Ruane (with lots of help from Gloria Zhao)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[vjudeu via bitcoin-dev]

> What do you mean "capture that" and "your network"? I was imagining a 
> scenario where these poll messages are always broadcast globally. Are you 
> implying more of a private poll?

If you vote by making a Bitcoin transaction, then someone could move real 
bitcoins, just by including your transaction into a block. I thought you only 
want to get some feedback, in this case you only need to sign things, not to 
move real coins. So, there will be one network for moving bitcoins and one 
network for signalling/voting/whatever. If you combine both of them to be the 
same network, then you end up in a situation, where moving coins is needed to 
signal anything (that may quickly fill mempools and increase on-chain fees).

Also, as you earlier proposed custom data format for signing, I thought you 
want to create a separate network.

> I still don't understand. Why would a signed transaction be invalid anywhere? 
> Wouldn't a signed transaction be valid everywhere?

It depends what is signed and how it is signed. A transaction moving "1 BTC -> 
1.5 BTC" with SIGHASH_SINGLE|SIGHASH_ANYONECANPAY cannot be included directly 
into a block, but can be turned into a valid transaction, just by attaching 
more inputs. A signed "Bitcoin Message" can be used to prove ownership, but 
cannot be included into a block as a valid transaction. So, if you want to move 
coins and vote, you can just sign a transaction (or even just observe your 
mempool and receive new blocks, then you can use existing transactions and 
pretend they are all signalling for or against something). But if you want to 
only move coins or to only vote, then you need to carefully choose data for 
signing, just to do one thing and not the other.

> Perhaps I don't understand how signet works well enough to understand this, 
> but I would think that signing an message would work with signet just as well 
> as mainnet. I get the feeling perhaps we're misunderstanding each other in 
> some fundamental way.

In signet, whole transactions are signed. There are separate BIP's that 
describe signing in a different way than famous "Bitcoin Message". Because if 
you sign just some message, extending such format is complicated. But if you 
sign a transaction, then you can sign P2SH address, P2WSH address, Taproot 
address, and potentially even not-yet-implemented-future-soft-fork-address.

> But it would require an on-chain transaction. We don't want 6 billion people 
> to have to send an on-chain transaction all in the same week in order to 
> register their preference on something.

It would require an on-chain transaction every sometimes, not every vote. If 
someone is going to do some on-chain transaction, then that person could attach 
some commitment for the whole network. So, instead of just doing regular 
transaction, people could attach commitments at the same cost, with the same 
on-chain transaction size. The only needed change is just tweaking their own 
keys and informing your network about pushed commitment.


On 2022-03-22 16:19:49 user Billy Tetrud  wrote:
>  If you vote by making transactions, then someone could capture that and 
>broadcast to nodes
>  you can only send that to your network



What do you mean "capture that" and "your network"? I was imagining a scenario 
where these poll messages are always broadcast globally. Are you implying more 
of a private poll?


> If it will be sent anywhere else, it will be invalid


I still don't understand. Why would a signed transaction be invalid anywhere? 
Wouldn't a signed transaction be valid everywhere? 


> Another reason to sign transactions and not just some custom data is to make 
> it compatible with "signet way of making signatures", the same as used in 
> signet challenge.


Perhaps I don't understand how signet works well enough to understand this, but 
I would think that signing an message would work with signet just as well as 
mainnet. I get the feeling perhaps we're misunderstanding each other in some 
fundamental way.


> Even if it is not needed, it is kind of "free" if you take transaction size 
> into account


But it would require an on-chain transaction. We don't want 6 billion people to 
have to send an on-chain transaction all in the same week in order to register 
their preference on something. 


On Mon, Mar 21, 2022 at 10:56 AM  wrote:

> I don't quite understand this part. I don't understand how this would make 
> your signature useless in a different context. Could you elaborate?

It is simple. If you vote by making transactions, then someone could capture 
that and broadcast to nodes. If your signature is "useless in a different 
context", then you can only send that to your network. If it will be sent 
anywhere else, it will be invalid, so also useless. Another reason to sign 
transactions and not just some custom data is to make it compatible with 
"signet way of making signatures", the same as used in signet challenge.

> I don't think any kind of chain is 

Re: [bitcoin-dev] Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks

[ZmnSCPxj via bitcoin-dev]

Good morning again Russell,

> Good morning Russell,
>
> > Thanks for the clarification.
> > You don't think referring to the microcode via its hash, effectively using 
> > 32-byte encoding of opcodes, is still rather long winded?

For that matter, since an entire microcode represents a language (based on the 
current OG Bitcoin SCRIPT language), with a little more coordination, we could 
entirely replace Tapscript versions --- every Tapscript version is a slot for a 
microcode, and the current OG Bitcoin SCRIPT is just the one in slot `0xc2`.
Filled slots cannot be changed, but new microcodes can use some currently-empty 
Tapscript version slot, and have it properly defined in a microcode 
introduction outpoint.

Then indication of a microcode would take only one byte, that is already needed 
currently anyway.

That does limit us to only 255 new microcodes, thus the cost of one microcode 
would have to be a good bit higher.

Again, remember, microcodes represent an entire language that is an extension 
of OG Bitcoin SCRIPT, not individual operations in that language.

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks

[ZmnSCPxj via bitcoin-dev]

Good morning Russell,

> Thanks for the clarification.
>
> You don't think referring to the microcode via its hash, effectively using 
> 32-byte encoding of opcodes, is still rather long winded?

A microcode is a *mapping* of `OP_` codes to a variable-length sequence of 
`UOP_` micro-opcodes.
So a microcode hash refers to an entire language of redefined `OP_` codes, not 
each individual opcode in the language.

If it costs 1 Bitcoin to create a new microcode, then there are only 21 million 
possible microcodes, and I think about 50 bits of hash is sufficient to specify 
those with low probability of collision.
We could use a 20-byte RIPEMD . SHA256 instead for 160 bits, that should be 
more than sufficient with enough margin.
Though perhaps it is now easier to deliberately attack...

Also, if you have a common SCRIPT whose non-`OP_PUSH` opcodes are more than say 
32 + 1 bytes (or 20 + 1 if using RIPEMD), and you can fit their equivalent 
`UOP_` codes into the max limit for a *single* opcode, you can save bytes by 
redefining some random `OP_` code into the sequence of all the `UOP_` codes.
You would have a hash reference to the microcode, and a single byte for the 
actual "SCRIPT" which is just a jet of the entire SCRIPT.
Users of multiple *different* such SCRIPTs can band together to define a single 
microcode, mapping their SCRIPTs to different `OP_` codes and sharing the cost 
of defining the new microcode that shortens all their SCRIPTs.

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks

[Russell O'Connor via bitcoin-dev]

Thanks for the clarification.

You don't think referring to the microcode via its hash, effectively using
32-byte encoding of opcodes, is still rather long winded?

On Tue, Mar 22, 2022 at 12:23 PM ZmnSCPxj  wrote:

> Good morning Russell,
>
> > Setting aside my thoughts that something like Simplicity would make a
> better platform than Bitcoin Script (due to expression operating on a more
> narrow interface than the entire stack (I'm looking at you OP_DEPTH)) there
> is an issue with namespace management.
> >
> > If I understand correctly, your implication was that once opcodes are
> redefined by an OP_RETURN transaction, subsequent transactions of that
> opcode refer to the new microtransaction.  But then we have a race
> condition between people submitting transactions expecting the outputs to
> refer to the old code and having their code redefined by the time they do
> get confirmed  (or worse having them reorged).
>
> No, use of specific microcodes is opt-in: you have to use a specific
> `0xce` Tapscript version, ***and*** refer to the microcode you want to use
> via the hash of the microcode.
>
> The only race condition is reorging out a newly-defined microcode.
> This can be avoided by waiting for deep confirmation of a newly-defined
> microcode before actually using it.
>
> But once the microcode introduction outpoint of a particular microcode has
> been deeply confirmed, then your Tapscript can refer to the microcode, and
> its meaning does not change.
>
> Fullnodes may need to maintain multiple microcodes, which is why creating
> new microcodes is expensive; they not only require JIT compilation, they
> also require that fullnodes keep an index that cannot have items deleted.
>
>
> The advantage of the microcode scheme is that the size of the SCRIPT can
> be used as a proxy for CPU load  just as it is done for current Bitcoin
> SCRIPT.
> As long as the number of `UOP_` micro-opcodes that an `OP_` code can
> expand to is bounded, and we avoid looping constructs, then the CPU load is
> also bounded and the size of the SCRIPT approximates the amount of
> processing needed, thus microcode does not require a softfork to modify
> weight calculations in the future.
>
> Regards,
> ZmnSCPxj
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks

[ZmnSCPxj via bitcoin-dev]

Good morning Russell,

> Setting aside my thoughts that something like Simplicity would make a better 
> platform than Bitcoin Script (due to expression operating on a more narrow 
> interface than the entire stack (I'm looking at you OP_DEPTH)) there is an 
> issue with namespace management.
>
> If I understand correctly, your implication was that once opcodes are 
> redefined by an OP_RETURN transaction, subsequent transactions of that opcode 
> refer to the new microtransaction.  But then we have a race condition between 
> people submitting transactions expecting the outputs to refer to the old code 
> and having their code redefined by the time they do get confirmed  (or worse 
> having them reorged).

No, use of specific microcodes is opt-in: you have to use a specific `0xce` 
Tapscript version, ***and*** refer to the microcode you want to use via the 
hash of the microcode.

The only race condition is reorging out a newly-defined microcode.
This can be avoided by waiting for deep confirmation of a newly-defined 
microcode before actually using it.

But once the microcode introduction outpoint of a particular microcode has been 
deeply confirmed, then your Tapscript can refer to the microcode, and its 
meaning does not change.

Fullnodes may need to maintain multiple microcodes, which is why creating new 
microcodes is expensive; they not only require JIT compilation, they also 
require that fullnodes keep an index that cannot have items deleted.


The advantage of the microcode scheme is that the size of the SCRIPT can be 
used as a proxy for CPU load  just as it is done for current Bitcoin SCRIPT.
As long as the number of `UOP_` micro-opcodes that an `OP_` code can expand to 
is bounded, and we avoid looping constructs, then the CPU load is also bounded 
and the size of the SCRIPT approximates the amount of processing needed, thus 
microcode does not require a softfork to modify weight calculations in the 
future.

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Eric Voskuil via bitcoin-dev]

> > Even if it is not needed, it is kind of "free" if you take transaction size 
> > into account
> 
> But it would require an on-chain transaction. We don't want 6 billion people 
> to have to send an on-chain transaction all in the same week in order to 
> register their preference on something.

I haven’t followed this thread, so apologies if I’m missing some context, but 
confirmed tx signaling remains miner signaling.

Regardless, miners are the only actors who can create soft fork compatibility, 
so theirs is the only relevant signal. Otherwise people can just fork 
themselves at any time using any voting mechanism they want.

e
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Billy Tetrud via bitcoin-dev]

>  If you vote by making transactions, then someone could capture that and
broadcast to nodes
>  you can only send that to your network

What do you mean "capture that" and "your network"? I was imagining a
scenario where these poll messages are always broadcast globally. Are you
implying more of a private poll?

> If it will be sent anywhere else, it will be invalid

I still don't understand. Why would a signed transaction be invalid
anywhere? Wouldn't a signed transaction be valid everywhere?

> Another reason to sign transactions and not just some custom data is to
make it compatible with "signet way of making signatures", the same as used
in signet challenge.

Perhaps I don't understand how signet works well enough to understand this,
but I would think that signing an message would work with signet just as
well as mainnet. I get the feeling perhaps we're misunderstanding each
other in some fundamental way.

> Even if it is not needed, it is kind of "free" if you take transaction
size into account

But it would require an on-chain transaction. We don't want 6 billion
people to have to send an on-chain transaction all in the same week in
order to register their preference on something.

On Mon, Mar 21, 2022 at 10:56 AM  wrote:

> > I don't quite understand this part. I don't understand how this would
> make your signature useless in a different context. Could you elaborate?
>
> It is simple. If you vote by making transactions, then someone could
> capture that and broadcast to nodes. If your signature is "useless in a
> different context", then you can only send that to your network. If it will
> be sent anywhere else, it will be invalid, so also useless. Another reason
> to sign transactions and not just some custom data is to make it compatible
> with "signet way of making signatures", the same as used in signet
> challenge.
>
> > I don't think any kind of chain is necessary to store this data.
>
> Even if it is not needed, it is kind of "free" if you take transaction
> size into account. Because each person moving coins on-chain could attach
> "OP_RETURN " in TapScript, just to save commitments. Then, even
> if someone is not in your network from the very beginning, that person
> could still collect commitments and find out how they are connected with
> on-chain transactions.
>
> > Perhaps one day it could be used for something akin to voting, but
> certainly if we were going to implement this to help decide on the next
> soft fork, it would very likely be a quite biased set of responders.
>
> If it will be ever implemented, it should be done in a similar way as
> difficulty: if you want 90%, you should calculate, what amount in satoshis
> is needed to reach that 90%, and update it every two weeks, based on all
> votes. In this way, you reduce floating-point operations to a bare minimum,
> and have a system, where you can compare uint64 amounts to quickly get
> "yes/no" answer to the question, if something should be triggered (also,
> you can compress it to 32 bits in the same way as 256-bit target is
> compressed).
>
> > But on that note, I was thinking that it might be interesting to have an
> optional human readable message into these poll messages.
>
> As I said, "OP_RETURN " inside TapScript is enough to produce
> all commitments of arbitrary size for "free", so that on-chain transaction
> size is constant, no matter how large that commitment is. And about
> storage: you could create a separate chain for that, you could store that
> in the same way as LN nodes store data, you could use something else, it
> doesn't really matter, because on-chain commitments could be constructed in
> the same way (also, as long as the transaction creator keeps those
> commitments as a secret, there is no way to get them; that means you can
> add them later if needed and easily pretend that "it was always possible").
>
>
> On 2022-03-21 10:17:29 user Billy Tetrud via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> Good Evening ZmnSCPxj,
>
>
> >  I need to be able to invalidate the previous signal, one that is tied
> to the fulfillment of the forwarding request.
>
>
> You're right that there's some nuance there. You could add a block hash
> into the poll message and define things so any subsequent poll message sent
> with a newer block hash overrides the old poll message at the block with
> that hash and later blocks. That way if a channel balance changes
> significantly, a new poll message can be sent out.
>
>
> Or you could remove the ability to specify fractional support/opposition
> and exclude multiparty UTXOs from participation. I tend to like the idea of
> the possibility of full participation tho, even in a world that mainly uses
> lightning.
>
>
> > if the signaling is done onchain
>
>
> I don't think any of this signaling needs to be done on-chain. Anyone who
> wants to keep a count of the poll can simply collect together all these
> poll messages and count up the weighted preferences. 

Re: [bitcoin-dev] Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks

[Russell O'Connor via bitcoin-dev]

Setting aside my thoughts that something like Simplicity would make a
better platform than Bitcoin Script (due to expression operating on a more
narrow interface than the entire stack (I'm looking at you OP_DEPTH)) there
is an issue with namespace management.

If I understand correctly, your implication was that once opcodes are
redefined by an OP_RETURN transaction, subsequent transactions of that
opcode refer to the new microtransaction.  But then we have a race
condition between people submitting transactions expecting the outputs to
refer to the old code and having their code redefined by the time they do
get confirmed  (or worse having them reorged).

I've partially addressed this issue in my Simplicity design where the
commitment of a Simplicity program in a scriptpubkey covers the hash of the
specification of the jets used, which makes commits unambiguously to the
semantics (rightly or wrongly).  But the issue resurfaces at redemption
time where I (currently) have a consensus critical map of codes to jets
that is used to decode the witness data into a Simplicity program.  If one
were to allow this map of codes to jets to be replaced (rather than just
extended) then it would cause redemption to fail, because the hash of the
new jets would no longer match the hash of the jets appearing the the
input's scriptpubkey commitment.  While this is still not good and I don't
recommend it, it is probably better than letting the semantics of your
programs be changed out from under you.

This comment is not meant as an endorsement of ths idea, which is a little
bit out there, at least as far as Bitcoin is concerned. :)

My long term plans are to move this consensus critical map of codes out of
the consensus layer and into the p2p layer where peers can negotiate their
own encodings between each other.  But that plan is also a little bit out
there, and it still doesn't solve the issue of how to weight reused jets,
where weight is still consensus critical.

On Tue, Mar 22, 2022 at 1:37 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning list,
>
> It is entirely possible that I have gotten into the deep end and am now
> drowning in insanity, but here goes
>
> Subject: Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks
>
> Introduction
> 
>
> Recent (Early 2022) discussions on the bitcoin-dev mailing
> list have largely focused on new constructs that enable new
> functionality.
>
> One general idea can be summarized this way:
>
> * We should provide a very general language.
>   * Then later, once we have learned how to use this language,
> we can softfork in new opcodes that compress sections of
> programs written in this general language.
>
> There are two arguments against this style:
>
> 1.  One of the most powerful arguments the "general" side of
> the "general v specific" debate is that softforks are
> painful because people are going to keep reiterating the
> activation parameters debate in a memoryless process, so
> we want to keep the number of softforks low.
> * So, we should just provide a very general language and
>   never softfork in any other change ever again.
> 2.  One of the most powerful arguments the "general" side of
> the "general v specific" debate is that softforks are
> painful because people are going to keep reiterating the
> activation parameters debate in a memoryless process, so
> we want to keep the number of softforks low.
> * So, we should just skip over the initial very general
>   language and individually activate small, specific
>   constructs, reducing the needed softforks by one.
>
> By taking a page from microprocessor design, it seems to me
> that we can use the same above general idea (a general base
> language where we later "bless" some sequence of operations)
> while avoiding some of the arguments against it.
>
> Digression: Microcodes In CISC Microprocessors
> --
>
> In the 1980s and 1990s, two competing microprocessor design
> paradigms arose:
>
> * Complex Instruction Set Computing (CISC)
>   - Few registers, many addressing/indexing modes, variable
> instruction length, many obscure instructions.
> * Reduced Instruction Set Computing (RISC)
>   - Many registers, usually only immediate and indexed
> addressing modes, fixed instruction length, few
> instructions.
>
> In CISC, the microprocessor provides very application-specific
> instructions, often with a small number of registers with
> specific uses.
> The instruction set was complicated, and often required
> multiple specific circuits for each application-specific
> instruction.
> Instructions had varying sizes and varying number of cycles.
>
> In RISC, the micrprocessor provides fewer instructions, and
> programmers (or compilers) are supposed to generate the code
> for all application-specific needs.
> The processor provided large