Re: [bitcoin-dev] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

[Anthony Towns via bitcoin-dev]

On Mon, Jul 05, 2021 at 09:46:21AM -0400, Matt Corallo via bitcoin-dev wrote:
> More importantly, AJ's point here neuters anti-covanent arguments rather
> strongly.
>
> On 7/5/21 01:04, Anthony Towns via bitcoin-dev wrote:
> > In some sense multisig *alone* enables recursive covenants: a government
> > that wants to enforce KYC can require that funds be deposited into
> > a multisig of "2   2 CHECKMULTISIG", and that
> > "recipient" has gone through KYC. Once deposited to such an address,
> > the gov can refus to sign with gov_key unless the funds are being spent
> > to a new address that follows the same rules.

I couldn't remember where I'd heard this, but it looks like I came
across it via Andrew Poelstra's "CAT and Schnorr Tricks II" post [0]
(Feb 2021), in which he credits Ethan Heilman for originally coming up
with the analogy (in 2019, cf [1]).

[0] https://medium.com/blockstream/cat-and-schnorr-tricks-ii-2f6ede3d7bb5
[1] https://twitter.com/Ethan_Heilman/status/1194624166093369345

Cheers,
aj

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

[bitcoin-dev] BIP-119 CTV Meeting #3 Draft Agenda for Tuesday February 8th at 12:00 PT

[Jeremy Rubin via bitcoin-dev]

Bitcoin Developers,

The 3rd instance of the recurring meeting is scheduled for Tuesday February
8th at 12:00 PT in channel ##ctv-bip-review in libera.chat IRC server.

The meeting should take approximately 2 hours.

The topics proposed to be discussed are agendized below. Please review the
agenda in advance of the meeting to make the best use of everyone's time.

Please send me any feedback, proposed topic changes, additions, or
questions you would like to pre-register on the agenda.

I will send a reminder to this list with a finalized Agenda in advance of
the meeting.

Best,

Jeremy

- Bug Bounty Updates (10 Minutes)
- Non-Interactive Lightning Channels (20 minutes)
  + https://rubin.io/bitcoin/2021/12/11/advent-14/
  + https://utxos.org/uses/non-interactive-channels/
- CTV's "Dramatic" Improvement of DLCs (20 Minutes)
  + Summary: https://zensored.substack.com/p/supercharging-dlcs-with-ctv
  +
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html
  + https://rubin.io/bitcoin/2021/12/20/advent-23/
- PathCoin (15 Minutes)
  + Summary: A proposal of coins that can be transferred in an offline
manner by pre-compiling chains of transfers cleverly.
  + https://gist.github.com/AdamISZ/b462838cbc8cc06aae0c15610502e4da
  +
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019809.html
- OP_TXHASH (30 Minutes)
  + An alternative approach to OP_CTV + APO's functionality by programmable
tx hash opcode.
  + See discussion thread at:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
- Emulating CTV for Liquid (10 Minutes)
  +
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019851.html
- General Discussion (15 Minutes)

Best,

Jeremy




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

[bitcoin-dev] CTV Meeting #2 Summary & Minutes

[Jeremy Rubin via bitcoin-dev]

This meeting was held January 25th, 2022. The meeting logs are available
https://gnusha.org/ctv-bip-review/2022-01-25.log

Please review the agenda in conjunction with the notes:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019807.html

Feel free to make any corrections if I did not summarize accurately.

The next meeting is next Tuesday at 12:00 PT. I will attempt to circulate a
pre-meeting agenda draft shortly.

Best,

Jeremy

*Bug Bounty Update:*

   1. Basic Rules set, working to formalize the program.
   2. It turns out that 1 person allocating ~$10k is easy, a multi
   stakeholder organization requires more formality.
   3. 501c3 status / tax deducitbility available.
   4. See here for more details:
   
https://docs.google.com/document/d/1pN6YzQ6HlR8t_-ZZoEdTegt88w6gJzCkcA_a4IXpKAo/edit
   5. Rules still subject to change, but issues found under the current
   descriptions awarded in good faith by me/Ariel for now.



*Notes from Feedback Review:*

*Luke's Feedback:*

   1. Sentiment that activation / CTV should be discussed somewhat
   separately.
   2. Sentiment that having more clear cut use cases is good, no agreement
   about what venue / type of document those should be (no disagreement really
   either, just that BIPs might be too formal, but blog posts might not be
   formal enough).


*James' Feedback:*

   1. Sentiment that a minor slowdown isn't problematic, we've done it
   before for other precomputations.
   2. James was to spend a bit more time on benchmarking in a more modern
   segment of the chain (the range he used was slightly irrelevant given low
   segwit adoption period).
   3. *After meeting: James' shows updates for CTV don't cause any notable
   slowdown for current chain segments.*


*Peter's Feedback:*

   1. Denial-of-Service concerns seem largely addressed.
   2. Comment on tests was a result of reviewing outdated branch, not PR.
   3. Main feedback that "sticks" is wanting more use cases to be more clear

I've seen some reviews that almost run into a kind of paradox of choice and
> are turned off by all the different potential applications. This isn't
> necessarily a bad thing. As we've seen with Taproot and now even CTV with
> the DLC post, there are going to be use cases and standards nobody's
> thought of yet, but having them out there all at once can be difficult for
> some to digest



