Topic: Decrits: The 99%+ attack-proof coin - page 17. (Read 45356 times)

I have an error. I was thinking the closest to the hash wins, so the joins of other SH could be closer than the pre-existing joins the attacker already committed for his SH.

But the attacker could choose his pre-existing keys to match the order of a hash of a hash of a hash, etc.. So then the attacker only needs to be able to obtain that desired hash from the solution space of possible hashes using the power of being last and controlling the input entropy of the last. This was the original conclusion I made up thread, as to why randomization of joins/leaves does not help us.

However, this assumes the desired hash would be in the solution space and mobodick's point is that even if it is, it might not be practical to compute it. I would need to see some math to convince me that it is insured. But apparently we don't need that insurance any way.

Your point I think is that if we modulate the attacker's pre-existing keys by the random joins/leaves, then the attacker can't know what his keys will be and set them up to be linear in any hash of hash of hash pattern. So yes the function is important in the sense that it propagates the input randomness to the hacker's keys.

How am I supposed to argue with these notions? How can you possibly draw any valid conclusions when the idea you have formulated is something completely other than what the OP states?


There is no bidding described here. No cartel is inherently in this design. And yes, the design is intended to have a fixed cost to purchase a share. Want a share? Buy a share. Perhaps shareholder has a poor connotation, but I admitted I am terrible with terminology. With this settled maybe we can start discussing something closer to a vulnerability in the actual design? I'm sure you have a whole slew of things you can think up for why a fixed price is a bad idea, but I can make cogent arguments since you are using the actual design, for a change.


While I have only probably hinted at addressing this, it is addressed, but it involves going into the monetary system, and I still want to nail down consensus for you first.


Except that part of the design is to foster (peaceful) forking if deemed necessary. That is hardly thinking in a closed system. If the monetary system stops working in a reasonable manner, the people are free to bust it wide open with something new, and retain value from the old, and part of this break has to be denying access to any of the existing SHs who do not wish to switch. But now we're getting deep into section 4, and you still haven't mastered section 1 yet.


Every SH does not need to see the updates as they happen. Even ones around the same time frame do not need to see each other. There is no overload of communication unless you can prove that a steady and predictable 1kB/s at 5 million SHs is impossible to overcome. There is risk in accepting a transaction if you are missing recent blocks, but not much. I don't even remember now who I started explaining this to, but I think it was you, and I don't really feel like explaining it again at the moment. Suffice it to say that I can go much deeper into why transactions are secure when they're secure, and it is easy to identify when a transaction is risky to accept without waiting. Just take it as a given for now because I'm tired.


Yes, we have to multiply the data times the number of connected peers divided by about half, assuming half of the network gets the transactions before you. But lite clients only need to maintain 1kB/s to verify any part of the ongoing consensus. (4,000 tx/s [visa] * 100 + 5.7 SH sigs/s [5 million / 876,600] * 150) = 400,855B/s, times say 100 connected peers, divided by half, is 20MB/s or approximately a 160Mbit connection, or around the very high end of consumer bandwidth available today. And notice that the SH part is still a meaningless amount.


It can't possibly prevent the exchange, but it definitely has a cost. Any drastic uptick in the demand can only be assuaged by higher prices in the short term which means the large exchange is going to have to pay increasingly more fiat to obtain increasingly more decrits. And in the long term, new decrits will be created and distributed throughout the network. The people using decrits will profit off of selling you decrits for much more than their cost to produce, and then the people using decrits will profit again when new coins are distributed to bring the price back down.


This is true, but the economic calculation is much more beneficial to the decrits user.


Based on some assumption that I think the system is closed.


Based on not understanding the topology of a distributed network, I think? I really don't see why you still think SHs need to be artificially limited. They will be limited by the currency required to purchase them.


The order of joins/leaves has little to do with it. The function just needs to mix up the order so that the vulnerability you have fought so fiercely for does not exist. It can be entirely predictable and it still can't be gamed, at least not to any degree of reason. EvilCorp could keep leaving the SHs and rejoining until it has a beneficial lineup for a whole CB, but doing this will cost him as there are penalties for early withdrawal. Shares must be kept for 1 year, or else. And the function just needs to intersperse new SHs throughout the existing order to basically avoid any notion of this possibility too.

