I responded privately to Zcash as follows: Okay I read the document you provided and it doesn't change anything I have written in the past. I never said the developers would be at-risk of FinCEN regulation. It is the miners who transfer coinbase to your company/foundation that will be subject to registration as MSBs. And the document you provided does not argue otherwise. The document you provided is only talking about miners who don't transfer their coinbase but rather mine it for themselves (they may exchange it later as an individual but that is not the same as a regularized transfer operation). Now you might argue that since they are transferring it only to one (or just two) entity then there is no risk of money laundering, thus the MSB regulation would not apply. But that is not what FinCEN guidance says. They say if the entity is creating and transferring, then they must register. Sorry you are potentially wrong and this could cost you dearly. Why not simply premine it! Much easier and avoids the problem on your miners. |
|
|
|
That's the dichotomy at hand
There is no dichotomy in the case of strict partitions for asset transfers. I will not repeat myself again. |
|
|
|
Note I edited my post on the prior page of this thread and inserted the following. See my new comments below this quoted text.| [1] | Correct with regard to your first scenario where 2 partitions never talk to each other in the future, you dont need to consider it. If they do talk to each other in the future, and have to merge, this is where Bitcoin, blocks, POW and longest chain rule falls on its arse. Only one partition can exist, there is no merge possibility so the other has to be destroyed. Even if the 2 partitions have not existed for an extended period of time you are screwed as they can never merge without a significant and possibly destructive impact to ALL historic transactions prior to the partition event, so you end up with an unresolvable fork. I feel this is a critical design issue which unfortunately for Bitcoin imposes a number of limitations.
CAP theorem certainly doesn't imply you can't ever fulfill C, A and P, as most of the time you can at least enough to get the job done. What it does state is that you cant fulfill all 3 to any sufficient requirement 100% of the time, as there will always be some edge cases that requires the temporary sacrifice of C, A or P. This isn't the end of the world though, as detecting an issue with P is possible once nodes with different partitions communicate, at which point you can sacrifice C, or A for a period of time while you deal with the issue of P.
If you structure your data set in a flexible enough manner, then you can limit the impact of P further. Considering CAP theorem once again, there is no mandate that prohibits most of the network being in a state that fulfills C, A and P, with a portion of the network being in a state of partition conflict. For example, if there are a network of 100 nodes, and 1 of those nodes has a different set of data to everyone else and thus is on its own partition, the remaining 99 nodes can still be in a state of CAP fulfillment. The rogue node now has to sacrifice C or A, in order to deal with P while the rest of the network can continue on regardless.
All of this can be done without blocks quite easily, the difficulty is how to deal with P in the event of a failure, which is where consensus algorithms come into play.
Bitcoins consensus of blocks and POW doesn't allow for merging as stated, even if the transactions on both partitions are valid and legal.
DAGs and Tangles DO allow merging of partitions but there are important gotchas to consider as TPTB rightly suggests, but they aren't as catastrophic as he imagines and I'm sure that CfB has considered them and implemented functionality to resolve them.
Channels also allows merging of partitions (obviously thats why Im here), but critically it allows a node to be in both states of CAP fulfillment simultaneously. For the channels that it has P conflicts it can sacrifice C or A to those channels, for the rest it can still fulfill CAP.
Lets rewind a bit and look at whats really going on under Bitcoins hood.
Natural network partitions arise in BTC from 1 of 4 events happening:
1. A node/nodes accept a block that has transactions which are double-spending an output present in another block
2. A miner produces a block that conflicts with a block on the same chain height
3. Network connectivity separates 2 parts of the network
4. A miner has control of 51% or more
All 4 of these create a P inconsistency, and so the LCR (longest chain rule) kicks into action to resolve them.
In the case of 1, miners can filter these against historic outputs and just reject the transaction. If multiple transactions are presented in quick succession that spend the same output, miners pick one to include in a block, or they could reject all of them. On the receipt of a valid block, the remaining double-spend transactions that are not in a block get dumped. If a block with a higher POW then turns up, all nodes switch to that block, which may or may not include a different transaction of the double-spend set.
In the case of 2, this happens ALL the time. Orphans cause temporary partitions in the network, but the duration between them is short enough that it doesn't cause any inconvenience. Worst case you have to wait a little longer for your transaction to be included in the next block if the accepted block which negates the orphan block doesn't have yours in it.
In the case of 3, if the separation duration is short, see 2. If its long and sustained, 1 of the partitions will have to be destroyed and undo any actions performed, legal or otherwise causing disruption and inconvenience.
In the case of 4, well, its just a disaster. Blocks can be replaced all the way back to the last checkpoint potentially and all transactions from that point could be destroyed.
There can also be local partition inconsistencies too, where a node has gone offline, and shortly after a block or blocks have been accepted by the network that invalidate one or more of the most recent blocks it has. Once that node comes back online it syncs to the rest of the network and does not fulfill CAP at all. The invalid blocks that is has prior to coming back online are destroyed and replaced.
You could argue that this node creates a network level partition issue also to some degree, as it has blocks that the network doesn't, but the network will already have resolved this P issue in the past as it would have triggered an orphan event, thus I deem it to be a local P issue.
So whats my point?
In the cases of 1 or 2 there does not need to be any merging of partitions. Bitcoin handles these events perfectly well with blocks, POW and LCR with minimal inconvenience to honest participants providing that the partition duration of the network is short (a few blocks).
In the case of 3, which is by far the most difficult to resolve, the partition tolerance reduces proportional to the duration of the partitioned state, and becomes more difficult to resolve without consequence in any system, as there may be conflicting actions which diverge the resulting state of all partitions further away from each other. These partition events will always become unsolvable at some point, no matter what the data structure, consensus mechanisms or other exotic methods employed, as it is an eventuality that one or more conflicts will occur.
The fact is that DAGs/Tangles and our channels have a better partition resolution performance in the case of event 3 as the data structures are more granular. An inconsistency in P doesn't affect the entire data set, only a portion of it, thus it is resolvable without issue more frequently as the chances of a conflict preventing resolution is reduced.
Now, you haven't provided any detail on exactly how you imagine a data structure that uses blocks that could merge non-conflicting partitions, let alone conflicting ones. In fact I see no workable method to do this with blocks that may contain transactions across the entire domain. Furthermore, who creates these "merge" blocks and what would be the consensus mechanism to agree on them? In the event of a conflict, how do you imagine that would be resolved?
When it comes to partition management and resolution where block based data structures are employed, Satoshi has already given you the best they can do in the simplest form. Trying to do it better with blocks is IMO a goose chase and you'll get nowhere other than an extremely complicated and fragile system.
|
I believe what he is attempting is to define a data structure wherein he can partition double-spends so that they can not cross-partition each other. In other words, once there is a double-spend, instead of discarding it (and unrelated transactions in the same chain), he isolates those transactions which depend on the double-spend and prevents them from cross-pollinating each other in derivative transactions.
The problem with this of course is it ruins the incentive to converge. It becomes a divergent block chain where the incentive is to double-spend and create forks (within the same system).
I'd be interested to hear Fuserleer's retort. I will PM him.
|
|
|
|
You apparently still haven't comprehended that for a strict partitioning that obeys the Nash equilibrium, i.e. for transactions that are never allowed to cross-partitions, then the partition doesn't need a separate PoW nor separate block chain. It can be essentially merge-mined (but in the same block chain) without impacting the Nash equilibrium for the block producers. And my other point was that strict partitioning can't exist for scripting yet it can exist for asset transfers (e.g. crypto coin transactions).
I understand perfectly. Under this model, the incentive for block producers is to exclude partitions from their blocks, because every partition they include increases the chance of their block being orphaned due to double spends. In fact, this is analogous to the problem faced by Iota. No you don't. And you are slobbering all over the thread. I guess I have to put you on ignore again. Excluding a partition means the coin dies and thus their block rewards become worthless. You seem to not even comprehend Nash equilibrium. Really this is getting to be too much. You constantly waste my time. And you feel no remorse. You apparently still haven't understood the point. The blocks are not invalid when a strict partition is invalid.
Of course one might argue that strict partitioning (thus by definition is without cross-partition transactions) is not that flexible. But nevertheless the point remains that there is a design which refutes your assumption.
A strict partition which is invalid serves no purpose that I can see? You seem to be incapable of remembering anything I write: The case of strict partioning which I explained upthread does not cause the block to be invalidated if the partition lied (and I think I explained in my video too)! Did you forget that again. Do I need to go quote that upthread statement by me again! Because the partitions are independent, thus a partion can be invalidated without needing to invalidate the entire block (i.e. the next block corrects the partition in the prior block by providing a proof-of-cheating).
|
|
|
|
I responded privately to Zcash as follows: Okay I read the document you provided and it doesn't change anything I have written in the past. I never said the developers would be at-risk of FinCEN regulation. It is the miners who transfer coinbase to your company/foundation that will be subject to registration as MSBs. And the document you provided does not argue otherwise. The document you provided is only talking about miners who don't transfer their coinbase but rather mine it for themselves (they may exchange it later as an individual but that is not the same as a regularized transfer operation). Now you might argue that since they are transferring it only to one (or just two) entity then there is no risk of money laundering, thus the MSB regulation would not apply. But that is not what FinCEN guidance says. They say if the entity is creating and transferring, then they must register. Sorry you are potentially wrong and this could cost you dearly. Why not simply premine it! Much easier and avoids the problem on your miners. |
|
|
|
One point they forgot to make is that it doesn't matter if Ethereum did their ICO under Swiss laws. The USA has securities law is that if you advertise and market securities to US investors, then you are culpable under US law no matter where in the world you are. They will come after you. KimDotCom will soon learn this that you can't run and you can't hide from the USA. Don't forget that Sweden was involved in trying to extradite Assange and probably turning him over to the USA. And Switzerland has been caving in to USA demands for turning over US citizens hiding wealth in Swiss banks. And besides, Martin Armstrong has pointed out that the G20 will start sharing information and cooperating on enforcement as of 2017 (when the global economy will collapse in earnest and capital controls will be ramped up significantly). Here is something related to FinCEN which is not the same as SEC regulation, but nevertheless the same principle applies of filtering out US residents/citizens: You can avoid US customers, but it takes work America Plenty of businesses, some of my own clients included, have decided that the US market just isn’t for them. They’ve either soured on the idea of servicing US clients altogether, or have decided to launch and wait it out in jurisdictions like Canada until the US sees regulatory reform. This can be both profitable and practical, but simply incorporating the overseas market isn’t going to cut it. The smart business will develop a set of policies and procedures reasonably calculated to keep US residents out. A competent attorney can help guide you through this process, and I can give some very basic principles here. Firstly, a pre-emptive response to a question I get asked weekly: geofiltering incoming IP addresses is only the beginning. The business itself should detect the jurisdiction of the customer’s IP address, display that address, and ask the customer to confirm that this is his or her jurisdiction. Both customer and business can take affirmative steps: the customer can be required to click a button stating “I affirm that I am a resident of *country*,” and the business can require verifying documentation, like a passport or utility bill. Several providers offer these kinds of onboarding services. Your business should develop a risk profile for each of its customers in real time setting forth the probability that the customer is a US resident. The risk profile should take into account different factors like: (i) whether the customer registers a US bank account with your business, (ii) how many transfers to US bank accounts the customer requests (if you offer such a service), and (iii) how many times the customer accesses your service from within the US after setting up a new account. The record shouldn't just show that your business followed its own policies, but that those policies worked. If push comes to shove, a judge and jury would probably like to see that, every once in a while, your procedures actually caught a US resident trying to use your service, and that you closed his or her account. Finally, it should go without saying that your business should not advertise to US customers. This all might seem excessive for, or inapplicable to, your business and indeed it might be. The proper set of procedures will depend heavily upon the details of your business model and your degree of risk tolerance. For some, even crafting and implementing these policies may be just as unappetising as compliance. There is, in fact, a way to service US customers and avoid these burdens. Namely, you can become the agent of a Bank or Credit Union, as existing MSB Certified agents of banks, credit unions and money services businesses are typically exempt from registration and licensure requirements. Functionally, becoming an agent means hiring an attorney to negotiate and execute an agreement with the bank, credit union or MSB (called the “principal”) setting forth your relative rights and obligations.
I don't have time to read this: http://www.coindesk.com/forking-bitcoin-msb-legal-issues/I was also provided the following link by Zcash: https://coincenter.org/2016/02/no-fincen-policy-is-not-relevant-to-the-bitcoin-forking-debate |
|
|
|
a design without partitions and where every full node verifies every transaction, which obviously can't scale and which due to economics that I A partitioned network operates exactly like two independent networks. If invalid transactions propagate throughout a network, that network is in trouble, regardless of whether there are partitions or not. You apparently still haven't comprehended that for a strict partitioning that obeys the Nash equilibrium, i.e. for transactions that are never allowed to cross-partitions, then the partition doesn't need a separate PoW nor separate block chain. It can be essentially merge-mined (but in the same block chain) without impacting the Nash equilibrium for the block producers. And my other point was that strict partitioning can't exist for scripting yet it can exist for asset transfers (e.g. crypto coin transactions). #2 is why the design for partitioning (or delegation of validation) has to maintain a Nash equilibrium, meaning the requirement that there exists no game theory advantage for partitions (or delegates) to lie about their validation. This point about Nash equilibrium has been explained to you numerous times!
My point is that if you allow block producers to produce invalid blocks, that will be gamed by those who do validate, leading to SPV miners being pushed out of business. You apparently still haven't understood the point. The blocks are not invalid when a strict partition is invalid. Of course one might argue that strict partitioning (thus by definition is without cross-partition transactions) is not that flexible. But nevertheless the point remains that there is a design which refutes your assumption. |
|
|
|
#1 does not apply because the design is such that validation is split between partitions. This has been explained to you numerous times! #1 would be
What is 'the' design? This is a thread about Ethereum, where full nodes do validation and miners produce blocks. The thread is about Ethereum's promised future version named Casper which is supposed to introduce sharding (partitions). My gosh how did you miss that. |
|
|
|
monsterer w.r.t. to the underlined, I grow very weary of you subjecting all of us to your pretending you are some sort of expert.
I have no idea why you can't comprehend what I already explained:
What you are saying makes no sense at all. That is uncivil accusation against your Professor. No. As usual when you fail to understand what has been written, you fill a thread with your nonsense and you refuse to grasp your mistake even after it has been explained to you over and over and over again. Sorry I can't tolerate this any more monsterer. I guess this is an example to me of why very smart people don't work on very complex projects with people who are not smart enough to work efficiently. I don't like to look down on others, because I hate when others do that to me. Normally I would prefer to respond pretending I am your peer and not desiring to gain any perception from readers otherwise. But I don't know how else to react your repeated insistence to force your inability to comprehend new concepts on everyone else. I would think you might be embarrassed enough from other times where you eventually realized I was correct, to go take some quiet time and try to figure out your mistake. The problem is you think I am wrong and your lack of respect for my superior expertise, is where your noise problem originates. I don't mean that to be condescending nor uncivil. Rather I just wish you would get in touch with reality. Let me demonstrate this reality to you again as follows... Btw, I like questions. But I also like when the person asking, actually tries to understand and think what I meant rather than just deciding to view it in only one way. And declare the Professor wrong. There are two possibilities as I see it:
1. Invalid transactions arrive in the hands of the block producers. This implies the network as a whole has failed because invalid transaction should not be propagated.
2. Block producers produce blocks containing invalid transactions due to lack of validation. Their blocks will be orphaned by block producers which do validate, which is a net loss for those who don't, forcing these SPV miners out of business and causing centralisation.
#1 does not apply because the design is such that validation is split between partitions. This has been explained to you numerous times! #1 would be a design without partitions and where every full node verifies every transaction, which obviously can't scale decentralized and which due to economics that I explained will always end up centralized. It is a dead design. Bitcoin and Nxt (which is now run by a dictator) have proven these designs end up centralized as I predicted in 2013 (back when people like you said I was loony). #2 is why the design for partitioning (or delegation of validation) has to maintain a Nash equilibrium, meaning the requirement that there exists no game theory advantage for partitions (or delegates) to lie about their validation. This point about Nash equilibrium has been explained to you numerous times! Note in case it wasn't clear from my upthread posts, strict partition (no cross-partition transactions) for crypto coin (i.e. asset transfers) maintains Nash equilibrium. But cross-partition transactions for asset transfers does not maintain Nash equilibrium (unless using a statistical check as I am proposing for my design, and some may think this is dubious but my white paper will make the argument for it). And strict partitioning for scripts can't exist, because the partitions are violated by external I/O.
I don't agree with this assessment either. In a partitioned system which requires a cross partition transaction, this new transaction merges the two partitions; it places a ordering constraint on both partitions which forces the new transaction to be located after the two points of dependency (both parents). Are you fucking blind? Let me quote again the part that renders your underlined complaint irrelevant: Note in case it wasn't clear from my upthread posts, strict partition (no cross-partition transactions) for crypto coin (i.e. asset transfers) maintains Nash equilibrium. But cross-partition transactions for asset transfers does not maintain Nash equilibrium (unless using a statistical check as I am proposing for my design, and some may think this is dubious but my white paper will make the argument for it). And strict partitioning for scripts can't exist, because the partitions are violated by external I/O.
Why can't you read and comprehend what you are reading! Fuck man. It is very frustrating to deal with someone like you who can't even add 1+1 together to realize what is being said. The point is that in the cases where Nash equilibrium is maintained, then there is no lying which renders the block invalid. The case of strict partioning which I explained upthread does not cause the block to be invalidated if the partition lied (and I think I explained in my video too)! Did you forget that again. Do I need to go quote that upthread statement by me again! Because the partitions are independent, thus a partion can be invalidated without needing to invalidate the entire block (i.e. the next block corrects the partition in the prior block by providing a proof-of-cheating). |
|
|
|
In my design, I have cross-partition transactions, but the way I accomplish this and maintain the Nash equilibrium is I entirely centralized verification, i.e. all transactions are validated by all centralized validators. This eliminates the problem that full nodes have unequal incomes but equal verification costs, thus ameliorates the economics that drives full nodes to become centralized. The centralized validators would still have the potential incentive to lie and short the coin. So the users in the system (hopefully millions of them) are constantly verifying a subsample of the transactions so that statistically a centralized validator is going to get caught fairly quickly, banned, and their hard won reputation entirely blown. Since these validations are done in a non-organized manner (i.e. they are randomly chosen by each node), then there is no viable concept of colluding to maintain a lie.
Regarding the last sentence, I take it that it refers to the extra validation performed by the users? How do you ensure that the selection of the txs to be validated is done randomly? And what incentives do the user nodes have to perform the extra validation at all? Users are going to chose randomly because they have no reference point nor game theory incentive to base some priority on choosing non-randomly which transactions to validate. And I will probably make the transaction(s) they validate be those identified by the PoW share hash they must submit with their transaction. Users have the incentive to validate, because it is an insignificant cost (perhaps some milliseconds of work every time they submit a transaction) and they have every incentive to make sure the block chain's Nash equilibrium isn't lost by a cheating centralized verifier. Also there may be a Lotto incentive where they win some reward by revealing a proof-of-cheating. There is no game theory by which users are better off by not validating, i.e. an individual failure to validate a subsample doesn't enable the user to short the coin. That was a very clever breakthrough insight (simple but still insightful). Note my idea could also be applied to partitioning, so if centralized validators can't scale then I would still support partitioning (and even for scripts!), but I think partitioning and reputations of multiple validators muddles the design and also muddles the economics (i.e. I think the validators will end up centralized within a partition any way due to economics). Note also that users can't normally validate constraints from the UXTO because they aren't full nodes. So they will be depending on a full node to relay to them the correct records from the UXTO, but these can be verified (by the non-full node users) to be correct from the Merkel trees. So this is why I said maybe Ethereum should perhaps try to hire me, but I also wrote a paragraph upthread saying basically "do not hire me". Hope readers don't think I am begging for a job. Geez. |
|
|
|
But that underlined wasn't the problem. Did you forget the point about the Nash equilibrium and all validators needing to trust that the validators from other partition didn't lie.
If validators lie so convincingly, the whole network is lying and you have a lost cause. Transactions will not propagate to the block producers in all other cases. monsterer w.r.t. to the underlined, I grow very weary of you subjecting all of us to your pretending you are some sort of expert. You may be expert on bitcoind (presumably you are given you created an exchange and btw I am ignorant of bitcoind specifics although I understand the conceptual aspects I need to know to do my design theory). I have no idea why you can't comprehend what I already explained: Note that validators can be computing a PoW block based on a hash of their partition and a hash of all the other partitions. Don't forget the power of Merkel trees.
The point is the block producers only need hashes of the partitions. They don't have to verify every transaction. I explained that this maintains Nash equilibrium in certain scenarios: Note in case it wasn't clear from my upthread posts, strict partition (no cross-partition transactions) for crypto coin (i.e. asset transfers) maintains Nash equilibrium. But cross-partition transactions for asset transfers does not maintain Nash equilibrium (unless using a statistical check as I am proposing for my design, and some may think this is dubious but my white paper will make the argument for it). And strict partitioning for scripts can't exist, because the partitions are violated by external I/O.
It seems monsterer that you have an inflexible mind. You can only see things in one way which is what you already understand about how bitcoind works. There are other possible designs. |
|
|
|
Of course Bitcoin is already broken, because the Chinese mining cartel controls 65% of the hashrate and they lied about the Great Firewall of China being a problem[1] because they really want to veto block size increases so they can maximize their profits via spiraling transactions fees which I predicted in 2013. And remember my point that on the next block reward halving (this year I think) then the lowest cost miners will survive and the marginal miners will lose profitability and thus China's 65% share will increase significantly. I also believe Chinese miners are operating with near 0 cost electricity with a "wink and a handshake" charging the electricity cost to the collective society. | [1] | We know they are lying because they can put a pool abroad and send only a block hash across the GFW thus bandwidth is not an issue. They are clearly lying! |
|
|
|
|
|
Apparently Ethereum is attempting to correctly use the terminology of verification vs. validation then.
|
|
|
|
Validating (a.k.a. verifying) also means checking that it isn't a double-spend, that the funds exist (either via UXTO or account balance).
Agreed. This is not very compute intensive, though, compared to PoW. That is why I said the problem is more acute for Ethereum and verifying long running scripts. That has been one of my main points about why Ethereum can't scale (at least not decentralized). Also realize even in the case of Bitcoin eventually scaling can outrun the costs of PoW, especially as block reward declines to 0 and assuming block size is allowed to increase so that transaction fees don't skyrocket. Of course Bitcoin is already broken, because the Chinese mining cartel controls 65% of the hashrate and they lied about the Great Firewall of China being a problem[1] because they really want to veto block size increases so they can maximize their profits via spiraling transactions fees which I predicted in 2013. And remember my point that on the next block reward halving (this year I think) then the lowest cost miners will survive and the marginal miners will lose profitability and thus China's 65% share will increase significantly. I also believe Chinese miners are operating with near 0 cost electricity with a "wink and a handshake" charging the electricity cost to the collective society. | [1] | We know they are lying because they can put a pool abroad and send only a block hash across the GFW thus bandwidth is not an issue. They are clearly lying! |
In a partitioned design, only the full nodes (a.k.a. validators) for each partition would validate and propagate the transactions for that partition. So yes you are correct to imply that partitioning means the P2P network is partitioned also (because otherwise DDoS spam amplication attacks would be plausible if peers relay that which they do not verify).
I think all that should have been clear just by thinking about the only way partitioning can work. I am just wondering why you can't deduce these sort of things and instead need to ask?
Note that validators can be computing a PoW block based on a hash of their partition and a hash of all the other partitions. Don't forget the power of Merkel trees.
My point is that validators don't lie without the entire network lying. That applies within partitions as well. But that underlined wasn't the problem. Did you forget the point about the Nash equilibrium and all validators needing to trust that the validators from other partition didn't lie. |
|
|
|
Who is Kayne  Who cares.  Synereo should be coding and stop trying to hype vaporware. Oh yeah the AMPs exist but the social network design is flawed and doesn't exist. And Greg Meredith the main guy of Synereo has been leeching off Ethereum which is another hype driven P&D. When will you speculators ever learn to just say "No!". Edit: Karma: http://www.mirror.co.uk/news/world-news/kanye-west-album-bitcoin-scam-7382496 |
|
|
|
Who is Kayne Who cares. Synereo should be coding and stop trying to hype vaporware. Oh yeah the AMPs exist but the social network design is flawed and doesn't exist. And Greg Meredith the main guy of Synereo has been leeching off Ethereum which is another hype driven P&D. When will you speculators ever learn to just say "No!". Edit: Karma: http://www.mirror.co.uk/news/world-news/kanye-west-album-bitcoin-scam-7382496 |
|
|
|
The entire point of partitions is that not all full nodes are validating (verifying) all transactions.
Thus of course the full node that wins a block (in PoW, and analogously ditto in PoS or consensus-by-betting) is trusting the validators of other partitions to not lie to him.
If that full node had to validate every transaction in every partition, then there wouldn't be partitions any more. The entire reason to make partitions is because verification costs are too high when every full node has to verify every transaction. Partitions exist to aid scaling.
Can we be clear on what you mean by validation? Validating a transaction (i.e. checking it is protocol valid) has no PoW cost associated with it, any full node can do this. Therefore any full node can reject an invalid transaction before it gets propagated around the network. Validating (a.k.a. verifying) also means checking that it isn't a double-spend, that the funds exist (either via UXTO or account balance). In a partitioned design, only the full nodes (a.k.a. validators) for each partition would validate and propagate the transactions for that partition. So yes you are correct to imply that partitioning means the P2P network is partitioned also (because otherwise DDoS spam amplication attacks would be plausible if peers relay that which they do not verify). I think all that should have been clear just by thinking about the only way partitioning can work. I am just wondering why you can't deduce these sort of things and instead need to ask? Note that validators can be computing a PoW block based on a hash of their partition and a hash of all the other partitions. Don't forget the power of Merkel trees. |
|
|
|
I don't understand this... I don't understand that... I don't understand the other... Yes those guys made many errors or leaps of faith in their opinions. One point they forgot to make is that it doesn't matter if Ethereum did their ICO under Swiss laws. The USA has securities law is that if you advertise and market securities to US investors, then you are culpable under US law no matter where in the world you are. They will come after you. KimDotCom will soon learn this that you can't run and you can't hide from the USA. Don't forget that Sweden was involved in trying to extradite Assange and probably turning him over to the USA. And Switzerland has been caving in to USA demands for turning over US citizens hiding wealth in Swiss banks. And besides, Martin Armstrong has pointed out that the G20 will start sharing information and cooperating on enforcement as of 2017 (when the global economy will collapse in earnest and capital controls will be ramped up significantly). Btw, I should mention I was awake all night in a long chat with jl777 (i.e. the SuperNet) and he is working on decentralized exchange (and decentralized games such as poker) and I want to make sure those will interopt with the social network I am coding for the launch of my coin. That is your hint on how to find it. I won't be announcing it here. I suggested to James that he support my "rainy day" suggestion for foiling jamming, by allowing users of the DE to choose a "Coin Days Destroyed". I asked him to see what TierNolan thinks of my idea. James is checking his atomic transfer protocol with TierNolan who wrote the BIP for decentralized exchange. James is working on income models for the SuperNet, i.e. a very small fee on each DE trade. James is not a GUI programmer (I am but I don't want to code game front-ends because I don't love playing games at my 50.7 age), so we are looking for GUI programmers who want to receive a % of the fees. We prefer these people be independent, i.e. neither of us want to manage employees. I am very interested in doing the GUI programming for the social network.
Who is Kayne Who cares. Synereo should be coding and stop trying to hype vaporware. Oh yeah the AMPs exist but the social network design is flawed and doesn't exist. And Greg Meredith the main guy of Synereo has been leeching off Ethereum which is another hype driven P&D. When will you speculators ever learn to just say "No!". |
|
|
|
I don't understand this... I don't understand that... I don't understand the other... Yes those guys made many errors or leaps of faith in their opinions. One point they forgot to make is that it doesn't matter if Ethereum did their ICO under Swiss laws. The USA has securities law is that if you advertise and market securities to US investors, then you are culpable under US law no matter where in the world you are. They will come after you. KimDotCom will soon learn this that you can't run and you can't hide from the USA. Don't forget that Sweden was involved in trying to extradite Assange and probably turning him over to the USA. And Switzerland has been caving in to USA demands for turning over US citizens hiding wealth in Swiss banks. And besides, Martin Armstrong has pointed out that the G20 will start sharing information and cooperating on enforcement as of 2017 (when the global economy will collapse in earnest and capital controls will be ramped up significantly). Here is something related to FinCEN which is not the same as SEC regulation, but nevertheless the same principle applies of filtering out US residents/citizens: You can avoid US customers, but it takes work America Plenty of businesses, some of my own clients included, have decided that the US market just isn’t for them. They’ve either soured on the idea of servicing US clients altogether, or have decided to launch and wait it out in jurisdictions like Canada until the US sees regulatory reform. This can be both profitable and practical, but simply incorporating the overseas market isn’t going to cut it. The smart business will develop a set of policies and procedures reasonably calculated to keep US residents out. A competent attorney can help guide you through this process, and I can give some very basic principles here. Firstly, a pre-emptive response to a question I get asked weekly: geofiltering incoming IP addresses is only the beginning. The business itself should detect the jurisdiction of the customer’s IP address, display that address, and ask the customer to confirm that this is his or her jurisdiction. Both customer and business can take affirmative steps: the customer can be required to click a button stating “I affirm that I am a resident of *country*,” and the business can require verifying documentation, like a passport or utility bill. Several providers offer these kinds of onboarding services. Your business should develop a risk profile for each of its customers in real time setting forth the probability that the customer is a US resident. The risk profile should take into account different factors like: (i) whether the customer registers a US bank account with your business, (ii) how many transfers to US bank accounts the customer requests (if you offer such a service), and (iii) how many times the customer accesses your service from within the US after setting up a new account. The record shouldn't just show that your business followed its own policies, but that those policies worked. If push comes to shove, a judge and jury would probably like to see that, every once in a while, your procedures actually caught a US resident trying to use your service, and that you closed his or her account. Finally, it should go without saying that your business should not advertise to US customers. This all might seem excessive for, or inapplicable to, your business and indeed it might be. The proper set of procedures will depend heavily upon the details of your business model and your degree of risk tolerance. For some, even crafting and implementing these policies may be just as unappetising as compliance. There is, in fact, a way to service US customers and avoid these burdens. Namely, you can become the agent of a Bank or Credit Union, as existing MSB Certified agents of banks, credit unions and money services businesses are typically exempt from registration and licensure requirements. Functionally, becoming an agent means hiring an attorney to negotiate and execute an agreement with the bank, credit union or MSB (called the “principal”) setting forth your relative rights and obligations. Btw, I should mention I was awake all night in a long chat with jl777 (i.e. the SuperNet) and he is working on decentralized exchange (and decentralized games such as poker) and I want to make sure those will interopt with the social network I am coding for the launch of my coin. That is your hint on how to find it. I won't be announcing it here. I suggested to James that he support my "rainy day" suggestion for foiling jamming, by allowing users of the DE to choose a "Coin Days Destroyed". I asked him to see what TierNolan thinks of my idea. James is checking his atomic transfer protocol with TierNolan who wrote the BIP for decentralized exchange. James is working on income models for the SuperNet, i.e. a very small fee on each DE trade. James is not a GUI programmer (I am but I don't want to code game front-ends because I don't love playing games at my 50.7 age), so we are looking for GUI programmers who want to receive a % of the fees. We prefer these people be independent, i.e. neither of us want to manage employees. I am very interested in doing the GUI programming for the social network. |
|
|
|
Following up on that bolded commitment quoted above, cross-partition transactions even with asset transfers (e.g. a crypto currency, not scriptable block chains) seems to destroy the Nash equilibrium also, because the cascade of derivative transactions infects across partitions, yet the validators did not validate all partitions (i.e. not all transactions). I don't follow you. The network won't accept an invalid transaction, just as bitcoin doesn't accept an invalid block. The entire point of partitions is that not all full nodes are validating (verifying) all transactions. Thus of course the full node that wins a block (in PoW, and analogously ditto in PoS or consensus-by-betting) is trusting the validators of other partitions to not lie to him. If that full node had to validate every transaction in every partition, then there wouldn't be partitions any more. The entire reason to make partitions is because verification costs are too high when every full node has to verify every transaction. Partitions exist to aid scaling. Partitions can also enable other features such as instant confirmations, but that is a tangential discussion and I am not going to give away all my design before I launch it. Also in case my other point got lost in the sea of words upthread, my other key point is that (in Satoshi's PoW) if every full node has to verify every transaction, then all full nodes have the same verification costs, but full nodes have various levels of income because they have various levels of hashrate. Thus over time, mining must become more centralized because those with higher hashrate are more profitable due to verification costs. So eliminating verification costs for full nodes is eliminating one of the economic reasons mining becomes more centralized over time. I had also mentioned some of the other reasons in my video, e.g. propagation costs meaning not the cost of the bandwidth but the cost of mining on the wrong chain for longer periods of time relative to those pools with more hashrate who see the new block instantly when they produce it. In my design, I eliminate propagation costs in a clever way something similar to what Iota is doing (but without the aspect of Iota that I assert won't allow it to converge without centralized control and enforcement of the math model that payers and payee's employ). Ditto I assume for Fuserleer and not wanting to give away his design for eMunie before he launches. Fuserleer has mentioned vaguely that he is using different data structures and that the one who commits a double-spend is then isolated into his own partition[1]. I don't know how he accomplishes this. Will be interesting to read his white paper. He has also said he is not using proof-of-work and rather some form of propagation and different nodes with different responsibilities. I await his white paper and can't pre-judge it, except to say I am very skeptical (but willing to be surprised). Note in case it wasn't clear from my upthread posts, strict partition (no cross-partition transactions) for crypto coin (i.e. asset transfers) maintains Nash equilibrium. But cross-partition transactions for asset transfers does not maintain Nash equilibrium (unless using a statistical check as I am proposing for my design, and some may think this is dubious but my white paper will make the argument for it). And strict partitioning for scripts can't exist, because the partitions are violated by external I/O.
The way I understand it (and that might be defective) is that the other
partition has no way of validating the cross-partition tx.
If it could do that, ie. if there were an unified database, then there would not really be a partition.
We were writing our posts at the same time. When I clicked to post mine, yours had appeared. Yes it seems you understand the issue.
| [1] | Correct with regard to your first scenario where 2 partitions never talk to each other in the future, you dont need to consider it. If they do talk to each other in the future, and have to merge, this is where Bitcoin, blocks, POW and longest chain rule falls on its arse. Only one partition can exist, there is no merge possibility so the other has to be destroyed. Even if the 2 partitions have not existed for an extended period of time you are screwed as they can never merge without a significant and possibly destructive impact to ALL historic transactions prior to the partition event, so you end up with an unresolvable fork. I feel this is a critical design issue which unfortunately for Bitcoin imposes a number of limitations.
CAP theorem certainly doesn't imply you can't ever fulfill C, A and P, as most of the time you can at least enough to get the job done. What it does state is that you cant fulfill all 3 to any sufficient requirement 100% of the time, as there will always be some edge cases that requires the temporary sacrifice of C, A or P. This isn't the end of the world though, as detecting an issue with P is possible once nodes with different partitions communicate, at which point you can sacrifice C, or A for a period of time while you deal with the issue of P.
If you structure your data set in a flexible enough manner, then you can limit the impact of P further. Considering CAP theorem once again, there is no mandate that prohibits most of the network being in a state that fulfills C, A and P, with a portion of the network being in a state of partition conflict. For example, if there are a network of 100 nodes, and 1 of those nodes has a different set of data to everyone else and thus is on its own partition, the remaining 99 nodes can still be in a state of CAP fulfillment. The rogue node now has to sacrifice C or A, in order to deal with P while the rest of the network can continue on regardless.
All of this can be done without blocks quite easily, the difficulty is how to deal with P in the event of a failure, which is where consensus algorithms come into play.
Bitcoins consensus of blocks and POW doesn't allow for merging as stated, even if the transactions on both partitions are valid and legal.
DAGs and Tangles DO allow merging of partitions but there are important gotchas to consider as TPTB rightly suggests, but they aren't as catastrophic as he imagines and I'm sure that CfB has considered them and implemented functionality to resolve them.
Channels also allows merging of partitions (obviously thats why Im here), but critically it allows a node to be in both states of CAP fulfillment simultaneously. For the channels that it has P conflicts it can sacrifice C or A to those channels, for the rest it can still fulfill CAP.
Lets rewind a bit and look at whats really going on under Bitcoins hood.
Natural network partitions arise in BTC from 1 of 4 events happening:
1. A node/nodes accept a block that has transactions which are double-spending an output present in another block
2. A miner produces a block that conflicts with a block on the same chain height
3. Network connectivity separates 2 parts of the network
4. A miner has control of 51% or more
All 4 of these create a P inconsistency, and so the LCR (longest chain rule) kicks into action to resolve them.
In the case of 1, miners can filter these against historic outputs and just reject the transaction. If multiple transactions are presented in quick succession that spend the same output, miners pick one to include in a block, or they could reject all of them. On the receipt of a valid block, the remaining double-spend transactions that are not in a block get dumped. If a block with a higher POW then turns up, all nodes switch to that block, which may or may not include a different transaction of the double-spend set.
In the case of 2, this happens ALL the time. Orphans cause temporary partitions in the network, but the duration between them is short enough that it doesn't cause any inconvenience. Worst case you have to wait a little longer for your transaction to be included in the next block if the accepted block which negates the orphan block doesn't have yours in it.
In the case of 3, if the separation duration is short, see 2. If its long and sustained, 1 of the partitions will have to be destroyed and undo any actions performed, legal or otherwise causing disruption and inconvenience.
In the case of 4, well, its just a disaster. Blocks can be replaced all the way back to the last checkpoint potentially and all transactions from that point could be destroyed.
There can also be local partition inconsistencies too, where a node has gone offline, and shortly after a block or blocks have been accepted by the network that invalidate one or more of the most recent blocks it has. Once that node comes back online it syncs to the rest of the network and does not fulfill CAP at all. The invalid blocks that is has prior to coming back online are destroyed and replaced.
You could argue that this node creates a network level partition issue also to some degree, as it has blocks that the network doesn't, but the network will already have resolved this P issue in the past as it would have triggered an orphan event, thus I deem it to be a local P issue.
So whats my point?
In the cases of 1 or 2 there does not need to be any merging of partitions. Bitcoin handles these events perfectly well with blocks, POW and LCR with minimal inconvenience to honest participants providing that the partition duration of the network is short (a few blocks).
In the case of 3, which is by far the most difficult to resolve, the partition tolerance reduces proportional to the duration of the partitioned state, and becomes more difficult to resolve without consequence in any system, as there may be conflicting actions which diverge the resulting state of all partitions further away from each other. These partition events will always become unsolvable at some point, no matter what the data structure, consensus mechanisms or other exotic methods employed, as it is an eventuality that one or more conflicts will occur.
The fact is that DAGs/Tangles and our channels have a better partition resolution performance in the case of event 3 as the data structures are more granular. An inconsistency in P doesn't affect the entire data set, only a portion of it, thus it is resolvable without issue more frequently as the chances of a conflict preventing resolution is reduced.
Now, you haven't provided any detail on exactly how you imagine a data structure that uses blocks that could merge non-conflicting partitions, let alone conflicting ones. In fact I see no workable method to do this with blocks that may contain transactions across the entire domain. Furthermore, who creates these "merge" blocks and what would be the consensus mechanism to agree on them? In the event of a conflict, how do you imagine that would be resolved?
When it comes to partition management and resolution where block based data structures are employed, Satoshi has already given you the best they can do in the simplest form. Trying to do it better with blocks is IMO a goose chase and you'll get nowhere other than an extremely complicated and fragile system.
|
|
|
|
|
|
Show Posts
