News for hackers. Stuff that matters.
Re:What Satoshi Did Not Know (2015) [pdf] by jentist_retol on Friday September 04, 2020 @04:26PM (#24378566)
Decentralization works great for small communities and use cases. The moment you start scaling you run into a myriad of problems:

- fraud/abuse (spam)

- outsized influence of providers who make it easy to get on board without having to self host (gmail)

- inability to easily change your protocols to handle new features (IMAP4 is from the 90s)

- inflexibility to easily fix bugs and distribute patches across the entire fleet

- unequal footing in both feature capacity and security posture from node to node

Email, Matrix/Riot, etc all suffer from these problems. As does bitcoin. That's not to say that they're not overcomeable, but many of the challenges (especially fraud/abuse) require close collaboration between different decentralized node owners - which to some, defeats the purpose. I ask, what is the internet if not a way to communicate, so I guess I don't think it defeats the purpose.

I'm actually interested to see what matrix is doing, because they seem to realize that a platform of decentralized nodes that handles a lot of the challenges (updates, auth, etc) means that people will be able to build their own new use-cases on top of the network, or diverge.

Anyways, despite these problems, despite the uphill battle in user experience, despite the pain of self-hosting, despite all of the challenges: I still do it.

The internet is a miracle and one way to keep it a miracle is to take the reins of your presence on it.

Re:What Satoshi Did Not Know (2015) [pdf] by MrXOR on Friday September 04, 2020 @04:38PM (#24378660)
This is the blockchain trilemma: Decentralization, Scalability or Security, choose only two.
Re:What Satoshi Did Not Know (2015) [pdf] by realsunnyg on Friday September 04, 2020 @05:11PM (#24378930)
That isn’t the trilemma - it’s decentralization, scalability and global state.
Re:What Satoshi Did Not Know (2015) [pdf] by neosat on Saturday September 05, 2020 @12:45AM (#24381463)
That's true for distributed computing in general so it has nothing specifically to do with the blockchain protocol itself.
Re:What Satoshi Did Not Know (2015) [pdf] by MrXOR on Friday September 04, 2020 @05:17PM (#24378974)
Global state? Please explain more.
Re:What Satoshi Did Not Know (2015) [pdf] by vishnugupta on Friday September 04, 2020 @05:44PM (#24379180)
Perhaps they meant global consensus?
Re:What Satoshi Did Not Know (2015) [pdf] by hinkley on Saturday September 05, 2020 @12:20AM (#24381390)
How is global consensus not global state?

What are we consensing on, if not a mutually agreeable set of facts (state) that we can use as a basis for future decisions?

If the answer is “nothing” then you by definition have a toy, not a tool.

Re:What Satoshi Did Not Know (2015) [pdf] by pfraze on Friday September 04, 2020 @09:47PM (#24380754)
I suspect they’re referring to how some blockchains (eg ethereum) are using sharing and lightning to scale
Re:What Satoshi Did Not Know (2015) [pdf] by noxer on Friday September 04, 2020 @06:04PM (#24379344)
It has been solved long time ago. Just remove the PoW its not needed. XRPL did it first others followed.
Re:What Satoshi Did Not Know (2015) [pdf] by MrXOR on Friday September 04, 2020 @06:11PM (#24379409)
Ripple is not permissionless. I think Algorand[1] is the first.

[1] https://people.csail.mit.edu/nickolai/papers/gilad-algorand-...

Re:What Satoshi Did Not Know (2015) [pdf] by dlubarov on Friday September 04, 2020 @06:32PM (#24379558)
That Algorand paper suggests a way of scaling consensus to large numbers of nodes, i.e. by running a consensus algorithm on a random sample of nodes. It doesn't address scalability with respect to transaction volume, which is what people usually mean in the context of the blockchain trilemma.
Re:What Satoshi Did Not Know (2015) [pdf] by MrXOR on Friday September 04, 2020 @06:43PM (#24379623)
>It doesn't address scalability with respect to transaction volume.

For scalability with small transaction volume, Coda[1] is the best.

[1] https://codaprotocol.com

Re:What Satoshi Did Not Know (2015) [pdf] by noxer on Friday September 04, 2020 @07:08PM (#24379822)
Thats laughable nonsense tbh. People should "mine" to compress the blockchain lol. The blockchain isnt even needed (the history). Have a look at XRPL srsly its the perfect example it has terabytes of past transactions and they are stored by some nodes but its not needed to make progress. And ofc it could be compressed but that totally destroys its purpose. If you want the transactions you want to be able to query them which you cant do efficient if its compressed.
Re:What Satoshi Did Not Know (2015) [pdf] by tromp on Saturday September 05, 2020 @06:41AM (#24382677)
History is very much needed to verify that the current state was arrived at by following the rules.
Re:What Satoshi Did Not Know (2015) [pdf] by noxer on Saturday September 05, 2020 @10:44AM (#24383899)
No, that's commonly made up thing coming form bitcoin where "balances" don't exist and the state of the ledger is defined by chain of past transactions. It is a design decision not a fundamental rule. It does not apply to the XRPL where each closed ledger has to follow all rules and contains all information to make forward progress. For example if a balance would be made up it would guaranteed violate a rule now (in the current ledger) there is no need to know the past transactions because if you add balances that would change the sum of all balances which obviously violates the rules. So form that point on each following ledger would be obviously and known in real time to be invalid. In reality ofc that cant happen because the software would simply not include a transaction that causes the invalid state. If for any reason there would actually be something considered "wrong" in the past it would not have any effect. The system is the code itself all participants agreed on running the same code and agreed on that what the code deems valid is valid and unchangeable forever. A bug can be fixed but what it caused in the past cant be. So the whole validation thing is useless it was validated already by the rules (the code) that was running back then. Validating it again with a bug fixed version of the code is useless. Just like if you would find an error in the bitcoin blockchain that validated fine with the version from that time. So what? it doesn't matter it cant be changed and if someone sends you bitcoins he only has because of a bug how does that matter if it don't change anything in the presets? You don't have to trust that no mistakes where made in the past you only need to trust that the past cant be changed to rely on the system in the presets.

Here's an example how you can validate the current state without knowing the past.

Imagine there are 100 coins made form something that does not exist beside in these coins. Someone wants to pay something to you using 2 of these coins. Do you need to know where he got them from and where the person before got them from and so on? If you know there are only 100 in total. (state is public) And no way to change that. (rules/code is known) And you know that if you take the 2 no one can force you to give it back. (transactions are irreversible) Then no, you don't need to know the past transactions at all. Maybe they where stolen in the past a thousand times also lost and found by someone else many times. Does it matter? Not at all.

Re:What Satoshi Did Not Know (2015) [pdf] by tromp on Saturday September 05, 2020 @02:39PM (#24385833)
The need to verify history applies to all cryptocurrencies, including account-based ones like Ethereum and XRP. You can assume the current state as valid and verify from there on, but then you're not a fully verifying node, and you risk being fooled by some peers presenting you with a made-up current state.
Re:What Satoshi Did Not Know (2015) [pdf] by noxer on Tuesday September 08, 2020 @01:37AM (#24405496)
You just repeated yourself and you are still wrong. Maybe read my message or inform you somewhere else. There is no way for anyone to fool you with a made up state. The systems state is public remember? It's up to you from whom you get it but usually from one node and the hash from many others to verify that all have the same state) And unlike with bitcoin there cant show up a longer chain later.
Re:What Satoshi Did Not Know (2015) [pdf] by noxer on Friday September 04, 2020 @06:25PM (#24379491)
You didn't even say permissionless in your post. Ripple is a company you mean the XRPL. The XRPL is permissionless in every aspect. You can insert transaction without anyones permission. You can run a node without anyones permission. You can fork and create you own version without anyones permission. You can change code and create an amendment without anyone's permission. It needs 80% favorable votes for two weeks to become active but it doesn't need anyone's permission. There is no entity that can vote against it and prevent it.
Re:What Satoshi Did Not Know (2015) [pdf] by fossuser on Friday September 04, 2020 @06:00PM (#24379319)
I think you point out a lot of issues with decentralized services that lead to centralization.

Matrix is exciting, but still has the hosting problem. Even with the easy ability to get a host from them for $10/month you're still going to have a handful of players providing most of the hosting.

I think Urbit's design is actually really interesting and makes some progress on a few of these problems.

> Fraud/abuse (spam)

Their ID model that has inexpensive and limited IDs that require some cost ($10-20) change the economics on spam. IDs carry a reputation.

> Outsized influence of providers

Urbit still has some of this in the sense that where you host your 'planet' (basically your private server) will probably end up being dominated by centralized groups that do this work for you. Where it's different though is the design of urbit means your server is only accessible by you and the communication is still p2p/encrypted. It's a little like Matrix in that way, but the design makes install and updates way easier.

The other cool bit is that the p2p complexity is abstracted away at the application layer, so things are decentralized by default without the users having to be aware of any of that complexity. You'll eventually be able to share photos from one user to the other and no centralized server is required.

> Bug fixing across fleet

Urbit's hierarchical structure is a good solution to this too. There are 256 'galaxies' which are voting governance nodes in the network. Each of these spawn 256 'stars' (basically infrastructure nodes) and each star can span 65,536 'planets' (individuals IDs or private servers for users). Updates come down the pipe from stars and get seamlessly applied to all users on the fleet.

User planets can escape to a different star if their star becomes a problem. Stars are incentivized to remain up and neutral in order to stay relevant. Similarly stars can escape to different galaxies if there's an issue with theirs. In an extreme case a 'stellar congress' could push back against the galaxy governance body if they had to and start reporting to their own.

- unequal footing in both feature capacity and security posture from node to node

The OTA approach and functional VM design solve this for Urbit.

https://urbit.org/using/install/

A more detailed introduction: http://hyperstition.al/post/urbit-an-introduction/

Anyway - I've playing with it for the last few months during lock down and it's the most interesting thing I've seen in a while.

Re:What Satoshi Did Not Know (2015) [pdf] by nyolfen on Friday September 04, 2020 @10:14PM (#24380871)
i wrote that second link :) delighted to see it in the wild
Re:What Satoshi Did Not Know (2015) [pdf] by fossuser on Friday September 04, 2020 @10:37PM (#24380972)
Cool! - I thought it was a pretty good summary of a lot of the details.

Thanks for writing it.