I hope you take the positive perspective that we have made a lot of progress. And I don't think we've trashed your proposal. We need to work out the specifics of the choices about limits and the randomization.

Re-read the post you were replying to, as I may have added to it at the bottom while you were replying to it.


If the SH are limited to a reasonable maximum potential transaction delay.

Which is what I concluded 2 or 3 pages upthread.


End the discussion of how the SH are limited, or how we use randomization of joins/leaves to mitigate? (should I roll my eyes now)


Because there is no other possible purpose to such a deterministic function, regardless whether you did not increase computation much.

Either the input joins/leaves are random are they are not. The proposed function is irrelevant to the randomization, and can only be relevant to the cost to compute the solution space of possible SH orders. See my prior comment about mobodick.


This is all contingent on the input joins/leaves not being entirely controlled by the attacker, and so your function accomplishes nothing, since the order of the hash of a hash in not linear in the order of joins any way.

Disagree, because once an attacker bids up the price of a SH beyond profitability, no one else will buy.

Do you propose to set a price for a SH that never changes? I think this would cause another set of problems.


Incorrect logic because the % inside the system says nothing about resources outside the system that can come in via fiat exchange. Also a higher transaction fee means another altcoin with lower transaction fees can outcompete you.

It appears me that you keep thinking in terms of a closed system (unless I am missing something in your analysis). That is why my point about Coase's Theorem is so fundamental.


If every SH needs to see these 10 second incremental updates, then the overload communication attack vector resurfaces again.


This is another example of you writing incoherently. I can't understand that.

Usually people that write incoherently, think incoherently, but I am offering you a lot of patience, because some of your ideas are good. I wish you could slow down when you write and think about if the reader can grasp what you've written given we don't have all that is in your head which is unwritten.


Just because you assert it is so, but I can't understand what reasoning you are using to base your claim.


Sent from each signing SH to one other SH. But I was assuming this has to be communicated to all SH, so they will know which transactions have been excluded, so that when they sign, they can include the missing transactions.

Or are your proposing that each signing SH only send the ledger to the next signing SH? But this needs to be sent to all the SHs that can sign during that TB window, given we have no limit on SH and so we may have multiple SHs signing in that TB window.

Bottom line is some calculations on numbers of SH and the maximum delays that could be achieved are needed.


I assume you mean something special about your minting proposal. I have stated I do not yet understand your minting design. Are you going to explain it now?


Sorry but I am.

The only way your design will work is if it is stable in the natural universe, not as some conceptual walled garden.

If your minting proposal is able to prevent large exchange of fiat for Decrits, then that is a valid transaction cost in Coase's theorem. But I don't yet understand your minting proposal, so I can not yet agree if it works.


Agreed.


Agreed.


But only in the 51+% scenario do they have no chance of getting profit.

Otherwise it is just an economic calculation, same as for Decrits.


Have any of my conclusions been proven wrong yet?

All I concluded was that the system can not be closed and must be natural within the realities of the real world. And that the SH would need to be limited. Both conclusions appear to be correct.

I also concluded that if there is no random input entropy, then the order of SH can not be assumed to be random. I stated that whoever is last will be able to game this order. You stated that wobble solved this, but it sounded like handwaving to me, because you never explained what the heck wobble is. Now I understand you were referring to the random order of joins/leaves, which is not "wobble" in any definition that comes to my mind at least.

And the randomization is not required. So can we end this now?


How can you gather this from an example that talks about shuffling SHs around? There is no computation required at all other than running the function itself. Mix new peers in, reorder them around so that most neighbors do not stay next to each other. Take a step back and reevaluate the situation. If 50% of the SHs are controlled by one entity and they are all in a row and the mixing function is "Move the 10th peer 4 places down" eventually, after many CBs, there would be an equal or at least random (looking) distribution of evil and good SHs. Fortunately, the mixing function does not have to be that stupid.

I do not believe that you can come up with a successful scenario here. Everything you have relies on EvilCorp being able to significantly delay transaction processing. All reality goes against this.

Funny thing about consensus is that a 50% attack works differently. Any percentage attack requires an exponentially increasing stake in the network. If there are 100k honest shareholders, a 50% attack requires a 100% match of the money in the shareholder part of the network. 100k new shares, now 50% control. A 75% attack would require a 300% match. A 90% attack would require a ~1000% match. A bitcoin 50% attack requires 50% of the current total hash power, because they can deny the blocks of others; a 75% requires a 75% match. >50% is only significant because it is enough to always overtake the honest chain eventually, no matter what.

