Re: [bitcoin-dev] Package Relay Proposal

[Gloria Zhao via bitcoin-dev]

(To everyone):
I should have made it much clearer that version 1 is only supposed to solve
1 of the 2 use cases. I was a lot more focused on the fee-bumping use case,
since it’s more important. Orphan-fetching was added to the motivation
section last-minute because John Newbery mentioned to me “hey you could
deal with orphans really easily with this.” Of course,
child-with-unconfirmed-parents packages aren’t very useful for
orphan-fetching since non-parent ancestors are quite common.

Maybe a version 2 package for orphan-fetching could look like this:

“pckginfo2” message contains a tx with all of its ancestors

“MSG_PCKG2” inv type refers to a “pckginfo2” for a tx. You don’t send
inv(MSG_PCKG2), but a node can request getdata(MSG_PCKG2) for a transaction
they want the ancestors for, provided they sent sendpackages(version=2)
ahead of time. It seems to me that orphan-fetching only ever needs to be
receiver-initiated.

Protocol flow would look like this:
https://user-images.githubusercontent.com/25183001/168891185-1630f583-de47-4937-86b1-2652cf8852f2.png

We don’t have a policy for dealing with anything more than a child with its
direct parents, but I also don’t think anybody is relying on fee-bumping
more than 2 generations, so the validation logic here could probably just
submit them all individually. Maybe they can request a pckginfo1 if they
see something that’s too-low-fee, and/or use the
child-with-unconfirmed-parents logic opportunistically.

Thanks aj for the feedback! Responding:

> The "PCKG" abbreviation threw me for a loop; isn't the usual
> abbreviation "PKG" ?

Oh I didn't know that. I could change it if people feel strongly.

> Does it make sense for these to be configurable, rather than implied
> by the version?
> … would it be better to either just not do sendpackages
> at all if you're limiting ancestors in the mempool incompatibly

Effectively: if you’re setting your ancestor/descendant limits lower than
the default, you can’t do package relay. I wonder if this might be
controversial, since it adds pressure to adhere to Bitcoin Core’s current
mempool policy? I would be happy to do it this way, though - makes things
easier to implement.

> > 5. If 'fRelay==false' in a peer's version message, the node must not
> >send "sendpackages" to them. If a "sendpackages" message is
> > received by a peer after sending `fRelay==false` in their version
> > message, the sender should be disconnected.

> Seems better to just say "if you set fRelay=false in your version
> message, you must not send sendpackages"? You already won't do packages
> with the peer if they don't also announce sendpackages.

I guess, theoretically, if you allow bloom filters with this peer, it’s
plausible they’re saying “fRelay=false, I’ll send you a bloom filter later,
and I’ll also want to talk about packages.”
I don’t know if that’s a use case we want to support - my gut reaction is
no.

> Maybe: "You must not send sendpackages unless you also send wtxidrelay" ?

Do you mean if we get a verack, and the peer sent “sendpackages” but not
“wtxidrelay,” we should disconnect them?

> As I understand it, the two cases for the protocol flow are "I received
> an orphan, and I'd like its ancestors please" which seems simple enough,
> and "here's a child you may be interested in, even though you possibly
> weren't interested in the parents of that child".

(Btw, please see my notes at the top of this email about separating those
two use cases. sorry for the confusion).

> I think the logic for the latter is: […]

I have it as: we send a PCKG INV when this transaction’s feerate is above
the fee filter, but one or more of its parents don’t. I don’t think using
ancestor feerate is better.
See this counterexample:
https://raw.githubusercontent.com/glozow/bitcoin-notes/master/mempool_garden/abc_1parent_2kids.png
A (0fee) has 2 kids, B (3sat/vB) and C (20sat/vB), everything’s the same
vsize. Let’s say the fee filter is 3sat/vB.
If we do it based on ancestor feerate, we won’t send B. But B is actually
fine; C is paying for A.

> Are "getpckgtxns" / "pcktxns" really limited to packages, or are they
> just a general way to request a batch of transactions?

> Maybe call those messages "getbatchtxns" and "batchtxns" and allow them to
> be used more generally, potentially in ways unrelated to packages/cpfp?

Indeed, it’s a general way to request a batch of transactions. I’ll
highlight that it is “all or nothing,” i.e. if the sender is missing any of
them, they’ll just send a notfound.
The idea here was to avoid downloading any transactions that can’t be
validated right away. With packages, this makes sense, because there are
dependency relationships. But if you’re requesting multiple unrelated
transactions, for example, it’s unnecessary. You might end up with even
more transaction data that’s just sitting around waiting to be validated.

