Re: [bitcoin-dev] death to the mempool, long live the mempool

[yanmaani--- via bitcoin-dev]

[I removed a comment regarding the moderation of this list here because 
it caused for my message to be rejected]


On 2021-10-26 02:56, lisa neigut via bitcoin-dev wrote:

[...] the mempool is obsolete and should be eliminated.

Instead, users should submit their transactions directly to mining
pools, [...]
Mempools make sense in a world where mining is done by a large number
of participating nodes, [...] as you don’t know which participant will
be constructing the winning block template.

In reality however, mempool relay is unnecessary where the majority of
hashpower and thus block template creation is concentrated in a
semi-restricted set.


It's true that there is some centralization, but this is hardly a 
desirable goal that should be formally enshrined.


By that point, you might as well block people from keeping their coins 
in their own wallet, on the basis that in practice mostly everyone keeps 
them on the exchange.


And as the others have pointed out: even if you did hold this to be 
desirable, why would removing the mempool be a good idea? The pools 
would still need some way to get transactions, and a mempool seems like 
an excellent way to do this.


I think most of the people here have laid out all of the other obvious 
issues with the proposal.



Removing the mempool would greatly reduce the bandwidth requirement
for running a node


You can disable it already if you're strapped for cash. Is there a 
reason why this is not adequate?



keep intentionality of transactions private until confirmed/irrevocable


What is the "intentionality" of a transaction and why do I want to keep 
it private? My transactions are 100% intentional because I am trying to 
send money, and I wouldn't make them otherwise - what is a 
non-intentional transaction supposed to be?



Provided the number of block template producing actors remains
beneath, say 1000, it’d be quite feasible to publish a list of tor
endpoints that nodes can independently  + directly submit their
transactions to.


If nothing else, this would be a significant departure from the security 
model of Bitcoin:



The network is robust in its unstructured simplicity.
Nodes work all at once with little coordination.
They do not need to be identified, since messages are not routed to any 
particular place and only need to be delivered on a best effort basis.
Nodes can leave and rejoin the network at will, accepting the 
proof-of-work chain as proof of what happened while they were gone.


If you posit that the security model should be changed, that is one 
thing, but you should lay out your reasoning for this claim.



On the other hand, removing the mempool would greatly complicate solo
mining and would also make BetterHash proposals, which move the block
template construction away from a centralized mining pool back to the
individual miner, much more difficult.


I am amazed that you are intelligent enough to realize these trade-offs, 
yet still made this post. Are you suggesting that you find them to be 
acceptable?



It also makes explicit the target for DoS attacks.


Perhaps the only good aspect of this proposal. Under such conditions, 
denial of service attacks would be both just and desirable.



A direct communication channel between block template construction
venues and transaction proposers also provides a venue for direct
feedback wrt acceptable feerates at the time, which both makes
transaction confirmation timelines less variable as well as provides
block producers a mechanism for (independently) enforcing their own
minimum security budget. In other words, expressing a minimum
acceptable feerate for continued operation.


Why couldn't they just run a website about this for anyone who cares? 
Communicating two numbers can easily be done over HTTP. This technology 
exists already.



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

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

Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode

[Billy Tetrud via bitcoin-dev]

I very much like this idea. It seems pretty flexible and has a lot of
interesting properties and use cases without being very complex. I'll have
to read through this more deeply later. I'm curious to understand more how
it compares to OP_CTV. It seems that implementing OP_TLUV wouldn't make
OP_CTV obsolete/uncessary, is that right?

> And second, it doesn't provide a way for utxos to "interact",

This is talking about sending data to the output from an input or getting
data from a parent input, other than any added output tapscripts, right? I
think this can/should be done with a separate opcode, so I'm not sure I
would really call this a limitation here. I wrote a proposal for something
that does allow interaction like that (specifically sending data to an
output: OP_PUSHOUTPUTSTACK

).

On Wed, Sep 22, 2021 at 7:29 PM Olaoluwa Osuntokun via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi AJ,
>
> Happy to see that this proposal has finally seen the light of day! I've
> been
> hearing about it in hinted background convos over the past few months, so
> happy I can finally dig into the specifics of its operation.
>
> > So the idea is to do just that via a new opcode "TAPLEAF_UPDATE_VERIFY"
> > (TLUV) that takes three inputs: one that specifies how to update the
> > internal public key (X), one that specifies a new step for the merkle
> path
> > (F), and one that specifies whether to remove the current script and/or
> > how many merkle path steps to remove
>
> What if instead, it obtained the script from the _annex_? I think this
> small
> modification would make the op code even _more_ powerful. Consider that
> this
> allows a new script to be passed _dynamically_ after the output has been
> created, possibly by a threshold of parties that control the output, or
> them
> all (mu sig, etc, etc). This serves to create a generic "upgrade" mechanism
> for any tapscript output (covenant or not). Functionally, this is similar
> to
> the existence of "admin keys" or voted DAO upgrades that exists in chains
> that utilize an account based systems. This is really useful as it allows a
> script any given output to optional add in graftroot like behavior (leaf in
> tree that accepts script updates), and also allows contract developers to
> progressively upgrade or fix issues in prior versions of their deployed
> contracts.
>
> This little trick is secure since unlike the witness itself, the annex is
> actually _signed_ within the sighash like everything else. Incorporating
> this proposal would require the addition of an OP_PUSH_ANNEX op code, which
> by itself seems expertly useful. If one views the annex as a sort of
> authenticated associated data that can be passed into the script execution
> context, then this actually serves to absorb _some_ uses cases of a
> hypothetical OP_CHECKSIG_FROM_STACK opcode. A push annex op code also makes
> doing things like output delegation to a given key passed into the witness
> secure since the prior "owner" of the output commits to the key within the
> sighash.
>
> Even assuming a more powerful type of covenant that allows partial
> application of binding logic, something like this is still super useful
> since the action of re-creating a new tapscript tree based in dynamic input
> data would generate a rather large witness if only something like OP_CAT
> was
> available. The unique "update" nature of this appears to augment any other
> type of covenant, which is pretty cool. Consider that it would allow you
> (with the annex addition above), take something like a CTV congestion tree,
> and add in _new_ users at the tree is already being unrolled (just a toy
> example).
>
> It would also allow an individual to _join_ the payment pool construct
> described earlier which makes it 1000x more useful (vs just supporting
> unrolling). I haven't written it all down yet, but I think this along with
> something like CTV or CSFS makes it possible to implement a Plasma Cash [4]
> like Commit Chain [5], which is super exciting (assume a counter is
> embedded
> in the main script that tracks the next free leaf slot(s). With this model
> an "operator" is able to include a single transaction in the chain that
> stamps a batch of updates in the payment tree.  Users then get a
> contestation period where they can refute a modification to the tree in
> order to withdraw their funds.
>
> > And second, it doesn't provide a way for utxos to "interact",
>
> This is due to the fact that the op code doesn't allow any sort of late
> binding or pattern matching then constraining _where_ (or whence?) the
> coins
> can Be sent to. There's a group of developers that are attempting to make
> an
> AMM-like system on Liquid [1] using more generic stack based covenants [2]
> (see the `OP_INSPECTINPUT` op code, which seems very much inspired by
> jl2012's old proposal). However one challenge that still