Thomas Zander [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-09 📝 Original message:On Saturday 8. August 2015 ...
📅 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
📝 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