> The "only be sent if both peers agreed to do package relay" rule could
> simply be dropped, I think.

Re: [bitcoin-dev] A Calculus of Covenants

[Keagan McClelland via bitcoin-dev]

> One must also analyze all the covenants that one *could* author using a
primitive

So as I've been contemplating this more, I'm realizing that a calculus of
covenants themselves may not make as much sense as a broader calculus of
Bitcoin transactions as a whole. I think this comment that you made in your
followup solidified that position. If you have to analyze it in the context
of all of the other opcodes that could potentially interact with it, you
don't really have a closed algebra that you can really try to understand
and evaluate. I'm still ruminating on what such a calculus would be, but it
also makes me more convinced that Simplicity gets a lot right here. That
said, there is probably an opportunity for a significantly more domain
specific set of primitives than what simplicity offers that would allow you
similar practical use cases but with a much more high level analysis.

The way I think about this now is that most of the primitives in the
Bitcoin script VM right now are constraints on the witness, you have a
couple of opcodes that are constraints on the chain state, and then
covenants are really a constraint on the body of the transaction that
spends an input. I think most of the time we imagine covenants of output
constraints but you can also imagine a hypothetical covenant that says,
"this input may not be spent alongside any other inputs". This is still a
constraint on the spending transaction despite the fact that it mentions
nothing of the outputs, and I would still broadly think of this as a
covenant. I think depending on how you define "family" and "state
transition" it would tolerate this distinction. However, it definitely
complicates the question of things like unrollability. Is a covenant that
permits any output(s) but the input must be spent alone unrollable? Does
the concept unrollable even make any sense when you aren't constraining the
outputs?

These thoughts aren't completely baked but I figured I'd jot them down
while I was thinking about it.

Keagan

On Tue, Apr 12, 2022 at 9:04 AM Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> note of clarification:
>
> this is from the perspective of a developer trying to build infrastructure
> for covenants. from the perspective of bitcoin consensus, a covenant
> enforcing primitve would be something like OP_TLUV and less so it's use in
> conjunction with other opcodes, e.g. OP_AMOUNT.
>
> One must also analyze all the covenants that one *could* author using a
> primitive, in some sense, to demonstrate that our understanding is
> sufficient. As a trivial example, you could use
> OP_DELETE_BITCOIN_ENTIRELY_IF_KNOWS_PREIMAGE_TO_X_OR_TLUV and just because
> you could use it safely for TLUV would not mean we should add that opcode
> if there's some way of using it negatively.
>
> Cheers,
>
> Jeremy
> --
> @JeremyRubin 
>
>
> On Tue, Apr 12, 2022 at 10:33 AM Jeremy Rubin 
> wrote:
>
>> Sharing below a framework for thinking about covenants. It is most useful
>> for modeling local covenants, that is, covenants where only one coin must
>> be examined, and not multi-coin covenants whereby you could have issues
>> with protocol forking requiring a more powerful stateful prover. It's the
>> model I use in Sapio.
>>
>> I define a covenant primitive as follows:
>>
>> 1) A set of sets of transaction intents (a *family)*, potentially
>> recursive or co-recursive (e.g., the types of state transitions that can be
>> generated). These intents can also be represented by a language that
>> generates the transactions, rather than the literal transactions
>> themselves. We do the family rather than just sets at this level because to
>> instantiate a covenant we must pick a member of the family to use.
>> 2) A verifier generator function that generates a function that accepts
>> an intent that is any element of one member of the family of intents and a
>> proof for it and rejects others.
>> 3) A prover generator function that generates a function that takes an
>> intent that is any element of one member of the family and some extra data
>> and returns either a new prover function, a finished proof, or a rejection
>> (if not a valid intent).
>> 4) A set of proofs that the Prover, Verifier, and a set of intents are
>> "impedance matched", that is, all statements the prover can prove and all
>> statements the verifier can verify are one-to-one and onto (or something
>> similar), and that this also is one-to-one and onto with one element of the
>> intents (a set of transactions) and no other.
>> 5) A set of assumptions under which the covenant is verified (e.g., a
>> multi-sig covenant with at least 1-n honesty, a multisig covenant with any
>> 3-n honesty required, Sha256 collision resistance, DLog Hardness, a SGX
>> module being correct).
>>
>> To instantiate a covenant, the user would pick a particular element of
>> the set of sets of transaction intents. For example, in TLUV payment pool,
>> it 

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[ZmnSCPxj via bitcoin-dev]

