[neㄘcash, ᨇcash, net⚷eys, or viᖚes?] Name AnonyMint's vapor coin?

[TPTB_need_war]

....

Agreed this is a problem when there is a huge double-digit percentage annual debasement due to PoW that is mostly ending up in professional miners hands. The professional miners locate their latest model ASICs next to hydropower plants have 1/4 the electricity costs (compared to residential) and 1/100th - 1/1000th (for a specially designed PoW hash function such as the one I will soon release, not SHA) the computational costs compared to general CPU at home, thus their cost of mining for example a Bitcoin is less than $50 each. They will always have an incentive to add more resources to capture a greater percentage of the mined coins.

But that isn't the only way to structure PoW mining.

There are two ways to deal with this problem:

1) Force every user to submit PoW with their transactions, i.e. no transaction gets on the block chain without PoW attached. Note getting this sort of design to be robust, requires an entirely different way of structuring a block chain. If the attached PoW is low enough difficulty, then it costs more to farm it out (network latency cost) than to mine it locally given it is an insignificant and unnoticeable cost.

2) Limit debasement to a small annual percentage.

In that case, the professional miner will not be able to mine a significant quantity of the coins, and they will not be selling a significant percentage of the market cap. Thus the downward pressure on the price that impacts Bitcoin will be abated....

Why not just use copyrighted cpu extensions that are illegal for manufacturers to produce without Intel and or AMd licensing?

China doesn't enforce our copyrights.

Governments don't enforce our property rights when it conflicts with their power.

If not for the fact that not all global jurisdictions will comply, I would presume that authorities could probably track down the centralized sources of PoW that a botnet could be retrieving the PoW from. The botnet itself can't be targeted with legal action.

Generally speaking I do not even consider any ideas that involve relying on legal structures to enforce, because I am strongly anarchist/Libertarian. But it is also true that until there is a NWO world government totalitarianism that has a monitoring 666 chip on every computer and human, then enforcing law is leaky.

We are trying to construct monetary freedom orthogonal to dependence on governments.

I don't consider a copyright to be property, rather I consider it to be theft from the future (degrees-of-freedom). Coasian barriers are stable until they burst.

[TPTB_need_war]

There are two ways to deal with this problem:

1) Force every user to submit PoW with their transactions, i.e. no transaction gets on the block chain without PoW attached. Note getting this sort of design to be robust, requires an entirely different way of structuring a block chain. If the attached PoW is low enough difficulty, then it costs more to farm it out (network latency cost) than to mine it locally given it is an insignificant and unnoticeable cost.

2) Limit debasement to a small annual percentage.

In that case, the professional miner will not be able to mine a significant quantity of the coins, and they will not be selling a significant percentage of the market cap. Thus the downward pressure on the price that impacts Bitcoin will be abated.

The reason for the block reward is to subsidise the security of the blockchain. In bitcoin, each transaction would need to pay $7 of transaction fees to achieve the level of security that it currently enjoys, without block reward.

Point 1 - if only transaction submitters can mine their own blocks, how do you handle difficulty adjustment?

Difficulty is adjusted as it is always is for PoW.

Point 2 - If it is not profitable to mine the chain, how do you achieve the same level of security as with a subsidised chain?

It might still be profitable to mine the chain for the professionals with very low electricity costs and very efficient ASICs, but for the transaction submitters it surely isn't profitable (but it isn't noticeable either so they don't care or even know).

The profitability is orthogonal to your point, which is you mean how to get Bitcoin's security if the percentage of your market cap paid to mining debasement and the market cap are not the same level as for Bitcoin.

You are making the point that small market cap and/or low debasement coins have lower PoW security.

I already asserted that 51% attacks are pretty much impotent. It will require nearer to 100% attack to snuff out the minority and force them to adopt a protocol change, which is the major risk from a 51% attack in existing PoW designs. Also in my design 51% doesn't help for creating a double-spend.

The only need for the PoW in my design is to prevent a Sybil attack on the distributed confirmation resources. A 51% attack that orphans a legitimate chain of these statements about resources, can't undo the reality of the inertia that has been established on that orphaned chain. It can supplement the resources, but attempting to take away resources that already intertwined in the inertia will be ignored by all those nodes which are bound to lose income from unwinding that inertia. In other words, there will be sufficient allowance made for any reasonable orphan rate due to normal propagation delays and anything outside of that will have already accrued inertia and be impossible for the 51% attack to unwind in order to create a double-spend.

The reason that inertia alone couldn't be used to establish the single-point-of-truth on the resource set is because it doesn't have a definable boundary such as blocks that can be counted. Inertia is a local perspective (each participating node has a perspective on the inertia that is invested in) but it doesn't have global consistency. This is why I am confident the DAG coins such as Iota are flawed. Thus I still needed PoW for this global consensus, but the 51% can't win every block (only near to 100% can), so it is impotent in my design. The 51% can blacklist the minority's block solutions, but if the reasonable propagation delay is orders-of-magnitude less than the period of 1 block then such habitual blacklisting can be statistically distinguished from orphan rate and thus can be objectively identified as malicious and ignored.  Propagation ends up being the crucial design factor in design like mine. This is why I said I don't think Bitcoin can graft these things onto their existing paradigm. More details will forthcoming in the white paper.

That is far more details than I really wanted to release now. So any further questions that require explaining the details of my design might illicit from me, "wait for the white paper".

