📅 Original date posted:2015-08-09
📝 Original message:On Saturday 8. August 2015 15.45.28 Dave Scotese via bitcoin-dev wrote:
> Someone mentioned that when the backlog grows faster than it shrinks, that
> is a real problem. I don't think it is. It is a problem for those who
> don't wait for even one confirmation
The mention you refer to was about the fact that the software doesn't cope
well with a continuously growing mempool.
If Bitcoind starts eating more and more memory, I expect lots of people that
run it now to turn it off.
> but backlogs in the past have already
> started training users to wait for at least one confirmation, or go
> off-chain.
I am wondering how you concluded that? The only time we saw full blocks for a
considerable amount of time was when we had a spammer, and the only thing
we taught people was to use higher fees.
Actually, we didn't teach people anything, we told wallet developers to do it.
Most actual users were completely ignorant of the problem.
Full blocks will then stop being a supported usecase when real humans are
trying to buy a beer or a coffee. Waiting for a confirmation won't work either
for the vast majority of the current usages of Bitcoin in the real world.
> I am comfortable leaving those zero-conf people in a little bit
> of trouble. Everyone else can double-spend (perhaps that's not as easy as
> it should be in bitcoin core) and use a higher fee, thus competing for
> block space.
This is false, if you want to double spent you have to do a lot of work and
have non-standard software. For instance sending your newer transaction to a
random node will almost always get it rejected because its a double spent.
Replace by fee (even safe) is not supported in the vast majority of Bitcoin
land.
--
Thomas Zander
Thomas Zander [ARCHIVE] /
npub1du…vyg93
2023-06-07 17:45:47
in reply to nevent1q…pyp0
Author Public Key
npub1du3xh5wgds32a5fweqkd9k45kh30wl7kv2kyu8ugz9c2ztdg00tqqvyg93Published at
2023-06-07 17:45:47Event JSON
{
"id": "1c4d733d12119f1ca6484df02e05be598ffad1a1807df4dfdd2d32d2d74c0a9a",
"pubkey": "6f226bd1c86c22aed12ec82cd2dab4b5e2f77fd662ac4e1f881170a12da87bd6",
"created_at": 1686152747,
"kind": 1,
"tags": [
[
"e",
"cf6411bfecea99b0c4ea78e985838b5e3fd62429f4968960ffd260356286401f",
"",
"root"
],
[
"e",
"cdc16571e15531f99fd44b355d70a23e72a06d3a05fc31fda8cca944c437534f",
"",
"reply"
],
[
"p",
"6f226bd1c86c22aed12ec82cd2dab4b5e2f77fd662ac4e1f881170a12da87bd6"
]
],
"content": "📅 Original date posted:2015-08-09\n📝 Original message:On Saturday 8. August 2015 15.45.28 Dave Scotese via bitcoin-dev wrote:\n\u003e Someone mentioned that when the backlog grows faster than it shrinks, that\n\u003e is a real problem. I don't think it is. It is a problem for those who\n\u003e don't wait for even one confirmation\n\nThe mention you refer to was about the fact that the software doesn't cope \nwell with a continuously growing mempool.\nIf Bitcoind starts eating more and more memory, I expect lots of people that \nrun it now to turn it off.\n\n\u003e but backlogs in the past have already\n\u003e started training users to wait for at least one confirmation, or go\n\u003e off-chain.\n\nI am wondering how you concluded that? The only time we saw full blocks for a \nconsiderable amount of time was when we had a spammer, and the only thing\nwe taught people was to use higher fees.\nActually, we didn't teach people anything, we told wallet developers to do it. \nMost actual users were completely ignorant of the problem.\n\nFull blocks will then stop being a supported usecase when real humans are \ntrying to buy a beer or a coffee. Waiting for a confirmation won't work either \nfor the vast majority of the current usages of Bitcoin in the real world.\n\n\u003e I am comfortable leaving those zero-conf people in a little bit\n\u003e of trouble. Everyone else can double-spend (perhaps that's not as easy as\n\u003e it should be in bitcoin core) and use a higher fee, thus competing for\n\u003e block space.\n\nThis is false, if you want to double spent you have to do a lot of work and \nhave non-standard software. For instance sending your newer transaction to a \nrandom node will almost always get it rejected because its a double spent. \nReplace by fee (even safe) is not supported in the vast majority of Bitcoin \nland.\n\n-- \nThomas Zander",
"sig": "e0085f8549474495d74761d6823744cd890eca6f4636c53e7bd6b4ab760adcea916c62886d74a408c266086b4624da50a96be8bd8cbfa26c661dcd7881ebf5de"
}