Good morning e,

> Good evening ZmnSCPxj,
>
> Sorry for the long delay...

Thank you very much for responding.

>
> > Good morning e,
> >
> > > Good evening ZmnSCPxj,
> > >
> > > For the sake of simplicity, I'll use the terms lender (Landlord), borrower
> > > (Lessor), interest (X), principal (Y), period (N) and maturity (height 
> > > after N).
> > >
> > > The lender in your scenario "provides use" of the principal, and is paid
> > > interest in exchange. This is of course the nature of lending, as a period
> > > without one's capital incurs an opportunity cost that must be offset (by
> > > interest).
> > >
> > > The borrower's "use" of the principal is what is being overlooked. To
> > > generate income from capital one must produce something and sell it.
> > > Production requires both capital and time. Borrowing the principle for the
> > > period allows the borrower to produce goods, sell them, and return the
> > > "profit" as interest to the lender. Use implies that the borrower is 
> > > spending
> > > the principle - trading it with others. Eventually any number of others 
> > > end up
> > > holding the principle. At maturity, the coin is returned to the lender (by
> > > covenant). At that point, all people the borrower traded with are bag 
> > > holders.
> > > Knowledge of this scam results in an imputed net present zero value for 
> > > the
> > > borrowed principal.
> >
> > But in this scheme, the principal is not being used as money, but as a 
> > billboard
> > for an advertisement.
> >
> > Thus, the bitcoins are not being used as money due to the use of the 
> > fidelity
> > bond to back a "you can totally trust me I am not a bot!!" assertion.
> > This is not the same as your scenario --- the funds are never transferred,
> > instead, a different use of the locked funds is invented.
> >
> > As a better analogy: I am borrowing a piece of gold, smelting it down to 
> > make
> > a nice shiny advertisement "I am totally not a bot!!", then at the end of 
> > the
> > lease period, re-smelting it back and returning to you the same gold piece
> > (with the exact same atoms constituting it), plus an interest from my 
> > business,
> > which gained customers because of the shiny gold advertisement claiming "I
> > am totally not a bot!!".
> >
> > That you use the same piece of gold for money does not preclude me using
> > the gold for something else of economic value, like making a nice shiny
> > advertisement, so I think your analysis fails there.
> > Otherwise, your analysis is on point, but analyses something else entirely.
>
>
> Ok, so you are suggesting the renting of someone else's proof of "burn" 
> (opportunity cost) to prove your necessary expense - the financial equivalent 
> of your own burn. Reading through the thread, it looks like you are 
> suggesting this as a way the cost of the burn might be diluted across 
> multiple uses, based on the obscuration of the identity. And therefore 
> identity (or at least global uniqueness) enters the equation. Sounds like a 
> reasonable concern to me.
>
> It appears that the term "fidelity bond" is generally accepted, though I find 
> this an unnecessarily misleading analogy. A bond is a loan (capital at risk), 
> and a fidelity bond is also capital at risk (to provide assurance of some 
> behavior). Proof of burn/work, such as Hash Cash (and Bitcoin), is merely 
> demonstration of a prior expense. But in those cases, the expense is provably 
> associated. As you have pointed out, if the burn is not associated with the 
> specific use, it can be reused, diluting the demonstrated expense to an 
> unprovable degree.

Indeed, that is why defiads used the term "advertisement" and not "fidelity 
bond".
One could say that defiads was a much-too-ambitious precursor of this proposed 
scheme.

> I can see how you come to refer to selling the PoB as "lending" it, because 
> the covenant on the underlying coin is time constrained. But nothing is 
> actually lent here. The "advertisement" created by the covenant (and its 
> presumed exclusivity) is sold. This is also entirely consistent with the idea 
> that a loan implies capital at risk. While this is nothing more than a 
> terminology nit, the use of "fidelity bond" and the subsequent description of 
> "renting" (the fidelity bond) both led me down another path (Tamas' proposal 
> for risk free lending under covenant, which we discussed here years ago).

Yes, that is why Tamas switched to defiads, as I had convinced him that it 
would be similar enough without actually being a covenant scam like you 
described.

> In any case, I tend to agree with your other posts on the subject. For the 
> burn to be provably non-dilutable it must be a cost provably associated to 
> the scenario which relies upon the cost. This provides the global uniqueness 
> constraint (under cryptographic assumptions of difficulty).

Indeed.
I suspect the only reason it is not *yet* a problem with existing JoinMarket 
and Teleport is simply