Edit: Bitcoin pays far too much to security. The only reason to pay anything for security in my design is because 0% debasement is deflationary because users lose private keys. By paying those losses back to users who transact, it transfers value over time from those who don't transact to those who do, which is favorable for encouraging more currency use and more network effects. What could be done instead is pay nothing for PoW mining and then pay debasement proportionally to every coin that transacted in that period (or pay weighted by coin days destroyed age). But this weighting by value would be incongruent with hidden values (private data). Instead the payment could be weighted by the number of transactions, which is functionally equivalent to paying for each mining share of PoW (assuming every transaction is required to include the same level of PoW). If the PoW allowed to be submitted with each transaction is less than the profitability for the confirmation node from typical transaction fee, then professional miners could not mine profitably. They might consider being their own confirmation node, except the assumption is transaction fees will in a competitive environment be very near to cost with very low profit margins so if the PoW was sufficiently high then professional miner couldn't overcome. But I think that is unlikely to be the case because of the asymmetry in the delay for a home user and cost for a professional miner to compute that PoW share. If private keys timed out (e.g. yearly), we could more precisely calculate the level of debasement needed, but this would be shocking to people that lose their coins because they were inactive. Instead if coins assumed to be lost were allowed to be spent, one could use demurrage to recapture excess prior debasement, but the problem is that doesn't spread the pain out equitably between those who were formerly invested in the coin but sold and those who are currently invested. Debasement is much less individually and immediately noticeable. Small levels of debasement are not an issue for users (nor investors). Heck Bitcoin's debasement is still nearly 10% per year and was much higher in the past. I think many people forget that many coins are lost (I've lost private keys for close to 1 BTC in 2 years already which is roughly 1+% of the volume of BTC that ever passed through my hands). With smaller balances and microtransactions, much larger percentage will be lost.

[monsterer]

Difficulty is adjusted as it is always is for PoW.

How do you deal with user A with a very slow device sending a transaction vs user B with a mining farm sending a transaction? I.e why can't B push the difficulty up so high as to make sending a transaction impossible for A?

The profitability is orthogonal to your point, which is you mean how to get Bitcoin's security if the percentage of your market cap paid to mining debasement and the market cap are not the same level as for Bitcoin.

Yes and no. Bitcoin's security is not orthogonal to the block reward - it is tied directly to it. If you assume hashing power is proportional to reward, interpolating the hashing power at 25 BTC per block down to the average amount of transaction fees per block, the security of the chain diminishes accordingly.

The only need for the PoW in my design is to prevent a Sybil attack on the distributed confirmation resources. A 51% attack that orphans a legitimate chain of these statements about resources, can't undo the reality of the inertia that has been established on that orphaned chain. It can supplement the resources, but attempting to take away resources that already intertwined in the inertia will be ignored by all those nodes which are bound to lose income from unwinding that inertia.

I look forward to reading more details about your definition of inertia as it pertains to consensus design with great enthusiasm

[TPTB_need_war]

It is 3:30am and I been awake since 7am, so please excuse if this reads like I am drunk.

Difficulty is adjusted as it is always is for PoW.

How do you deal with user A with a very slow device sending a transaction vs user B with a mining farm sending a transaction? I.e why can't B push the difficulty up so high as to make sending a transaction impossible for A?

Because A is not required to increase the PoW difficulty (number of leading 0 bits) for the PoW required to be submitted with a transaction. It is not used to rate limit spam. The only purpose is to get every payer to contribute something to the security. Again as I explained in the prior message, for as long as no entity has control over (near to) 100% of the PoW, their asymmetric leverage is fairly impotent.

Even most mobile phones has SIMD Neon now, so their performance on BLAKE2 would only about be about 1/4 - 1/10. However the PoW hash I designed is optimized for desktop processors due to the highly optimized carryless multiply instruction in the AES_NI. So mobile phones might end up with a noticeable delay. There is a sweet spot to balance this, because devices will get faster over time, and there are a lot more mobile devices than desktop PCs these days. Will choose some reasonably balanced level, and the goal is to maintain at least a few percent (if not better) of the network PoW hash rate coming from distributed users instead of 100% from professional farms.

Edit: it is possible to have two PoW hash function alternatives if it can be determined that the relative advantage for ASICs for the SIMD BLAKE2 hash is compensated relative to the PoW function that I designed which uses the carryless multiply instruction. Thus it might be possible to leverage the SIMD NEON in mobile phones.

The profitability is orthogonal to your point, which is you mean how to get Bitcoin's security if the percentage of your market cap paid to mining debasement and the market cap are not the same level as for Bitcoin.

Yes and no. Bitcoin's security is not orthogonal to the block reward - it is tied directly to it. If you assume hashing power is proportional to reward, interpolating the hashing power at 25 BTC per block down to the average amount of transaction fees per block, the security of the chain diminishes accordingly.

As I wrote in my prior post, all that matters is what percentage of your market cap you are paying to debasement over any period of time, and that determines how much electricity can be spent each such period on PoW. But more debasement doesn't lower the ratio of professional miners to distributed non-professional miners, thus it really doesn't increase security. It is isn't a defense against a 51% attack, because more debasement doesn't correlate with better distribution of PoW resources. It is basically nonsense and we've been hoodwinked into throwing our money away to professional miners who are siphoning all the value out of Bitcoin by mining at < $50 per BTC cost. (Edit: and then by roughly 2032 or sooner, Bitcoin completely dies because mining funding has to come nearly all from transactions and the coin becomes highly deflationary, but long before then we will have replaced Bitcoin)

This is why I have tried to move entirely away from viewing PoW as security, because it isn't by itself security. I view PoW only a Sybil prevention mechanism for obtaining a consensus on nominated resources, which an aspect of driving the security of the inertia that results from those resources. Without PoW, anyone could nominate themselves and there'd be no convergence of the inertia (which is the precisely what I expect for Iota once someone writes a client other than the one they release to game theory their protocol)— other than meta-protocol convention and community coordination.

The only need for the PoW in my design is to prevent a Sybil attack on the distributed confirmation resources. A 51% attack that orphans a legitimate chain of these statements about resources, can't undo the reality of the inertia that has been established on that orphaned chain. It can supplement the resources, but attempting to take away resources that already intertwined in the inertia will be ignored by all those nodes which are bound to lose income from unwinding that inertia.

I look forward to reading more details about your definition of inertia as it pertains to consensus design with great enthusiasm

The key is that when propagation is orders-of-magnitude faster than the block period, and there is no way to Sybil attack the network due to PoW consensus, then lying about having not propagated is statistically and objectively filterable as fraud. Thus the 51% attack falls away. There are more details that need to be explained.

In Satoshi's design the nodes want to be on the longest chain of PoW. In my design, they want to be on the longest chain of PoW which is not incongruent with the propagated inertia. There are two aspects (PoW and inertia) interlocking and supporting each other synergistically. The reason Bitcoin (Satoshi's design) can't do this distinction is because there is no inertia orthogonal to PoW. If you are thinking the PoW nominates the inertia, so the inertia is not orthogonal, then don't forget another key detail which is duration of nomination is much greater than any statistically objective honest orphan chain length (duration). Essentially my design is a form of anti-aliasing. More PoW resources can gain a larger share of the inertia, but the thing about inertia is that each participant views their own inertia as a priority and so any entity trying to blacklist another's inertia is going to be viewed statistically and objectively as fraudulent and thus that fraudulent PoW can be filtered out and its inertia spirals down. In other words, greater share of resources doesn't allow you to violate the laws of physics about propagation.

[TPTB_need_war]

Apologies my brain was toast in my prior post after 20 hours non-stop coding (other than a few minutes to eat and urinate).

---8<---

In Satoshi's design the nodes want to be on the longest chain of PoW. In my design, they want to be on the longest chain of PoW which is not incongruent with the propagated inertia. There are two aspects (PoW and inertia) interlocking and supporting each other synergistically. The reason Bitcoin (Satoshi's design) can't do this distinction is because there is no inertia orthogonal to PoW. If you are thinking the PoW nominates the inertia, so the inertia is not orthogonal, then don't forget another key detail which is duration of nomination is much greater than any statistically objective honest orphan chain length (duration). Essentially my design is a form of anti-aliasing. More PoW resources can gain a larger share of the inertia, but the thing about inertia is that each participant views their own inertia as a priority and so any entity trying to blacklist another's inertia is going to be viewed statistically and objectively as fraudulent and thus that fraudulent PoW can be filtered out and its inertia spirals down. In other words, greater share of resources doesn't allow you to violate the laws of physics about propagation.

