To those voting, "invesment securities" has a meaning in law which is different than your common sense thought of what it should mean. Please take the time to understand the difference before you vote. In particular it doesn't mean any share of anything you investment in. There are certain tests of whether a share of something is an "investment security" or not.

Please indicate if your vote in the poll does not include all those which are below your choice and why.

Please review the following three linked posts wherein I overview my interpretation of the USA and also international law on what constitutes an "investment security" which must be registered with the government regulatory agencies around the world:

https://bitcointalk.org/index.php?topic=1211093.msg12739508#msg12739508
https://bitcointalk.org/index.php?topic=1211093.msg12727136#msg12727136
https://bitcointalk.org/index.php?topic=1211093.msg12722193#msg12722193

Also my comment:


Apparently the implications of not registering "investment securities" means harsh fines and potentially criminal charges can result on being involved with these unregistered "investment securities". I am interested in this from the implications of not only the long-term future of the coin if it is attacked later by government regulators, but also as it pertains to government classification of taxation of the various crypto-coins:

https://www.reddit.com/r/Bitcoin/comments/3pu6v7/by_ruling_that_%C6%80itcoin_exchange_is_taxfree/

Come-from-Beyond has been very cordial to me, so I don't want to defecate on his effort. I have my doubts about viability for the following reason. The ramifications of this probably needs to be discussed more. But it seems to me that having users who send transactions viewing all the transactions before they can send is the antithesis of instant microtransactions and also places a burden on who can send a transaction. You need certain minimum level of connectivity and bandwidth on your connection just to send a transaction. It is an interesting concept and maybe DAG can be integrated in other ways into cryptocurrency. Maybe he needs to figure out how to eliminate this apparent weakness with some paradigm shift. Note it appears to me that Lightning Networks is in some facets (not all) similar to a DAG concept. Perhaps thinking about those two different paradigms will lead to some epiphany.

Hey cool name Iota (IoT)! Good one!

Lending Dash from the masternodes who are accumulating all the coins over time (because the interest rates paid are higher than the debasement rate) could probably drive more usership which might expand network effects value, but the problem is that interest rate paid to masternodes must be less than the debasement rate otherwise mathematically eventually all loans can't be paid back (eventually everything loaned is for making interest payments then the Minsky Moment arrives if not sooner due to stampede of confidence).

You have indicated how Dash could basically become the same fiat economy we've always had, where a group of insiders leech away our production on the debasement-debt hamster wheel.

I may be wrong, but I tend to think that most people entered crypto not only to make a buck, but also because they really want a new paradigm of decentralized, permission-less commerce and not an extension of the debt-debasement hamster wheel society is stuck in. Thus I tend to think most users (and thus network effects) are only going to get really excited about a design that doesn't have anything like a masternode or a delegated-proof-of-share paying an inordinate interest rate to those who can amass large quantity of coins to be one of the masternodes or delegates. For example even though PoW encourages centralization via mining pools, these pools don't earn incredible returns because this is a competitive market where any miner can choose any pool they want at any time. Whereas these masternodes and delegates design take a finite resource of the coin and use that to leech over time all the coins to those who were in this preestablished position (whom ever got the instamine, and I am not going to point fingers, let the SEC do that which I expect they may in due time or not if the culpable parties are also insiders from the financial industry).

Note it is possible to lend any crypto coin, but this is different from lending a coin where the insiders get replenished with all the coins over time. That is a Too Big To Fail model. It is the same model we have that is destroying our society. Debt default losses are socialized and paid by everyone, while the insiders keep getting fatter and fatter. Thus I entirely expect the wider crypto market to reject Dash and it has no chance in hell of becoming the leader for a new paradigm of block chaining scaling.

Also as I said, afaics Evan is bloating the block chain, while increasing instant TPS. The block chain still have to keep up with this proliferation of signatures (N x number of inputs more) which is unscalable decentralized (the problem Bitcoin is facing now but Dash doesn't have this problem yet because user adoption is no where near Bitcoin's modest adoption).

Do you really think Dash will become widely adopted for micropayments with these issues? Okay I hope to shut up now.

You compel me to reply because that is a strong idea.

That will likely open up new game theory scenarios since you know a priori which quorum will receive which inputs in which future blocks. Perhaps an adversary can try to create masternodes to target inputs to accept or deny signing.

