angus [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2022-10-19 to 2023-05-08
💬 Posted a total of 4 messages
📚 Participated in the following categories: bitcoin-dev, Opt-in full-RBF
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 23:21:40

- reply

📅 Original date posted:2023-05-08
🗒️ Summary of this message: Storing arbitrary data should not be banned as people will start abusing useful data to do so, which is worse. The UTXO set getting too big is a bigger problem than the chain getting bigger.
📝 Original message:> Is there a reason such a validation check is a bad idea? We already have OP_RETURN to store arbitrary data that is limited to 80kb.
A reason to not ban storing arbitrary/non-functional data is that people will still want to store things, so will start (ab)using useful data to do so, which is worse -- see Stamps[1], which stores Inscription-like data in fake outputs that consume UTXO set storage (using the Counterparty spec IIRC).
The UTXO set getting 'too big' is a much bigger problem than the chain getting bigger at closer to 4MB/10mins than the 'expected' ~1MB/10mins is (some nuance/argument to be had here, though).
> Was it an oversight that arbitrary data can be inserted between OP_FALSE and OP_IF when the size limit for witness scripts was lifted as part of taproot?
Kinda? But if we want Taproot to enable large useful scripts, it's probably hard/impossible to have an undefeatable definition of 'not useful' to then filter out. You could say "scripts must not have any unreachable code (dead code)" but then it'd be easy to come up with Inscriptions 2.0 where the code is reachable but never used, rinse and repeat in a game of whack-a-mole.
In my opinion, it'd be wise to not incentivize people to do something worse by attempting to censor what they're currently doing, given that it could be a fair bit worse!
[1]: https://github.com/mikeinspace/stamps/blob/main/BitcoinStamps.md
Angus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230508/13d8dff3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230508/13d8dff3/attachment-0001.sig>

2023-06-07 23:21:40

- reply

2023-06-07 23:17:30

- reply

📅 Original date posted:2022-12-09
📝 Original message:I think the fundamental disagreement here that's causing the controversy and impasse is this:
Those in favour of Full RBF see trusting and relying on predictable mempool policy as a fundamentally flawed bad idea. Node policy is not a consensus rule - a miner has always been allowed to produce a block in the way a Full RBF node now would. An otherwise valid block that contains a tx that your not-full-RBF node ignored because it double-spent an earlier lower fee tx that didn't opt in to RBF is still a valid block. Knowing this, we conclude that it doesn't matter how useful or widely used Zero Conf is, it is fundamentally unsafe and should be actively discouraged, and changing mempool policy is a way to do this. The existence of Lightning as an alternative for immediate settlement makes this case stronger.
(As I see it) those that oppose Full RBF and want Zero Conf use to continue argue that node mempool policy can and has been relied upon for a long time already, and argue (rightly) that Zero Conf acceptance is already widely used and useful for both customers and merchants. Further arguing that Full RBF can be sucessfully unshipped, which requires that majority of node operators don't particularly care about it. Lastly, that neither miners nor users have an economic incentive to switch to Full RBF from the current core First-Seen policy. (Am I missing something else?)
---
I have sympathy for the utility argument, but to me it's completely overpowered by the "node policy is not consensus and not trustworthy" argument. Zero Conf acceptance rests on trusting that nodes are running with a first-seen policy. Just because this has worked out OK so far, doesn't mean that you won't get got bigtime in the future. You can accept this risk if you want to, but it shouldn't be a soft-rule that everyone else running a node should please help reduce that risk for you.
Sure, if I'm selling something on eBay or whatever for 100k sats and someone wants to pay in BTC in person, I'll accept with zero confirmations because there's a degree of trust and the risk isn't unbearable. If I'm accepting BTC as a company though, no, I'm not considering zero-confirmation transactions as settled.
I don't think the economic incentive argument currently matters all that much - miners want to maximise fees, users want to minimise, it's hard to tell which policy would have the higher overall fees for miners, and who wins miners-vs-users. This would also seem to depend on how wallets do or don't make use of the new RBF option (particularly hard for multisig). There is still an obvious incentive for someone to double-spend attack a Zero-Conf merchant, though.
I could be convinced to reverse my stance and oppose Full RBF if there was a strong economic argument that miners (better still, miners and users) should oppose it, because that would imply first-seen is incentive aligned. Aligning policy with incentives feels like the correct principle.
But for now, I want to run a Full RBF node because I see it as ultimately making Bitcoin stronger. It eliminates a use-case that takes risk. Accepting Zero Conf changes from "hrm, you shouldn't really do that but it works most of the time" to "no, really don't do that, you will probably lose money". Perhaps this is actually somewhat "vindictive, and perverse" as John said, but Bitcoin is money for enemies.
Thanks,
Angus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221209/12161097/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221209/12161097/attachment-0001.sig>

2023-06-07 23:17:30

- reply

2023-06-07 23:17:15

- reply

📅 Original date posted:2022-12-05
📝 Original message:Core adding full RBF is a change of node policy that may be highly inconvenient for zero-conf users, but there has always been and will always be a risk of a double-spend for anyone that treats zero-confirmation transactions as settled. It's literally in the name - this transaction has zero confirmations and no guarantee it'll make it into a block, and so has not yet settled.
The perception seems to be that Core adding the full RBF option is increasing the risk to zero-conf users, but I'm not convinced that that is the case - someone wanting to double-spend attack you isn't going to be bothered to do so over a few thousand sats (unless they can do it thousands of times), and losing a few thousand sats to a double-spend isn't the biggest deal.
It's always been the risk of getting double-spent out of hundreds or thousands of bitcoins that's worth seriously worrying about, which is much more the kind of attack a determined attacker is able to carry out. Such a determined attacker is much more likely to attempt and succeed at a sybil attack, or directly colluding with a miner. So your zero-conf risk increases non-linearly as the amount of bitcoin being transacted grows. (caveat: this paragraph is opinion).
There does, however, seem to be a legitimate business for providing insurance/risk management for people that are willing to accept the zero-conf risk - it is pretty similar to accepting credit cards with a chargeback risk or any payment card with a capture risk, though there's no-one to mediate a dispute. On-chain is final.
But what doesn't make any sense is trying to avoid Bitcoin Core and nodes from adopting a full RBF policy to try to protect this use case. As has been pointed out by may others before, full RBF is aligned with miner (and user) economic incentives and is a node policy, not consensus, so you can't even tell which nodes are doing it nor can you prevent them from doing so. Second, Bitcoin core 24 with the full RBF option is already out in the wild at around 5%+ of running nodes and growing, so it's too late to kill it.
So my point is that relying on node policy as part of your protection for zero-conf transaction acceptance is fragile, and should not be relied upon. The protocol rules have always tacitly allowed double-spending before a confirmation, and it has always been clear that there's no consensus on which transactions have occurred until they have in a block and have at-least one confirmation.
The long-term 'what to do about it' is to use Lightning if you want fast payments with risk-free instant settlement, or as above, accept the zero-conf risk and cover yourself with an insurance premium (e.g. a margin on transactions that goes into an insurance fund, and limiting max transaction amount so you're not exposed to uncoverable losses if you do get double-spend attacked)
Angus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221205/e9c2f67d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221205/e9c2f67d/attachment-0001.sig>

2023-06-07 23:17:15

- reply

2023-06-07 23:15:41

- reply

📅 Original date posted:2022-10-19
📝 Original message:> Let's allow a miner to include transactions until the block is filled, let's call this structure (coining a new term 'Brick'), B0. [brick=block that doesn't meet the difficulty rule and is filled of tx to its full capacity]
> Since PoW hashing is continuously active, Brick B0 would have a nonce corresponding to a minimum numeric value of its hash found until it got filled.
So, if I'm understanding right, this amounts to "reduce difficulty required for a block ('brick') to be valid if the mempool contains more than 1 block's worth of transactions so we get transactions confirmed faster" using 'bricks' as short-lived sidechains that get merged into blocks?
This would have the same fundamental problem as just making the max blocksize bigger - it increases the rate of growth of storage required for a full node, because you're allowing blocks/bricks to be created faster, so there will be more confirmed transactions to store in a given time window than under current Bitcoin rules.
Bitcoin doesn't take the size of the mempool into account when adjusting the difficulty because the time-between-blocks is 'more important' than avoiding congestion where transactions take ages to get into a block. The fee mechanism in part allows users to decide how urgently they want their tx to get confirmed, and high fees when there is congestion also disincentivises others from transacting at all, which helps arrest mempool growth.
I'd imagine we'd also see a 'highway widening' effect with this kind of proposal - if you increase the tx volume Bitcoin can settle in a given time, that will quickly be used up by more people transacting until we're back at a congested state again.
> Fully filled brick B0, with a hash that doesn't meet the difficulty rule, would be broadcasted and nodes would have it on in a separate fork as usual.
How do we know if the hash the miner does find for a brick was their 'best effort' and they're not just being lazy? There's an element of luck in the best hash a miner can find, sometimes it takes a long time to meet the difficulty requirement and sometimes it happens almost at instantly.
How would we know how 'busy' the mempool was at the time a brick from months or years ago was mined?
Nodes have to be able to run through the entire history of the blockchain and check everything is valid. They have to do this using only the previous blocks they've already validated - they won't have historical snapshots of the mempool (they'll build and mutate a UTXO set, but that's different). Transactions don't contain a 'created-at' time that you could compare to the block's creation time (and if they did, you probably couldn't trust it).
With the current system, Nodes can calculate what the difficulty should be for every block based on those previous blocks' times and difficulties - but how would you know an old brick was valid if its difficulty was low but at the time the mempool was busy, vs. getting a fraudulent brick that is actually invalid because there isn't enough work in it? You can't solve this by adding some mempoolsize field to bricks, as you'd have to blindly trust miners not to lie about them.
If we can't be (fairly) certain that a miner put a minimum amount of work into finding a hash, then you lose all the strengths of PoW.
If you weaken the difficulty requirement which is there so that mining blocks is hard so that it is very hard to intentionally fork the chain, re-mine previous blocks, overtake the other fork, and get the network to re-org onto your chain - then there's no Proof of work undergirding consensus in the ledger's state.
Secondly, where does the block reward go? Do brick miners get a fraction of the reward proportionate to the fraction of the difficulty they got to? Later when bricks become part of a block, who gets the block reward for that complete block? Who gets the fees? No miner is going to bother mining a merge-bricks-into-block block if the reward isn't the same or better than just mining a regular block, but each miner of the bricks in it would also want a reward. But, we can't give them both a block reward as that'd increase Bitcoin's issuance rate, which might be the only thing people are more strongly opposed to than increasing the blocksize! xD
> At this point, instead of discarding transactions, our miner would start working on a new brick B1, linked with B0 as usual.
>
> Nodes would allow incoming regular blocks and bricks with hashes that don't satisfy the difficulty rule, provided the brick is fully filled of transactions. Bricks not fully filled would be rejected as invalid to prevent spam (except if constitutes the last brick of a brickchain, explained below).
>
> Let's assume that 10 minutes have elapsed and our miner is in a state where N bricks have been produced and the accumulated PoW calculated using mathematics (every brick contains a 'minimum hash found', when a series of 'minimum hashes' is computationally equivalent to the network difficulty is then the full 'brickchain' is valid as a Block.
But the brick sidechain has to become part of the main blockchain - and as you've got N bricks in the time that there should be 1 block, and each brick is a full block, it feels like this is just a convoluted way to increase the blocksize? Every transaction has to be in the ledger somewhere to be confirmed, so even if the block itself is small and stored references to the bricks, Nodes are going to have to use storage to keep all those full bricks.
It also seems that you'd have to require the bricks sidechain to always be merged into the next actual block - it wouldn't work if the brick chain could keep growing and at the same time the actual blockchain advances (because there'd be risks of double-spends where one tx is in the brick chain and the other in the new block). Which I think further makes this feel like a roundabout way of increasing the blocksize
Despite my critique, this was interesting to think about - and hopefully this is useful (and hopefully I've not seriously misunderstood or said something dumb)
Angus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221019/3c06b968/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221019/3c06b968/attachment.sig>

2023-06-07 23:15:41

- reply