Here is some overview of the conceptual math to make this more concrete.

In Satoshi's design, the probability of your chain not being the longest chain and thus being orphaned is calculated (employing a Poisson distribution approximation) solely based on the number of blocks, z, that have followed (and including) the block containing your transaction. No where in the calculation of the longest chain or probabilities for a double-spend do you see any variable related to anything other than z and the relative PoW power (p/q) of the entity computing a longer chain:

https://bitcoin.org/bitcoin.pdf#page=6
https://bitcoil.co.il/Doublespend.pdf#page=5  (http://arxiv.org/pdf/1402.2009.pdf#page=5)

Here follows references on the computing the orphan rate and the statistics about "informed nodes":

http://diyhpl.us/~bryan/papers2/bitcoin/Information%20propagation%20in%20the%20Bitcoin%20network.pdf#page=8
https://bitcointalk.org/index.php?topic=250735.msg2666847#msg2666847
https://blog.ethereum.org/2014/07/11/toward-a-12-second-block-time/#comment-1521884349
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/009916.html
https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf#page=4

As an approximation, as the "average" verification+propagation delay decreases linearly relative to the block period (block period is enforced with PoW difficulty), then the orphan rate and probability of being an uninformed node or on an orphaned chain (at some z) decreases exponentially.

Thus statistically it should be possible to ignore longer chains that become widely informed much later than the probabilities would indicate are reasonable, i.e. one could select a threshold for filtering at say 1/1000 chance without causing appreciable pain to honest miners.

But Bitcoin's nodes can't measure how relatively informed all nodes are for the competing chains (i.e. there is no reference point, everything is totally relative solely to longest chain measured in blocks and/or cumulative difficulty of the blocks), thus it can't incorporate such a statistical anti-aliasing against dishonest mining. What I have initially named "inertia" are the confirmations that occur orthogonal to the PoW chain, which Bitcoin doesn't even have (and the Bitcoin-NG proposal/paper doesn't change this, because confirmations don't occur out-of-order and orthogonal w.r.t. to the nomination from the longest chain). Thus in my design there is an objective measurement that is valid from the perspective of each node as to whether one chain (although longer) was withheld from the network or is blacklisting some portion of the network. Again this depends on some very specific changes to the design and propagation of the P2P network. Which also depends on an overall change to the way confirmations are achieved and recorded in the block chain. It has some conceptual similarities to a DAG, but I assert (not yet shown publicly) my design rectifies the issues with a DAG that I outlined in my discussions last month with CfB@Iota. Details to be forthcoming in white paper.

So in my design the math—for choosing the longest chain to mine on—include the calculations about what is statistically fraudulent.

Thus double-spending, blacklisting the minority PoW, and forking the protocol with a 51% attack becomes statistically implausible (intractable).

In other words, I unconflate confirmation of transactions (which is inertial evidence of who is lying about propagation) with PoW longest chain consensus (and use that consensus only to nominate who can do confirmations). Thus being nominated is permissionless, unless the adversary has 100% of the PoW. The adversary could have 99% of the PoW and the nominated resources, but it would still be objectively clear to the remaining 1% that the 99% is fraudulenting blacklisting the minority or forking the protocol and thus the minority's inertia would fork away from the fraudulent inertia. The payer's (non-full node) clients would recognize this also (by monitoring block announcements on both chains and computing relative statistics about delay, noting that block announcements are very light to verify and "fraud proofs" are employed as security mechanism ... see my recent posts about "segregated witness") and send their transactions through the 1% fork. This of course requires a much longer block period because the propagation delay to any client could be much longer. So in essence the dishonest fork could have 99% of the PoW yet none of transaction activity. If the 99% PoW fork is not measurably dishonest, then it will of course not be filtered out.

A future white paper will lay out the precise math for peer review.

[monsterer]

As an approximation, as the "average" verification+propagation delay decreases linearly relative to the block period (block period is enforced with PoW difficulty), then the orphan rate and probability of being an uninformed node or on an orphaned chain (at some z) decreases exponentially.

It's certainly the case that, during nominal operation, latency is a driving factor in orphan rate, especially as the block period decreases. It's easy to see why because the easier it is so solve a POW, the more miners will build on the same block, causing orphans to be more common as the same data structure gets updated simultaneously by different miners.

However, this is nominal operation, not an attack scenario. It does not follow that statistically less orphans means better security, simply because an attack is not nominal operation.

So in my design the math—for choosing the longest chain to mine on—include the calculations about what is statistically fraudulent.

Taking a guess here, I suspect you have two classes of miner? Type A is the professional miner expending a lot of energy to produce chains of work and type B is the every day user sending transactions already mined by including a POW with the transaction. So the key becomes how to make sure that you cannot impersonate type B miners to throw your new chain selection rule out of whack, since their POW difficulty must be trivially easy to solve.

You'll need to prove that the type A miner (with say 1M x the hashing power), cannot have 1M x the influence over the chain selection rule (by, say, impersonating 1M type B miners), otherwise this will collapse to being equivalent to regular longest chain selection rule.

[TPTB_need_war]

For example, assume a design scenario where the block period T is 10 minutes (600 seconds) and within 6 seconds of a block announcement (note one white paper showed the weighted average in Bitcoin is 11.37 seconds), it will have propagated to at least 80% of all nodes. Thus the probability of having 2 or more competing chains is approximately 1/100. Before getting into the implications of that fact w.r.t. to my design, first let us note that an entity controlling 50+% of the PoW resources could choose to withhold his block solutions until another one is announced (thus making sure it propagates within the 6 seconds), while continuing to mine on his hidden solution (thus the adversary's chain will ultimately always be longer after sufficient blocks) and thus that 50+% entity will always be able to blacklist (overrule) any minority block announcements. That is the selfish mining attack and it causes the rest of the network to do wasted PoW. However, by rewarding all block solutions that are announced within the propagation window, the attacker's strategy is foiled. In 2014, I had revealed the math proving that is a solution to the selfish mining attack. However, if we are not interested in just foiling the economic incentive of selfish mining, but we also want to foil the blacklisting incentive, I will hereby reveal another epiphany. We can require that any blocks will follow a contest between chains, must include the nominations (in my design) from both blocks (note we might not be able to, depending on the design be able to incorporate the txns from both chains because there may be double-spend conflicts, but suffice that nominations can't conflict).

Thus the only way for the 50+% adversary to blacklist minority PoW that nominates its nodes is for that adversary to win all the blocks and always announce the blocks as soon as they are found (otherwise the adversary is required to include the nominations from minority announcements if the adversary pursues the selfish strategy mentioned above which defeats the blacklisting). But if the adversary announces block solutions as soon they are found, then the adversary can't statistically win all the block announcements unless it has 100% of the PoW.

Okay the adversary must shift his strategy to fooling the payers (non-full nodes) into believing that the minority did not propagate first (or within for example 6 seconds if we choose 6 seconds as the rule), thus convincing the payers that the minority announcements were not required to be included in the longest chain. If the payers are not listening to the network, they have to trust some full nodes to tell them what happened. If the adversary violates the protocol and doesn't include the minority nominations (because the adversary can fool the payers), then the adversary can own all the nominations and thus report what ever it wants to report to the payers. The typical Bitcoin security argument is the community will call out such an adversary and take action. But I was never satisfied with that reasoning, because the masses are easy to manipulate because they are preoccupied.

So to make my design really robust, the payers need to be listening so they can enforce the protocol. Remember I am making a micro-transaction coin, so the payers will be online often. And often is good enough. Because if the payers clients blacklist the 50+% adversary's chain for violating the protocol, then the adversary could have 99% of the PoW resources, but if they constantly lose a larger and larger share of the payers, then they honest network has forked away from the adversary and filtered it out. This is what I mean by inertia. And also this inertia will become entangled (DAG-like) such that it is impossible to undo this filtering and the 50+% attacker racks up huge losses (in transaction fee revenue and uncompensated PoW). In my design the block announcements don't include any transaction nor PoW share data, so they are very lightweight to propagate.

Note I am still searching for holes in this design. So I am not assuming it is perfect yet. (There are likely issues revolving around conflicts in UTXO between competing chains, i.e. one users is wants the transaction to go on the adversary's chain which another user has observed as the fraudulent chain and is not accepting. The payer would then need to spend on both chains until the conflicting user has observed for itself that the adversary's chain is dishonest, then it would shift over the honest inertia) At the moment, I am preoccupied with getting something launched, so the peer review of the theory will need to wait.

I did take the time to write this part down, because I do have to incorporate some aspects of this design in the coding work I am doing now. So I wanted to make sure that my logic on the necessity of the payer monitoring is correct, because I am incorporating the necessary block chain records so the users of the network have the necessary state persisted for them in the block chain.

Point being that this is going to be easy as pie for a dummy to use. And personal password security should be much easier to deal with.

However, this is nominal operation, not an attack scenario. It does not follow that statistically less orphans means better security, simply because an attack is not nominal operation.

As I explained above, latency is a parameter for the holistic security design when incorporated into a holistic paradigm as I have explained. The higher the latency of propagation (the interval of indeterminism about which block announcement was first and what was the interval between announcements), the larger the block period needed to reduce the incidence of competing chains (if the selfish mining scenario has been defeated given my solutions for defeating selfish mining). The higher the expected (computed probability of) incidence of competing chains, the more often that multiple sets of nominations have to be included (per the epiphany rule I mentioned). This may be acceptable by appropriately dialing down the duration of nomination consummately, assuming that doesn't adversely impact some other important factor.

So in my design the math—for choosing the longest chain to mine on—include the calculations about what is statistically fraudulent.

Taking a guess here, I suspect you have two classes of miner? Type A is the professional miner expending a lot of energy to produce chains of work and type B is the every day user sending transactions already mined by including a POW with the transaction. So the key becomes how to make sure that you cannot impersonate type B miners to throw your new chain selection rule out of whack, since their POW difficulty must be trivially easy to solve.

The PoW from all is unified. Sending PoW with transactions is one way to incentivize users to contribute their CPU resources so the professional miners won't control near to 100% of the PoW. Another way to incentivize them is they will need to pay some PoW to nodes that propagate block announcements to them. Thus while they are online doing microtransactions, their computer will be doing some background mining (but very lightly so, preferably scaled down when CPU load is high, i.e never significant enough for the user to complain about or increase their electricity bill noticeably and on mobile phones not plugged into the charger this really has to be subdued). The user can pay instead using micro-transactions which is more economical except they can perhaps notice this (or maybe not since the entire point of micro-transactions is your don't fuss over small incremental spend decisions). We'll work out this balance over time. These are the short of maturity issues that really require a lot of contributors and people working on the source code. I can't do all of these microscopic optimizations by myself. I am just trying to first get the basic coin launched.

You'll need to prove that the type A miner (with say 1M x the hashing power), cannot have 1M x the influence over the chain selection rule (by, say, impersonating 1M type B miners), otherwise this will collapse to being equivalent to regular longest chain selection rule.

I explained above that yes the entity that controls 50+% of the PoW could monopolize the nominated confirmation nodes by lying to non-full nodes (using that monopoly on nodes) about the propagation events that occurs when the non-full node wasn't listening. But by having non-full nodes listen (only when they are online doing micro-transactions and remember most people these days are online most of the day and if micro-transactions become integrated into everything we do on the internet!), then I explained the 50% adversary can't violate the rule and monopolize.

Realize also that once a listening peer has saved (on the block chain!) that he requires the hash of a given block to be included in any chain he accepts, this is a form of distributed checking pointing too. And also that node doesn't have to be online in the intervening period in to detect that a future chain has or has not incorporated that hash earlier in the chain. Thus the honest inertia aggregates over time, and is not diluted by being off line. It is a form of automated community policing by algorithm.

Note also this is not the same as nodes just checkpointing which ever chain they want to. That would cause chaos and divergence. Instead there is a clear rule about consensus which is defined by PoW in such a way that the only way to monopolize it to control what propagation the users observe (which means global control and thus I shift the security from 50% control to nearly 100% control required). Afaics, the only way to have divergence is for nodes to be lied to about propagation. Here is where the community needs to play a role and maintain a list of honest relay servers and easy-as-pie ways for users to access these automatically configured into clients. I am leading the way on this ease-of-use lesson with my initial coin launch example web-based client. It will be easier than Coinbase and Paypal, yet the user controls his own coins (and private key).

[monsterer]

So to make my design really robust, the payees need to be listening so they can enforce the protocol. Remember I am making a micro-transaction coin, so the payees will be online often. And often is good enough. Because if the payees clients blacklist the 50+% adversary's chain for violating the protocol, then the adversary could have 99% of the PoW resources, but if they constantly lose a larger and larger share of the payees, then they honest network has forked away from the adversary and filtered it out.

Why can't an attacker simply pretend to be 1M payees, and use that control to vote in his fraudulent chain?

[TPTB_need_war]

So to make my design really robust, the payers need to be listening so they can enforce the protocol. Remember I am making a micro-transaction coin, so the payers will be online often. And often is good enough. Because if the payers clients blacklist the 50+% adversary's chain for violating the protocol, then the adversary could have 99% of the PoW resources, but if they constantly lose a larger and larger share of the payers, then they honest network has forked away from the adversary and filtered it out.

Why can't an attacker simply pretend to be 1M payers, and use that control to vote in his fraudulent chain?

The attacker can do that (even with a minority of the PoW). It is good to see that my prior explanation was coherent enough that you pondered that possibility, so I know I have made progress in my elucidation of my block chain design.

But anyone today could create a fork of Bitcoin and use it for paying from themselves to themselves, but no one does that because it is pointless.

As I explained, in my block chain design all the users who are (or their client is automatically) concerned about following the protocol which enforces honesty, will not be on the attacker's chain which has violated the protocol, because the objectivity of the protocol is not subjective.

To recap, a majority PoW attacker with approximately 49 - 99% (49% because the network wastes some of its PoW mining the orphaned chain per the white paper I linked in my prior post) of the systemic PoW resources normally in Satoshi's design has the ability to win every block announcement (thus blacklisting the minority PoW from the longest chain of PoW), because the attacker can ultimately build a longer chain which orphans all the block solutions produced by the minority. However I have stated that if we change Satoshi's protocol so that every announced block solution which is not challenged by another block solution within the reasonable propagation window (e.g. 6 seconds), must be based off the previously propagated block solution. Thus the attacker can no longer blacklist the minority PoW from the longest chain of PoW.  (With 99 - 100% majority of the PoW resources, an attacker can defeat the security in my design as well).

For n00b readers (not you monsterer), please understand the Bitcoin 101 concept that due to the randomness in the Poisson distribution, an attacker with < 100% of the PoW resources can't produce the first block solution every block period if the attacker is required to start his computation of each block at the same time as everyone else in the network. An attacker can produce a longer chain with a majority of the PoW resources, but only if the attacker is allowed by the protocol to ignore the minority's PoW solutions that occasionally (not a majority incidence) arrive faster than the attacker can produce the next block. Satoshi's design does not require the attacker to build his next block off the propagated block. Satoshi's design allows the attacker to build his chain hidden. This is the major design error of Satoshi's design, that enables selfish mining and the 51% attack. I correct Satoshi's design error. I believe this is the first explanation of any where of my aforementioned rule as a solution. If anyone can cite a prior art on this point, please do. Probably there is a post (or posts) from the 2010 - 2011 timeframe on this forum (or in 2013/14 discussions about the selfish mining white paper) that has some similarity to my point. I would be very interested in reading such posts if anyone can find such.

There are reasons that Satoshi's design can't incorporate my aforementioned rule which defeats selfish mining and the 51% attack:

• The attacker could put a double-spend in his chain, thus he can not follow a rule which forces him to base his chain on the announced chain which contains a double-spend. In Satoshi's design, there is no objectivity about which double-spend in which chain came first (i.e. there is intra-chain objectivity but no inter-chain objectivity). Whereas, my design is different because PoW has a dual role, one of which is to confirm nominations for "confirmation nodes" (the nodes which do the transaction confirmations distributed thus enabling the 1 second confirmed transactions, not 0-confirmation insecurity of Satoshi's design). Thus my rule is that nominations from the propagated block have to be included in the next propagated block, thus defeating the selfish mining and 51% attacks, but Satoshi's design can't do this rule because it doesn't have the concept of nominations. Note that unlike transactions, nominations of "confirmation nodes" can't conflict because they are accumulative. My design can't just be grafted onto Bitcoin, because it requires a radical hard fork which necessities changes throughout the ecosystem of clients (thus virtually impossible to accomplish).
• Satoshi's design has no mechanism to constrain the variance of the propagation. Afair, Satoshi's white paper doesn't even talk about P2P network design (other than the SPV client suggestion) in the propagation context and the propagation design issues. All that design work has been done ad hoc over the past years, where I showed with my recent paper that Maxwell et all still haven't even addressed DDoS (which it is synergistic with propagation due to amplication as I explained my recent paper) in the scaling up scenario. I will not explain my entire design now.
• Satoshi's suggestion of SPV lite nodes are too lite to guard the network. Recent comments from the Hong Kong Bitcoin scaling conference (which I really wanted to attend but I am just too overloaded with my illness and trying to get a coin launched) show that Bitcoin lead core dev Wuille at al are thinking more about Segregated Witness and user clients that are in between the power of a full node and an SPV node, as is the case in my proposed design. But afaics, they are a probably a long way from realizing all the issues and then realizing they can't realistically graft this onto Bitcoin and it will instead need to be a side-chain (since those guys work for Blockstream).

