From robertwilliamallen at gmail.com Wed Mar 18 21:51:48 2020 From: robertwilliamallen at gmail.com (Robert Allen) Date: Wed, 18 Mar 2020 14:51:48 -0700 Subject: [Lightning-dev] Superbolt Proposal - a professionally run LN subset delivering superior UX In-Reply-To: References: Message-ID: On Tue, Mar 10, 2020 at 5:11 AM ZmnSCPxj wrote: > 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. > I was familiar with this story. Also a great reminder of the dangers of government "solutions" in general. > > 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. > I guess it wasn't explicit in my proposal, but the intention is for SBN nodes to be LN nodes. Thus, in order to be accepted into SBN, your node would have to run the LN software. Is there a way to set up an LN node, connect to other nodes, and then not allow routing of payments through your node? If so, then I don't believe SBN would be any more in danger of this scenario than vanilla LN. > 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). > Yes, it would be expensive both in server costs and in cost-of-capital locked up in nodes. I believe incentives are aligned correctly. > > (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) > You've convinced me that node liquidity limits do not make sense. I am moving instead to minimum node capacity requirements with no maximum number of channels or capacity limits. > 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. > I like the sound of blinded commitments. Any suggestions for where to read up on this approach? > > 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. > > How would this approach differ from the OTS server setup? OTS is using Merkle trees no? (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 > Best, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: