Good morning Robert, > How did you know that I'm a closet furry?! ;) I'm shaking in my onesie right > now...
It was so obvious, my furdar was picking up your furriness just from parsing the individual bytes arising from your email server. > It is definitely not my goal to split the network up but rather to provide > some guide rails to help ensure usability and decentralization. I also agree > 100% that Tor nodes are a must for LN. > > In terms of maximum node size for SBN, I do feel that it would be beneficial > to the decentralization of the network to have that in place (if it worked as > intended) but also understand the scenario you outline where many nodes could > be spun up on the same machine. Perhaps a better (and actually enforceable) > approach would be to require that all RNs commit 0.5 BTC per channel (1 BTC > total per channel) with a minimum of 4 channels. So, a larger node could have > many more than 4 channels assuming each channel meets the liquidity > requirement. This wouldn't help to further decentralization but would at > least ensure uniform channel liquidity. It seems that just as the one > computer one vote idea with BTC didn't pan out, there is a similar problem > here that may be insurmountable. > > Your suggestion for self-attestation using OpenTimeStamps is really brilliant > and elegant. I don't see any reason why this shouldn't work. I do think it > would be better to extend the minimum number of self-attestations to perhaps > 7 days worth of blocks (so that a node cannot easily join/exit/rejoin SBN). > I'm also wondering if it would make sense to add OpenTimeStamps servers to > all SBN nodes and then use some kind of random election function such that > for each block all attestations would be sent to the elected server and > published to BTC (thus ensuring the lowest possible fee vs. using a redundant > approach with multiple OTS servers). If the election is sufficiently random, > it would seem to be very difficult to coordinate an attack where a furry's > attestation would be excluded from a block for more than some very small > number (well bellow putting them in danger of being excluded from the network > for insufficient uptime). Unfortunately for the poor fool who came up with that proposal, it suffers from "what you measure is what you get". Specifically, it measures node uptime, but not node correct behavior, and it is node correct behavior (i.e. making an effort to actually forward) that you want; what this proposal does is measure node uptime, which *correlates with* but *is not exactly identical to* node correct behavior. I find that most furries are more able to understand this with a fable, so let me present the issue of "what you measure is what you get" in fable form. Once upon a time, the government of London, seeking to reduce the rat problem of the city, decided to delegate the problem to the private sector, by offering to pay an amount for every rat tail provided by the citizenry. At first this seemed to work well, but eventually the rat infestation came back with a vengeance, even as the coffers of the city government were continuously emptied by the rat-tail program. Eventually an extensive investigation by the government officials uncovered the existence of *rat farms*, where private individuals grew rats (and where well-fed healthy rats sometimes escaped from, leading to worse rat infestations than before) for their lucrative tails. This shows the issue: what they measured was *the number of rat tails shown*, not *the reduction of rats in the city*, and so they got shown a lot of rat tails (at the expense of actively increasing the number of rats in the city, since they were now being grown in rat farms). Similarly, I could attack the SBN by having a cheap RaspPi (or maybe Arduino) continuously attesting its uptime, but not actually running any Lightning node software, so that paths through my pathetic RaspPi "node" will always fail. With enough cheap RaspPis and some HODLed funds in 2-of-2s (where both pubkeys are mine anyway), I can ensure that most of SBN is composed of my "nodes" and make it worthless. Against this, we can observe that the blockchain layer itself is ultimately protected by the economics of mining. Thus, the blockchain security cannot be better than economically-infeasible security, and Lightning, as it is anchored to the blockchain, also cannot get better than economically-infeasible security. If attesting its own uptime is expensive enough, then every additional node that I fake is going to be an additional expense, and it may become impractical for me to take over the entire SBN unless I work honestly and actually forward payments and earn fees from it (in much the same way that a miner could always just mine empty blocks and make the blockchain layer worthless, but it is impractical for them to do so since they would earn less compared to a miner who honestly adds new transactions to the blocks and thereby earn fees from those). (the above does not protect against running multiple nodes to get around any per-node limit, by the way; if running one honestly-forwarding node is at all lucrative, running more honestly-forwarding nodes should be more lucrative. thus, the above only protects against nodes that are not honestly-forwarding, but cannot protect against multiple honestly-forwarding nodes being run by the same entity to get around per-node limits you might impose) Further, adding more OTS-like servers may still allow a minority OTS-server to effectively censor hated furries like you. Remember, we now require that SBN-nodes have 99% uptime by showing 99 proof-of-uptime entries in the last 100 blocks. If I have enough OTS-servers to comprise at least 2% of all OTS-servers, then I can force you, you furry, to have at most 98% uptime recorded onchain, thus effectively censoring you from the SBN. This might be helped by adding some salting of some kind, and having OTS-server protocol to accept any blinded commitments that will only be opened after they are actually committed onchain, though. Alternately, groups of independent citizens can just put a fund in a k-of-n address and always continuously spend that k-of-n address to itself on every block, with the proof-of-uptimes of the group embedded in a Merkle tree committed to in the `R` of the signature (i.e. sign-to-contract). With Schnorr this allows the k-of-n to be hidden in a single signature as well, though the signing ritual would have to be significantly more complex (I have not considered the proper signing ritual) to ensure that the generated `R` indeed commits to the Merkle tree root of the group uptime proofs, and k-of-n requires a complicated setup, and k-of-n is susceptible to majority takeover (i.e. it can be spent without your key, thus not your coins) and sybilling. This may also combine well with the need to make proof-of-uptime expensive (else it would be cheap to take over SBN). Though of course our colleagues over in bitcoin-dev will cry over the blockchain bloat such a scheme would have, you spoony furry, that is precisely why furries should be censored. (taking the above offchain is possible, but the entire point of doing the above onchain is that it proves onlineness, whereas offchain does not prove that anything is online at each block, only at the blocks where the offchain system is pushed onchain.) Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
