📅 Original date posted:2013-10-28
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sat, Oct 26, 2013 at 12:25 AM, Gavin Andresen
<gavinandresen at gmail.com> wrote:
> I feel like there is a lot of "in the weeds" discussion here about
> theoretical, what-if-this-and-that-happens-in-the-future scenarios.
>
> I would just like to point out (again) that this is not intended to be The
> One True Solution For Transaction Fees And Transaction Prioritization. If
> you've got a better mechanism for estimating fees, fantastic! If it turns
> out estimates are often-enough wrong to be a problem and you've got a
> solution for that, fantastic!
This discussion seems to be a lot of hot air over a simple observation that
estimates are imperfect and always will be. I do not understand you vehement
opposition the notion that a backup is a good thing except in the context that
replacement to change fees is halfway to profit-seeking replacement by fee.
Peter Todd:
You did a fair bit of leg work for replace-by-fee. Seems to me that
replace-for-fee will help prep infrastructure to eventual replace-by-fee usage,
while avoiding some of the politics around zero-conf transactions.
Go dust off your code and make it happen. I want to see a mempool
implementation similar to what you did for me on replace-for-fee, and I
understand much of the code is written in any case. This time I also want to
see a increasetxfee RPC command, and erasewallettx RPC command to deal with
duplicates. (I know touching the wallet code is scary) Having all will enable
usage, and I can imagine getting pools to use this will be easy enough.
(eligius?)
Here is your 4BTC bounty. In the event I am not around Gregory Maxwell can also
adjudicate. If both you and him feel someone else deserves it, by all means
send them the funds
bitcoind decodescript
522102d527466a144aac2030cd16d8be3d91231af26a95c2f8fc345a0ea0e8d53ac3914104d34775baab521d7ba2bd43997312d5f663633484ae1a4d84246866b7088297715a049e2288ae16f168809d36e2da1162f03412bf23aa5f949f235eb2e71417834104f005d39733ec09a1efa0cf8dcf3df50691e22c2374ff9a96d1d9ecb98a1e866c9f558a9fa1ba8ef0bbbad01f396768c0cb2dda9924dc0aaee1481604a8bd9ce453ae
{
"asm" : "2 02d527466a144aac2030cd16d8be3d91231af26a95c2f8fc345a0ea0e8d53ac391
04d34775baab521d7ba2bd43997312d5f663633484ae1a4d84246866b7088297715a049e2288ae16f168809d36e2da1162f03412bf23aa5f949f235eb2e7141783
04f005d39733ec09a1efa0cf8dcf3df50691e22c2374ff9a96d1d9ecb98a1e866c9f558a9fa1ba8ef0bbbad01f396768c0cb2dda9924dc0aaee1481604a8bd9ce4
3 OP_CHECKMULTISIG",
"reqSigs" : 2,
"type" : "multisig",
"addresses" : [
"1L9p6QiWs2nfinyF4CnbqysWijMvvcsnxe",
"1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv",
"1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB"
],
"p2sh" : "3BST1dPxvgMGL3d9GPCHvTyZNsJ7YKTVPo"
}
(I realized right after my Tor payment protocol bounty that I would need some
bit of uniqueness like a bounty-specific pubkey to disambiguate multiple such
bounties!)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJSbg9wAAoJEEWCsU4mNhiPROQH/j+eWccx7oSVsr94cgGu7qza
kdnA7B6BAlnCPg3D+nqEFKDqzOyFppeHLadCCIYHHc5iVRfJuu9J1Gh9lgMCuyCW
qN7ZOBCARjiVOqrHPQR1pf18i0ko7dQWw2hZjy51XKuFxAsHwZpB/fzQCbVVzyB6
l5SECCou58bJ/x7B0L93K+yjXuMGnvi9jqiLAKkLWYDzVm7TeVWNVQr04B7sqi6A
mY+BfG61e7sqM2UJd69yGLeQdEfghYTmtA+EaaqYS0L11m7yFGZdUqD7UNy1FKO7
44M1JTh2ANnQRjSTJWOBXQNHMa/mxDCji1VFUtJhZKEuOZyWpGm7HMH1D3vcvcQ=
=4flN
-----END PGP SIGNATURE-----
John Dillon [ARCHIVE] /
npub15z…kn0zr
2023-06-07 15:07:58
in reply to nevent1q…ev74
Author Public Key
npub15z6e9t07ugx267aj3s3c487pln852ydytzlgu0vkkqxfznyvx4jq4kn0zrPublished at
2023-06-07 15:07:58Event JSON
{
"id": "3c92d0f5a4a0397ec288d1b9866ad460f8d809fb93e84bca5a0f7c9e585207e0",
"pubkey": "a0b592adfee20cad7bb28c238a9fc1fccf4511a458be8e3d96b00c914c8c3564",
"created_at": 1686150478,
"kind": 1,
"tags": [
[
"e",
"82aca9d85d9f8088587f8710d511958183b300f7daa0a8fd33090fc324b509ac",
"",
"root"
],
[
"e",
"5ae6a04c1463ca77920ed35b4a5667b3b6cedf373932b38659d60ee0e2836b81",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2013-10-28\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\nOn Sat, Oct 26, 2013 at 12:25 AM, Gavin Andresen\n\u003cgavinandresen at gmail.com\u003e wrote:\n\u003e I feel like there is a lot of \"in the weeds\" discussion here about\n\u003e theoretical, what-if-this-and-that-happens-in-the-future scenarios.\n\u003e\n\u003e I would just like to point out (again) that this is not intended to be The\n\u003e One True Solution For Transaction Fees And Transaction Prioritization. If\n\u003e you've got a better mechanism for estimating fees, fantastic! If it turns\n\u003e out estimates are often-enough wrong to be a problem and you've got a\n\u003e solution for that, fantastic!\n\nThis discussion seems to be a lot of hot air over a simple observation that\nestimates are imperfect and always will be. I do not understand you vehement\nopposition the notion that a backup is a good thing except in the context that\nreplacement to change fees is halfway to profit-seeking replacement by fee.\n\n\nPeter Todd:\n\nYou did a fair bit of leg work for replace-by-fee. Seems to me that\nreplace-for-fee will help prep infrastructure to eventual replace-by-fee usage,\nwhile avoiding some of the politics around zero-conf transactions.\n\nGo dust off your code and make it happen. I want to see a mempool\nimplementation similar to what you did for me on replace-for-fee, and I\nunderstand much of the code is written in any case. This time I also want to\nsee a increasetxfee RPC command, and erasewallettx RPC command to deal with\nduplicates. (I know touching the wallet code is scary) Having all will enable\nusage, and I can imagine getting pools to use this will be easy enough.\n(eligius?)\n\nHere is your 4BTC bounty. In the event I am not around Gregory Maxwell can also\nadjudicate. If both you and him feel someone else deserves it, by all means\nsend them the funds\n\nbitcoind decodescript\n522102d527466a144aac2030cd16d8be3d91231af26a95c2f8fc345a0ea0e8d53ac3914104d34775baab521d7ba2bd43997312d5f663633484ae1a4d84246866b7088297715a049e2288ae16f168809d36e2da1162f03412bf23aa5f949f235eb2e71417834104f005d39733ec09a1efa0cf8dcf3df50691e22c2374ff9a96d1d9ecb98a1e866c9f558a9fa1ba8ef0bbbad01f396768c0cb2dda9924dc0aaee1481604a8bd9ce453ae\n{\n \"asm\" : \"2 02d527466a144aac2030cd16d8be3d91231af26a95c2f8fc345a0ea0e8d53ac391\n04d34775baab521d7ba2bd43997312d5f663633484ae1a4d84246866b7088297715a049e2288ae16f168809d36e2da1162f03412bf23aa5f949f235eb2e7141783\n04f005d39733ec09a1efa0cf8dcf3df50691e22c2374ff9a96d1d9ecb98a1e866c9f558a9fa1ba8ef0bbbad01f396768c0cb2dda9924dc0aaee1481604a8bd9ce4\n3 OP_CHECKMULTISIG\",\n \"reqSigs\" : 2,\n \"type\" : \"multisig\",\n \"addresses\" : [\n \"1L9p6QiWs2nfinyF4CnbqysWijMvvcsnxe\",\n \"1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv\",\n \"1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB\"\n ],\n \"p2sh\" : \"3BST1dPxvgMGL3d9GPCHvTyZNsJ7YKTVPo\"\n}\n\n(I realized right after my Tor payment protocol bounty that I would need some\nbit of uniqueness like a bounty-specific pubkey to disambiguate multiple such\nbounties!)\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.11 (GNU/Linux)\n\niQEcBAEBCAAGBQJSbg9wAAoJEEWCsU4mNhiPROQH/j+eWccx7oSVsr94cgGu7qza\nkdnA7B6BAlnCPg3D+nqEFKDqzOyFppeHLadCCIYHHc5iVRfJuu9J1Gh9lgMCuyCW\nqN7ZOBCARjiVOqrHPQR1pf18i0ko7dQWw2hZjy51XKuFxAsHwZpB/fzQCbVVzyB6\nl5SECCou58bJ/x7B0L93K+yjXuMGnvi9jqiLAKkLWYDzVm7TeVWNVQr04B7sqi6A\nmY+BfG61e7sqM2UJd69yGLeQdEfghYTmtA+EaaqYS0L11m7yFGZdUqD7UNy1FKO7\n44M1JTh2ANnQRjSTJWOBXQNHMa/mxDCji1VFUtJhZKEuOZyWpGm7HMH1D3vcvcQ=\n=4flN\n-----END PGP SIGNATURE-----",
"sig": "629ebfb75ae1483c93459b67695cfadcbeeec08834951afd3f73ecea5454a788f00a025f8f24f1f0c000eedcfda7079fbd76a5e38f4f189b28669bcccbd85dff"
}