[bitcoin-dev] Take 2: Removing the Dust Limit

[Jeremy via bitcoin-dev]

Bitcoin Devs (+cc lightning-dev),

Earlier this year I proposed allowing 0 value outputs and that was shot
down for various reasons, see
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019307.html

I think that there can be a simple carve out now that package relay is
being launched based on my research into covenants from 2017
https://rubin.io/public/pdfs/multi-txn-contracts.pdf.

Essentially, if we allow 0 value outputs BUT require as a matter of policy
(or consensus, but policy has major advantages) that the output be used as
an Intermediate Output (that is, in order for the transaction to be
creating it to be in the mempool it must be spent by another tx)  with the
additional rule that the parent must have a higher feerate after CPFP'ing
the parent than the parent alone we can both:

1) Allow 0 value outputs for things like Anchor Outputs (very good for not
getting your eltoo/Decker channels pinned by junk witness data using Anchor
Inputs, very good for not getting your channels drained by at-dust outputs)
2) Not allow 0 value utxos to proliferate long
3) It still being valid for a 0 value that somehow gets created to be spent
by the fee paying txn later

Just doing this as a mempool policy also has the benefits of not
introducing any new validation rules. Although in general the IUTXO concept
is very attractive, it complicates mempool :(

I understand this may also be really helpful for CTV based contracts (like
vault continuation hooks) as well as things like spacechains.

Such a rule -- if it's not clear -- presupposes a fully working package
relay system.

I believe that this addresses all the issues with allowing 0 value outputs
to be created for the narrow case of immediately spendable outputs.

Cheers,

Jeremy

p.s. why another post today? Thank Greg
https://twitter.com/JeremyRubin/status/1468390561417547780


--
@JeremyRubin 

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

Re: [bitcoin-dev] [Bitcoin Advent Calendar] What's Smart about Smart Contracts

[Jeremy via bitcoin-dev]

--
@JeremyRubin 


Hi!

On Tue, Dec 7, 2021 at 4:33 PM ZmnSCPxj  wrote:

> Good morning Jeremy,
>
> >
> > Here's the day 6 post: https://rubin.io/bitcoin/2021/12/03/advent-6/,
> the topic is why smart contracts (in extended form) may be a critical
> precursor to securing Bitcoin's future rather than something we should do
> after making the base layer more robust.
>
>
> *This* particular post seems to contain more polemic than actual content.
> This is the first post I read of the series, so maybe it is just a
> "breather" post between content posts?
>

The series in general is intended to be a bit more on the approachable side
than hardcore detail.



>
> In any case, given the subject line, it seems a waste not to discuss the
> actual "smart" in "smart" contract...
>
>
Yeah maybe a better title would be "The Case for Enhanced Functionality in
Bitcoin" -- it's not really about smart contracts per se, but the thing
that people are calling smart contracts in the broader community. This gets
down to prescriptive v.s. descriptive lingo and it's not really a debate I
care much for :)




> ## Why would a "Smart" contract be "Smart"?
>
> A "smart" contract is simply one that somehow self-enforces rather than
> requires a third party to enforce it.
> It is "smart" because its execution is done automatically.
>

There are no automatic executing smart contracts on any platform I'm aware
of. Bitcoin requires TX submission, same with Eth.

Enforcement and execution are different subjects.


> Consider the humble HTLC.
> **
> This is why the reticence of Bitcoin node operators to change the
> programming model is a welcome feature of the network.
> Any change to the programming model risks the introduction of bugs to the
> underlying virtual machine that the Bitcoin network presents to contract
> makers.
> And without that strong reticence, we risk utterly demolishing the basis
> of the "smart"ness of "smart" contracts --- if a "smart" contract cannot
> reliably be executed, it cannot self-enforce, and if it cannot
> self-enforce, it is no longer particularly "smart".
>

I don't think that anywhere in the post I advocated for playing fast and
loose with the rules to introduce any sort of unreliability.

What I'm saying is more akin to we can actually improve the "hardware" that
Bitcoin runs on to the extent that it actually does give us better ability
to adjudicate the transfers of value, and we should absolutely and
aggressively pursue that rather than keeping Bitcoin running on a set
mechanisms that are insufficient to reach the scale, privacy, self custody,
and decentralization goals we have.



> ## The N-of-N Rule
>
> What is a "contract", anyway?
>
> A "contract" is an agreement between two or more parties.
> You do not make a contract to yourself, since (we assume) you are
> completely a single unit (in practice, humans are internally divided into
> smaller compute modules with slightly different incentives (note: I did not
> get this information by *personally* dissecting the brains of any humans),
> hence the "we assume").



