📅 Original date posted:2015-05-13
📝 Original message:Conservative is a relative term. Dropping transactions in a way that is
unpredictable to the sender sounds incredibly drastic to me. I'm suggesting
increasing the blocksize, drastic as it is, is the more conservative
choice. I would recommend that the fork take effect when some specific
large supermajority of the pervious 1000 blocks indicate they have
upgraded, as a safer alternative to a simple flag date, but I'm sure I
wouldn't have to point out that option to people here.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Wed, May 13, 2015 at 5:58 PM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
> On Wed, May 13, 2015 at 5:48 PM, Aaron Voisine <voisine at gmail.com> wrote:
>
>> We have $3billion plus of value in this system to defend. The safe,
>> conservative course is to increase the block size. Miners already have an
>> incentive to find ways to encourage higher fees and we can help them with
>> standard recommended propagation rules and hybrid priority/fee transaction
>> selection for blocks that increases confirmation delays for low fee
>> transactions.
>>
>
> You may find that the most economical solution, but I can't understand how
> you can call it conservative.
>
> Suggesting a hard fork is betting the survival of the entire ecosystem on
> the bet that everyone will agree with and upgrade to new suggested software
> before a flag date.
>
> --
> Pieter
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150513/f4f8a27c/attachment.html>;
Aaron Voisine [ARCHIVE] /
npub18g…knkzl
2023-06-07 15:34:46
in reply to nevent1q…52j7
Author Public Key
npub18gjvug29c4yg46lmplq38e75gg6wn5mn8taytckcsr4jt8p74h3s5knkzlPublished at
2023-06-07 15:34:46Event JSON
{
"id": "7c6e2fb933bc9feb59b2e6e005d83299c3f875bf2340444a448aad0f1c1d03d4",
"pubkey": "3a24ce2145c5488aebfb0fc113e7d44234e9d3733afa45e2d880eb259c3eade3",
"created_at": 1686152086,
"kind": 1,
"tags": [
[
"e",
"4fca8766cb3622944ad3338913b2eaab58533c317983b04a538d878303c3c989",
"",
"root"
],
[
"e",
"56d25de5f2a00506eb88d220e6f29a6ddbc622f7106340d8e077b170334eca35",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2015-05-13\n📝 Original message:Conservative is a relative term. Dropping transactions in a way that is\nunpredictable to the sender sounds incredibly drastic to me. I'm suggesting\nincreasing the blocksize, drastic as it is, is the more conservative\nchoice. I would recommend that the fork take effect when some specific\nlarge supermajority of the pervious 1000 blocks indicate they have\nupgraded, as a safer alternative to a simple flag date, but I'm sure I\nwouldn't have to point out that option to people here.\n\n\nAaron Voisine\nco-founder and CEO\nbreadwallet.com\n\nOn Wed, May 13, 2015 at 5:58 PM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003e\nwrote:\n\n\u003e On Wed, May 13, 2015 at 5:48 PM, Aaron Voisine \u003cvoisine at gmail.com\u003e wrote:\n\u003e\n\u003e\u003e We have $3billion plus of value in this system to defend. The safe,\n\u003e\u003e conservative course is to increase the block size. Miners already have an\n\u003e\u003e incentive to find ways to encourage higher fees and we can help them with\n\u003e\u003e standard recommended propagation rules and hybrid priority/fee transaction\n\u003e\u003e selection for blocks that increases confirmation delays for low fee\n\u003e\u003e transactions.\n\u003e\u003e\n\u003e\n\u003e You may find that the most economical solution, but I can't understand how\n\u003e you can call it conservative.\n\u003e\n\u003e Suggesting a hard fork is betting the survival of the entire ecosystem on\n\u003e the bet that everyone will agree with and upgrade to new suggested software\n\u003e before a flag date.\n\u003e\n\u003e --\n\u003e Pieter\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150513/f4f8a27c/attachment.html\u003e",
"sig": "69215f63f3f9fdb22119fcce87134759a5aed65ed063fa3f128d8b5a49c19dd0fdacdeda94b9945cc6f1e1da6317bce54690c3014769ad306dff79be06ceeda6"
}