Rethinking incentive compatibility within the Bitcoin Protocolbitcoinerrorlog.medium.com/rethinking-incentive-compatibility-within-the-bitcoin-protocol-684277171797
374 sats \ 3 comments \ @edblock 10 Dec 2022 bitcoin
write
preview
related posts
1 sat \ 2 replies \ @petertodd 10 Dec 2022
Thread on the many problems with this argument: https://twitter.com/mHaGqnOACyFm0h5/status/1601633543435669506
LOL "incentive compatible" framed as an antonym of "user compatible". JFC just open up the wikipedia entry.
how can people be around in this space literally for years and not only not bother learning what these terms mean, but have the audacity to waste other peoples' time writing think pieces about what they think those terms should mean?
Indeed.
Anyway, this obsession some people have over the incentive compatibility of full-rbf is short sighted. People do things for all kinds of reasons; accepting unconfirmed transactions means you're relying on approximately all miners to not do something. That's very risky, as all it takes is one individual miner to decide what you're doing is dumb and turn on full-rbf. Or indeed, they may just find BitcoinErrorLog tedious and decide to give him a bad day.
Security models that rely on no-one doing something are not good security models.
reply
0 sats \ 0 replies \ @_gowith 11 Dec 2022
You claim 0conf is very risky, now provide some real-world factual data to support your claim.
Please tell us how much money a single merchant, any merchant, has lost from double spend attacks because of their 0conf policy. Really, it can be any merchant-educate me.
Lightning is getting coopted and destroyed by Taro assets. 0conf is destroyed by Core. What options exist for scaling and using Bitcoin as everyday money? Bigger blocks?
reply
0 sats \ 0 replies \ @petertodd 10 Dec 2022
FYI, there were a few full-rbf double-spends earlier today: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021260.html
reply