> Thus, a contract must by necessity require N participants


This is getting too pedantic about contracts. If you want to go there,
you're also missing "consideration".

Smart Contracts are really just programs. And you absolutely can enter
smart contracts with yourself solely, for example, Vaults (as covered in
day 10) are an example where you form a contract where you are intended to
be the only party.

You could make the claim that a vault is just an open contract between you
and some future would be hacker, but the intent is that the contract is
there to just safeguard you and those terms should mostly never execute. +
you usually want to define contract participants as not universally
quantified...

>
> This is of interest since in a reliability perspective, we often accept
> k-of-n.
> 
> But with an N-of-N, *you* are a participant and your input is necessary
> for the execution of the smart contract, thus you can be *personally*
> assured that the smart contract *will* be executed faithfully.
>
>
Yes I agree that N-N or K-N have uses -- Sapio is designed to work with
arbitrary thresholds in lieu of CTV/other covenant proposals which can be
used to emulate arbitrary business logic :)


However, the benefit of the contracts without that is non-interactivity of
sending. Having everyone online is a major obstacle for things like
decentralized coordination free mining pools (kinda, the whole coordination
free part). So if you just say "always do N-of-N" you basically lose the
entire thread of"smart contract capabilities improving the four pillars
(covered in earlier posts) which solidifies bitcoin's adjudication of
transfers of value.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] [Bitcoin Advent Calendar] Contract Primitives and Upgrades to Bitcoin

[Jeremy via bitcoin-dev]

This post is a mini high level SoK covering basic details of a number of
different new proposed primitives that folks might find useful -- I think
there's less to discuss around this post, since it is at a higher level and
the parts contained here could be discussed separately.

If something isn't on this list, it's an oversight by me and I'd love to
add it. The subjective criteria for inclusion/exclusion is if it seems
something the community is actively considering and is relatively well
researched.

Post here: https://rubin.io/bitcoin/2021/12/05/advent-8/

best,

Jeremy

(sorry it's out of order sent from the wrong email so it bounced, this is
day 8)

--
@JeremyRubin 

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

Re: [bitcoin-dev] [Bitcoin Advent Calendar] What's Smart about Smart Contracts

[ZmnSCPxj via bitcoin-dev]

Good morning Jeremy,

>
> Here's the day 6 post: https://rubin.io/bitcoin/2021/12/03/advent-6/, the 
> topic is why smart contracts (in extended form) may be a critical precursor 
> to securing Bitcoin's future rather than something we should do after making 
> the base layer more robust.


*This* particular post seems to contain more polemic than actual content.
This is the first post I read of the series, so maybe it is just a "breather" 
post between content posts?

In any case, given the subject line, it seems a waste not to discuss the actual 
"smart" in "smart" contract...

## Why would a "Smart" contract be "Smart"?

A "smart" contract is simply one that somehow self-enforces rather than 
requires a third party to enforce it.
It is "smart" because its execution is done automatically.

Consider the humble HTLC.
It is simply a contract which says:

* If B can provide the preimage for this hash H, it gets the money from A.
* If the time L arrives without B claiming this fund, A gets its money back.

Why would an HTLC self-enforce?
Why would a simple paper contract with the above wording, signed and notarized, 
be insufficient?

An HTLC self-enforces because given the Bitcoin network, it is not possible to 
violate and transfer the funds outside of the HTLC specification.
Whereas a paper contract can be mere ink on a page, if sufficient firepower is 
directed at the people (judges, lawyers, etc.) that would ensure its faithful 
execution.
You puny humans are notoriously squishy and easily destroyed.

But we must warn as well that the Bitcoin network is *also* run by people.
Thus, a "smart" contract is only "smart" to a degree, and that degree is 
dependent on how easily it is for the "justice system" that enforces the 
contract to be subverted.
After all, a "smart" contract is software, and software must run on some 
hardware in order to execute.

Thus, even existing paper contracts are "smart" to a degree, too.
It is simply that the hardware they run on top of --- a bunch of puny humans 
--- is far less reliable than cold silicon (so upgrade your compute substrate 
already, puny humans!).
Our hope with the Bitcoin experiment is that we might actually be able to make 
it much harder to subvert contracts running on the Bitcoin network.

It is that difficulty of subversion which determines the "smart"ness of a smart 
contract.
Bitcoin is effectively a massive RAID1 on several dozen thousands of redundant 
compute hardware, ensuring that the execution of every contract is faithful to 
the Bitcoin SCRIPT programming model.

