RT @GlobalMeshLabs: State Chains (like Channel Factories) suggest a way for off-grid mesh nodes to setup payment channels with each other using a local federation of nodes on the same local mesh network.
This could replace the need for an on-chain transaction facilitated by an internet gateway. https://t.co/2JuisrvIsg
Statechains turn the concept of Bitcoin transactions on its head. Instead of sending coins from address to address, statechain users just send the private key that can be used to spend the coins.
Here’s why that’s not as crazy as it sounds, by @AaronvanW. https://t.co/uJninbcj8zhttps://t.co/LZg9tN0GPe
You linked to a publication, not a patent. Did it issue as a patent anywhere, or are you yet another dumbfuck who doesn't know the difference?
It hasn't even been filed as a national-stage application in the U.S., which would arguably be their most important national filing destination.
Not quite. The statechain invention has the "exchange platform" signing blinded, whereas under the patented invention the "exchange platform" signs cooperatively with the second party. IANAL though so maybe it's near enough?
Not really. The patent describes only single transfers of money, not chains, and the exchange platform is fully aware that it is working with Bitcoins. It's like saying Satoshi was envisioning the Lightning Network already when he was groping towards payment channels with his broken implementation of `nSequence`.
Is anyone actually able to see an article? I get a page with a giant logo graphic in the center, and a menu bar at the top. No text whatsoever. Both of the "archive" sites that I know of show the same.
Even looking at the web page source, there is no article text tucked away among all the HTML tags.
The biggest problem with this proposal that I can see is that it doesn't actually scale Bitcoin; it just moves transaction data into a separate chain. Participants would then need to download both the main chain and the state chain, which is no better than simply having Bigger Blocks℠ on the main chain.
It seems like it could scale better than sidechains, because every coin is its own chain, so you only track the full history of coins you receive. You do need a list of all chains in order to ensure your chain is only listed once. Note that the history can also be reset with a single on-chain transaction.
> every coin is its own chain
Does that mean, in practice, you would need to download the entire statechain for each coin you receive? Given that statechain coins will likely have to be in quite fine denominations to be useful, that could be a lot of history for each coin and a lot of coins in each payment. Imagine if you needed to download the entire history of every hand that every dollar bill you touch has ever been through.
It's hard to tell how fine the denominations will be in practice, but yes, you'd have to download the history of each coin you want to receive. While this is less data than downloading the history of all coins, it's not something you'd be able to do ahead of time (like in IBD). I imagine a UTXO with a long history could grow to a couple of MB.
It might be kind of interesting to use statechain coins for the "large denominations" and then fill in the remainder (like under 1 mBTC) with a Lightning payment. That would play to the strengths of each technology.
Two points I want to make:
* This is an optional layer, which is fine in my opinion. No one has to use it.
* For some companies this may be a better solution given their tech budgets. It could prove to be efficient for their needs.
We will have a lot of Layer 2 solutions, and we should keep seeing these surface as long as they don't interfere or impact the development of Layer 1.
Yes, I understand that. That doesn't change the mathematical fact that this doesn't scale any better than the base Bitcoin layer. In other words, statechains add *capacity* but do not improve *scaling*. In order to improve *scaling*, a proposal must not require all users (of the proposed technology) to receive and verify all transactions of all users (of the proposed technology).
* Lightning **is** a scaling solution because each Lightning user **doesn't** need to know or care about the Lightning transactions of any other Lightning users.
* Statechains are **not** a scaling solution because each statechain user **does** need to know about and validate the statechain transactions of every other statechain user.
You make a valid observation about Sidechains vs Lightning. Allow me to add a few more:
\- Lightning is limited in throughput. You cannot send more than the channels allows, and the more you send, the higher the fees.
\- Sidechains do achieve some limited amount of scaling, depending on economic activity. E.g. if Bitcoin is the "world" chain, and there is a "Europe" and "Asia" sidechain, then you'd only have to verify Bitcoin + "Europe" or Bitcoin + "Asia"
\- Statechains scale differently from Sidechains, because every coin is a chain.
Staechains seem different enough to be potentially useful in some situations, which imo is good enough.
The intent is that the statechain data is of interest only to the direct participants signing on the statechain.
Onchain you do not depend on SPV, you depend on the fact that the federation signers are working honestly. Given that assumption you don't really care what the statechain is.
It is mildly different from true Federated sidechains in this manner:
1. The starting participant set selects the federation. There is no fixed federation that all Statechain users must use. This distributes the risk relative significantly better than Liquid or Rootstock: no single federation is likely to lock more than 0.1% of coin supply (exchanges are much bigger risks than this and you can't audit them).
2. The federation members cannot be sure 100% that they are signing Bitcoin txes under the hood; as blind signers in theory they could be signing random nonces. Even if their signature and pubkey is published onchain they cannot recognize it since a tweak known only to participants is added.
3. Even if the federation realizes they're signing Bitcoin txes, they can steal only with the cooperation of at least one participant.
The above is supposed to assure us that we need only check the signature onchain, since federation fuckery is unlikely.
For myself I probably wouldn't use it either.
The benefit it adds to channel factories is the ability to add and remove factory participants offchain. That's it. You can't add more funds to the factory without onchain activity, you can't remove funds from the factory without onchain activity. It's not a big enough advantage IMO, but I'm cautiously hedging that *maybe* it will be useful in practice, so I don't entirely dismiss it.
Thanks for your thoughts, almkgor. I'm happy to see people like you are thinking about it deeply.
> There is no fixed federation that all Statechain users must use
It would be harder to do swaps across federations, because everyone needs to agree on who to trust. It also seems strictly superior to have one big federation as opposed to many smaller ones.
> The above is supposed to assure us that we need only check the signature onchain
[As I mentioned, that is not entirely accurate](https://www.reddit.com/r/Bitcoin/comments/c0npb6/statechains_sending_keys_not_coins_to_scale/ercgn68?utm_source=share&utm_medium=web2x). And more generally, I would not use Statechains if you do not trust the federation that runs it.
> you can't remove funds from the factory without onchain activity
You can, by swapping Statechain UTXOs, and this is quite crucial. E.g. if you have a 2BTC UTXO with a BC channel where B has 0.5 and C has 1.5, you can swap the 2BTC UTXO for two 1BTC UTXOs, one of which owned by BC (B 0.5, C 0.5) and the other by Carol.
Perhaps I'm not following the argument, but it seems he's arguing you need to be part of the federation, rather than making an argument against large federations. That argument very clearly holds for N-of-N, but becomes weaker in M-of-N.
But I do agree that 3-of-5 where you trust 3 participants is better than 30-of-50 where you trust 3 participants, so I guess an argument for custom federations can be made, but I do suspect the coordination problem of having to trust the same federations in order to trade with someone makes it complicated.
Yes, I believe ZmnSCPxj is indeed arguing for small N-of-N federations.
> I do suspect the coordination problem of having to trust the same federations
Suppose we are two participants. I don't trust you. I elect myself and one of *my* trusted entity. You elect yourself and one of *your* trusted entities. We create a 3-of-4 federation, so that even if you or me is offline, assuming our trusted entities are permanently online, we can still operate the federation.
If we want to have m-of-n federations where m = n - k, then we can have each participant elect k + 1 members to the federation.
>in order to trade with someone makes it complicated.
Trade can be done across cryptocurrency systems by use of HTLCs (or Scriptless Script equivalents). The Statechain mechanism is just another cryptocurrency system. If I want to trade money from one statechain I trust to another statechain you trust, we just need to find a participant common to both statechains that will accept an HTLC (or SS equivalent). You know: LN routing.
(That's why I think LN is the future of scaling, and no scaling solution will be worth the effort to implement unless it actually works well with LN)
In any case, a single central federation is a single point-of-failure, and multiple participant-selected federations are more resilient, at least to my thinking.
> If we want to have m-of-n federations where m = n - k, then we can have each participant elect k + 1 members to the federation.
In practice that seems to come down to having to trust 33% of the federation in order to accept its services, regardless of whether you yourself are in the federation.
> If I want to trade money from one statechain I trust to another statechain you trust
That was the part I meant would become difficult. Our set of tradeable coins is limited to the set of federations we both trust, which makes me think it's likely that everyone will just gravitate towards a single highly reliable federation.
>In any case, a single central federation is a single point-of-failure, and multiple participant-selected federations are more resilient, at least to my thinking.
It is a point of failure, and I do think the market should be free to create any set of federations it likes, so generally speaking I support the possibility of your vision.
I guess you could have a list of trusted federation members Any chain for which 33% of the federation isn't on your list gets rejected. If you are picky, it means your set of acceptable coins shrinks.
1. I think the statechain could be smaller than a blockchain. Just a chain of signatures, no need to verify or keep all the other (backup) transaction data.
2. On Bitcoin (on-chain) everyone needs to keep track of all transactions. But there could be many statechains, and you wouldn't need to keep track of everything that happens on all of them.
Pinging /u/rubensomsen so he can correct me if I'm wrong.
You do have to unblind and verify all off-chain backup transactions (otherwise their backup transaction might have higher on-chain priority than yours), but only for coins you're interested in receiving. See also [here](https://www.reddit.com/r/Bitcoin/comments/c0npb6/statechains_sending_keys_not_coins_to_scale/ercfdev?utm_source=share&utm_medium=web2x).
> But there could be many statechains, and you wouldn't need to keep track of everything that happens on all of them.
This is the same tired argument that's been made over and over for altcoins, but it rings hollow. It's not *scaling*.
The same argument underlies Lightning, for that matter: you don't have to audit transactions occurring in the channel. Lightning channels even have an ever growing "shachain" that contains the revocation keys for every revoked state update. Why is ithe argument valid for LN but not here?
Under Lightning, the signers onchain are the participants of the channel. We depend on their self-interest: a participant would not sign off on a particular state update and revoke the current one unless their interests are served by it. In a certain point of view, it has a federation, but all participants in a channel are the federation members and activity requires consensus of the federation, not a quorum. So we don't need to audit the channel activity: we depend on the self-interest of the participants.
Under statechains, the federation is not the participant set and it votes on a quorum (m of n). The setup is better than federated sidechains: federation signers are blinded and cannot know which UTXO they are signing for (if any), federation signers cannot steal except with collusion of at least one participant. That is the argument for why we won't need to audit the statechain activity. I don't quite buy it myself.
Interesting Lightning comparison. Note that with eltoo there will no longer be a need for revocation on Lightning.
> That is the argument for why we won't need to audit the statechain activity
You do need to audit the Statechain activity (see [here](https://www.reddit.com/r/Bitcoin/comments/c0npb6/statechains_sending_keys_not_coins_to_scale/ercfdev?utm_source=share&utm_medium=web2x)), because otherwise they can misbehave without anyone noticing. At the end of the day you are still trusting the federation, because we have to assume the worst case where they unblind your transactions and intercept the transitory key.
> Note that with eltoo there will no longer be a need for revocation on Lightning.
Publishing a later state in Decker-Russell-Osuntokun, when an old state is broadcast, is "equivalent in spirit" to revoking an older state in Poon-Dryja, so I see this as a distinction without a difference.
> is "equivalent in spirit" to revoking
In some senses, yes. Note that I was saying that in reply to this:
>Lightning channels even have an ever growing "shachain" that contains the revocation keys for every revoked state update
This is no longer true for eltoo. You only need to keep the last state.
>The same argument underlies Lightning
I don't see how. Each Lightning participant only needs to download/store the Bitcoin blockchain, the current channel graph, and the history (revocation keys) for only the channels directly pertaining to the participant. Each statechain participant would need to download/store the Bitcoin blockchain and an ever-growing additional chain that contains data not directly pertinent to the participant. So that is still linear growth of bandwidth/storage in proportion to the number of payments made in the entire network. Contrast to Lightning, which has linear growth in proportion to the number of payments made by the individual user.
Then you misunderstand statechains and my post.
1. It is not a single chain that has all transactions of all statechain users. Instead, if you are a participant in a statechain-backed cryptocurrency system, you keep around the statechain data, just as you keep around the shachain containing the revocation keys iof a Lightning channel.
2. The above is argued for statechains based on the argument that the federation signers are blinded and cannot do anything other than refuse to sign (with a unilateral-close fallback available, any participant can drop onchain in case of federation failure, something you cannot do with federated sidechains) or sign blindly and honestly according to the blind signing algo, if it sees all participants signing the update.
3. I don't quite buy the above argument for statechains.
3. I am saying your argument is technically wrong (Lightning is hit hy your argument too, but has a counterargument that you don't need to audit it because of incentives), but is correct in spirit.
> Instead, if you are a participant in a statechain-backed cryptocurrency system, you keep around the statechain data **of all users of that statechain**, just as you keep around the shachain containing the revocation keys iof a Lightning channel **for only your own channels**.
Are you seeing the distinction?
And what I am pointing out is that for Lightning, there is a good reason why you only audit your own channels and not every channel: i.e. you can depend on the incentives of the participants of each other channel.
I am agreeing with you here, simply telling you to be more precise in your objection.
A Lightning user need only care that the base layer is operating honestly and that the counterparties in that user's own channels are operating honestly. Dishonest actions by *other* Lightning users aside from that user's own counterparties are *irrelevant* to that user, so their incentives are also irrelevant.
Precisely; it is irrelevant since if the other Lightning users are self-serving, they will be doing the right thing (i.e. not sign states that make them lose money, not steal because you might be watching/have a watchtower). Statechains require that the federation is audited, and the federation being self-serving would be more interested in actively stealing coins. Blinding the federation helps reduce, but not eliminate, this risk.
My understanding of the proposal is that the person running a state chain would not need to download and verify the entire chain, but only the data about his utxo. I don't know if that claim is accurate, but that's how I've heard it reported.
I don't yet understand the proposal well enough to answer your question with any kind of accuracy. But when I heard about the proposal, I came away with the impression that -- at least the *claim* is -- the security assumptions are so different from a *normal* sidechain that all the information you need for full security is available without verifying everybody else's transactions. It honestly sounds too good to be true to me, so I don't believe it yet. But if it's even SPV-level privacy that would still be good enough for the vast majority of transactions. But I'm awaiting the feedback of more knowledgeable people.