[monsterer]

However I have stated that if we change Satoshi's protocol so that every announced block solution which is not challenged by another block solution within the reasonable propagation window (e.g. 6 seconds), must be based off the previously propagated block solution.

* How do you prove to a syncing node that a given historical block arrived within the 6 second propagation window without having a different protocol for syncing/live nodes?

* Is it possible to differentiate between a syncing/live node in a p2p blockchain without being subject to attack edge cases? (e.g. all proof of stake chains)

What about this attack:

1. Miner A controls a large amount of POW resources and wishes to double spend by creating a bunch of finney blocks
2. They start with the genuine last propagated block
3. Generate a new block on top
4. Nominate the crap out of it with their superior POW resources
5. Fake the time stamps
6. Loop to 3

When they're done, they dump this huge finney chain onto the network which also contains their double spend?

[TPTB_need_war]

However I have stated that if we change Satoshi's protocol so that every announced block solution which is not challenged by another block solution within the reasonable propagation window (e.g. 6 seconds), must be based off the previously propagated block solution.

* How do you prove to a syncing node that a given historical block arrived within the 6 second propagation window without having a different protocol for syncing/live nodes?

My design doesn't (and afaics shouldn't need to) prove to a syncing node anything about propagation that occurred while that node wasn't listening live. Remember that the 49 - 99% attack must be sustained otherwise it can't maintain the blacklist on the minority PoW. The minority PoW will have identified the dishonest chain and be humming along (at a reduced level of PoW difficulty, yet still including the attacker's nominations so as to prove to syncing nodes which chain is refusing to include the other's nominations). So the syncing node will have ample opportunities while live to objectively determine which chain is dishonest.

(Assuming the node is syncing to a honest relay and remember my point about community responsibility for this,) the syncing node will see there are two competing chains and thus syncing node will be wary to accept any transaction as final until it has determined which chain is the honest one. Note that if the dishonest chain is an extension of the chain the syncing node had earlier identified as dishonest (a hash for that node's choice is saved on the block chain so the node can't forget), that node already knows it blacklisted that chain (which can be determined from the chain history).

* Is it possible to differentiate between a syncing/live node in a p2p blockchain without being subject to attack edge cases? (e.g. all proof of stake chains)

What about this attack:

1. Miner A controls a large amount of POW resources and wishes to double spend by creating a bunch of finney blocks
2. They start with the genuine last propagated block
3. Generate a new block on top
4. Nominate the crap out of it with their superior POW resources
5. Fake the time stamps
6. Loop to 3

When they're done, they dump this huge finney chain onto the network which also contains their double spend?

Finney attacks are not possible in my design, because transactions are not confirmed by PoW blocks. So the payee will not accept the transaction until it has been confirmed, which can be on the order of 1 second from the time the transaction is sent to the confirmation network.

