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 commitment scheme, commitments *are* blinded already. They are cryptographically blinding and cryptographically binding (you have a choice between: information-theoretic blinding and computationally-infeasible binding, or computationally-infeasible blinding and information-theoretic binding). The issue is if an OTS-server demands to see the opening of a commitment before adding it to their Merkle trees (for example, if it becomes expensive to hire an OTS-server, they might offer a discount for this). Basically a comnitment can be as simple as a hash of a salt plus the information you are committing to. If the OTS-server demands to see the preimage before adding the hash, then we have a problem because the OTS-server can now filter depending on the information it sees in the preimage. What we need to do is basically have every SBN node insist on using an OTS-server that does not demand the opening of the commitment, just accepts the commitment (which is already blinded). > > > > 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? *Currently* the single OTS server available is, well, a single server run by a single individual, Peter Todd, with Peter shouldering all the (very tiny) expenses of running that server. If you make the reliability of SBN dependent on this single server, it paints a big target on the single OTS server and its operator, which is bad. If instead anyone can run an SBN attestation server, this would use roughly the same technologies (blockchain-embedded Merkle trees of commitments) but would be distributed at least, and follow the principle of Risk Sharing (at the cost of increased blockchain usage). Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
