public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Pieter Wuille <bitcoin-dev@wuille•net>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Cc: lightning-dev <lightning-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
Date: Fri, 08 Oct 2021 22:47:11 +0000	[thread overview]
Message-ID: <R4jC1XUMFSWW9kRbnQJokALtkpD3PMGtgcITeUbKsln6lNEZqxzM4ax9QquWP39jwQLXXPfojeEqI5wkuYCsqbepR07r3CAyV70VjNQYzLc=@protonmail.com> (raw)
In-Reply-To: <MkPutJpff5rqUxXFQrEyHZl6Iz0DfrJU_-BQD-y0El65GQFnj7igVfmWU79fPCtiFztUYl4ofzrqeaN0HFMB45YPErY9rYY7_h1XkuTMfvc=@wuille.net>

Good morning Pieter,

> Indeed - UTXO set size is an externality that unfortunately Bitcoin's consensus rules fail to account
> for. Having a relay policy that avoids at the very least economically irrational behavior makes
> perfect sense to me.
>
> It's also not obvious how consensus rules could deal with this, as you don't want consensus rules
> with hardcoded prices/feerates. There are possibilities with designs like transactions getting
> a size/weight bonus/penalty, but that's both very hardforky, and hard to get right without
> introducing bad incentives.

Why is a +weight malus *very* hardforky?

Suppose a new version of a node adds, say, +20 sipa per output of a transaction (in order to economically discourage the creation of additional outputs in the UTXO set).
Older versions would see the block as being lower weight than usual, but as the consensus rule is "smaller than 4Msipa" they should still accept any block acceptable to newer versions.

It seems to me that only a -weight bonus is hardforky (but then xref SegWit and its -weight bonus on inputs).

I suppose the effect is primarily felt on mining nodes?
Miners might refuse to activate such a fork, as they would see fewer transactions per block on average?

Regards,
ZmnSCPxj



  parent reply	other threads:[~2021-10-08 22:47 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-08 18:52 [bitcoin-dev] " Jeremy
2021-08-08 21:14 ` Matt Corallo
2021-08-08 21:41   ` Oleg Andreev
2021-08-08 21:51 ` [bitcoin-dev] [Lightning-dev] " David A. Harding
2021-08-08 22:46   ` Jeremy
2021-08-08 23:07   ` Jeremy
2021-09-30 22:07   ` Pieter Wuille
2021-10-01 13:40     ` Erik Aronesty
2021-10-07  4:52       ` ZmnSCPxj
2021-10-07  8:17         ` LORD HIS EXCELLENCY JAMES HRMH
2021-10-07  8:34           ` LORD HIS EXCELLENCY JAMES HRMH
2021-10-07 10:35             ` LORD HIS EXCELLENCY JAMES HRMH
2021-10-07  9:13         ` shymaa arafat
2021-10-07 10:01           ` ZmnSCPxj
     [not found]             ` <CAM98U8kKud-7QoJKYd5o245o8vGeUD7YD2OnXF_QeKaO33dSTw@mail.gmail.com>
     [not found]               ` <MCYvJzqskIC56X-ylVCNgdaVk6SNnpCE6GgssXxK-znwwK4MoA41a2A-yNuCG8s99ll3h__YjCjBlP99A27Clbip-aYbF2ZwLpZ0SJT0j2U=@protonmail.com>
2021-10-08  7:44                 ` shymaa arafat
2021-10-08 10:38                   ` ZmnSCPxj
2021-10-08 22:47     ` ZmnSCPxj [this message]
2021-08-09 13:22 ` Antoine Riard
2021-08-10  0:30   ` Billy Tetrud
2021-08-10  5:04     ` Jeremy
2021-08-10  5:44       ` Billy Tetrud
2021-08-10 11:37         ` ZmnSCPxj
2021-08-10 18:39           ` Charlie Lee
2021-08-10  6:14   ` David A. Harding
2021-08-10 22:37     ` Antoine Riard
2021-08-11  0:46       ` ZmnSCPxj
2021-08-12 22:03       ` Anthony Towns
2021-08-20  4:51         ` Jeremy
2021-08-20  5:45           ` shymaa arafat
2021-08-21  3:10           ` ZmnSCPxj
2021-08-26 21:21             ` Billy Tetrud
2021-08-27  9:07               ` shymaa arafat
2021-08-30  3:31                 ` LORD HIS EXCELLENCY JAMES HRMH
2021-08-18 19:06 shymaa arafat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='R4jC1XUMFSWW9kRbnQJokALtkpD3PMGtgcITeUbKsln6lNEZqxzM4ax9QquWP39jwQLXXPfojeEqI5wkuYCsqbepR07r3CAyV70VjNQYzLc=@protonmail.com' \
    --to=zmnscpxj@protonmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=bitcoin-dev@wuille$(echo .)net \
    --cc=lightning-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox