📅 Original date posted:2022-06-21
📝 Original message:> The PoW security of Bitcoin benefits all Bitcoin users, proportional to
the
value of BTC they hold; if Bitcoin blocks aren't reliably created the value
of
*all* BTC goes down. It doesn't make sense for the entire cost of that
security
to be paid for on a per-tx basis. And there's a high chance paying for it
on a
per-tx basis won't work anyway due to lack of consistent demand.
FWIW I prefer the demurrage route. Having something with finite supply as a
means of measuring economic activity is unprecedented and I believe deeply
important. I'm sympathetic to the argument that the security of the chain
should not be solely the responsibility of transactors. We realize the
value of money on receipt, hold *and* spend and it would be appropriate for
there to be a balance of fees to that effect. While inflation may be
simpler to implement (just chop off the last few halvings), I think it
would be superior (on the assumption that such a hodl tax was necessary) to
keep the supply fixed and have people's utxo balances decay, at least at
the level of the UX.
But also none of this should be reasons we don't improve Bitcoin's value
(and therefore demand)
Keagan
On Mon, Jun 20, 2022 at 2:42 AM Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> On Sun, Jun 19, 2022 at 2:04 PM Manuel Costa via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> if we start seeing issues with block rewards being too low to maintain
>> acceptable security, we're going to have multiple solutions being
>> implemented for it, and definitely a hard fork to indefinitely maintain
>> some degree of block subsidy
>>
>
> if we failed to first try increasing block demand with advanced
> transaction support, it would seem like we were just throwing money and
> growth away to support one narrative (simplicty of function), while
> destroying another (finite supply)
>
> if stuff like covenant support and mweb gets us higher fees, with stuff
> like on-chain mixing protocols, vaults, and higher utility, it might be
> more than enough to sustain bitcoin on fees alone forever
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220621/3685c7d8/attachment.html>;
Keagan McClelland [ARCHIVE] /
npub1f2…ms289
2023-06-07 23:10:07
in reply to nevent1q…ypkm
Author Public Key
npub1f2nxequ09nz44775vv6lkffq2plzqvrqramnk29eddmwcc9z7jys8ms289Published at
2023-06-07 23:10:07Event JSON
{
"id": "298e2ef023fb7ba36054d582142a955db5351ddc14def857516bb294cbcdae4f",
"pubkey": "4aa66c838f2cc55afbd46335fb2520507e2030601f773b28b96b76ec60a2f489",
"created_at": 1686179407,
"kind": 1,
"tags": [
[
"e",
"5551b13e7da6b3f09c0d99802a19f9d792bb6230bb9f7b81382a9edb07abfa59",
"",
"root"
],
[
"e",
"a8e95e6350c103ee391dc5d9c6f485d305fc56600e90545efb2acfd83e532184",
"",
"reply"
],
[
"p",
"22944ce1e29904e3826d25013a614e4665693ec514003efacc1b7586e8e5d0aa"
]
],
"content": "📅 Original date posted:2022-06-21\n📝 Original message:\u003e The PoW security of Bitcoin benefits all Bitcoin users, proportional to\nthe\nvalue of BTC they hold; if Bitcoin blocks aren't reliably created the value\nof\n*all* BTC goes down. It doesn't make sense for the entire cost of that\nsecurity\nto be paid for on a per-tx basis. And there's a high chance paying for it\non a\nper-tx basis won't work anyway due to lack of consistent demand.\n\nFWIW I prefer the demurrage route. Having something with finite supply as a\nmeans of measuring economic activity is unprecedented and I believe deeply\nimportant. I'm sympathetic to the argument that the security of the chain\nshould not be solely the responsibility of transactors. We realize the\nvalue of money on receipt, hold *and* spend and it would be appropriate for\nthere to be a balance of fees to that effect. While inflation may be\nsimpler to implement (just chop off the last few halvings), I think it\nwould be superior (on the assumption that such a hodl tax was necessary) to\nkeep the supply fixed and have people's utxo balances decay, at least at\nthe level of the UX.\n\nBut also none of this should be reasons we don't improve Bitcoin's value\n(and therefore demand)\n\nKeagan\n\nOn Mon, Jun 20, 2022 at 2:42 AM Erik Aronesty via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\n\u003e\n\u003e On Sun, Jun 19, 2022 at 2:04 PM Manuel Costa via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e if we start seeing issues with block rewards being too low to maintain\n\u003e\u003e acceptable security, we're going to have multiple solutions being\n\u003e\u003e implemented for it, and definitely a hard fork to indefinitely maintain\n\u003e\u003e some degree of block subsidy\n\u003e\u003e\n\u003e\n\u003e if we failed to first try increasing block demand with advanced\n\u003e transaction support, it would seem like we were just throwing money and\n\u003e growth away to support one narrative (simplicty of function), while\n\u003e destroying another (finite supply)\n\u003e\n\u003e if stuff like covenant support and mweb gets us higher fees, with stuff\n\u003e like on-chain mixing protocols, vaults, and higher utility, it might be\n\u003e more than enough to sustain bitcoin on fees alone forever\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220621/3685c7d8/attachment.html\u003e",
"sig": "50f63291e243b4bf4d0d9ce6d148df5c5781d98919425618a050d26ffbdf8d42e56d945cb8e27f956bba2a57f0adf4f444fdc3813cfabbae009f510d372f74d6"
}