pull down to refresh

316 sats \ 4 replies \ @optimism 25 Sep \ on: Gmax's theocratic populist sex prohibition analogy for filters bitcoin
Core attempts to model what will get mined.
I still feel that this is a bit new-ish of a narrative though, afaik it was b10c that started analyzing cmpctblock reconstruction at some point. It is okay that the narrated purpose of the mempool shifts but perhaps this is the difference between what Core does and what Knots aims for, and all that is needed is coexistence.
I'd argue that:
  1. Core is heavily LN-influenced and LN benefits from as-uniform-as-possible mempools between the sum of all miners, and your (watchtower) node. However, since there is no consensus over mempool, any limiting policy doesn't work (for a watchtower). LN is basically a zeroconf protocol, see this 2015 email on how policy messes with zeroconf, and then think about how Peter could analyze what happened with his modified nodes (2 replies below in that thread). The idea then becomes: Not relaying any transaction will be bad for other watchtowers, so as a community, the greatest value is the dissemination of transactions, so that everyone's watchtower knows everything.
  2. Knots isn't LN-oriented at all, but instead focuses on L1 and community values. Nodes relay transactions and the operator is in charge of what to relay, and there are people that do bad things, such as shittoken mints, that make the network more expensive to run (and make it more expensive to transact.) The idea: It's in everyone's interest to try to keep this shit out, no matter the cost.
These are the opposing views. No ridicule is needed. Both views are valid and funnily, if we give up on the uniform mempool idea, and optimize implementations for the usecase we desire, yet can bring up the intellectual honesty that not everyone is in the same camp, then there doesn't have to be a war, at all, if people get their dumb doomscrolling butts off X and instead spend time building tools for their community to co-exist with the other.
The polarization is the problem, not the different ideologies.
write
preview
200 sats \ 1 reply \ @TheCharlatan 25 Sep
I don't think it is that new, but you are definitely correct that lightning helped shaping it into that direction. What do you think its primary purpose should be?
reply
333 sats \ 0 replies \ @optimism 25 Sep
I should have said "relatively new" - 50 years minimum horizon, lol.
What do you think its primary purpose should be?
Disclaimer: never listen to a retard like me!
But since you are asking, I'd say that it depends on use-case.
  1. No mempool. I agree with Gmax' argument that blocksonly is a perfect mode, for "leaf" nodes 1. Also, I feel that while a properly running relay node may help, a badly configured one or low-capacity node doesn't 2. If you're just looking to do your own validation of (low volume) utxos, no mempool is the best mempool, as you anyway don't want to zeroconf.
  2. Knowing what's going on with your LN channels (or other pre-confirmation risk monitoring). Like I said above, for watchtowers you want to know as much as you can, even stuff that is unlikely to get mined 3. This is technically more permissive than being a reflection of what gets mined, especially when we see pool / template decentralization.
  3. But we do need relays also without LN, because hub-and-spoke would be bad for centralization. For this, I'd say the mempool is basically your pre-validated set of transactions that you pass around, like a hot database of what you want to relay to others. This is the use case where - although not necessarily useful from where I'm sitting - filters could make sense if an operator feels strongly about it. Since someone filtering important transactions is a threat scenario that needs to be minimized no matter what, it shouldn't be too much of a problem when other operators do this.
  4. Edit because I forgot: And as a stage for mining of course. I wouldn't filter my mempool if I were a miner/pool, but I'd definitely look to filter my inclusion rules.

Footnotes

  1. it would be useful to have (degraded?) smartfee work when a node has only the block inclusion statistics, i.e. estimate based on what was mined only, without tracking confirmation time of seen->mined. I'm still building some test scenarios based on a discussion we had about this on SN a week or so ago and have promised to share anything I think can be improved (but I'm slow, sry.) ↩
  2. In the past Ian Coleman had a simulator (pre-segwit, pre-compactblocks and now discontinued?) that illustrated the impact of more nodes on the network in terms of hops a tx would need to travel and what kind of data use we'd look at network-wide, which was interesting to play with. ↩
  3. I've had the temptation to make my watchtower allownonstandard but since there were little/no peers with that and I felt there may be some risks I would miss and then not catch (don't want to be banned from all peers), I instead ran with a maximally permissive policy through config and a much-larger-than-default mempool (had thought of using librerelay instead.) Either way, this is why I feel configurability is very important. Someone may need it for a reason no one thought of. ↩
reply
121 sats \ 1 reply \ @Scoresby OP 25 Sep
we give up on the uniform mempool idea, and optimize implementations for the usecase we desire
It seems like the debate has become intractable because in addition to the base disagreement about the effectiveness of filters, there is also a debate about how to decide on controversial changes to the reference implementation. Core does not seem willing to merge a PR they disagree with and Knots does not seem solely content with building in the Knots repo. So polarization happened because both sides feel like they have "ownership" (probably not the right word) of the reference implementation.
I appreciated @flaco's take on this from yesterday (#1234973), and would be very interested to read your thoughts in response.
LN is basically a zeroconf protocol
This feels like one of those high-density statements the unpacking of which leads to a lot of learning on my part.
I'll spend more time on it, but from what you said and the attached mailing list thread,
Is it that everyone's watchtower needs to know everything, or that everyone's watchtower needs to know miner's mempools? In the thread Todd says that the double spent txs had "were highly relayable/minable" but that the problem was that Shapeshift relied on something that used percent of nodes to which a tx has propagated as a proxy for confidence. This makes me think that the entire relay network can be the same, but if miners are willing to mine nonstandard, zero conf won't be reliable.
But all that aside, I'm still trying to figure why LN is a zero conf protocol: in the case of uncooperative channel close, first one to get a tx in a block wins. But what about penalty transactions? Don't they mitigate this?
Or is LN like a zero conf protocol because I don't really have my sats till I return to the chain?
I think I still don't have this fully in my mind, but I don't mean to take up your time with it (more just writing it out for the practice -- I'll spend a while on it and see where I end up).
reply
223 sats \ 0 replies \ @optimism 25 Sep
I appreciated flaco's take on this from yesterday
Same - I had a reply but I didn't like how it sounded so I'm still drafting, lol
the entire relay network can be the same .. zero conf won't be reliable.
The network cannot be the same because there is latency between nodes, thanks to the awesome principle of the speed of light, processing requirements, memory latency, utxo db lookup speed... and so on. Therefore zeroconf cannot be 100% reliable, because even if you see everything, you cannot know what is included in a miner's template that got distributed to all these ASICs, or maybe you only see it after a block was already found... So even in a tx replacement fight, you need luck. It's a race.
I'll spend a while on it and see where I end up
Check out Replacement Cycling - that's a nice thread to unravel 1

Footnotes

  1. Note that I don't really want to be discussing stuff like this in all its glorious larp-cases in the open if you don't mind - the defense is always aggressive replacement / rebroadcasting and mempool monitoring. And being aware of what you're using your node for. ↩
reply