Now that is not to say that the cartel could not start with some percentage of the network already in hand, but the exponential increases over the honest shareholders is still required. Feel free to do the math, but I'm fairly certain a cartel controlling even 50% of the SHs could not delay transactions more than a minute on average (although graphed against the total # of SHs would be interesting), given an ungameable distribution. Annoying, but hardly network breaking; it's still 10 times faster than bitcoin.


It's fairly simple. If you are worried about cartels such as this, start with a higher transaction fee. The transaction fee will ultimately dictate how much of the total money supply is locked in the network, and how much money this cartel must acquire and be willing to lock away to game the network. If 10% were locked in the honest network, the cartel could never go above 90% because the entire money supply would be in shares.


You have missed key points. There is the consensus block, the block to which all shareholders have last agreed is the state of the network, and the ongoing consensus, which is updated every transaction block. Assuming a peer has the vast majority of TBs leading up to the TB it is interested in, and a split is not likely to occur immediately after, his transactions are secure as of that block. They could theoretically be respent within the same block. No 100% consensus is required for this.

As far as limiting the # of SH, if the CB period is 10 CDs, the CB period is 10 CDs and 100% consensus will be reached over that time frame. It does not matter if there are 10 SHs, it does not matter if there are 5 million SHs. More SHs != more delay. It just means there is another 150 byte piece of consensus you need to be sure everyone agrees. I chose 10 seconds and 10 days because 87k is such a large number that it has a vast amount of room to grow into. But growing above it is not problematic because of the efficiency described a few posts above. 5 million x 150 bytes / 10 CDs is less than 1kB/s. SHs not having TB priority will still be able to add transactions. There is no need to limit the consensus. Only design around how much is expected to be needed to be secure. Of course this is only a guess, but you have not once acknowledged section 4's existence, either.


How about by requiring it to cost a lot of money in a currency that has a decentrally managed, incorruptible distribution system?


Sorry, but you are not.


Yes, if we ignore any notion of probability.


Yes, if we ignore any notion of probability (or if we ignore the notion that I have any sense and would allow a group to control the ordering of the network). Those delays that can be created with bitcoin also steal money that people wasted on electricity. It's much easier to get those people to quit when they start falling under the wasted-energy-profitability-curve that does not exist in decrits.


Then, if we want to communicate better, stop skipping to conclusions. Ask questions about what you see as potential vulnerabilities, and allow me to respond before rolling into an essay about the ills of this vulnerability that is not specifically addressed in a proposal that is intended to be a digest only.

Yes I am asserting that who ever is last can in theory game the deterministic function.

And with algorithms that we can't entirely analytically anticipate, because at the generative essence there exists the infamous Halting Incompleteness Theorem (due to the fact that a Turing machine is essentially unbounded recursion).


I don't know what the 2nd sentence means. Do you mean shuffle the order based on some deterministic entropy?


This is still a deterministic function. Thus it can still be gamed.

I do not see how you can get around the conclusion I made upthread, which is if the input entropy is not randomized, there is no way to get randomization.

I assume you are attempting to make a complex function that has a higher cost of computation, so that it is more computationally expensive to search the space of solutions in order to find the inputs that achieve the attacker's desired pattern.

However, I do see merit in your idea in the sense that the attacker can not control the order of joins/leaves of others, so his preexisting SH may not be target-able by any solution to the space. This is because the order of joins/leaves is random to the extent that non-attackers are joining and leaving (and the recording of that order can not be gamed). I had admitted this upthread. Having control over the last join/leave does not give one control over the patterns of keys that preceded it, because the attacker is not in control of everyone.

Perhaps this was mobodick's point upthread, although he did not articulate this form of random input entropy; he was arguing the function was too expensive to compute. The key distinction I am making is the computational complexity of the function is not what saves us, rather the randomization of the input entropy. Period.

But if the attacker is able to spam the joins, he can dominate this. This is yet another reason that I say we must be very concerned about the limit or methodology for SH joins.

Also we need an incentive for there to be many leaves and joins, otherwise the randomization is not maximized.


Possibly yes, if the SH limit and the incentive for frequent joins/leaves, are well fleshed out.

