Re: [Lightning-dev] Superbolt Proposal - a professionally run LN subset delivering superior UX
Good morning Robert, > > 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. Anyone who can update the software can easily create a faked node that appears to have completely legit channels to one or more real nodes. Basically, I would just write a little bit of signing code using the node secret of a real node I control, put up a UTXO somewhere with a new ephemeral key I control plus the node id of my real node, and voila I can have a non-working "channel" that attests to a non-working "node" on the LN, and I can make that non-working "node" attest its uptime over SBN using a cheap 5mBTC RaspPi. I can make the "channel" UTXO almost as secure as my hardware-wallet-locked funds by making the non-working "node" id be a key from my hardware wallet, and then this fund is no more than me HODLing BTC onchain with my hardware wallet (channels are 2-of-2 so even if my real node is compromised and its private key stolen, the funds in my non-working "channel" are still protected by my hardware wallet key). I can easily run a few real nodes, over Tor .onion services, on a single low-end server, and then have them attest to non-working "channels" attesting to a few non-working "nodes" on the LN, and then run a simple SBN self-attestation daemon on the RaspPi to attest the faked "nodes" on the SBN. Since the SBN is intended to interconnect to the LN, the real nodes do not need to have a lot of capitalization themselves or be on the SBN, so for example I could have one or two real node on the SBN and a few throwaway real nodes with little capitalization, interconnected with channels to the faked node. I might do this, for example, if Roger Ver suddenly offers me a few hundred BTC (not BCH, sorry) to attack the SBN and reduce its UX to not much better than the 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. Yes, but it might not be enough --- we want SBN attestation itself to be a cost, and thus SBN might want to charge higher than current feerates for premium reliable service. > > 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? Generally when we say "commitment" that is a cryptographic
Re: [Lightning-dev] Superbolt Proposal - a professionally run LN subset delivering superior UX
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,