In my (monumental?) prior two posts, I was starting to lay out some of the paradigmatic gains that arose from separation-of-concerns for transaction confirmation and PoW chains. Bitcoin-NG (from the researchers who published the selfish mining attack) separates timing of transaction confirmation from PoW chains (thus removing the latency spikes for propagation of block announcements, i.e. a form of anti-aliasing), but it doesn't eliminate double-spending by orphaned chains (which my design does eliminate). Also Bitcoin-NG nominates only one node per block period to confirm transactions thus Bitcoin-NG (and Bitshares' DPOS) is highly vulnerable to DDoS (even more vulnerable than current Bitcoin which employs Satoshi's design!).

Based on your use of the word 'nominate', you may be misunderstanding what is nominated in my design. C.f. how Bitcoin-NG nominates a node to confirm all the transactions until the next block. In my design, there are a plurality of confirmation nodes nominated, they persist for a plurality of PoW blocks.

Afaics, in my design there simply isn't a way to create an orphaned chain which would be required to create a double-spend other than a Finney attack. In my design, orphaned chains can only occur due to network partitioning and in that case Satoshi's design also allows double-spends on both forks. Dealing with network partitioning is another issue. We can discuss that later.

P.S. as a tribute to the prodigious generosity and amiable unassuming attitude of Hal Finney, I like to share his description of how Chaum's Ecash worked which helped me a lot when I was first learning what the Fiat-Shamir transform is and how it converts an interactive ZKP to a NIZKP (non-interactive zero knowledge proof).

[monsterer]

My design doesn't (and afaics shouldn't need to) prove to a syncing node anything about propagation that occurred while that node wasn't listening live. Remember that the 49 - 99% attack must be sustained otherwise it can't maintain the blacklist on the minority PoW. The minority PoW will have identified the dishonest chain and be humming along (at a reduced level of PoW difficulty, yet still including the attacker's nominations so as to prove to syncing nodes which chain is refusing to include the other's nominations). So the syncing node will have ample opportunities while live to objectively determine which chain is dishonest.

Why isn't it the case that the majority POW also has a monopoly on the set of nodes which can be nominated, thereby dominating the choices for the honest nodes?

[TPTB_need_war]

My design doesn't (and afaics shouldn't need to) prove to a syncing node anything about propagation that occurred while that node wasn't listening live. Remember that the 49 - 99% attack must be sustained otherwise it can't maintain the blacklist on the minority PoW. The minority PoW will have identified the dishonest chain and be humming along (at a reduced level of PoW difficulty, yet still including the attacker's nominations so as to prove to syncing nodes which chain is refusing to include the other's nominations). So the syncing node will have ample opportunities while live to objectively determine which chain is dishonest.

Why isn't it the case that the majority POW also has a monopoly on the set of nodes which can be nominated, thereby dominating the choices for the honest nodes?

In the honest scenario, the 49 - 99% attacker can nominate 49 - 99% of the confirmation nodes, but the crucial distinction from the security of Satoshi's design is the attacker can't dominate ALL the confirmation nodes and thus can't destroy the permissionless quality of decentralized cryptocurrency. Nor afaics can this preponderance of confirmation nodes gain the attacker any advantage in terms of double-spending or abusing the protocol.

In the dishonest attack scenario where attacker wants to own ALL the confirmation nodes, I already explained that:

---8<---

Thus the only way for the 50+% adversary to blacklist minority PoW that nominates its nodes is for that adversary to win all the blocks and always announce the blocks as soon as they are found (otherwise the adversary is required to include the nominations from minority announcements if the adversary pursues the selfish strategy mentioned above which defeats the blacklisting). But if the adversary announces block solutions as soon they are found, then the adversary can't statistically win all the block announcements unless it has 100% of the PoW.

Okay the adversary must shift his strategy to fooling the payers (non-full nodes) into believing that the minority did not propagate first (or within for example 6 seconds if we choose 6 seconds as the rule), thus convincing the payers that the minority announcements were not required to be included in the longest chain. If the payers are not listening to the network, they have to trust some full nodes to tell them what happened. If the adversary violates the protocol and doesn't include the minority nominations (because the adversary can fool the payers), then the adversary can own all the nominations and thus report what ever it wants to report to the payers. The typical Bitcoin security argument is the community will call out such an adversary and take action. But I was never satisfied with that reasoning, because the masses are easy to manipulate because they are preoccupied.

So to make my design really robust, the payers need to be listening so they can enforce the protocol. Remember I am making a micro-transaction coin, so the payers will be online often. And often is good enough. Because if the payers clients blacklist the 50+% adversary's chain for violating the protocol, then the adversary could have 99% of the PoW resources, but if they constantly lose a larger and larger share of the payers, then they honest network has forked away from the adversary and filtered it out. This is what I mean by inertia. And also this inertia will become entangled (DAG-like) such that it is impossible to undo this filtering and the 50+% attacker racks up huge losses (in transaction fee revenue and uncompensated PoW). In my design the block announcements don't include any transaction nor PoW share data, so they are very lightweight to propagate.

---8<---

You'll need to prove that the type A miner (with say 1M x the hashing power), cannot have 1M x the influence over the chain selection rule (by, say, impersonating 1M type B miners), otherwise this will collapse to being equivalent to regular longest chain selection rule.

I explained above that yes the entity that controls 50+% of the PoW could monopolize the nominated confirmation nodes by lying to non-full nodes (using that monopoly on nodes) about the propagation events that occurs when the non-full node wasn't listening. But by having non-full nodes listen (only when they are online doing micro-transactions and remember most people these days are online most of the day and if micro-transactions become integrated into everything we do on the internet!), then I explained the 50% adversary can't violate the rule and monopolize.

---8<---

Also include the following snippet in the above context:

But anyone today could create a fork of Bitcoin and use it for paying from themselves to themselves, but no one does that because it is pointless.

So the 49 - 99% attacker could nominate ALL the confirmation nodes in his private chain, but attacker can't convince the rest of the network that his chain is valid, due to my rule that attacker must include all the nominations from propagated block announcements (which attacker didn't refute within the 6 second window...because as I explained, the attacker can't refute because the rule requires him to restart his computation of next block after each block announcement).

I told you (and all readers) for many months to expect a "Bitcoin killer" algorithmic twist that no one else had apparently thought of.

It is time for everyone to start realizing that I am not a bullshitter and I am legit.

[monsterer]

So the 49 - 99% attacker could nominate ALL the confirmation nodes in his private chain, but attacker can't convince the rest of the network that his chain is valid, due to my rule that attacker must include all the nominations from propagated block announcements (which attacker didn't refute within the 6 second window...because as I explained, the attacker can't refute because the rule requires him to restart his computation of next block after each block announcement).

He doesn't need to convince the rest of the network. The problem is insidious; the attacker presents a majority of fully compliant, well behaved nodes with which the rest of the network becomes acquainted and then sits and waits until he needs to pull of his attack, at which point the minority of the network will go along with his presented truth because they will already be nominating his 'sleeper' nodes.

Unless I have misunderstood the entire design, which is very possible

[TPTB_need_war]

So the 49 - 99% attacker could nominate ALL the confirmation nodes in his private chain, but attacker can't convince the rest of the network that his chain is valid, due to my rule that attacker must include all the nominations from propagated block announcements (which attacker didn't refute within the 6 second window...because as I explained, the attacker can't refute because the rule requires him to restart his computation of next block after each block announcement).