You lost my comprehension with this sentence. I have no idea how CNPs are created, incentivized, network topology, fed the data they burst, etc..

Except that in theory a cartel which is gaining profits by delaying non-member transactions, can shift profits to a fee or tax on members outside of your transaction fees. This is why I said above that you can't build a closed-system (walled off from exchange to/from fiat) and there is no such equilibrium.

Also such a cartel can drive the profitability of transaction processing below 0, so as to cause a snowball effect where they gain 100% of the SH. Monopolies function exactly this way throughout history. They even use debt to create the snowball wave, because they can stay solvent for longer than you can (especially when they've captured the statism and can basically print money at will as they are doing now... look at where Fed QE is going and remember the Fed is privately owned).

Even say 49% of the SHs could (in worst case) delay transactions by up to 49% of the period that we need for all SHs to have communicated and reported to the signed CB (see comment below about ledger).


When I think in abstract generative essence, it is not to inflate my ego; rather it is to cut through a lot of slog and straight to the conclusion.

I have spent much less than 2 days on your proposal, maybe a few hours in total. Because I don't have infinite time. Work needs to be efficiently done.


That is why I wrote the above. I am thinking about how we set a limit and how it can't be dominated.


Yes I anticipated this rebuttal. The CB ledger does not exist until all SHs have seen all TBs and done all their signing. It is chicken and egg problem.

I guess you could incrementally build up the ledger, having CBs built more frequently, so the maximum delay isn't excessive. But the fact remains, you are still going to need to limit the # of SH so that the maximum delay is not excessive, which has been my point all along.


If the order is randomized, then yes the likelihood is much reduced. Without randomization, we must assume the worst case scenario, which is the delay could be proportional to the percent of SH they control. Unless we can show some cogent calculations otherwise where all the input entropy is analytically characterized.


The distinction is I am trying to reason about how to set the limit on SH such that it can't be readily monopolized as in how Rockefeller monopolized railways and oil.


I am merely trying to morph the best of your ideas into something that works, if it is true that your design is not sufficient or if there is a simpler design that is just as good.

No where here am I trying to push anything from my prior attempts at an altcoin. I mentioned my proof-of-harddisk space among 5 other possible minting options. We had not even discussed those yet.


Wish you would be so professional.


I am proving that to be a true statement with my rebuttal above.

Btw, the philosophical post that annoyed you so much, was really written to address a paradigm shift in my thinking where I went from my prior altcoin attempt to create a Utopia that could never be subverted by the state, to just wanting to improve upon the Bitcoin metrics.

It wasn't entirely your design that was in mind, except to the extent that of any facets of your design the do not clearly and unequivocally improve upon Bitcoin.

You have made the valid point that 51% attack in Bitcoin means the attacker can delay all transactions forever, whereas a 51% attack in your proposal means potentially they can delay transactions by at most 51% of the maximum period for all SH to sign.

I am just thinking about how we set the limit so that gaining 51% in your system is not any easier than gaining 51% in Bitcoin.

Also because your proposal has a weakness that Bitcoin doesn't have, which is that malicious control of less than 50% of the peers in Bitcoin can only delay transactions that percentage of the blocks with delays randomly distributed, but in your design without randomization, the delay could be (in a worst case) up to that percentage of the maximum time for all SH to sign.

So I don't know why you say I have totally redesigned your system or am not supporting your novel concepts.

Now, as far as the random ordering of shareholders. I can see why you did not take much solace in my "wobble" idea after I quickly dismissed the importance of the vulnerability you exposed in the randomness function I came up with. However, the wobble idea was the prior idea that I had analyzed for vulnerabilities and did not find any significant. But then all kinds of tangents were had and the question regarding this was lost in one line of a page of responses.

With that said, there are a million different ways that a wobble in the order of SHs can be set up. The initial premise is this:

{ current ordered list of shareholder public keys + joins/leaves + something simple like the consensus block number } and crunch this into a function that spits out a new ordered list.

Now, before we even get into what that function might do, you must realize that adjusting the one adjustable part of this input is not simple. Creating a join requires 3k decrits. And, at first thought, creating a join seems like the unlimited options scenario because you can join with whatever public key you like, naively presuming that you have an unlimited amount of options in controlling the next ordered list assuming that no one leaves or joins after you (which is possible if you own the last TB in the CB period).

However, a very simple wobble function defeats that. Start by replacing joins/leaves with each other. Then, divide the network up into an arbitrary number of groups based on the current list, say 10, and distribute all remaining joins among them (if there are a lot of joins, pick some distance factor between them in each division). Then, based on the consensus tick, select 25 or 50% from each division that are not in a row and move their position up or down 1 or 2 or 3 spaces. Do this several times with several groups. To prevent the almost same time frame for each SH's TB, just in case, simply pick a new starting spot.

You could also shuffle two divisions together like cards. Or whatever, all kinds of possible functions. The only thing that matters is that it can't be gamed, not that it isn't random or anything like that. Everybody knows which way the function will wobble, but no one can actually jockey into a better position. Any chance meeting of an attacker's SHs will be gone by the next CB, and there will not be anything he can do about it.


Does this satisfy the security requirements of this most improbable of vulnerabilities?

The second premise is using a symmetric encryption scheme to hide your entropy, but I will wait on explaining that if perhaps you find fault with the wobble.

Ok, I will start with the "data overload" part of the problem because I have fleshed it out much more.

A simple transaction can be described in this format: { timestamp, acct_from, acct_to, amount, misc, signature }
timestamp is your typical 4 byte timestamp
acct_from is the 5 byte account number of the originating transaction
acct_to is the same for the receiver of the transaction
amount is a 4 byte integer (you can send 429k in one simple tx using 4 decimals which I think will be the standard)
misc is other stuff like the CNP code and a message if desired, etc.

The only important things here to identify the transaction are timestamp, acct_from, acct_to, and amount. The only *real* important things to differentiate transactions is the timestamp, the acct_from, and a hash of the remaining important data. With the timestamp as part of the transaction, each account need only check that the hash does not collide among txes with the same timestamp. This is easy, even with a 1 byte hash unless this one account is sending on the order of 200 transactions per second.

Now, CNPs will be designed so that with each connected peer receiving full data, it will store then burst the newest transactions it has not sent this peer about every tenth of a second. Say the network is huge and there are hundreds of transactions per second at this point.

Prior to actually sending the transactions, the CNP will send a list and ask which the peer needs. Say there are 100 transactions for one timestamp, and let's just say they all share 3 bytes of account offset (this would be a span of 65k accounts, 5 bytes acct number - 3 bytes offset).

{timestamp X}
{acct offset Y}
{tx 1: 2 bytes for remaining acct offset, 1 byte hash}
{tx 2-99: "" }

4+3+ 3*100 = 307 bytes to verify if 100 transactions have been received yet or not. That is 3.07 bytes per transaction to avoid sending duplicate data. Of course this is a highly efficient scenario, but the worst case is still 4+5+1, and a really smart protocol could reuse most of the first 9 bytes some of the time by sending the data that is requested in an explicit order. (Can't reuse a generic hash.)

Whenever a transaction has already been seen between peers, they can keep a rolling counter of say 4-bytes that identifies a specific transaction. This can be used to more efficiently refer to transactions in a TB when you know the peer has seen it, but it would not be as efficient to use the account offsets and timestamps. This is the "guaranteed second time" everyone will see a transaction, same as with bitcoin's block chain. You only need to make sure the peer knows what the transaction is and it can fill in the blanks and verify the signature. You do not ever have to send the same transaction to the same peer twice.


Maybe this sounds complicated, but I think it's easy and awesomely efficient. It is also not a requirement of the protocol from the start and is something that can be added down the road.

Regardless, multiple SHs acknowledging the same transaction does not pose a heavy data load on the network. We are still vastly below bitcoin in bandwidth usage.

The limit is based on each person's idea of profitability. I do not make any notions about this. If SHs are making 0.05 decrits per day each, the incentive is much less than if there were 1/4th the SHs making 0.20 per day. Remember, they are putting a significant amount of money on the line for the privilege, and while it is privilege, it is also a job, and there are benefits to doing it well and penalties for doing poorly. And there is also the simple fact that when a banking system is in place, there will be competition for better interest rates.


Bitcoin uses a transaction ledger, decrits will use an account ledger that maintains the balance of each account rather than keeping the history of all transactions. This significantly reduces the storage requirements, and it significantly lowers the bandwidth requirements as any accounts that already exist can be referenced by a 5 byte account integer rather than a tx out address. The Consensus Block, which the entire network has to agree on or the network splits, contains the hash tree of this ledger.


In theory, yes. In practice, the likelihood is still bound by the odds of how many corrupted SHs EvilCorp can get in a row.


I'm not sure I understand your concern about an open consensus. Didn't you just propose a closed one? Shouldn't I be the one concerned about the centralization of your proposed idea?



Ah yes, this is the AnonyMint thread on his proposed currency, I forgot.


I am totally fine with that and I appreciate it. A lot of the ideas in decrits were incorporated from discussions of prior proposals, and a lot of the time I disagreed with the person making those ideas at the time.

What I am not fine with is this:


Not only is it a fallacious argument, but it is also based on a lack of understanding. I know, I know, the proposal is not that clear. But you were coming along just find on understanding the consensus system when you decided to take a nose dive into completely redesigning it because of some weaknesses that are not so weak on further inspection (we can get into this later), and some weaknesses that don't exist at all. Namely SHs being able to prevent others from signing consensus, and/or the data cost that preventing this in an open consensus might take.

Can we say that this is a fairly succinct description of the problem? I'm going to try avoiding gigantic posts so I will continue this in another post.

May I interrupt your little fight? A clash of two egos mixed with 10% discussion on the real matter is very annoying to follow for anyone else. Both of you seem to be bright minds, so please drop the bullshit.

The vulnerability you keep reiterating is one where SHs will not get a chance to be involved in consensus. This is completely antithetical to the idea of consensus, so I don't know why you've picked up this notion.

I can understand your worry about data usage, and it is a valid concern. But instead of assuming that some SHs won't get to participate in consensus (repeatedly), or that SHs have to be heavily limited, you could have asked how I propose to resolve this to keep the system efficient and decentralized, rather than assuming I have walked into this without any consideration for these things.

So give me a freakin chance to respond and stop making 3 posts in a row that go all over the place with my ideas, your ideas, and NWO.

I will respond in a few hours with why your vulnerability is not there, and I will give you two examples of potential ways to reduce/eliminate gaming of even the order of SH selection.

You have not proven that it is my misunderstanding. I may be correct. You need to defend your proposal, by explaining why I am incorrect. You haven't done so yet.

Am I not free to float ideas, points, and discussion?

You are free to explain clearly how your design improves upon anything I write.

If you do so convincingly, I will say, "wow your design is better".

I am always swayed by unequivocal logic.

Whereas, handwaving is something I put a stop to immediately.

Ball is in your court.

(if you feel you can't explain your design concisely, whose fault is that?)

My mind is free to keep thinking about solutions, and any thing that I don't understand about your protocol (or which seems like handwaving), frees my mind to go thinking about ways I would do something. I am also free to appreciate ideas that I get from your proposal, and build on them. Which I have done.

Let's see... how about completely ripping it apart based on vulnerabilities that you believe exist because you don't understand parts of it, and then reformatting it into something else that you are trying to convince me is the way forward. After I've spent 2 years designing this and you've spent 2 days learning about it.


Fine, but I'm not getting into that with you until you understand the security.


I changed the post to say straw proposal.

"It is probably not desirable for the SH private keys to be permanent, because they can be lost or stolen.

The two ways to award SHs is selling them to highest bidder or randomized gift."

Where are you getting this from? What have you intuited here that has any relevance to my proposal? This continues throughout that post. You are either telling me how my proposal works (incorrectly) in spite of the discussion so far, or you are basing this off of your redesign. I have no idea.


Then why the hell did you take all of a day before trying to fix something you don't even understand yet?

Please stop insulting me, when clearly I have shown in the prior post, that you think you solved the problem, but you did not.

You think you have a solution, then you think everyone else is wrong. Take some time to let others explain what you do not see. Then discuss until we see where we are. Insulting people will just kill everything and you won't get any help.


I have not insulted you. You have insulted me. Go re-read to satisfy that this statement is true.

Only if there is a limit to the number SHs. I was proposing a limit. Now it seems you are agreeing to a limit too.


A centralized ledger for a decentralized system?


Thus further increasing the maximum potential delay in a delay transactions attack.


Ditto centralized concern above.


Thus further increasing the maximum potential delay in a delay transactions attack.