*Sapio*

   1. Sapio can be used today, without CTV.
   2. Main change with CTV is more "non-interactivity".
   3. Need for a more descriptive terms than "non-interactive", e.g.,
   "asynchronous non-blocking", "independently verifiable", "non-stallable".
   4. Composability is cool, but people aren't doing that much composable
   stuff anyways so it's probably under-appreciated.



*Vaults*

   1. Very strong positive sentiment for Vaults.
   2. CTV eliminates "toxic waste" from the setup of vaults with pre-signed
   txns / requirement for a RNG.
   3. CTV/Sapio composability makes vaults somewhat "BIP Resistant" because
   vaults could be customized heavily per user, depending on needs.
   4. CPFP for smart contracts is in not the best state, improving
   CPFP/Package relay important for these designs.
   5. The ability to *prove* vaults constructed correctly w/o toxic waste,
   e.g., 30 years later, is pretty important for high security uses (as
   opposed to assume w/ presigned).
   6. More flexible vaults (e.g., withdraw up to X amount per step v.s.
   fixed X per step) are desirable, but can be emulated by withdrawing X and
   sending it somewhere else (e.g. another vault) without major loss of
   security properties or network load -- more flexible vault covenants have
   greater space/validation costs v.s. simpler CTV ones.



*Congestion Control*

   1. Sentiments shared that no one really cares about this issue and it's
   bad marketing.
   2. Layer 2 to 1 Index "21i" which is how long for a L2 (sidechain,
   exchange, mining pools, etc) to clear all liabilities to end users (CTV
   improves this to 1 block, currently clearing out and Exchange could take
   weeks and also trigger "thundering herd" behaviors whereby if the expected
   time to withdraw becomes too long, you then also need to withdraw).
   3. Anecdotally, Exchanges seem less interested in congestion control,
   Mining Pools and Lightning Channel openers seem more into it.


Main Issues & Answers:

Q: wallet complexity?
A: Wallets largely already need to understand most of the logic for CTV,
should they be rational
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019756.html

Q: uses more space overall
A: Doesn't use more space than existing incentive compatible behavior on
how you might split up txns already, and even if it did, it's a small
constant factor more. See https://utxos.org/analysis/batching_sim/ for more
analysis.

Q: block space is cheap right now, why do we need this?
A: we do not want or expect blockspace to be cheap in the future, we should
plan for t

Re: [bitcoin-dev] non-default ports for automatic connections in Bitcoin P2P network

[Vasil Dimov via bitcoin-dev]

Prayank, thanks for taking the time to inform the wider community.

I just want to clarify to avoid confusion that this is about whether to
open automatic outgoing connections to a peer at addr:port if port is
not 8333. Right now, Bitcoin Core has a very very strong preference
towards peers that listen on port 8333. So, if one listens on !=8333
then he is practically not getting any incoming connections (from
Bitcoin Core).

See the PR for details and justifications:
https://github.com/bitcoin/bitcoin/pull/23542.

-- 
Vasil Dimov
gro.DSBeerF@dv
%
Diplomacy is the art of telling people to go to hell in such a way that
they ask for directions.
-- Winston Churchill


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

Re: [bitcoin-dev] Improving RBF Policy

[Anthony Towns via bitcoin-dev]

On Tue, Feb 01, 2022 at 10:30:12AM +0100, Bastien TEINTURIER via bitcoin-dev 
wrote:
> But do you agree that descendants only matter for DoS resistance then,
> not for miner incentives?

There's an edge case where you're replacing tx A with tx X, and X's fee
rate is higher than A's, but you'd be obsoleting descendent txs (B, C,
D...) and thus replacing them with unrelated txs (L, M, N...), and the
total feerate/fees of A+B+C+D... is nevertheless higher than X+L+M+N...

But I think that's probably unusual (transactions D and L are adjacent
in the mempool, that's why L is chosen for the block; but somehow
there's a big drop off in value somewhere between B/C/D and L/M/N),
and at least today, I don't think miners consider it essential to eke
out every possible sat in fee income.

(If, as per your example, you're actually replacing {A,B,C,D} with
{X,Y,Z,W} where X pays higher fees than A and the package in total pays
either the same or higher fees, that's certainly incentive compatible.
The tricky question is what happens when X arrives on its own and it
might be that no one ever sends a replacement for B,C,D)

> The two policies I proposed address miner incentives. I think they're
> insufficient to address DoS issues. But adding a 3rd policy to address
> DoS issues may be a good solution?

>>> 1. The transaction's ancestor absolute fees must be X% higher than the
>>> previous transaction's ancestor fees
>>> 2. The transaction's ancestor feerate must be Y% higher than the
>>> previous transaction's ancestor feerate

Absolute fees only matter if your backlog's feerate drops off. If you've
got 100MB of txs offering 5sat/vb, then exchanging 50kB at 5sat/vb for
1kB at 6sat/vb is still a win: your block gains 1000 sats in fees even
though your mempool loses 245,000 sats in fees.

But if your backlog's feerate does drop off, *and* that matters, then
I don't think you can ignore the impact of the descendent transactions
that you might not get a replacement for.

I think "Y% higher" rather than just "higher" is only useful for
rate-limiting, not incentive compatibility. (Though maybe it helps
stabilise a greedy algorithm in some cases?)

Cheers,
aj

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