 Show Posts
|
|
Pages: [1] 2 3 »
|
You can operate your stellar-core in two modes, validating or observing. If you are in validating mode you are both listening and participating in consensus.
But semantics aside, in Stellar anyone can participate in consensus. As in anyone can both listen and talk. It is true that maybe no one else will want to listen to you but there is certainly no barrier in the protocol keeping people from talking. And again if there is some cartel or some group that people feel are getting too much control it is trivial to set up your own nodes that are fully participating in consensus and have the non-cartel nodes listen to each other. This is simply not how reality works when it comes to namespaces, and supposing it were, it would also be bad, because in both instances you are sacrificing security. In the first instance, where a cartel is formed, the namespace is fully controlled and censored by them. In the second hypothetical scenario you raise, where a second cartel is created over the same namespace, you have a global conflict over the namespace and effectively a group-based MITM attack. In other words, the total destruction of consensus. So in both instances: Bad Things™. Also I'm not sure what people have in mind for the IETF ILC thing You may want to pay attention to how your software is actually going to be used. |
|
|
|
There was a thread on twitter ( https://twitter.com/taoeffect/status/832041974735654912) debating this question and I wanted to move it here since discussions on twitter usually aren't that productive. In my view Stellar is definitely permission-less. Anyone can run a validator. You don't need permission from anyone to join or use the network. Jed, it seems like there may be a misunderstanding over what the word "permissionless" means. Yes, anyone can run a validator, but that does not make Stellar permissionless. The question is: permission for what? Validation refers to validation of a log of events. In other words, validation is listening. Consensus, on the other hand, is both listening and talking. Stellar does not allow anyone to talk (participate in consensus of the creation of the log). It only allows anyone to listen (validate what the talkers are saying). If the talkers/consensus-group/cartel is creating a namespace, as is the proposal in the IETF ILC list, then any proposal to restrict consensus to any one system is by definition a hostile takeover of the ICANN/DNS namespace by a cartel. To quote from this message on the IETF ILC: What this group is doing, which is not very clear from its self-description, is the creation of a consensus-based namespace.
The Internet does not currently have consensus-based namespaces.
DNS, for example, does not operate on any real form of consensus.
For this reason, it is also not secure. Anyone who can MITM a network connection, can override apple.com <http://apple.com/> to be anything they want, along with any other name in the insecure, federated ICANN namespace.
A *consensus-based namespace*, on the other hand—as this group and [trans] are proposing—consolidates ownership and definition of the entire namespace to a group that attempts to maintain consensus.
The means by which consensus is achieved *matters a great deal*, but some general statements are possible too.
In the example of Stellar, consensus is restricted to a small cartel, and the protocol's inability to resolve consensus forks means that this cartel will most likely only get smaller over time, since participation requires the _permission_ of the existing cartel. FYI, Stellar's marketing in this department is also highly misleading [1].
What you're left with is a log, and it can be "append-only", but that really doesn't matter much if the proposal is for the /entire Internet/ to use *just* that one log. That is tantamount to a global, Internet takeover by a cartel.
It's important to emphasize: _such a group would have *total power* to decide who is and who is not allowed to have a website._
A consensus-based namespace offers security—but only if it's not a defacto namespace, but one of an arbitrary number of consensus-based namespaces. Getting back to your comment above: Keep in mind that this can also easily happen in bitcoin, if a cartel of miners with over 51% of the hashing decide to stop accepting blocks from people outside of cartel they can do this. The difference is in bitcoin it would be hard to ignore the cartel and there is economic incentive for the cartel to take all the blocks. You'll notice I am also against using Bitcoin to define a defacto namespace: https://twitter.com/taoeffect/status/832081089787097088No single consensus system can be a defacto Internet namespace. Let a thousand consensus-based namespaces bloom. |
|
|
|
That blog post doesn't mention the weaknesses of Cryptonote/RingCT which I have explained numerous time. I posted a comment to that blog and it still hasn't appeared. Thus so far, I think that blog is a monero shilling vehicle and not objective. Hello, I noticed this thread in our referrer logs. I am the author of that post on Zcash. To be clear, neither myself nor okTurtles are in any way associated with Monero. I chose Monero simply as an example of one well known Cryptonote cryptocurrency, and I chose it specifically because it felt (to me) to be one of the more reputable cryptonote implementations (the post also links to this comprehensive listing of cryptonotes). Regarding your comment not appearing on the post, I am very sorry but I'm not aware of any such comment being posted. I checked whether Akismet (our anti-spam software) might have captured it, but searching for "Cryptonote" and "Monero" did not bring up any results. We'd be more than happy to host your comment criticizing Monero for any technical shortcomings. I am very curious what those shortcomings are, so if you'd like to PM me the email you used to post the comment that might make it easier for me to find it. Or, you are more than welcome to try posting it again. |
|
|
|
No offense, but I'm not sure you understand "UTXO" well enough to explain it to others. For starters, UTXO is nothing new, this post is about "committed utxo". As maaku explained, miners need to know that they're mining on top of the valid chain, that's the only way they can know they have the accurate UTXO.
maaku confirmed that I understood UTXO's SPV+ mode. |
|
|
|
- One of the few important things that you're missing is the recent 51% solution to mining pools. Add that to your protocol/software and you'll go a long way to have a altcoin/altchain of major significance. Well I'll keep that in mind but we already have a lot on our plate and I don't feel like pools pose a significant threat. People tend to leave pools when they become too large anyway. Hmm.. myopia from the outset is not a good sign for the project, especially when such assumptions have been proven demonstrably false already. - You use "we" frequently in your writings but it sounds like you mean to say "I". If you have multiple people working on this you should make that clear by mentioning their names. There were several people involved in the development of the scheme and I have two developers working on the implementation. Some of them would prefer to remain anonymous so I refrain from mentioning names when possible. "Some" or "all" wish to remain anonymous? If "some", then why aren't you mentioning the names of those who don't wish to be anonymous? - Your other thread seems to indicate that you're already mining and giving away coins? No, that is a test thread where the client must run in testnet mode. Any coins mined in those tests will be lost, we've already had to reset the blockchain one or two times due to changes we made in the protocol. Ah, that's good to hear. |
|
|
|
I'm not sure who misunderstands. I'll try to rephrase.
Here's the core of my question - does the system (all nodes) forget a prefix of the chain at some point?
If a node reads the entire chain (from genesis), it can prune it locally, sure. But how does a new node bootstrap without the entire chain? It needs to trust a snapshot (rolling root, utxo block, whatever it's called). That's my issue. Rolling root and UTXO are very different architecturally, so I'll just answer for UTXO here. Nobody, whether it's new nodes or old nodes, needs to know the entire histories of coins. The only thing that matters is whether they have the accurate unspent transactions. New nodes download the entire UTXO meta chain (step #2 in the summary I posted earlier). This chain is protected by PoW. That's it. By knowing the accurate UTXO tree fingerprint, they can safely build the UTXO tree. |
|
|
|
I thought you might answer something like "do arithmetic"... I hate to say it but I think that I must agree with some of the other members who have posted here when they say that I think you lack quite a lot of understanding regarding bitcoin: the protocol.
NB. I'm not saying that I think that you don't understand bitcoin: the idea.
What do I not understand? Be specific, otherwise you're wasting everybody's time.  |
|
|
|
I guess I'm not sure what's the ultimate goal of this. Do you want to actually prune the Blockchain prefix at some point, or is this just a mechanism to speed up bootstrapping? My feeling is that this mechanism is secure enough for the latter cause, but not for the former. What do you mean "not for the former"? This scheme would make the prefix irrelevant. If you don't care about the history of those coins there's no issue (that I can see). To verify that a UTXO set i includes all utxo's, the verifier has to go back to the latest UTXO set it trusts j and make sure there are no missing outputs between j and i. There is no way to do that once the Blockchain get pruned at i.
Technically, it's possible to lose utxo's this way, if the network wrongfully accepts a partial UTXO set and prunes the prefix. That being said, it's quite difficult to take advantage of this vulnerability, so I think it is viable for fast bootstrapping.
Or perhaps I'm missing a part of the mechanism? Please correct me if I'm wrong. I think either I've misunderstood what you're saying here, or you've misunderstood the how this would work. Please let me know either way. Once a node has a complete UTXO tree that corresponds to the most recently accepted block, there should be no problems from that point on. It does not go to the UTXO to verify much of anything, but merely updates it based on newly minted blocks. The blockchain can be pruned locally according to any lossless scheme the node desires. The only place I see a potential issue is if there's a reorganization (a different fork suddenly exceeds the current in length). If that happens, and the node pruned too closely to the current time, then it might not know how to safely deal with the reorg event. To mitigate against this, nodes can keep a blockchain prefix of sufficient length. |
|
|
|
bitfreak: your paper is on my reading list and I have already read part of it. I'd like to get back to you soon on it with my impressions. Your paper will be the ... 3rd or 4th alternative consensus/blockchain proposal that I've reviewed, and it looks promising. Here are some preliminary comments since I suspect that my full review won't come for a while due to deadlines: - One of the few important things that you're missing is the recent 51% solution to mining pools. Add that to your protocol/software and you'll go a long way to have a altcoin/altchain of major significance. - You use "we" frequently in your writings but it sounds like you mean to say "I". If you have multiple people working on this you should make that clear by mentioning their names. - Your other thread seems to indicate that you're already mining and giving away coins? There are good ways and bad ways of doing this, and depending on which method you choose it can make or break your coin. More fair = more chances of success for the coin (and you). I recommend doing a *lot* of reading on this and seeing how other coins approached the task (and what the end result was). And if you're too lazy to do that, just do whatever Ethereum is doing (Vitalik is a bright guy). Now, to answer e4xit: Could you show me the lines from the blockchain (not the website) which show the 'balance' for this address you have selected as I can't find them and I have been searching for hours, thanks. (reminder of your selected address 18uvwkMJsg9cxFEd1QDFgQpoeXWmmSnqSs) The balance is calculated from the inputs and outputs to that address. You would need to know how to do arithmetic to figure it out (or have your computer or friend do it for you). |
|
|
|
I don't know of anyone besides me who is still working on UTXO commitments. It is developer time limited right now since for about six months I've been split between multiple projects trying to make ends meet. I posted a summary of the current state earlier in this thread, and any bitcoins or bitcoind developers would be appreciated in speeding the process along.
Mmmk, sent ya a PM. |
|
|
|
Then fork it and implement the changes - unless that is what you've been working on since March and are ready to release some alpha or beta code, which would be cool.
Code will give some very good data as to how it works, potential issues etc. Discussing it here will do little, but since it is open source, implementing will do a lot.
Sounds like "bitfreak!" might have implemented something not quite the same as a rolling root... I'm not sure why he's getting rid of unspent transactions after 1 week though (sounds like a bad design choice, but maybe I misunderstood when I skimmed it). However, I am now getting more and more convinced that UTXO accomplishes the same goals as rolling root, just in a different manner. Since someone appears to be involved in implementing it, that seems like the way to go. See this post and the replies that come after it: https://bitcointalk.org/index.php?topic=88208.msg7423013#msg7423013 |
|
|
|
That appears to be a correct description of SPV+ mode.
OK cool, thanks maaku for reviewing it!  Then it sounds like UTXO / SPV+ is a solution to the long running problem of safely and quickly bringing new bitcoin nodes online. That's really great news if true!  So who's working on this? I haven't seen etotheipi post anything recently, is he still working on it? Does he still need donations? |
|
|
|
Erm, just a note, I forgot to remove Step 7 when I copied that post: 7. Continue mining blocks as per above to secure the network and build new blocks, slowly transforming this light node into a full node. I deleted that. Mining will commence only *after* our local UTXO merkle tree thing has be completed. |
|
|
|
I think it would be helpful (in general) for me to paste here my updated understanding of how these "full-security new lite-nodes" would be booted up: For a new node to boot up from scratch and begin securing the network, approximately the following needs to happen:
1. Download entire BTC blockchain headers.
2. Download the entire UTXO meta chain.
3. Begin merged mining on UTXO and BTC blockchains. begin mining *only* when we've built up the complete UTXO tree.
4. For each new transaction the "almost-full node" receives, query other nodes for the block in which the payer's bitcoins were previously located, along with the hashes to verify the merkle root in the BTC blockchain. Verify the root can be found. Edit: This part is just regular SPV!
5. Query other nodes for the transactions and merkle root hashes that result in the merkle root hash of the most recent block in the UTXO blockchain. Verify that previous txn the coins belong to exists in the current data comprising the most recent merkle root of the UTXO blockchain.
6. If the transaction passes the above verifications, store all received data so far in order to build the Merkle hash tree that represents all the UTXOs.
To build the complete UTXO tree, ask for any missing children of our current UTXO merkle tree and verify them according to the above.
|
|
|
|
It's the difference between saying:
1) I believe the UTXO checkpoint is valid because people built on top of it. (SPV-like, depth-based) With a UTXO checkpoint built-in to the client, safety is guaranteed (so far as I can tell) if the checkpoint is valid. That is the scenario the wiki discusses. The scenario I originally asked about is downloading the entire UTXO chain (not a checkpoint of it). I'm not even trying to argue about a practical attack, I'm simply explaining why they're different. They are. They are different but if the difference isn't meaningful in terms of security for the chain then there's no issue and UTXO and/or ledger-block can be used instead of downloading everything from genesis (this is good news btw! You should want to make it work, otherwise bitcoin won't be sustainable). |
|
|
|
(For any audience, see SPV in Thin client security.)Ok, well again, this is still SPV-like security(block depth). That's the definition of the security model. Practically you might feel it's ok, but it's certainly a different security model than Bitcoin full node security.
In that it is using block-depth it is like SPV (this I already acknowledged in a previous post), but it is not the same because of the extra information in the UTXO, and it is not the same as rolling-root/ledger-block because the current root is guaranteed to not have any relevant transactions prior to it. Please be specific. What does the attack scenario look like with UTXO and/or ledger-block, and why does it require the full transaction history? The wiki seems to agree with me actually: Edit: Although it is saying something slightly different (shipping clients with the full UTXO already intact, but I don't think that's necessary with rolling root. Would have to give it more thought, but might not be necessary for UTXO either. If there's a problem for UTXO, it could be fixed with a rolling-root type solution).
|
|
|
|
Let's say we only have one ledger block, or whatever, or UTXO commitment thing. If we don't know the blocks before that, other than just headers, we can't verify that people are building on valid blocks. Someone could have made a fraudulent ledger block, and built on top of it. If people don't catch this, and never check contents before that, they have successfully attacked the network. (For any audience, "ledger block" is same thing as "rolling root".) Thank you for the reply (and trying to address my questions)! I'm not convinced that is correct, however. How would this attacker create a convincing fraudulent ledger block that beats the ledger block of the honest nodes? 1. The ledger block of the honest nodes will contain transactions that can be verified to have thousands of confirmations. 2. The ledger block of the honest nodes will be part of a longer chain than the fraudulent one for the same reasons described in the bitcoin paper. If I'm wrong, I must be missing some subtle and would appreciate it if you (or anyone else) could explain what that is. |
|
|
|
I explained myself, twice: The miner needs to verify the entire block chain history because otherwise he has no way of knowing if he is actually on a valid chain or not. This has nothing to do with UTXO commitments, rolling root, or any other proposal. It's a basic, fundamental requirement of any consensus system: if the miners themselves operate in SPV mode (which you advocate), then anyone -- no matter their hashrate! -- can trick the network into mining an invalid chain. The attacker does so by mining a fork with invalid history and temporarily (by luck or 51%) overcoming the honest network. New miners coming online, or miners tricked into reseting their state then switch to the invalid chain This completely invalidates the SPV assumption and makes it unsafe for anybody to use the network.
In what universe is that an answer to the facts that I pointed out? You're continuing to ignore that: 1. I did not advocate SPV. 2. UTXO is not SPV. 3. Rolling root is not SPV. The 51% attack you describe would have *equal* impact on nodes with the full history (so far as I understood what you're describing). You never explained— anywhere—how UTXO "full-leaf nodes" are different in any meaningful manner from nodes with complete transaction histories. Still waiting for that reply. |
|
|
|
|
