Lightning on Stellar: Technical Spec and Roadmap(stellar.org)
stellar.org
Lightning on Stellar: Technical Spec and Roadmap
https://www.stellar.org/blog/lightning-on-stellar-roadmap/
62 comments
Is there an advantage to Lightning/Stellar as compared to Lightning/Bitcoin? I understand that Stellar has far better speed than Bitcoin, but with Lightning being used as the transaction layer, does that speed difference matter?
Instant zero fee channel open/close. Plus stellar is also an ICO platform so you can issue your own tokens.
Stellar is already fast enough, but I think it will improve scalability. Stellar aims to be "the internet of money" and for this the current throughput of 1000 tx/s is just not enough.
Right, but that doesn't seem to answer my question. I know that Stellar isn't quite fast enough to become the word's money transfer solution on its own. It appears that the Lightning Network (or some other solution) needs to go into the mix for that. But once we're using Lightning Network, why do we need Stellar? Does Stellar have any advantage over Bitcoin as the underlying foundation? Or is the idea here just that Stellar doesn't want to be left out of the Lightning Network, rather than it solves some problem that LN would otherwise have?
EDIT: Proposing an answer to my own question, perhaps LN transaction fees could be significantly lower if using Stellar rather than Bitcoin as the supporting blockchain? If so, does anyone have any estimates regarding the difference?
EDIT 2: It does seem that there would be an advantage to Stellar at the time a channel is closed, since the fee for the underlying blockchain transaction should be significantly less.
EDIT: Proposing an answer to my own question, perhaps LN transaction fees could be significantly lower if using Stellar rather than Bitcoin as the supporting blockchain? If so, does anyone have any estimates regarding the difference?
EDIT 2: It does seem that there would be an advantage to Stellar at the time a channel is closed, since the fee for the underlying blockchain transaction should be significantly less.
Every single project I've seen that is looking into Lightning has simply offered lofty promises and roadmaps but without any compelling advantage of Lightning on their coin as opposed to Lightning on Bitcoin. If anything, they have a big hurdle to overcome - Bitcoin's first mover advantage with regards to LN development. PLEASE correct me if I am wrong, but as far as I have seen 99% of off-chain development progress has been Bitcoin/Litecoin, with other coins simply following the progress made and hoping to change a few parameters to make it compatible with their coin.
And the speed difference you mention is an important point - so many of these coins have acted as artificial capacity surrogates during Bitcoin's scaling woes. But with LN, I don't see their use at all...
And the speed difference you mention is an important point - so many of these coins have acted as artificial capacity surrogates during Bitcoin's scaling woes. But with LN, I don't see their use at all...
They allow faster and cheaper on-chain transactions.
Some prefer to avoid LN if possible, especially as its topology may turn out to be not as p2p as people prefer, and LN nodes may be operated by corporations who may or may not have KYC regulations that people would like to avoid. Besides this, there are general PoS vs PoW differences--some consider PoW an undesirable waste of energy while others consider it a way to secure the network.
Some prefer to avoid LN if possible, especially as its topology may turn out to be not as p2p as people prefer, and LN nodes may be operated by corporations who may or may not have KYC regulations that people would like to avoid. Besides this, there are general PoS vs PoW differences--some consider PoW an undesirable waste of energy while others consider it a way to secure the network.
I feel the same way about most new coins trying things out. Bitcoin just has to sit and wait for it to show promise (and stability) before integrating it and invalidating that coin's only differentiation.
Even things like smart contracts can be integrated into Bitcoin (I believe the Bitcoin Cash camp is working on this)
Even things like smart contracts can be integrated into Bitcoin (I believe the Bitcoin Cash camp is working on this)
The Bitcoin Core developers have been openly been hostile toward the smart contract use case. They even went so far as to change the size limits on Bitcoin's OP_RETURN op code in order to screw over Counterparty one of the original smart contract implementations. Vitalik Buterin, the creator of Ethereum, is on record saying that the whole reason Ethereum exists as a separate thing instead of a system on top of Bitcoin is because of the contempt the Bitcoin Core developers showed toward the smart contract use case.
Bitcoin has RSK (and Szabo)
RSK (RootStock) relies on side chains. Side chains still have unresolved issues before they can be used for real.
That's true, but I merely intended to say that there are plans to introduce smart contracts for Bitcoin, and there is considerable support for this. Naturally, this is intended as a second-layer solution.
I haven't looked into the Lightning/Stellar combo yet, but one thing that Lightning/Litecoin and Lightning/Bitcoin (and others) have is that you can abstract away which coin you are paying with, and which coin the vendor accepts.
If all the LN implementations match, then I could, for example, pay with Bitcoin on LN to a node that will convert it to Litecoin at a given price, then will send that payment to the vendor's node who will accept Litecoin as payment.
That gives a massive incentive for altcoins to support and match the Bitcoin lightning-network APIs exactly, as then it becomes much easier for them to gain market share based on their other qualities (like stability, security, decentralization, longevity, etc...)
If all the LN implementations match, then I could, for example, pay with Bitcoin on LN to a node that will convert it to Litecoin at a given price, then will send that payment to the vendor's node who will accept Litecoin as payment.
That gives a massive incentive for altcoins to support and match the Bitcoin lightning-network APIs exactly, as then it becomes much easier for them to gain market share based on their other qualities (like stability, security, decentralization, longevity, etc...)
Stellar is more bank-friendly: it can handle fiat currencies and fiat exchanges, and it supports regulatory compliance (KYC and AML).
Also — Lightning reduces fees and transaction times, but these costs still matter. The time and cost to open and later close a payment channel is a multiple of the latency and transaction cost of the underlying chain. Not very transaction will need a new payment channel, but other things being equal (in particular: connectivity of the Lightning graphs, average transactions per payment channel), the network with lower non-Lightning costs will have proportionally lower Lightning costs too. The cost matters when there’s lots of transactions; the latency makes a difference to both mean and worst-case Lightning transaction and settlement time.
Stellar also uses less energy.
Also — Lightning reduces fees and transaction times, but these costs still matter. The time and cost to open and later close a payment channel is a multiple of the latency and transaction cost of the underlying chain. Not very transaction will need a new payment channel, but other things being equal (in particular: connectivity of the Lightning graphs, average transactions per payment channel), the network with lower non-Lightning costs will have proportionally lower Lightning costs too. The cost matters when there’s lots of transactions; the latency makes a difference to both mean and worst-case Lightning transaction and settlement time.
Stellar also uses less energy.
Transaction costs.
With the lighting network you still have to make 2 on chain transactions. 1 to establish the initial channel, and 1 to close it.
And this is PER channel that you establish.
These transaction fees could be quite high, if history is to be used as an example (only a couple months ago, fees hit something like 40 USD).
With the lighting network you still have to make 2 on chain transactions. 1 to establish the initial channel, and 1 to close it.
And this is PER channel that you establish.
These transaction fees could be quite high, if history is to be used as an example (only a couple months ago, fees hit something like 40 USD).
You only need to open a few channels to reliably connect to the network - the network allows you to transact with those you don't have a direct channel with. And in actual usage you won't ever need to close them. Lightning solves transaction costs.
Well that depends. If you run out of money, then you have to transfer more coins onto the network.
If you don't want to make frequent 'top up' transactions to what is effectively a hot wallet, then you'd have to lock away many thousands of dollars.
Transaction fees on chain still matter quite a lot if you are unwilling to lock away a whole bunch of money up front.
Also the more money that is locked away on the LN, the more vulnerable to attack it is.
This is because one can attack the network by DDoSing the main chain, such that blocks are full for the time lock period. IE, if someone cheats and publishes an old LN transaction history, you have to publish your anti cheat transaction and if blocks are full for the couple weeks, then you can't defend yourself.
This style of attack only works if there is a bunch of money in the network though.
It is also counteracted if the main chain has high capacity as it becomes that much more expensive to attack the main chain.
If you don't want to make frequent 'top up' transactions to what is effectively a hot wallet, then you'd have to lock away many thousands of dollars.
Transaction fees on chain still matter quite a lot if you are unwilling to lock away a whole bunch of money up front.
Also the more money that is locked away on the LN, the more vulnerable to attack it is.
This is because one can attack the network by DDoSing the main chain, such that blocks are full for the time lock period. IE, if someone cheats and publishes an old LN transaction history, you have to publish your anti cheat transaction and if blocks are full for the couple weeks, then you can't defend yourself.
This style of attack only works if there is a bunch of money in the network though.
It is also counteracted if the main chain has high capacity as it becomes that much more expensive to attack the main chain.
Lightning for X means a way to transact in X without waiting for block intervals, for example for micropayments. Eventually it will be used to do rapid atomic swaps between tokens, and for this reason it will likely be available for all major tokens.
Bitcoin is the slow part of on-chain atomic swaps, so that could be a reason to implement lightning for tokens that already have fast transactions.
Bitcoin is the slow part of on-chain atomic swaps, so that could be a reason to implement lightning for tokens that already have fast transactions.
atomic swaps have awesome potential, the first to provide a stable intercurrency decentralized exchange with escrow of funds and wallets held by the asset owners with private keys will be a big winner :)
Speed? No, not really in comparison to any other LN implementation.
But Stellar will be supporting state channels in addition to payment channels, (presumably) allowing for even faster exchange operations (buy/sell market and limit orders) and path payments across multiple currencies, neither of which LN on Bitcoin can do (at least for now).
But Stellar will be supporting state channels in addition to payment channels, (presumably) allowing for even faster exchange operations (buy/sell market and limit orders) and path payments across multiple currencies, neither of which LN on Bitcoin can do (at least for now).
Also you can send inordinately small amounts, practically, with stellar/ln. The smallest unit of measure in Bitcoin, one satoshi, is already 1/110th of penny! It would cost you more than that to send it to someone and you would have trouble doing a million of those per second. This exact concept was used as a ddos of sorts to slow down legitimate Bitcoin transactions.
I'm currently looking into Nano (formerly Raiblocks). Coincidentally they've also just released their updated roadmap at the same time. https://developers.nano.org/roadmap
At the moment it appears like a lot of cryptos are jumping on the lightning solution, I'm curious to see if Nano can compete with them by avoiding lightning all together.
At the moment it appears like a lot of cryptos are jumping on the lightning solution, I'm curious to see if Nano can compete with them by avoiding lightning all together.
Who decided that "BUMP_SEQUENCE operation" should be implemented? Was there onchain governance or it was a authoritarian decision?
[deleted]
Perhaps someone could help me.
Lightning seems quite sound in theory, but I have misgivings about the order in which a fresh transaction is signed, and the secret to the old transaction revealed.
It would seem that by interrupting this chain before both old secrets are revealed, the attacker could safely claim all coins in the channel.
I'm probably wrong, but I'd like to know why.
Lightning seems quite sound in theory, but I have misgivings about the order in which a fresh transaction is signed, and the secret to the old transaction revealed.
It would seem that by interrupting this chain before both old secrets are revealed, the attacker could safely claim all coins in the channel.
I'm probably wrong, but I'd like to know why.
No one can close a channel before some given deadline, preset at the time of its creation.
By the protocol, the deadline for all relevant operations on the channel is set to before the channel close date.
By the protocol, the deadline for all relevant operations on the channel is set to before the channel close date.
So how does the system know what time it is? Host time is not reliable. Genuinly curious.
This is the reason why Ethereum contract usually set start time, end time and similar in block numbers. Block number is reliable while timestamp is just a local time of the miner that mined the transaction in which the contract call was included.
This is the reason why Ethereum contract usually set start time, end time and similar in block numbers. Block number is reliable while timestamp is just a local time of the miner that mined the transaction in which the contract call was included.
Timestamps in the block header. These timestamps are used to regulate the proof of work to maintain a block interval, so in the end both measures have the same time accuracy.
This isn't quite accurate to how we set it up.
Each step in our protocol could set a different amount of delay to close the channel. Beginning the close process does not require waiting, but finishing it does. It's actually the opposite, if you wait too long to close, you may not be able to close at all. This means that if you need to close it, and you can't reach your peers for the honest_close case, you better get to it!
Because each step can pick delay, the honest_close case allows a channel to close without any delay.
Each step in our protocol could set a different amount of delay to close the channel. Beginning the close process does not require waiting, but finishing it does. It's actually the opposite, if you wait too long to close, you may not be able to close at all. This means that if you need to close it, and you can't reach your peers for the honest_close case, you better get to it!
Because each step can pick delay, the honest_close case allows a channel to close without any delay.
Here's my understanding of how this works in a Poon-Dryja payment channel[1]. I haven't reviewed the Stellar proposal to see if it's substantially different.
Let's assume an Alice-Bob channel funded with 1 BTC, and look at how we get from payment state 1 (Alice: 0.5 BTC, Bob: 0.5 BTC) to payment state 2 (Alice: 0.4 BTC, Bob: 0.6 BTC), and who could do what during the transition. This is just a sketch, but I think it fills in what you're asking.
Payment state 1:
* Alice holds a transaction C1a, that only she can broadcast. C1a has two outputs: 0.5 BTC -> {Alice in the future; or, Bob if signed by Alice's key Ak1}; 0.5 BTC -> Bob.
* Bob holds C1b, which looks like C1a but with names reversed. [Names reversed except both transactions send the same amounts to each party. In this special example case of a 50/50 distribution, that comes to the same thing.]
Transition to payment state 2:
1. Alice and Bob create new transactions C2a and C2b, half-sign them, exchange them, yada yada. This is complicated and has internal steps where only some of the information has been exchanged, but I don't think it's the part you're asking about.
At this point, Alice could broadcast C1a or C2a without penalty, and Bob could broadcast C1b or C2b without penalty, so the channel hasn't conclusively moved to payment state 2. Any broadcast will either close the channel in payment state 1, which it's coming from, or payment state 2, which it's going to. So as long as everyone knows that payment state 2 isn't confirmed (which they do), this isn't really a threat.
(With physical currency: if I hand you a nickel, there's a period where it's not clear if you're going to take it and it's not clear if I'm going to let it go, but at the end of that period either I paid you — the new state — or I didn't — we're back where we were before I started to hand you the nickel, but no earlier.)
2. Alice sends Bob Ak1.
Now if Alice publishes C1a to the blockchain, he can take its both outputs. So she wouldn't do that. Alice can safely publish C2a, and Bob can publish either C1a or C2a. We're halfway to payment state 2.
3. Bob sends Alice Bk1.
Now Bob can't publish C1b without penalty, either.
If Alice and Bob are rational, nobody will ever broadcast C1a or C1b. (If Alice — the only person who can broadcast C1a — does so, she forfeits the channel funds to Bob; and vice versa.)
The channel is now in payment state 2.
---
[1] J. Poon, T. Dryja. “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments”, pp. 22–26, Section 3.3.4, “Creating a new Commitment Transaction and Revoking Prior Commitments”. This uses the terminology Commitment Transactions, Revocable Delivery Transaction, and Breach Remedy Transaction to describe the concepts that I've either waved my hands about or completely elided, above. It has lots of pictures. “Payment state” is my non-standard neologism.
---
“I got here the same way the coin did.” – C. McCarthy, No Country for Old Men.
Let's assume an Alice-Bob channel funded with 1 BTC, and look at how we get from payment state 1 (Alice: 0.5 BTC, Bob: 0.5 BTC) to payment state 2 (Alice: 0.4 BTC, Bob: 0.6 BTC), and who could do what during the transition. This is just a sketch, but I think it fills in what you're asking.
Payment state 1:
* Alice holds a transaction C1a, that only she can broadcast. C1a has two outputs: 0.5 BTC -> {Alice in the future; or, Bob if signed by Alice's key Ak1}; 0.5 BTC -> Bob.
* Bob holds C1b, which looks like C1a but with names reversed. [Names reversed except both transactions send the same amounts to each party. In this special example case of a 50/50 distribution, that comes to the same thing.]
Transition to payment state 2:
1. Alice and Bob create new transactions C2a and C2b, half-sign them, exchange them, yada yada. This is complicated and has internal steps where only some of the information has been exchanged, but I don't think it's the part you're asking about.
At this point, Alice could broadcast C1a or C2a without penalty, and Bob could broadcast C1b or C2b without penalty, so the channel hasn't conclusively moved to payment state 2. Any broadcast will either close the channel in payment state 1, which it's coming from, or payment state 2, which it's going to. So as long as everyone knows that payment state 2 isn't confirmed (which they do), this isn't really a threat.
(With physical currency: if I hand you a nickel, there's a period where it's not clear if you're going to take it and it's not clear if I'm going to let it go, but at the end of that period either I paid you — the new state — or I didn't — we're back where we were before I started to hand you the nickel, but no earlier.)
2. Alice sends Bob Ak1.
Now if Alice publishes C1a to the blockchain, he can take its both outputs. So she wouldn't do that. Alice can safely publish C2a, and Bob can publish either C1a or C2a. We're halfway to payment state 2.
3. Bob sends Alice Bk1.
Now Bob can't publish C1b without penalty, either.
If Alice and Bob are rational, nobody will ever broadcast C1a or C1b. (If Alice — the only person who can broadcast C1a — does so, she forfeits the channel funds to Bob; and vice versa.)
The channel is now in payment state 2.
---
[1] J. Poon, T. Dryja. “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments”, pp. 22–26, Section 3.3.4, “Creating a new Commitment Transaction and Revoking Prior Commitments”. This uses the terminology Commitment Transactions, Revocable Delivery Transaction, and Breach Remedy Transaction to describe the concepts that I've either waved my hands about or completely elided, above. It has lots of pictures. “Payment state” is my non-standard neologism.
---
“I got here the same way the coin did.” – C. McCarthy, No Country for Old Men.
The only way to close the channel before the deadline is by having all participants (in the channel) sign a closing transaction with all the updated balances.
Isn't Stellar cheap and fast enough to not need any Lightning Network at all?
Compared to other cryptos, Stellar is fast. Compared to credit card networks, Stellar is very slow.
If one of their goals is to replace credit cards and other money movement mechanisms (as I believe is the case), they need to speed transactions up significantly.
If one of their goals is to replace credit cards and other money movement mechanisms (as I believe is the case), they need to speed transactions up significantly.
The question then becomes what the point of Stellar is
To give the original creators (who pre-mined something like 17 billion tokens) a giant amount of money.
https://www.reddit.com/r/CryptoCurrency/comments/6bi958/ripp...
https://www.reddit.com/r/CryptoCurrency/comments/6bi958/ripp...
Unlike Ripple, where the pre-mined tokens are held by individuals, the pre-mined stellar tokens are owned by Stellar Development Foundation, a nonprofit corporation.
Here are some quotes, but do check the link bellow too:
"SDF manages the execution of lumen distribution, with oversight and direction provided by SDF’s Expansion Board. The initial lumens held by SDF are required to be distributed to the world in the following manner:
50% for distribution via the Direct Sign-up Program
25% for distribution via the Partnership Program
20% for distribution via the Bitcoin Program
5% held by SDF to support operational costs"
https://www.stellar.org/about/mandate/
Here are some quotes, but do check the link bellow too:
"SDF manages the execution of lumen distribution, with oversight and direction provided by SDF’s Expansion Board. The initial lumens held by SDF are required to be distributed to the world in the following manner:
50% for distribution via the Direct Sign-up Program
25% for distribution via the Partnership Program
20% for distribution via the Bitcoin Program
5% held by SDF to support operational costs"
https://www.stellar.org/about/mandate/
How much control does Jed McCaleb have over this foundation?
Are there any updates on the status of SDF as a non-profit? https://www.xrpchat.com/topic/17500-a-stellar-story/ suggests their tax exempt status is at least unclear.
Nothing could have been premined since there is no mining on Stellar.
Can handle fiat currencies; supports regulatory compliance (KYC, AML). Compared to Bitcoin: lower transaction fees, faster, lower energy costs.
(Stellar without Lightning is magnitudes faster and cheaper than Bitcoin without Lightning. Stellar with Lightning should be faster and cheaper than Bitcoin with Lightning — assuming the Stellar network is equally well-connected, which it might not be.)
(Stellar without Lightning is magnitudes faster and cheaper than Bitcoin without Lightning. Stellar with Lightning should be faster and cheaper than Bitcoin with Lightning — assuming the Stellar network is equally well-connected, which it might not be.)
Read the blog?
What’s the point? Stellar is centralized.
I think anybody can run a Stellar validator node[1], somewhat akin to anybody being able to set up a full Bitcoin node.
Ripple is completely centralized in all meanings of the word, and a lot of people confuse the two since Jed McCaleb is a shared founder between the two projects[2]. Having said this, the Ripple Foundation has tried to dispel this notion and claims that they have a roadmap for the Ripple ledger to become more decentralized[3], so perhaps it's fairer to say that Ripple is centralized today but in the future plans to become less so as they try to onboard 3rd party validators.
IBM seems to have stood up a large proportion of verified Stellar validator nodes[4].
[1] https://www.stellar.org/developers/stellar-core/software/adm...
[2] https://en.wikipedia.org/wiki/Jed_McCaleb
[3] https://ripple.com/dev-blog/decentralization-strategy-update...
[4] https://dashboard.stellar.org/
Ripple is completely centralized in all meanings of the word, and a lot of people confuse the two since Jed McCaleb is a shared founder between the two projects[2]. Having said this, the Ripple Foundation has tried to dispel this notion and claims that they have a roadmap for the Ripple ledger to become more decentralized[3], so perhaps it's fairer to say that Ripple is centralized today but in the future plans to become less so as they try to onboard 3rd party validators.
IBM seems to have stood up a large proportion of verified Stellar validator nodes[4].
[1] https://www.stellar.org/developers/stellar-core/software/adm...
[2] https://en.wikipedia.org/wiki/Jed_McCaleb
[3] https://ripple.com/dev-blog/decentralization-strategy-update...
[4] https://dashboard.stellar.org/
Anyone can deploy a node, but who owns 97% of the tokens?
https://www.reddit.com/r/CryptoCurrency/comments/6bi958/ripp...
https://www.reddit.com/r/CryptoCurrency/comments/6bi958/ripp...
That information may not be accurate, but either way there's confusion between two related things: Stellar and lumens.
Stellar is the technology which anyone can use to create tokens which may or not be exchangeable for other types of tokens created with Stellar. You can control 100% of the supply of the currency type of your choice within Stellar.
The lumen is the native asset of the Stellar network intended to stabilize the decentralized network. This is mostly pre-mined. Its intended use is as a bridge to facilitate exchanges between different currency types. An inconsequential amount of lumens are used as transaction fees (less than one hundred-thousandth of $0.01) to fight spam.
Stellar is the technology which anyone can use to create tokens which may or not be exchangeable for other types of tokens created with Stellar. You can control 100% of the supply of the currency type of your choice within Stellar.
The lumen is the native asset of the Stellar network intended to stabilize the decentralized network. This is mostly pre-mined. Its intended use is as a bridge to facilitate exchanges between different currency types. An inconsequential amount of lumens are used as transaction fees (less than one hundred-thousandth of $0.01) to fight spam.
I think the Stellar Foundation distributed 20% of the tokens so far (from the dashboard[1]), and holds back 5% of available token supply for their operating costs.
Your point still stands though: like Ripple, Stellar's token supply is still in early stages of distribution which gives the respective foundations immense influence over the nascent networks.
[1] https://dashboard.stellar.org/
Your point still stands though: like Ripple, Stellar's token supply is still in early stages of distribution which gives the respective foundations immense influence over the nascent networks.
[1] https://dashboard.stellar.org/
Does this mean that Stellar is completely decentralized, or is there some component that is still centralized? I'm not very knowledgeable about Stellar.
Most of the outstanding token supply is still held by the Stellar Foundation to be distributed. In my books, that means that it's still pretty centralized, but much less so than other ICOs or early coins that seem like outright scams.
The most charitable interpretation is that Stellar is on the right path to decentralization.
The most charitable interpretation is that Stellar is on the right path to decentralization.
But that means that every cryptocurrency is centralized, if I buy enough of it, which makes the term meaningless.
How does that make the term meaningless? If you owned 90% of a crypto currency it would indeed be centralized
If someone owns the vast majority of a crypto currency, they have a lot of control over the price
And since stellar is centralized in that way on purpose, I don’t see how calling it centralized is inaccurate
If someone owns the vast majority of a crypto currency, they have a lot of control over the price
And since stellar is centralized in that way on purpose, I don’t see how calling it centralized is inaccurate
Actually the term does have meaning:
https://en.wikipedia.org/wiki/Cornering_the_market
"Although there have been many attempts to corner markets by massive purchases in everything from tin to cattle, to date very few of these attempts have ever succeeded; instead, most of these attempted corners have tended to break themselves spontaneously."
https://en.wikipedia.org/wiki/Cornering_the_market
"Although there have been many attempts to corner markets by massive purchases in everything from tin to cattle, to date very few of these attempts have ever succeeded; instead, most of these attempted corners have tended to break themselves spontaneously."
Whether a cryptocurrency is centralized or decentralized has a specific technical meaning, namely whether a party is, by design, in control of the security or trust of the currency and can unilaterally make decisions. By that definition, Bitcoin is decentralized and Ripple is not.
If you remove the current state of the token supply, then I'd say that Stellar seems to be relatively decentralized as evidenced by the number of verified validators not under direct control or ownership by the Stellar Development Foundation (around 13% by number; don't know the validator splits by volume).
Stellar has a perfect architecture for their intended use case: https://news.ycombinator.com/item?id=16544704
I would argue that the SCP is more decentralised than Bitcoin, where a few companies hold almost all the hash power.
I would argue that the SCP is more decentralised than Bitcoin, where a few companies hold almost all the hash power.
Stellar is not centralized. Anyone can deploy a node.
https://www.stellar.org/how-it-works/stellar-basics/explaine...
https://www.stellar.org/how-it-works/stellar-basics/explaine...
Keep the cash for lawyers...
Author here. Happy to answer any questions about our protocol design.
Can any Stellar operation be used within a state channel, and as a result, can any Stellar transaction be sent through the LN?
For example, my use case requires users increasing and decreasing the limits on trustlines between them and another user, as well as making path payments across these trustlines. I know how to do that with Stellar proper, but could such transactions use the LN instead?
[edit]: nvm, should've read more carefully as it's mentioned explicitly in the article: "Stellar supports a more flexible generalization of payment channels called state channels, meaning that any operation you can execute on the Stellar network (such as not only payments, but also creating, deleting, or changing permissions on accounts), you can execute within a payment channel."
For example, my use case requires users increasing and decreasing the limits on trustlines between them and another user, as well as making path payments across these trustlines. I know how to do that with Stellar proper, but could such transactions use the LN instead?
[edit]: nvm, should've read more carefully as it's mentioned explicitly in the article: "Stellar supports a more flexible generalization of payment channels called state channels, meaning that any operation you can execute on the Stellar network (such as not only payments, but also creating, deleting, or changing permissions on accounts), you can execute within a payment channel."
Can the final transaction to the network (that closes a channel) be a series of transactions? In other words, can a state channel allow for transactions with more than 100 operations?
Actually, as a quirk of the design, the final transaction MUST be a series of transactions which are 'conflict free'.
For instance, if the close gives Alice 10 lumens and Bob 10 lumens, these must be expressed as two transactions. Otherwise, if Bob deletes his account, this causes a conflict when the transaction is published (and the transaction will fail). If they are two separate transactions, there is no problem if Bob deletes his account.
For instance, if the close gives Alice 10 lumens and Bob 10 lumens, these must be expressed as two transactions. Otherwise, if Bob deletes his account, this causes a conflict when the transaction is published (and the transaction will fail). If they are two separate transactions, there is no problem if Bob deletes his account.
Thanks for getting back to me!
> if the close gives Alice 10 lumens and Bob 10 lumens, these must be expressed as two transactions.
As in, in this case, closing requires two transactions, Escrow -> Alice and Escrow -> Bob?
Can closing allow for more than n transactions, where n is the number of participants in the channel?
> if the close gives Alice 10 lumens and Bob 10 lumens, these must be expressed as two transactions.
As in, in this case, closing requires two transactions, Escrow -> Alice and Escrow -> Bob?
Can closing allow for more than n transactions, where n is the number of participants in the channel?