571–576 of 576 posts
Earlier quoted context omitted.
I have read that whitepaper. That was the first think I read when I started researching about the whole crypto and blockchain space. And this is the culmination of my research https://bit.ly/3OB5G18
I'm sure that that is a wonderful paper, behind a paywall.
Earlier quoted context omitted.
> There's a lot more entities Yes. That's decentralization. Rather than trusting one person irrevocably, you trust cryptographic security and the rational economics that emerge from alignment of incentive. Minimal trust in all other actors in the system, rather than maximum trust in one entity. > it becomes harder to understand Not really.. The general principles underlying blockchain are relatively simple. I'd agree…
>> it becomes harder to understand > Not really.. Oh Yes! As usual in blockchain defense, you must make a lot of assertions. > Yes. That's decentralization. Please not that tone. You don't assume you need to teach me, I even did some programming when this was new to try out the new tech. The proponents always only ever have a lot of hot air and a lot of faith , but never anything real.
Earlier quoted context omitted.
No, its really not. It is literally just a puzzle which solves the "problem" as to who gets to write the next block. Instead if you define the rules for the next block as strict as possible so it essentially eliminates a huge variety of possible blocks, participants can instead easily agree on one (the best) block (one that follows all rules and is objectionably better than all other possible blocks). There is no nee…
How do you solve double spend? So you make your objective rules as to what is the best block by defining some measure of quality (maybe include the most transactions that fit in, maybe sorted by fee-per-byte or so). Now all the good nodes agree on the next block B1 and then start working on B2 (not much work to do, because no PoW, but whatever, they build the next block B2.) Meanwhile, evil actor Eve has transferred…
A double spend would need to happen in the same block but all transaction are ordered sequentially so the second one will fail anyway as it still tries to moved funds that are already moved. The nodes just have to agree on one, it doesn't matter which one. If someone internationally tries to send the same funds to Bob an Alice he's just flipping a coin as to who will get it. Alice doesn't care and Bob doesn't care either. They only care about it being final if they see the funds in their account. And the rest of the network doesn't care that Eve is being a bit silly and wants a "decentral coin flip" to decide where the money goes.
Earlier quoted context omitted.
No, its really not. It is literally just a puzzle which solves the "problem" as to who gets to write the next block. Instead if you define the rules for the next block as strict as possible so it essentially eliminates a huge variety of possible blocks, participants can instead easily agree on one (the best) block (one that follows all rules and is objectionably better than all other possible blocks). There is no nee…
"agreeing is way more efficient" Then it's not trustless is it?
Its trustless in the sense that you yourself can apply the rules and verify that each block follows the public rules. The "agreeing" is only within the rules and the rules are in the code. So you have to trust (or verify) that the code actually does implement the rules the way you want them to be.
Earlier quoted context omitted.
How do you solve double spend? So you make your objective rules as to what is the best block by defining some measure of quality (maybe include the most transactions that fit in, maybe sorted by fee-per-byte or so). Now all the good nodes agree on the next block B1 and then start working on B2 (not much work to do, because no PoW, but whatever, they build the next block B2.) Meanwhile, evil actor Eve has transferred…
There is no block 2 created if block 1 is not final. Once consensus is reached on what is in B1 it doesn't matter anymore if someone comes around with a different idea what should be in B1. So by the time the nodes "debate" over B2, Alice has the money and its final. There can not be a double spend with time delay in between because the second transaction ties to move already moved funds so its objectively invalid. A…
So, when a new node comes online, and some of the existing nodes say that they've agreed on B1 and B2, and some other nodes say that they've agreed on B1' and B2', how does that new node decide which is the consensus? [0] With PoW, the decision criterion is easy: the longest chain rule (LCR) [1]. In your system, what's the rule?
[0] This is trivial with a central authority. But remember, here we have an open public blockchain, where anyone can join as a node, and they might be malicious.
[1] And as long as there are competing chains of equal length, just pick one randomly. That procedure, rather than picking the first one encountered, improves resistance to the selfish mining attack, IIRC
Earlier quoted context omitted.
There is no block 2 created if block 1 is not final. Once consensus is reached on what is in B1 it doesn't matter anymore if someone comes around with a different idea what should be in B1. So by the time the nodes "debate" over B2, Alice has the money and its final. There can not be a double spend with time delay in between because the second transaction ties to move already moved funds so its objectively invalid. A…
> Once consensus is reached on what is in B1 it doesn't matter anymore if someone comes around with a different idea what should be in B1. So, when a new node comes online, and some of the existing nodes say that they've agreed on B1 and B2, and some other nodes say that they've agreed on B1' and B2', how does that new node decide which is the consensus? [0] With PoW, the decision criterion is easy: the longest chain…
> the longest chain rule (LCR) [1]. In your system, what's the rule?
There is no direct equivalent to the longest chain rule because blocks are final on every chain. There is no "chain switching" possible (that would directly contradict finality). Instead the system is made so that forks dont happen. The system will produce empty blocks rather than fork if the 80% quorum can not be reached (for example if huge parts of the world are temporary discontented from each-other).
So any actual fork would need to be intentional and thus actually produce 2 immutable chains in 2 different networks with finality. Nodes wont be able to switch between these chains, the intentional fork separates the network. If a nodes wants to switch later on that is the equivalent of turning it off and starting a new one on the other chain.
BTW this is not MY system its been implemented multiple times with the oldest running since 9+ years [1]. It has never forked so this is not an actual problem in the real world. Dude to the quorum of 80% every change (in the code) goes trough an amendment process and will only ever get activated if it has 80% support. If a node is overruled it still is on the same chain. Unless the owner refuses to update in time then his node becomes incompatible with the rest and is ignored.
[1]The oldest running distributed ledger ("blockchain") that uses this system is the XRPL. You can read about its consensus mechanism on xrpl.org/intro-to-consensus.html and xrpl.org/consensus-network.html There are ofc many other projects that build upon the same principles.