đ
Original date posted:2015-06-18
đ Original message:On 06/18/2015 06:33 PM, Mark Friedenbach wrote:
>
> * Get safe forms of replace-by-fee and child-pays-for-parent
> finished and in 0.12.
> * Develop cross-platform libraries for managing micropayment
> channels, and get wallet authors to adopt
> * Use fidelity bonds, solvency proofs, and other tricks to minimize
> the risk of already deployed off-chain solutions as an interim measure
> until:
> * Deploy soft-fork changes for truly scalable solutions like
> Lightning Network.
One of my biggest concerns is that these solutions (lightning network in
particular) could end up being worse, in terms of decentralization, than
would be a bitcoin network using larger blocks. We don't exactly know
what the economies of scale are for pay hubs and could very well end up
with far fewer hubs than nodes at any conceivable block size.
Of course, it could also turn out to be fantastic, but it seems like an
enormous gamble to basically force everyone in the ecosystem to
collectively spend millions of dollars upgrading to Lightning /and then/
see whether it's actually an improvement in terms of decentralization.
To me, a much more sane approach would be to allow people to voluntarily
opt in to those other solutions after we've had an opportunity to
experiment with them and see how they actually function in practice, but
that can't happen if the network runs out of capacity first.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/68c14c0e/attachment.html>;
Chris Pacia [ARCHIVE] /
npub1jpâŚkn8jw
2023-06-07 15:38:36
in reply to nevent1qâŚj67v
Author Public Key
npub1jp0jnnq2jxcjy76nrt5dssvmpynt4f9psdelp3vxj0y0xtpxl7jqhkn8jwPublished at
2023-06-07 15:38:36Event JSON
{
"id": "488c6d5b967634d70109650a5d2004f8af54adc6204311a331c71231bb0ccb0d",
"pubkey": "905f29cc0a91b1227b531ae8d8419b0926baa4a18373f0c58693c8f32c26ffa4",
"created_at": 1686152316,
"kind": 1,
"tags": [
[
"e",
"23c1bb2f25b9e7356b48aa2a86751c4f26fb3977b440917a1cb3512c200b0b2f",
"",
"root"
],
[
"e",
"6ed64de65244b84a204b28a82ee2c188dd8caf1b5b4418f191adc7e7f793669d",
"",
"reply"
],
[
"p",
"787ecd48da0d9610d322fb67c86ad23a5287d688559b2ff8ee546721fd990129"
]
],
"content": "đ
Original date posted:2015-06-18\nđ Original message:On 06/18/2015 06:33 PM, Mark Friedenbach wrote:\n\u003e\n\u003e * Get safe forms of replace-by-fee and child-pays-for-parent\n\u003e finished and in 0.12.\n\u003e * Develop cross-platform libraries for managing micropayment\n\u003e channels, and get wallet authors to adopt\n\u003e * Use fidelity bonds, solvency proofs, and other tricks to minimize\n\u003e the risk of already deployed off-chain solutions as an interim measure\n\u003e until:\n\u003e * Deploy soft-fork changes for truly scalable solutions like\n\u003e Lightning Network.\n\nOne of my biggest concerns is that these solutions (lightning network in\nparticular) could end up being worse, in terms of decentralization, than\nwould be a bitcoin network using larger blocks. We don't exactly know\nwhat the economies of scale are for pay hubs and could very well end up\nwith far fewer hubs than nodes at any conceivable block size.\n\nOf course, it could also turn out to be fantastic, but it seems like an\nenormous gamble to basically force everyone in the ecosystem to\ncollectively spend millions of dollars upgrading to Lightning /and then/\nsee whether it's actually an improvement in terms of decentralization.\n\nTo me, a much more sane approach would be to allow people to voluntarily\nopt in to those other solutions after we've had an opportunity to\nexperiment with them and see how they actually function in practice, but\nthat can't happen if the network runs out of capacity first.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/68c14c0e/attachment.html\u003e",
"sig": "416cfc08cf76e20e5fa5e76bb8e7cfd0b6685cdc321f521eb25c69d5c06f6331dca16371c523a4aefe8f964174d27229299ea836ebea15f5575a5a196df53a36"
}