📅 Original date posted:2015-06-18
📝 Original message:On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>
> The whole point is getting out in front of the need, to prevent
> significant negative impact to users when blocks are consistently full.
>
> To do that, you need to (a) plan forward, in order to (b) set a hard fork
> date in the future.
>
Or alternatively, fix the reasons why users would have negative experiences
with full blocks, chiefly:
* 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.
Not raising the block size limit does not mean doing nothing to solve the
problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/b7699ac6/attachment.html>;
Mark Friedenbach [ARCHIVE] /
npub1r3…48d0u
2023-06-07 15:38:35
in reply to nevent1q…ecvz
Author Public Key
npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uSeen on
wss://relay.noswhere.comPublished at
2023-06-07 15:38:35Event JSON
{
"id": "0fab471e67f052895054b16418b572357087180a8e9009264f1fbb8a84dcf8ff",
"pubkey": "1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069",
"created_at": 1686152315,
"kind": 1,
"tags": [
[
"e",
"23c1bb2f25b9e7356b48aa2a86751c4f26fb3977b440917a1cb3512c200b0b2f",
"",
"root"
],
[
"e",
"30b72e45e97b5a2dfa1c86219b59553e0a8f019ade02bdecc63432c6814429a6",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 Original date posted:2015-06-18\n📝 Original message:On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik \u003cjgarzik at bitpay.com\u003e wrote:\n\n\u003e\n\u003e The whole point is getting out in front of the need, to prevent\n\u003e significant negative impact to users when blocks are consistently full.\n\u003e\n\u003e To do that, you need to (a) plan forward, in order to (b) set a hard fork\n\u003e date in the future.\n\u003e\n\nOr alternatively, fix the reasons why users would have negative experiences\nwith full blocks, chiefly:\n\n * Get safe forms of replace-by-fee and child-pays-for-parent finished and\nin 0.12.\n * Develop cross-platform libraries for managing micropayment channels,\nand get wallet authors to adopt\n * Use fidelity bonds, solvency proofs, and other tricks to minimize the\nrisk of already deployed off-chain solutions as an interim measure until:\n * Deploy soft-fork changes for truly scalable solutions like Lightning\nNetwork.\n\nNot raising the block size limit does not mean doing nothing to solve the\nproblem.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/b7699ac6/attachment.html\u003e",
"sig": "d74e1f6d39fa3bd6c982583a629d85000cd0befd184c726134970325b0b16962973dac2e488dbcba000389f9cffa8b147b4ba5eba53e1137e5173426fff4866c"
}