As for the claimed 51% immunity, how can one assume if the 51% that owns the mining power doesn't also own a large chunk of the masternodes thus can wreck havoc on any minority chain which desires to respect the signatures of other masternodes for which the 51% attack is not, i.e. a war between groups of masternodes.

Thus the masternodes could be restarted to by your change to infiltrate the quorums of the minority masternodes (up to the N - M + 1 threshold, another reason to set M very close to N  ), so they can remove instant transactions from the minority chain, thus making the claim of 51% immunity false.

Game theory is complex. There are likely many other scenarios of attacks.

The basic problem is using a hash to determine which masternodes are authorized (which is either subject to chain reorg or subject to game theory due to being known well in advance) combined with the fact that masternodes are not fungible but rather are entities owned and with motivation to maximize their gains.

Now having said that, masternodes earn very high payments from the block chain (I saw some chart Evan published that showed up to 50% per annum interest payments) thus I think for now the incentive is for masternodes to be cooperative. Afaics, Dash is basically designed (whether consciously or by serendipity) to funnel all the coins to the insiders over time.

But we are also discussing in the context of what would be the correct design for a coin that was not designed to be unfair and award an advantage to a few entrenched owners of the coin supply. In that case, we'd have to dump the masternodes and find a more fungible design that doesn't have these vulnerabilities. Dash may not actually have these vulnerabilities because the masternodes are making a killing by just cooperating. In a coin design where masternodes weren't leeching most of the coins away, then these game theory vulnerabilities would come into play because the masternodes would have an incentive to collude in other ways to maximize their profits. Yeah we can buy the illusion of decentralization and robust design by paying some masternodes all our coins over time. That works.

If you review the quotes of Evan I dug up and if you understand how he implemented InstantX, then you can deduce very obviously how he is intending to implement faster TPS, as I explained. To resummarize, the block chain hash combined mathematically (hashed?) with the inputs to a transaction is used to determine which quorum of masternodes can sign the transaction, then if M of N of them sign, this is broadcast to the block chain and the transaction is considered confirmed even before the block chain has produced the next block. Note Evan specifically stated inputs and not outputs and I assume the reason is so you can't game which masternodes can be the quorum, but then each input needs to reach a mathematically determined quorum separately (don't know if he has realized that yet), and thus the number of signatures on the block chain will increase by the average number of inputs per transaction (multiplied by N!).

Thus the negative implications of this increased TPS and instant confirmations (which will be realized in his design) are as I stated upthread:

