📅 Original date posted:2022-06-19
📝 Original message:On Sun, Jun 12, 2022 at 07:16:49PM +0000, alicexbt wrote:
> Hi Peter,
>
> > Only because the block reward goes away. If it was made to continue
> > indefinitely - most likely with an inflation hard fork - demand for block space
> > would not be critical to Bitcoin's security.
>
>
> I am not completely against your proposal although 100% sure this will not have "consensus" to be implemented. I think if bitcoin doesn't have enough demand for block space, it should die. I will be sad if bitcoin doesn't exist but it should be a lesson for all the people opposing soft forks based on drama and politics instead of technical review.
>
> I don't see anything wrong with users paying 100x fees for opening and closing LN channels.
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.
It would be extremely unfortunate if one of the very few decentralized ways to
store value died simply because we couldn't find a way to pay to keep it
secure.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220619/925b89c6/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-07 23:10:05
in reply to nevent1q…gn8x
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Seen on
wss://relay.noswhere.comPublished at
2023-06-07 23:10:05Event JSON
{
"id": "f5404546dd4351f3119c0cf3e040c2fef45336a8c7d5d2f8402e5fab8eacdd37",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686179405,
"kind": 1,
"tags": [
[
"e",
"5551b13e7da6b3f09c0d99802a19f9d792bb6230bb9f7b81382a9edb07abfa59",
"",
"root"
],
[
"e",
"017d230fe6fc856ac82209646105382108bca4fea95e1ae4602c9679297a4620",
"",
"reply"
],
[
"p",
"745e2723e72d7ded3f0dd293d710b706cd302ab8476983c292d4bdb7f9c5d366"
]
],
"content": "📅 Original date posted:2022-06-19\n📝 Original message:On Sun, Jun 12, 2022 at 07:16:49PM +0000, alicexbt wrote:\n\u003e Hi Peter,\n\u003e \n\u003e \u003e Only because the block reward goes away. If it was made to continue\n\u003e \u003e indefinitely - most likely with an inflation hard fork - demand for block space\n\u003e \u003e would not be critical to Bitcoin's security.\n\u003e \n\u003e \n\u003e I am not completely against your proposal although 100% sure this will not have \"consensus\" to be implemented. I think if bitcoin doesn't have enough demand for block space, it should die. I will be sad if bitcoin doesn't exist but it should be a lesson for all the people opposing soft forks based on drama and politics instead of technical review.\n\u003e \n\u003e I don't see anything wrong with users paying 100x fees for opening and closing LN channels.\n\nThe PoW security of Bitcoin benefits all Bitcoin users, proportional to the\nvalue of BTC they hold; if Bitcoin blocks aren't reliably created the value of\n*all* BTC goes down. It doesn't make sense for the entire cost of that security\nto be paid for on a per-tx basis. And there's a high chance paying for it on a\nper-tx basis won't work anyway due to lack of consistent demand.\n\nIt would be extremely unfortunate if one of the very few decentralized ways to\nstore value died simply because we couldn't find a way to pay to keep it\nsecure.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 488 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220619/925b89c6/attachment.sig\u003e",
"sig": "9cb455628e876d40430fdc91d7316d2643c6df41bea3483bbcb44ea9b504493a2dca7206150a0a67026d4a6a57c66a7391433d95611114cfdd9971c346d512a2"
}