📅 Original date posted:2015-06-15
📝 Original message:My understanding of this debate is that there are some people who want to
keep Bitcoin at 1MB block limit, and there are some who want to increase it.
I for one am curious to see how 1MB limited bitcoin evolves, and I believe
we can all have a chance to see this AND hard-fork bitcoin to remove the
block size restriction.
To remove the 1MB limit required a hard fork. This is not disputed. It's
what we do with the original (1MB limit) bitcoin that concerns me (and
other's I am sure).
What I would like to see is both being allowed to live. Harry Potter and
Voldermort! (Except neither are evil!)
The solution is to hard-fork and merge-mine. This way, both can live, and
mining power is not divided.
Dogecoin recently hardforked and this hardfork also involved switching to
merge-mining, so it's been done successfully.
So, simply, bitcoin as it is doesn't need to actually fork, but instead, at
a certain block size, a forked bitcoin with the blocksize lmit removed will
start to be merge-mined alongside bitcoin. Miners can be ready for this.
Wallets can be ready for this - in fact, for most wallets and merchants
they will possibly want to default to the bigger blocksize fork since this
caters for more transactions per block.
We still don't know how removing the block limit will pan out and what
other problems with scalability will arise in the future, so by preserving
the original bitcoin, we keep diversity, and people won't feel their
investments in bitcoin are being unnecessarily put at risk (as their
investments will stay in both the new and the old bitcoin).
The bitcoin core developers can implement a patch like the one recently
used for dogecoin, to allow the chain to fork at a set point, where at
which point, bitcoins will be split into the new and the old. Branding will
be an important issue here I think, so that there is as little confusion as
possible. I think this is a small price to pay in return for not killing
the original bitcoin (even if it's true that Satoshi did intend to remove
the 1MB limit at some point).
If I'm missing something obvious please let me know.
On Mon, Jun 15, 2015 at 1:50 PM, Mike Hearn <mike at plan99.net> wrote:
> The fact that using a centralized service is easier isn't a good reason
>> IMHO. It disregards the long-term, and introduces systemic risk.
>>
>
> Well sure, that's easy for you to say, but you have a salary :) Other
> developers may find the incremental benefits of decentralisation low vs
> adding additional features, for instance, and who is to say they are wrong?
>
>
>> But in cases where using a decentralized approach doesn't *add* anything,
>> I cannot reasonably promote it, and that's why I was against getutxos in
>> the P2P protocol.
>>
>
> It does add something though! It means, amongst other things, I can switch
> of all my servers, walk away for good, discard this Mike Hearn pseudonym I
> invented for Bitcoin and the app will still work :) Surely that is an
> important part of being decentralised?
>
> It also means that as the underlying protocol evolves over time, getutxos
> can evolve along side it. P2P protocol gets encrypted/authenticated? Great,
> one more additional bit of security. If one day miners commit to UTXO sets,
> great, one more additional bit of security. When we start including input
> values in the signature hash, great ... one more step up in security.
>
> Anyway, I didn't really want to reopen this debate. I just point out that
> third party services are quite happy to provide whatever developers need to
> build great apps, even if doing so fails to meet some kind of perfect
> cryptographic ideal. And that's why they're winning devs.
>
> Now back to your regularly scheduled block size debates ...
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/d3986cae/attachment.html>;
Rebroad (sourceforge) [ARCHIVE] /
npub1vf…ekcv3
2023-06-07 15:38:00
in reply to nevent1q…g9tq
Author Public Key
npub1vfx9qxevl6t9hk28s293ufcrh3yfnkgn6k4z3ucwumv37605w92ssekcv3Published at
2023-06-07 15:38:00Event JSON
{
"id": "aead27a272a5d57731e99e967b858ba83294edf3d658301c7129a21f624c4494",
"pubkey": "624c501b2cfe965bd947828b1e2703bc4899d913d5aa28f30ee6d91f69f47155",
"created_at": 1686152280,
"kind": 1,
"tags": [
[
"e",
"fcd2bd013d917ca502887a477adc89aba99878b8aa1ed69af92eff37ef4dc484",
"",
"root"
],
[
"e",
"4f1247c589d7e75200e070c4fc2f6e98d3f574d2009e57e8eaaccf7bd5dcc9ce",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2015-06-15\n📝 Original message:My understanding of this debate is that there are some people who want to\nkeep Bitcoin at 1MB block limit, and there are some who want to increase it.\n\nI for one am curious to see how 1MB limited bitcoin evolves, and I believe\nwe can all have a chance to see this AND hard-fork bitcoin to remove the\nblock size restriction.\n\nTo remove the 1MB limit required a hard fork. This is not disputed. It's\nwhat we do with the original (1MB limit) bitcoin that concerns me (and\nother's I am sure).\n\nWhat I would like to see is both being allowed to live. Harry Potter and\nVoldermort! (Except neither are evil!)\n\nThe solution is to hard-fork and merge-mine. This way, both can live, and\nmining power is not divided.\n\nDogecoin recently hardforked and this hardfork also involved switching to\nmerge-mining, so it's been done successfully.\n\nSo, simply, bitcoin as it is doesn't need to actually fork, but instead, at\na certain block size, a forked bitcoin with the blocksize lmit removed will\nstart to be merge-mined alongside bitcoin. Miners can be ready for this.\nWallets can be ready for this - in fact, for most wallets and merchants\nthey will possibly want to default to the bigger blocksize fork since this\ncaters for more transactions per block.\n\nWe still don't know how removing the block limit will pan out and what\nother problems with scalability will arise in the future, so by preserving\nthe original bitcoin, we keep diversity, and people won't feel their\ninvestments in bitcoin are being unnecessarily put at risk (as their\ninvestments will stay in both the new and the old bitcoin).\n\nThe bitcoin core developers can implement a patch like the one recently\nused for dogecoin, to allow the chain to fork at a set point, where at\nwhich point, bitcoins will be split into the new and the old. Branding will\nbe an important issue here I think, so that there is as little confusion as\npossible. I think this is a small price to pay in return for not killing\nthe original bitcoin (even if it's true that Satoshi did intend to remove\nthe 1MB limit at some point).\n\nIf I'm missing something obvious please let me know.\n\nOn Mon, Jun 15, 2015 at 1:50 PM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\n\u003e The fact that using a centralized service is easier isn't a good reason\n\u003e\u003e IMHO. It disregards the long-term, and introduces systemic risk.\n\u003e\u003e\n\u003e\n\u003e Well sure, that's easy for you to say, but you have a salary :) Other\n\u003e developers may find the incremental benefits of decentralisation low vs\n\u003e adding additional features, for instance, and who is to say they are wrong?\n\u003e\n\u003e\n\u003e\u003e But in cases where using a decentralized approach doesn't *add* anything,\n\u003e\u003e I cannot reasonably promote it, and that's why I was against getutxos in\n\u003e\u003e the P2P protocol.\n\u003e\u003e\n\u003e\n\u003e It does add something though! It means, amongst other things, I can switch\n\u003e of all my servers, walk away for good, discard this Mike Hearn pseudonym I\n\u003e invented for Bitcoin and the app will still work :) Surely that is an\n\u003e important part of being decentralised?\n\u003e\n\u003e It also means that as the underlying protocol evolves over time, getutxos\n\u003e can evolve along side it. P2P protocol gets encrypted/authenticated? Great,\n\u003e one more additional bit of security. If one day miners commit to UTXO sets,\n\u003e great, one more additional bit of security. When we start including input\n\u003e values in the signature hash, great ... one more step up in security.\n\u003e\n\u003e Anyway, I didn't really want to reopen this debate. I just point out that\n\u003e third party services are quite happy to provide whatever developers need to\n\u003e build great apps, even if doing so fails to meet some kind of perfect\n\u003e cryptographic ideal. And that's why they're winning devs.\n\u003e\n\u003e Now back to your regularly scheduled block size debates ...\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/d3986cae/attachment.html\u003e",
"sig": "d3f7b40d1396970036b7fb8555e544a88ae8dd8623d0ab92a9e0c5207968c21127e58a74d225d3a6a79aa6cc70784b3b04c3090d0dab9b3816ce6b4914deecd2"
}