This is why the reticence of Bitcoin node operators to change the programming 
model is a welcome feature of the network.
Any change to the programming model risks the introduction of bugs to the 
underlying virtual machine that the Bitcoin network presents to contract makers.
And without that strong reticence, we risk utterly demolishing the basis of the 
"smart"ness of "smart" contracts --- if a "smart" contract cannot reliably be 
executed, it cannot self-enforce, and if it cannot self-enforce, it is no 
longer particularly "smart".

## The N-of-N Rule

What is a "contract", anyway?

A "contract" is an agreement between two or more parties.
You do not make a contract to yourself, since (we assume) you are completely a 
single unit (in practice, humans are internally divided into smaller compute 
modules with slightly different incentives (note: I did not get this 
information by *personally* dissecting the brains of any humans), hence the "we 
assume").

Thus, a contract must by necessity require N participants.

This is of interest since in a reliability perspective, we often accept k-of-n.
For example, we might run a computation on three different pieces of hardware, 
and if only one diverges, we accept the result of the other two as true and the 
diverging hardware as faulty.

However, the above 2-of-3 example has a hidden assumption: that all three 
pieces of hardware are actually owned and operated by a single entity.

A contract has N participants, and is not governed by a single entity.
Thus, it cannot use k-of-n replication.

Contracts require N-of-N replication.
In Bitcoin terms, that is what we mean by "consensus" --- that all Bitcoin 
network participants can agree that some transfer is "valid".

Similarly, L2 layers, to be able to host properly "smart" contracts, require 
N-of-N agreement.
For example, a Lightning Network channel can properly host "smart" HTLCs, as 
the channel is controlled via 2-of-2 agreement.

Lesser L2 layers which support k-of-n thus have degraded "smartness", as a 
quorum of k participants can evict the n-k and deny the execution of the smart 
contract.
But with an N-of-N, *you* are a participant and your input is necessary for the 
execution of the smart contract, thus you can be *personally* assured that the 
smart contract *will* be executed faithfully.

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list

[bitcoin-dev] [Bitcoin Advent Calendar] Vaults

[Jeremy via bitcoin-dev]

Last one for today -- sorry for the overload, I had meant to post as the
series kicked off...

This post covers building various vaults/better cold storage using sapio
https://rubin.io/bitcoin/2021/12/07/advent-10/.

In an earlier post I motivated why self-custody is so critical (see
https://rubin.io/bitcoin/2021/11/30/advent-3/); this post demonstrates how
Sapio + CTV can dramatically enhance what users can do.

Cheers, you'll see me in the inbox tomorrow,

Jeremy

--
@JeremyRubin 

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

[bitcoin-dev] [Bitcoin Advent Calendar] Sapio Primer

[Jeremy via bitcoin-dev]

This post covers a basic intro to Sapio and links to more complete docs.
https://rubin.io/bitcoin/2021/12/06/advent-9/

I've previously shared Sapio on this list, and there's been a lot of
progress since then! I think Sapio is a fantastic system to express Bitcoin
ideas in, even if you don't want to use it for your production
implementation. Most of the future posts in the series will make heavy use
of Sapio so it's worth getting comfortable with, at least for reading.

Cheers,

Jeremy

--
@JeremyRubin 

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

[bitcoin-dev] [Bitcoin Advent Calendar] Review of Smart Contract Concepts

[Jeremy via bitcoin-dev]

This post covers some high-level smart contract concepts that different
opcodes or proposals could have (or not).

https://rubin.io/bitcoin/2021/12/04/advent-7/

Interested to hear about other properties that you think are relevant!

Best,

Jeremy

--
@JeremyRubin 

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

[bitcoin-dev] [Bitcoin Advent Calendar] What's Smart about Smart Contracts

[Jeremy via bitcoin-dev]

Hi!

Over the next month I'm doing a one-a-day blog post series till Christmas,
and I think some of the posts might be appropriate for discussion here.

Unfortunately I forgot to start the calendar series syndicated here too...
The first few posts are less bitcoin development related and philosophical,
so I think we could skip them and start around Day 6 and I'll post the rest
up to Day 10 here today (and do every day starting tomorrow). You can see
an archive of all posts at https://rubin.io/archive/. Every post will have
[Bitcoin Advent Calendar] if you wish to filter it :(.

-

Here's the day 6 post: https://rubin.io/bitcoin/2021/12/03/advent-6/, the
topic is why smart contracts (in extended form) may be a critical precursor
to securing Bitcoin's future rather than something we should do after
making the base layer more robust.

Cheers,

Jeremy Rubin

--
@JeremyRubin 

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

Re: [bitcoin-dev] A fee-bumping model

[Gloria Zhao via bitcoin-dev]

Hi Darosior and Ariard,

Thank you for your work looking into fee-bumping so thoroughly, and for
sharing your results. I agree about fee-bumping's importance in contract
security and feel that it's often under-prioritized. In general, what
you've described in this post, to me, is strong motivation for some of the
proposed changes to RBF we've been discussing. Mostly, I have some
questions.

> The part of Revault we are interested in for this study is the delegation
process, and more
> specifically the application of spending policies by network monitors
(watchtowers).

I'd like to better understand how fee-bumping would be used, i.e. how the
watchtower model works:
- Do all of the vault parties both deposit to the vault and a refill/fee to
the watchtower, is there a reward the watchtower collects for a successful
Cancel, or something else? (Apologies if there's a thorough explanation
somewhere that I haven't already seen).
- Do we expect watchtowers tracking multiple vaults to be batching multiple
Cancel transaction fee-bumps?
- Do we expect vault users to be using multiple watchtowers for a better
trust model? If so, and we're expecting batched fee-bumps, won't those
conflict?

> For Revault we can afford to introduce malleability in the Cancel
transaction since there is no
> second-stage transaction depending on its txid. Therefore it is
pre-signed with ANYONECANPAY. We
> can't use ANYONECANPAY|SINGLE since it would open a pinning vector [3].
Note how we can't leverage
> the carve out rule, and neither can any other more-than-two-parties
contract.

We've already talked about this offline, but I'd like to point out here
that even transactions signed with ANYONECANPAY|ALL can be pinned by RBF
unless we add an ancestor score rule. [0], [1] (numbers are inaccurate,
Cancel Tx feerates wouldn't be that low, but just to illustrate what the
attack would look like)

[0]:
https://user-images.githubusercontent.com/25183001/135104603-9e775062-5c8d-4d55-9bc9-6e9db92cfe6d.png
[1]:
https://user-images.githubusercontent.com/25183001/145044333-2f85da4a-af71-44a1-bc21-30c388713a0d.png

> can't use ANYONECANPAY|SINGLE since it would open a pinning vector [3].
Note how we can't leverage
> the carve out rule, and neither can any other more-than-two-parties
contract.

Well stated about CPFP carve out. I suppose the generalization is that
allowing n extra ancestorcount=2 descendants to a transaction means it can
help contracts with <=n+1 parties (more accurately, outputs)? I wonder if
it's possible to devise a different approach for limiting
ancestors/descendants, e.g. by height/width/branching factor of the family
instead of count... :shrug:

> You could keep a single large UTxO and peel it as you need to sponsor
transactions. But this means
> that you need to create a coin of a specific value according to your need
at the current feerate
> estimation, hope to have it confirmed in a few blocks (at least for now!
[5]), and hope that the
> value won't be obsolete by the time it confirmed.

IIUC, a Cancel transaction can be generalized as a 1-in-1-out where the
input is presigned with counterparties, SIGHASH_ANYONECANPAY. The fan-out
UTXO pool approach is a clever solution. I also think this smells like a
case where improving lower-level RBF rules is more appropriate than
requiring applications to write workarounds and generate extra
transactions. Seeing that the BIP125#2 (no new unconfirmed inputs)
restriction really hurts in this case, if that rule were removed, would you
be able to simply keep the 1 big UTXO per vault and cut out the exact
nValue you need to fee-bump Cancel transactions? Would that feel less like
"burning" for the sake of fee-bumping?

> First of all, when to fee-bump? At fixed time intervals? At each block
connection? It sounds like,
> given a large enough timelock, you could try to greed by "trying your
luck" at a lower feerate and
> only re-bumping every N blocks. You would then start aggressively bumping
at every block after M
> blocks have passed.

I'm wondering if you also considered other questions like:
- Should a fee-bumping strategy be dependent upon the rate of incoming
transactions? To me, it seems like the two components are (1) what's in the
mempool and (2) what's going to trickle into the mempool between now and
the target block. The first component is best-effort keeping
incentive-compatible mempool; historical data and crystal ball look like
the only options for incorporating the 2nd component.
- Should the fee-bumping strategy depend on how close you are to your
timelock expiry? (though this seems like a potential privacy leak, and the
game theory could get weird as you mentioned).
- As long as you have a good fee estimator (i.e. given a current mempool,
can get an accurate feerate given a % probability of getting into target
block n), is there any reason to devise a fee-bumping strategy beyond
picking a time interval?

It would be interesting to see stats on the spread of feerates in