📅 Original date posted:2015-06-15
📝 Original message:>
> 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 ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/ebebaacc/attachment.html>;
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 15:38:00
in reply to nevent1q…xy6z
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 15:38:00Event JSON
{
"id": "4f1247c589d7e75200e070c4fc2f6e98d3f574d2009e57e8eaaccf7bd5dcc9ce",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686152280,
"kind": 1,
"tags": [
[
"e",
"fcd2bd013d917ca502887a477adc89aba99878b8aa1ed69af92eff37ef4dc484",
"",
"root"
],
[
"e",
"a389c18a778ba1263820af6ce6313fc4088cc7ffb4daa82c2f23c9b8aa04fbef",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2015-06-15\n📝 Original message:\u003e\n\u003e The fact that using a centralized service is easier isn't a good reason\n\u003e IMHO. It disregards the long-term, and introduces systemic risk.\n\u003e\n\nWell sure, that's easy for you to say, but you have a salary :) Other\ndevelopers may find the incremental benefits of decentralisation low vs\nadding additional features, for instance, and who is to say they are wrong?\n\n\n\u003e But in cases where using a decentralized approach doesn't *add* anything,\n\u003e I cannot reasonably promote it, and that's why I was against getutxos in\n\u003e the P2P protocol.\n\u003e\n\nIt does add something though! It means, amongst other things, I can switch\nof all my servers, walk away for good, discard this Mike Hearn pseudonym I\ninvented for Bitcoin and the app will still work :) Surely that is an\nimportant part of being decentralised?\n\nIt also means that as the underlying protocol evolves over time, getutxos\ncan evolve along side it. P2P protocol gets encrypted/authenticated? Great,\none more additional bit of security. If one day miners commit to UTXO sets,\ngreat, one more additional bit of security. When we start including input\nvalues in the signature hash, great ... one more step up in security.\n\nAnyway, I didn't really want to reopen this debate. I just point out that\nthird party services are quite happy to provide whatever developers need to\nbuild great apps, even if doing so fails to meet some kind of perfect\ncryptographic ideal. And that's why they're winning devs.\n\nNow back to your regularly scheduled block size debates ...\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/ebebaacc/attachment.html\u003e",
"sig": "ae08f3e27296850244dffc66d8c5b45913da114a5b7af2f861abf0e1c41ae50a250fbc614fb038d5b1f77c2510b5cad390839289d2bf7708b1e5d10f33c6edf6"
}