He doesn't need to convince the rest of the network. The problem is insidious; the attacker presents a majority of fully compliant, well behaved nodes with which the rest of the network becomes acquainted and then sits and waits until he needs to pull of his attack, at which point the minority of the network will go along with his presented truth because they will already be nominating his 'sleeper' nodes.

Unless I have misunderstood the entire design, which is very possible

What attack? Up thread I already refuted for my design, all the known attacks on Satoshi's PoW (at least those presented by you and I thus far).

Fully compliant confirmation nodes can't do any attack. If they attack, they are no longer compliant and will be ignored by the honest network (not only ignored but all their transaction fees will be confiscated due to "fraud proofs" recorded by other confirmation nodes and you can see my recent posts relating my design to Segregated Witnesses).

Afaics, having nodes "sleep" (which I guess you mean they do only compliant activity while "sleeping", since you can't mean sleep in terms of being unknown because all nominations are public on the PoW block chain) doesn't aid the attacker in any way in terms of executing any attack at any future time.

I think I can deduce why you are misunderstanding (and it is an expected reason that can probably only be conquered with a very thorough elucidation). It seems you are conflating the concepts of attacks on PoW chains with attacks on, by, or leveraging confirmation nodes. These are orthogonal concepts in my design. For example, confirmation nodes do not gain any power to issue double-spends (all confirmations have an objectivity that can't be violated and that is another design secret and I won't discuss that now but you can look at Dash's Evolution design for a hint).

Again I will reiterate that afaics separating the concerns into PoW and confirmation nodes as orthogonal, provides paradigmatic elimination of the attack vulnerabilities in Satoshi's design.

In my (monumental?) prior two posts, I was starting to lay out some of the paradigmatic gains that arose from separation-of-concerns for transaction confirmation and PoW chains...

As you anticipated, afaics you've entirely misunderstood the design. I think it is improbable to give readers the holistic view (any more than I have already elucidated) without detailing the entire design in a well organized and quite lengthy white paper. And I am not ready to do that yet. Wait a few more weeks please. This discussion has been a "sneak preview".

I think you will be able to offer more constructive and deeper insights once you can understand well every detail of my block chain design. As of now, you will be handicapped by lacking full and deep elucidation from me.

P.S. thank you for injecting your peer review. Look forward to more of it once the design has been released in a well organized paper.

[monsterer]

I think I can deduce why you are misunderstanding (and it is an expected reason that can probably only be conquered with a very thorough elucidation). It seems you are conflating the concepts of attacks on PoW chains with attacks on, by, or leveraging confirmation nodes. These are orthogonal concepts in my design. For example, confirmation nodes do not gain any power to issue double-spends (all confirmations have an objectivity that can't be violated and that is another design secret and I won't discuss that now but you can look at Dash's Evolution design for a hint).

I think this will indeed be key to understanding this design. This probably doesn't help you at all, but the root of my line of reasoning is that the attacker can be both confirmation node(s) and regular node(s) and have a majority of both at any time.

[TPTB_need_war]

I think I can deduce why you are misunderstanding (and it is an expected reason that can probably only be conquered with a very thorough elucidation). It seems you are conflating the concepts of attacks on PoW chains with attacks on, by, or leveraging confirmation nodes. These are orthogonal concepts in my design. For example, confirmation nodes do not gain any power to issue double-spends (all confirmations have an objectivity that can't be violated and that is another design secret and I won't discuss that now but you can look at Dash's Evolution design for a hint).

I think this will indeed be key to understanding this design. This probably doesn't help you at all, but the root of my line of reasoning is that the attacker can be both confirmation node(s) and regular node(s) and have a majority of both at any time.

True, but that (bolded statement) isn't an attack.

Attack means can blacklist minority PoW and confirmation nodes, double-spend, or DDoS attack (or other form of real harm). I think I already explained why having even 99% of the PoW and confirmation nodes does not enable those attacks. But probably it is only clear to me because there are design details in my head that I haven't written here in public. So when I get it all organized in a white paper, it will be more clear to me what I need to explain in more detail.

Paradigmatic shifts are often non-obvious to others (an analogy to banging into a glass door which is obviously there to the person who banged into before), even though to the person who invented them they seem as obvious as sunshine already.

[TPTB_need_war]

monsterer, I was observing whether you would find the weakness in my design, but I don't fault you for not seeing it so early in your exposure to this new conceptual design and lacking all the details. I have been afforded months to think about it with full access to all the details.

I was feigning an incorrect (more accurately "an incomplete") design because I was thinking about keeping the following secret for while longer (and also to see if anyone would find the flaw), but I am also thinking some very astute readers (e.g. Bitcoin core devs if they happen to read this) might silently think I am foolish if I don't complete the description of the design.

So now I will elaborate on the fundamental Achilles heel and trade-off compared to Satoshi's design.

That is if users disagree on the objectivity, then the block chain is forked. The users could disagree if they could be fooled about which blocks propagated within the allotted (e.g. 6 seconds) window. Once they disagreed, they might never agree again (but read on for a solution to that). Since users rely on other nodes to relay to them, the objectivity is under the influence of those relay nodes. Well I already stated most of that in my prior post, but I didn't emphasize that the bad outcome is a fork:

---8<---

Realize also that once a listening peer has saved (on the block chain!) that he requires the hash of a given block to be included in any chain he accepts, this is a form of distributed checking pointing too. And also that node doesn't have to be online in the intervening period in to detect that a future chain has or has not incorporated that hash earlier in the chain. Thus the honest inertia aggregates over time, and is not diluted by being off line. It is a form of automated community policing by algorithm.

Note also this is not the same as nodes just checkpointing which ever chain they want to. That would cause chaos and divergence. Instead there is a clear rule about consensus which is defined by PoW in such a way that the only way to monopolize it to control what propagation the users observe (which means global control and thus I shift the security from 50% control to nearly 100% control required). Afaics, the only way to have divergence is for nodes to be lied to about propagation. Here is where the community needs to play a role and maintain a list of honest relay servers and easy-as-pie ways for users to access these automatically configured into clients. I am leading the way on this ease-of-use lesson with my initial coin launch example web-based client. It will be easier than Coinbase and Paypal, yet the user controls his own coins (and private key).

Whereas, Satoshi's design forces acceptance of the longest chain of PoW thus eliminating the risk of a fork due to disagreeing perspectives on propagation, but at the cost of incurring double-spend risk, 49+% attacks, selfish mining attacks (and for faster 1-confirmations of Bitcoin-NG incurring DDoS attacks).

Besides the problem of objective relaying, any window of time results in disagreement due to minute differences in propagation near to the end of the window! Ouch!

Both problems can be fixed by changing my protocol rule from “honest chain's next block must include the nominations from any that occurred in the 6 second window” to “honest chain must include the nominations from all block solutions that occurred (with the same difficulty)”. Thus the difficulty has to be calculated counting all block solutions.

Thus chains can't diverge, except if they disagree about the difficulty. The objectivity about difficulty is a combination of using very long periods for the calculation so that difficulty is the same in calculations that differ only in small changes in the blocks included can't result in half or double the difficulty (since difficulty increments are a factor of 2 since they are the leading bits of the PoW with a 0 value), and the rule that the correct difficulty is the one that counts the most difficulty in the numerator.

That entirely fixes the fork risk. It also virtually eliminates the trust issues around the relay nodes. The community only needs to verify they relay, not that they relay within very dubious small windows of time, e.g. 6 seconds.

And the inspiration for that conceptually comes from the same way I fixed the selfish mining problem mathematically in 2014 by rewarding all PoW in the orphaned chains. That ends up being one of the most important discoveries I've made, yet it was unceremoniously ignored:

---8<---

That is the selfish mining attack and it causes the rest of the network to do wasted PoW. However, by rewarding all block solutions that are announced within the propagation window, the attacker's strategy is foiled. In 2014, I had revealed the math proving that is a solution to the selfish mining attack.

...discussions about the selfish mining white paper...

Note that rule could not be grafted onto Satoshi's design for an additional reason to those I enumerated in a prior post on this page. That is it essentially removes the requirement to mine at the end of the chain, because there is no objectivity about when a block's computation had to begin. But this isn't a problem in my design, because my design doesn't depend on blocks to confirm the 1 second transactions and thus it doesn't matter if some percentage of the PoW resources are not applied to updating the checkpoints of the confirmation nodes. In short, everything is additive except for double-spends. However this does raise an issue for double-spends documented below.

Note there are other issues that revolve around how checkpoints of the confirmation nodes are recorded in the PoW block chain. Normally these are accumulative (same as for nominations) and can't mathematically be a conflicting double-spend (according to a quorum mechanism that is similar to the one employed in Dash's Evolution except the quorums don't change on every block as that introduces a double-spend risk on time windows on the order of the block period which would otherwise defeat the point of 1 second confirmations, which btw is a critical flaw in Dash's Evolution especially because it is based on Satoshi's design which allows chains to be orphaned). My design also requires a fallback mechanism where the payer is having difficulty finding a cooperative quorum due to the 49 - 99% attacker having a majority of the confirmation nodes. In that case the transactions have to be confirmed by the block chain. For this case, the payees need to wait until all confirmation nodes confirm all confirmation nodes in some number of block confirmations (just like in Satoshi's design) before it is more probable that the merging of all block chains can't have a conflicting double-spend. Double-spends within that interval are invalid upon merge. The objectivity is counting block confirmations (of the same difficulty) regardless which chain they are on. Again my conceptual fix to the selfish mining attack continues to be the solution to objectivity in every place where objectivity would fail otherwise. The potential subjectivity is due to a block solution built off a historic block that attempts to introduce a double-spend. The objectivity is that the block chain will reject this block because it attempts to mine too far into the past (again by counting the number of blocks). So the attack this enables is that the 49 - 99% attacker could build a longer chain has double-spends compared to the honest chain and which starts from far back in history, so then it is not objective as to which chain is honest, because neither chain can merge with the other. Here the objectivity is longer-term propagation (not 6 second windows but counted blocks) trumps and so any chain that was hidden and suddenly revealed from many blocks back in history is the dishonest chain. So what we end up with, is that there is no incentive to mine at the end of the chain if you aren't producing double-spends. However, the problem of subjectivity around the end of the window still applies to counting blocks. When receive more than one block within the propagation window, then if differing arrangements of the order of those block produce different answers as to whether a spend was double-spent or was already confirmed before the double-spend arrived, there is no objectivity. So to fix this we must abandon the feature of having a fallback mechanism to have a transaction confirmation by the block chain. Instead we can have a designated node that can supplant the quorum and this node also changes (but not every block) in the same mechanism as for the quorum (basing on the entropy of the historical block chain). Thus eventually the payer will be able to get confirmation on a node that is not the adversary, except that the adversary can precompute the entropy and try to game theory his nominations changes to prevent that eventuality (but the success of which may be foiled by making the period of confirmation node nomination longer than the number of confirmation nodes, so that all nodes are cycled through before a change can be made to the confirmation nodes). Anonymous transactions (Zerocash style where the IP address can't be correlated across transactions) would be another solution so the adversary can't easily determine which transactions to censor. Realize a vote wouldn't work (adversary controls most of the confirmation nodes) to provide permissionless guarantee, which is one of the critical flaws in the Railblocks design.

And that seems to cover all the scenarios. Whew.

[monsterer]

Both problems can be fixed by changing my protocol rule from “honest chain's next block must include the nominations from any that occurred in the 6 second window” to “honest chain must include the nominations from all block solutions that occurred (with the same difficulty)”. Thus the difficulty has to be calculated counting all block solutions.

Thus chains can't diverge, except if they disagree about the difficulty. The objectivity about difficulty is a combination of using very long periods for the calculation so that difficulty is the same in calculations that differ only in small changes in the blocks included can't result in half or double the difficulty (since difficulty increments are a factor of 2 since they are the leading bits of the PoW with a 0 value),

Why don't disagreements in the set of all nominations cause the same forking problem that would occur with a fixed time window?

Also, isn't adjusting difficulty by factors of 2 is in danger of increasing the volatility of the currency? The cost of production will double or halve rather than smoothly increasing/decreasing as it does in bitcoin.

[TPTB_need_war]

One of the applications of microtransactions will be to get my ethical revenge (i.e. fixing what is a broken concept suppressing open source) on Stackoverflow/Stackexchange and destroy their sites with a superior economic model:

Suppose it's time for me to write down some where and I probably ought to write in Meta, except wouldn't lead to any changes thus waste of time, because the problem is the entire economic model of SO/SE is flawed. First, the votes are hyperinflationary (i.e. you become popular by joining cliques which vote for each other, and speaking to the least common denominator) and can probably even be Sybil attacked to inflate votes. Moreover, downvoting and the comment system are economically misaligned. The entire system should be like open source where you pay and share in what you want to improve.

Lol, how can someone's perverted unethical B-lister conscience downvote a helpful answer[question] that I personally tested solved the issue on my system. I know they justified in their small minds probably something like they thought I was misusing the site as bug reporting tool. B-listers are all elbows & acrimony. Haters gonna hate, players gonna play, nothing I do...about the failure of SO and SE as concept for sharing information. That is until I invent a site to replace and destroy this site. Coming...

For context:

http://stackoverflow.com/questions/26769706/fix-so-cursor-moves-and-displays-correctly-in-eclipse-for-android-development

https://bitcointalk.org/index.php?topic=1284083.msg13220287#msg13220287

I have a myriad of reasons for making a cryptocurrency project. And all the motivations are ethically noble and driving me to work double-digit hours per day at the age of 50+.

P.S. instead of downvoting, fork. Then list all the forks. Downvoting is destructive and counter-productive. The effort to criticize should be consumerate with the effort to create. Duh!