• Block chain becomes more bloated due to N times more signatures, not less.
• Immunity to 51% attack is an incorrect claim, because the block chain hash determines which quorum, thus a chain reorganization can rewrite which quorum was authorized to M of N sign.
• The instant confirmations can not be trusted because if they are on an orphaned chain (not 51% attack but just the normal process of orphan rate or even 25 - 33% selfish mining attack), then they can be reversed. This is the same reason the prior InstantX (a more limited scope for instant confirmations than Evolution because the inputs had to precommitted to the quorum yet this committed could still be overturned by an orphaned chain, a.k.a. chain reorganization) was a technical failure.
• If the masternodes collude to refuse your M of N (and they don't need to be a majority of masternodes, just when ever they control an M of N, then your instant confirmation can not be routed to other masternodes until the next block thus no longer instant so even with a minority they can wreck havoc for example to cause a price decline where they could repurchase before the "fix" and next pump), they can remove your ability to do instant transactions. Remember masternodes are run by real people potentially with agendas and complicity with other motivations (e.g. selling out to the government to enforce KYC on all transactions or colluding to block transactions on decentralized exchanges to aid manipulations of clearing and market price movements or a zillion other things you can think of because top-down distributed is not the same as trustless decentralization. Bottom line is the masternode is not fungible!)

There are other issues. I am just touching the tip of the iceberg of hurt potentially lurking. Apparently not that many people actually use Dash (other than investing it and even then it is suspect how many people use it versus how many TXs are just fictional volume created by the insiders to make it look like the coin is widely used), so perhaps nothing gets really fully stress tested so this enables releasing stuff that wouldn't work in a widely used scenario but under reduced usership works well enough that people think the designs are solid when they aren't. Even Evan said in the Q & A session in the linked video that he has no idea how many users there are of Dash.

Btw, I am not a hater of Dash. I am forced to comment because I have a competing design in development and so I want people to start to think about the technical issues rationally. I will not comment a lot more about this. I would rather release a correct design and take the positive route of introducing solutions rather than analyzing the faults of other designs. I will not be sitting in Dash threads repeating these points. Investors have free will and if they choose to ignore my expertise, that is their prerogative. So let this be my last comments on this. At least I have given you some insight. And also Evan can read this and perhaps he can devise solutions to those weaknesses. So actually I should have shut my mouth. Last time I opened my mouth to explain to Evan in his thread the problems with his implementation of CoinJoin, then masternode concept was born as a way to address my technical points. So seems I am having $millions of influence on the crypto markets, yet haven't yet released a coin myself. This need to change.

Exactly. A truly decentralized (as opposed to top-down distributed) system can't easily prove the masternode is being intentionally uncooperative and ban it. And now instant transactions are broken for those who the masternodes wish to target, for what ever motivation. See also my post of how this interacts holistically with the intention to be immune to 51% attacks and thus why it fails in Dash's proposed design.

I have much more detailed analysis of scenarios and attacks, but I will reserve that for the appropriate time. If I spill too many beans now, it is a disadvantage for myself and my work.

And if they refuse to sign how do you prove they refused to sign  

They could argue you never sent the request to them or their connection was offline.

What you can do is build up witnesses who also try to submit to the same masternode and establish a pattern for many different transactions over a longer window of time. But the problem is the masternode may sign some transactions and not others, e.g. maybe it signs its own transactions or only the ones that have KYC identification attached to them, depending on what their driving motivation is for denial-of-service. There are many game theories and scenarios.

Instead of solving this problem that way which is very complex and probably unprovable in the holistic game theory if the entire design, I invert the paradigm in my design, but details are withheld at this time.

How do you prove the masternode received your InstantX communication   Thus who is lying the masternode or you?


I know. Because I know what is possible within his current design. Watch in January. He will read my post and try to correct the issues, but he can't. It is fundamental to his design choices that were made long ago. No turning back now.

I'd prefer some official technical document detailing the DDoS algorithm and real world tests or modeling results.

Hiccups every 10s with intermittent DDoS might not be squelched and many other possible scenarios. We can't piecemeal this, we need actually engineering level inspection and test data.

I wrote up an explanation of what I expect Evan is designing.

I think the key point is that this is not block chain scaling, i.e. he isn't reducing and probably instead increasing the load of what has to be stored on the block chain and propagated in winning blocks, because the multi-sigs from the quorum of masternodes has to be recorded on the block chain for each instantly confirmed transaction.

Also I disagree with his claim of 51% attack immunity. Because even if he intends to attain this by having the quorum multi-sig be the objective reality, the problem is many of masternodes can be under control of the same adversary and the masternodes are not required to respond to an instant transaction request, so by refusing to sign the multi-sig they can force instant transactions onto the block chain where the objective reality can be altered by the 51% attack. Also since a 51% attack reorganization can erase a prior chain hash, then any multi-sig issued from a prior chain hash would be illegal in the longer chain and there is no objective reality any more. One can't determine if communication failure or manipulation is the true cause of the reorganization.

Also since the masternodes that are chosen for each transactions are determined on block hash, the spender of the instant transaction has no recourse if the masternodes aren't responding, other than waiting until the next block, which defies the entire point of instant transactions.

I will probably find many other problems in this design.

How can I know these things as if I am reading his mind? Because I designed a decentralized block scaling solution so I know what the issues entail and so I can instantly guess his design and all the holes in his design.

Well Evan is apparently implementing CoinShuffle in Dash:

https://youtu.be/x5sNx7SMTP8?t=128

https://youtu.be/x5sNx7SMTP8?t=1138

The proposed Lightning Networks for Bitcoin is not on the table in the OP. I finally dug into some research on this today and I reasonably shocked to find out what a mess LN could end up being it if is enabled by some block chain changes.

• I haven't found any mention of what happens with chain reorganization but I am assuming it could create an irrevocable mess. Strategies could probably steal coins:
  
  
  Quote from: myself from pvt msg
  Reorg that removes all the payment transactions and refunds everything to himself. The payment transactions will have timeout, but the refunds can be made up to 40 days later. Lets say you can buy something of value with microtransactions that can be aggregated and exchanged back to crypto coin, such as game tokens.
  
  
  Quote from: myself from pvt msg
  Quote from: anonymous

  This seems like a massive 51% attack. You could do the same with confirmed on-chain transactions then.
  

  
  Not in my design. I have 51% attack immunity to double-spends in my design. Comparing designs for microtransactions.
• Extra block chain load (and not even in the context of DoS attacks).
  
  
  Quote from: myself from pvt msg
  To make this work they will need hubs with reputation that establish all the intermediate channels. So then you as a user open only one channel to pay and get paid with. That can work and eliminate the DoS problem and also the latency problem.
  
  But there is another way to DoS it which is to create more and more Bitcoin addresses so the block chain gets flooded with new channels. There is no way to stop a DoS attack against a resource which has no cost of creation. Well I guess you force the recipient to have a payment channel open so the cost is the minimum bond of a payment channel. But if they make that value too high you limit participation (as you said onramp cost). And you can't stop users from closing a payment channel (by sending the refund or the first spend TX) and immediately creating another Bitcoin channel with a new address. Well I guess you have the Bitcoin block chain TX fee to contend with.
• Kills anonymity. No ring sigs nor value hiding is possible in this structure. Trusted corporations must run the servers for this to work against DoS and latency issues. This is a tracking system.
• Requires big spikes in block chain headroom. Due to many people closing their channels at the same time. And if a server gets hacked.
  
  
  Quote from: myself from pvt msg
  At the end of the video they admit payment channels are likely to make block chain scaling worse because there will be proliferation of competing payment channel networks with different features thus users will open multiple channels on the block chain.
  
  This appears very, very messy and too many risks. I would endeavor to make sure payment channel networks can not function if I created a coin.
  
  On-chain type end-to-end anonymity should be seamless and available for microtransactions when you want it.
  
  They can make this LN stuff work sort of with lots of bandaids and duck tape. And then...kaboom.
  
  
  Quote from: myself from pvt msg
  Appears Lightening Networks is going to require orders-of-magnitude more block chain space than my block chain scaling design. Also the increased latency (unless corporate spying servers with reputation dominate) and on ramp delay (wait for block confirmation to open a channel). Also I bet LN will end up having effectively more than one signature to the block chain to settle up (when DoS attacked by unfriendly nodes). DoS attacks are going be nearly impossible to deal with given any sort of anonymity mixing such as CoinShuffle.
  
  I calculate the bandwidth cost per TX on my design will be in neighborhood of $0.000001 per TX. I haven't computed CPU costs yet. Bitshares is claiming 100,000 TPS on commodity hardware in one thread, so looks like amortized hardware costs will be extremely low also.

sidhujag, you are not disproving their the measurements are all assuming the network has scaled to the throughput of the CPU and they never mention DoS attacks at all.

As I wrote from the start of this, Bitshares 2.0 has optimized the witness code so the CPU can scale to 100,000 TX/s, but not only are they apparently requiring on the order of LMAX's 1ms network latency to achieve it, but I haven't read where they've modeled DoS service attacks on the transaction propagation network at such high TX/s. Real-time systems are not only about average throughput but also about CIS (guaranteed reliability and continuous throughput). If you are sending your real-time payment through and the next 10 witnesses that are queued in the chosen order are DoS attacked so they are unable to receive the transactions, then they can't complete their function. That is a fundamental problem that arises from using PoS as the mining method if you claim such high TX/s across variable hardware and network capabilities of nodes (those PoS claiming more conservative TX/s and block times are thus less likely to bump into these issues external to the speed of updating the ledger in the client code). They can adopt counter measures, but it is going to impact the the maximum TX/s rates to the downside, perhaps significantly.

I am not even confident they can maintain 100 TX/s on a real-world network today composed of a myriad of witnesses capabilities under a DDoS attack. Someone needs to do some modeling.

Okay thanks. I edited my post based on your tongue-in-cheek feedback, just to make sure I had links to where the estimates of the 850% size and 3-4 times performance gains are documented. I made that post today because following up on the estimates was on my todo list from the past couple of days.

I'll be happy to get off this anonymity issue and back on to other work where I feel I can create some intense action. The anonymity is important to me and now I am done with that for a while and just need to see if anyone wants to implement my design now. Otherwise it can wait for if I do my own coin.

How did I not answer that question already in the prior post to the best of my ability to predict the future scenarios?


Could you please be more precise? What hype was that? We are in the Altcoin discussion thread. I have a thread about a radical improvement to Cryptonote which is even better than the Zerocash which was a technology that originally made a lot of people excited. And what have I hyped? I have sought the best value and direction for my invention while also evaluating Monero-Shen's comparable invention.

Having a dialogue with the community so as to learn what works and doesn't work seems to be a desirable trait.

hype¹
hīp/
promote or publicize (a product or idea) intensively, often exaggerating its importance or benefits.

I am going to unlock the thread again in case any one wants to comment.

After all, it looks like Monero cryptographer Shen-Noether's design for this Holy Grail of on-chain anonymity where Cryptonote one-time rings are combined with homomorphic value hiding can do the same functionality as my design can. My white paper was completed in July all by myself. Shen's white paper was only completed in October and he interacted with some from Blockstream and apparently others.

The difference in our two designs appears to end up only in terms of efficiency. His design works with Blockstream's Confidential Transactions. My design works with an unpublished version of Denis Lukianov's Compact Confidential Transactions which contains my improvements to make it even more compact and probably 3-4 times faster (pending tests).

So you can compare CCT to CT and see that my design should have a better than 850% size advantage (see section 4.6 Comparison to CT) and the performance should also be faster than Shen's:

http://voxelsoft.com/dev/cct.pdf#page=10

Bitshares explains why efficiency of transactions is very important if you want to minimize transactions fees while maximizing the number of validating mining (PoW or PoS) nodes listening on the network:

http://wiki.bitshares.org/index.php/DPOS_or_Delegated_Proof_of_Stake#Scalability

My white paper will eventually be published of course. Some coin may get it secretly to implement first before it is published.

I am not totally against selling the exclusivity for it to Monero, but I don't think that is their development model. Monero is going after the open source model where to get paid you need to be paid by your company to work on Monero, e.g. Blockstream is paid $21 million to work on these technologies and I assume Shen-Noether would like to impress them and maybe increase his work offers due to increased recognition of his achievements. I am not even a part-time mathematician so I have no chance/motivation in hell of using my paper to increase my chances of gaining lucrative ongoing employment as a mathematician. Thus I seek to maximize the benefit or effect my work can impart to myself and the community which is most aligned with my direction in crypto. Had I known that Shen and some of the best cryptographers from Bitcoin were working intensely on this, I would not have expended the effort to design what is better left to those people who are paid to do this full-time. It was a tangent from my usual vocation as a programmer. I did it because I thought no one else was going to solve it soon and I wanted to know how I could implement rings without that damn requirement for power-of-10 balances in Cryptonote. I think Monero will eventually redesign what I did, or they can wait until mine is published. It isn't really big problem for them. Their model is the methodical march forward of the open source model.

I personally still believe having the best tech and being first mover in a market with it, can add stature for a coin and/or ecosystem.

You are obscuring that what you just wrote effectively means, "this is how many TX/s a fast server CPU can process and we eliminated any sense of a real network from the test".


This is like saying once we redesign our coin (or monopolize the DPOS witnesses with our own corporate funded super hardware because DPOS is really just a way to obscure that we are paying dividends to ourselves, analogous to how masternodes in Dash was ostensibly a way obscuring that those huge interest fees were going to those who owned the most coins), it will get faster. Let's rather talk about what a coin can do now, today, in the real world of decentralized witnesses of varying capabilities.

Obscuring instamines, and other means (cheap pre-sales of ProtoShares that were converted to Bitshares?) of having control over large percent of the coins and then setting up a paradigm where coins can be parked to earn dividends. Hmmm. How dumb are we. Hey more power to them if investors are gullible enough to buy it. But it all starts to fit together in terms of analyzing why they would even think they could have a uniform capability across all witnesses.


If you would be kind enough, you are welcome to cite a reference document. I was working from the official description of DPOS at the official website. As I wrote, I will edit my post for corrections if any one provides information. You have not yet provided any information. So far I read only your (perhaps incorrect) spin on the matter.