instagibbs

Bitcoin has a KYC problem. We don't know any customers. One man's spammer is another man's marketing genius.

This plays into how Bitcoin software handles transactions that are gossiped to it on the network. Your local node does a list of anti-DoS checks, as well as miner compatibility checks, caches the transaction, and forwards it to any nodes connected to yours.

For miner incentives, this is not exactly straight forward, but easy enough to inuit. If you can "make the mempool better", you accept a new transaction, and kick out whatever it replaced.

This isn't the whole story. What it it makes the mempool contents better for miners, but is worse

instagibbs

diff --git a/src/test/fuzz/package_eval.cpp b/src/test/fuzz/package_eval.cpp
index 9c64c39699..989373b044 100644
--- a/src/test/fuzz/package_eval.cpp
+++ b/src/test/fuzz/package_eval.cpp
@@ -98,51 +98,52 @@ struct TransactionsDelta final : public CValidationInterface {
          m_added.erase(tx);
     }
 };
 
 void MockTime(FuzzedDataProvider& fuzzed_data_provider, const Chainstate& chainstate)

instagibbs

LN-Symmetry Project

ln-symmetry started with a simple idea: Someone should take the eltoo idea and take it as far as possible to prove out the concept, without requiring community consensus required actions like softforks before proving it out.

The end result is research-level quality software, with basic functional tests of the common cases:

1. channel opens
2. payments (revamped + simplified channel state machine)
3. payments with hops

instagibbs

Given the general resistance of people to concept ACK a specific
transaction topology like V3, I was thinking it would be useful
to think ahead and see what policy relaxations or restrictions
we could enact in the future to make things more flexible,
incentive compatible, and overall more useful.

TL;DR: V3 is useful and likely upgradeable to something
we can be more proud of.

Here are some ideas on what path we could take. Here's a set