Bitcoin Forum
June 21, 2024, 08:59:20 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 »
1  Alternate cryptocurrencies / Altcoin Discussion / Re: 51% attack resistance? on: June 21, 2013, 05:38:39 PM
There are no public implementations resistant to 51% attacks.
2  Alternate cryptocurrencies / Altcoin Discussion / Re: Decrits: The 99%+ attack-proof coin on: June 15, 2013, 11:53:18 AM
Ok, now to your question.

But what about these issues with missing TB?
What happens when SH from 1 to K signs TB, but SH K+1 releases his claiming previous K TBs did not arrive on time? And what if this (K+1)th TB contains transactions conflicting with ones in previous K blocks?
Blockchain does not have any data that would allow nodes to tell 'real' course of action and it would always resolve to some kind of voting between SHs?
My current understanding: through blockchain you can't resolve it. You need to have been online during one of the 1 to K blocks and have seen for yourself that the signatures were indeed broadcasted. Then you can be sure that (K+1)th SH is the liar.
The honest nodes will then take action to suppress the (K+1)th from the network and enforce their opinion. For example, all the communication related to the false chain is not relayed by them. So it's a kind of vote of the whole network.
Now if the attacker has a significant portion of the network as well, he can form an appreciable fork. There it becomes harder, and the users will have to interfere. Those who missed the fork buildup (and therefore don't know the truth) will have to decide which chain they're going to be on. Etlase2 proposed some trust-based solutions. All the real people who are not the attacker will either know the good chain, or be undecided. So you could run a vote among the people whom you believe to be real.

I hope Etlase2 can comment as well.
3  Alternate cryptocurrencies / Altcoin Discussion / Re: Decrits: The 99%+ attack-proof coin on: June 15, 2013, 11:00:58 AM
Sorry AnonyMint, but I think you either don't know what you are talking about or bring confusion on purpose. "preimage the entropy"? "can't be a preimage because every peer is racing to compute it"? What is that supposed to mean?

"I can choose a seed a priori"? I've just proven that this is impossible.

I don't think this will be a productive discussion until you educate yourself enough to understand the arguments. Visit the "preimage attack" wikipedia page that I've linked, play the little md5 seed game. It will help.
4  Alternate cryptocurrencies / Altcoin Discussion / Re: Decrits: The 99%+ attack-proof coin on: June 14, 2013, 10:04:17 AM
Incorrect. If my SH controls the transactions in the last TBs for that hash, I can caused the hash to have any value I want (at some cost).
That cost is going to be very high. Bitcoin is built around the hardness of this task, only they try to find a partial preimage, while we're talking about finding a full preimage. So if you can choose the seed here, you'll have no trouble killing bitcoin as well. For some hashes this has not been accomplished even once: https://en.wikipedia.org/wiki/Preimage_attack
So you don't get to choose your seed.

This is silly, it's like saying "I got this encrypted message, so I can decrypt it by enumerating the key. So the encryption is useless." Yes you can, go on.
If you still find it difficult to understand, play a little game: imagine the seed is MD5 hash (that's a "weak" one), and the transactions are written in ascii text. The first transaction says "Transfer 5 decrits from account 1 to 2." You choose the next transaction(s), concatenate them with that string and compute the MD5. Now try to have the result of all zeroes. If you succeed, post your transaction here.

Quote
It has deterministic values from every seed. All I have to do is compute from any seed of my choice, target my SH IDs to those values over any length of time that it takes for me to do so. Then just create that hash seed every time one of my SH is last. Thus disruption.
First, the IDs are chosen, and then you know the seed. Not the other way around.

Quote
In order to prevent that, I proposed fixing all the seeds completely and not using any "entropy" by your terms. While this complicates the attack significantly, it's still not bulletproof.
Then I only need to target those known patterns. I have as much time as I need to get my SH's IDs into that pattern.
Yes. Still it may be very difficult, but it's safer to use the "random" input.

Quote
* he remained secret and covered all his tracks perfectly
On wikipedia there's a passage about some patent application: http://en.wikipedia.org/wiki/Bitcoin#Satoshi_Nakamoto
I think these guys are him Smiley
5  Alternate cryptocurrencies / Altcoin Discussion / Re: Decrits: The 99%+ attack-proof coin on: June 14, 2013, 12:59:19 AM
The seed could be the hash of all transaction in the previous CB. You can't control the value of a hash, that's a major point of hashes: you can't find the content of a transaction which, when concatenated with the other transactions, will result in the given hash value. So you can't control the seed even if you control a part of the transactions.

Furthermore, you have very limited control of IDs of your SHs. They're assigned by the order of their appearance. And they're decided before the seed for the next CB is decided.

Since there is no control of the random generator, you'll have to resort to bruteforcing it. In order to prevent that, I proposed fixing all the seeds completely and not using any "entropy" by your terms. While this complicates the attack significantly, it's still not bulletproof. Maybe it's easier to deal with the possibility of bruteforce search of a favorable seed. If the proportion of shares that you own is p, to have n consecutive TBs you'll have to enumerate (1/p)^n seeds. For n=360, an hour of disruption, and p=0.9, a 90% attack, you will need to enumerate 29695907506101728.772544490140544 seeds on average. We can live with that.
6  Alternate cryptocurrencies / Altcoin Discussion / Re: Decrits: The 99%+ attack-proof coin on: June 13, 2013, 11:43:55 AM
In Bitcoin, the probability of the next TB being an attacker is proportional to the percent of the peers the attacker controls, thus there is never 100% contiguity of control unless attacker controls 100% of the peers.
Bitcoin's 51% works like that: you create your own blocks in secrecy, however many you want, while you have the 51% advantage, and then release your chain. It will be longer than the honest one, so all peers will abandon the honest one and take yours, with whatever you put there. Not only you have continuous control of TBs proportional to your hashing power advantage period duration (which is the cost of the attack), but you can reverse the already accepted transactions, which you can't do in your weak attack on decrits.
7  Alternate cryptocurrencies / Altcoin Discussion / Re: Proof-of-Consensus is a dead-end, won't work on: June 13, 2013, 11:38:58 AM
Incorrect. No matter what randomization function you choose for #4, I can game it to place my SH in a contiguous order at some CB period in the future. Because the input entropy is deterministic in some way.
But we are not in the future, we're now and you said you want to place the next TB under your control. The only way to do this is to spend money or wait. You can't wait because then you'll lose the next TB. So you need to spend money continuously. That little program can simulate that.
If you wait a really long time until the current ID count is favorable, your percentage of the overall SHs will be lower, because all the IDs which you've skipped are not yours.

Quote
Also I explained that just disrupting the network might bring financial return in some other way, such as raising the value of a competing currency or winning a war by shutting down transactions for periods of time.

Also with the power of banking of savings. If I can get other Decrit holders to deposit their Decrits in my bank, I can spend (invest) them interim, while they are not being spent by the owner. The SHs have to profitable and return on investment, else no one will be a SH.
Ok then. Now we need the computation of how much you will gain exactly. If you come up with precise number, like I can gain this much (percent) for every day of continuous control, we could see how much you'll need to spend to achieve that. Then we will see if there's a situation where the attack is profitable.

Quote
I already explained why I don't need to control all of the SH to disrupt and attack.
Yes, for a limited period of time growing with the cost of the attack.

Quote
I already explained how I might gain considerable resources.
Not really. You may be able to gain some resources, but how much they are, compared to the considerable cost of an attack, is an open question.

Quote
And you can't increase the deposit locking time too much, otherwise honest SHs will be disincentivized from participating.
Agreed. But let's assume that the locking time is much greater than the time of possible continuous control. You can't recycle your funds which are being unlocked to prolong the attack.
8  Alternate cryptocurrencies / Altcoin Discussion / Re: Proof-of-Consensus is a dead-end, won't work on: June 12, 2013, 10:04:00 PM
The next one in the order of the random generator, which I a know a prior as you admitted below.
Say you have money to buy 2000 shares and there are 1000 honest ones, so it's a 66% attack. You buy one, the probability of you to not be the next is 1000/1001. If you've lost, you buy another, now the probability is 1000/1002. And so on. How long do you think you're going to hold the TBs on your side?
The answer is 2000 TBs on average: https://ideone.com/qnSuyP
You can play with different values yourself there on that website. After these 2000 TBs, for 10s TBs that's 5.6 hours, you fund is locked, and you can't control the things anymore. What did you gain? If that's the decrits-killing attack, I'm not impressed.

Quote
If I can always be next, I will always be next. The more often I am next, the more often I can get the ID that is next (or not so far from next).
No, because you'll quickly deplete your funds, they'll all be locked in shares that you deposited while gaming the order of TBs before. When you'll have no more money, you'll have no further control over the order of TBs, but the honest SHs keep arriving.

Quote
Because I know it before I do my deposit transaction, so I can target being next (or not so far from next). The more I populate my SHs nearer together in time, then more I can control the TBs and control my ID and thus control that I am nearly always next with my SHs.
Only assuming the infinite ability to create SHs, which you can't - there's simply not enough money in the system for that, it's a finite amount at given time.
Increasing the share amount and deposit locking time will make the power even more limited.
9  Alternate cryptocurrencies / Altcoin Discussion / Re: Decrits: The 99%+ attack-proof coin on: June 12, 2013, 08:58:56 PM
I have already stated that all it takes is a deterministic function to be applied to the current order of SHs. The only way to affect the outcome of this function is continually add or remove SHs from the equation. Adding costs significant amounts of money, subtracting has penalties in both power over the system and early withdrawals. There is no infinite possibility scenario for the attacker to perform. New joins will be added in a deterministic manner that has nothing to do with the public key.

Sor.rge, do not allow yourself to be derailed by what AnonyMint thinks is necessary due to his lack of competence.
Yes, my argument is exactly the same. Make arbitrary placement of ID cost a lot of money or time.

I just try to understand his point. After all, the issue is very simple. Much simpler than the other outstanding problems, like disconnected nodes.
10  Alternate cryptocurrencies / Altcoin Discussion / Re: Proof-of-Consensus is a dead-end, won't work on: June 12, 2013, 08:53:39 PM
That does not make any difference. I just wait until I can be the ID I need to be next in line.
Which ID do you want? How long do you wish to wait?
And I do this for every next SH, and as I have more next SH, I gain more ability to do this more often. My attack grows power until I am always next.
No, the rate of honest SHs is fixed and does not depend on how many SHs you possess currently.

Its output is known for all of future before I choose my ID as stated above. The only way for the output to not be known a priori, is to have some dynamic entropy. You can't escape the fundamental of the lack of ongoing entropy.
Sure it's known, and what? Suppose you know that you'll sign TB#35677 in the next day and TB#22789 in the day after that. What power does that give you compared to the case when you didn't know that? How to exploit that power?
11  Alternate cryptocurrencies / Altcoin Discussion / Re: Proof-of-Consensus is a dead-end, won't work on: June 12, 2013, 08:47:27 PM
You keep trying to pretend there is entropy where there isn't. It is fundamental. More chasing your tail in circles trying to design away from a fundamental concept that can't be designed away from?
I'm not even using the word "entropy".

For how many more posts are you going to waste time talking in circles like a dog chasing his tail?
Until you present a working attack on a very simple, fully specified by now algorithm which per your claim breaks the consensus completely. I want to see it, that's all. I've even offered to code your attack, just describe the algorithm in words. Now you're in position where Etlase2 was some time ago, remember? He managed to give the algorithm after some time.
12  Alternate cryptocurrencies / Altcoin Discussion / Re: Proof-of-Consensus is a dead-end, won't work on: June 12, 2013, 08:39:56 PM
More circles or are we done yet with this nonsense?
No, we're not done yet, one more circle of nonsense is necessary, I'm afraid. Your SH application will not be accepted if its timestamp falls out of the current TB (how long was that? Make it a minute). And the timestamp doesn't decide your ID, it's the order of the timestamps. So that the earliest timestamp has ID=1, the one after ID=2 etc. If you want to have an ID of 1000000, you'll have to wait a until a million other SHs register, that's quite long.

If you want to game the system you have to give me the algorithm. You may be forgetting that I chose a very strong cryptographic random number generator which is difficult to "game". And also you'll have to explain what your attack should actually achieve.
13  Alternate cryptocurrencies / Altcoin Discussion / Re: Proof-of-Consensus is a dead-end, won't work on: June 12, 2013, 08:25:41 PM
And who decides who was 1, 2, 3?
Timestamp ordering of the initial SH deposit transaction. In case of two peers applying to be an SH in the same nanosecond, lexicographical ordering of a hash of their deposit transactions decides. I believe this could not be an issue because only the same guy could realistically synchronize the timestamps with that precision, so he can only decide the distribution of a continuous sequence of IDs to his own SHs. But if you can exploit that in your attack, you're welcome.

To set the numbers straight, suppose that the honest SH count is a Poisson process such that there is one SH registration expected per hour.
14  Alternate cryptocurrencies / Altcoin Discussion / Re: Decrits: The 99%+ attack-proof coin on: June 12, 2013, 08:15:28 PM
I thought we are discussing 50+% nodes attack. With more than half nodes not cooperating in broadcast reliability is seriously affected. And reliability of transfer is far far away from time bounded broadcast.
Okay, okay, that's an assumption. This assumption is stronger than those made by bitcoin. It's a start. Before, I thought that it's impossible to know the truth at all by passive observation, now it turns out that you need to disrupt the communication severely to prevent that. If broadcast is not working at all, the network is split and the situation is hopeless. If it works, but slower than usual, then we need to evaluate how much slower it can be made, how this could be prevented, etc.

The point I was making by analogy (was not about the viability of propagating the info to those who are online rather) is the "always-online" is about as far from reality as you can get. There is no way to relax from those who are always online to those who not knowing who to believe is telling the truth.
At least there is a grade of how long were you offline. The nodes connecting for the first time ever are the extreme case. A node who missed one message is probably easier to handle.
15  Alternate cryptocurrencies / Altcoin Discussion / Re: Proof-of-Consensus is a dead-end, won't work on: June 12, 2013, 08:04:18 PM
I tried explaining this to him, but he adamantly refused to accept it. There is no point in arguing with him.
Well, now there's an algorithm, we can get down to business. Like, calculate what a particular ID allocation strategy could give you, in what time and for how much money Smiley
One thing I didn't specify is the random generator to use. Lets settle for HMAC_DRBG from http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf initialized with the first post of this thread as it is now in UTF-8 Smiley
16  Alternate cryptocurrencies / Altcoin Discussion / Re: Decrits: The 99%+ attack-proof coin on: June 12, 2013, 07:50:00 PM
Ludicrous. If everyone could see everyone in the world, then there would be no corruption due to secrets. Now how do we relax that to reality.  Roll Eyes
No, that's not so unreasonable. It's not true, of course, it's an assumption, but in a highly connected network the broadcasts are quite reliable. You can try to amuse yourself by computing the probability of a message being not received by a peer when everyone is connected to N other peers, as a function of reliability of a connection and size of the network. Imagine that everyone passes the message to all neighbors once upon receiving it.

Now with not-always-online nodes there may be problems, but again these could be addressed to minimize damage to them.
17  Alternate cryptocurrencies / Altcoin Discussion / Re: Proof-of-Consensus is a dead-end, won't work on: June 12, 2013, 07:37:35 PM
Randomized in this case means the selection order can't be known a priori when prospective SH peers chose their ID.
So the whole issue is based on the ability of SH to choose their IDs? Let their ID be their number in the SH sequence. So the very first SH has ID=1, the one who registers after him ID=2 and so on. Their order for signing TBs is determined by a chosen good pseudorandom number generator in [1..number of SHs at the moment], initialized with seed value of 0 at the very first TB.
Not good? Please provide an algorithm to gain significant control over your position in TB signing queue with that (good luck). We can test it right away, I'll write the program Smiley SHs have very limited control over their ID now, they can just wait until the number grows to their desired position, or fill the IDs by creating a lot of SHs, which is supposed to be costly, and your resources are limited.

I skipped the rest because it was all based on this.
18  Alternate cryptocurrencies / Altcoin Discussion / Re: Decrits: The 99%+ attack-proof coin on: June 12, 2013, 06:15:41 PM
And how is this always-online node knowledge relevant when it cannot prove it is true? How will another node tell honest and liars apart? Calculate 50%+ votes?
That node itself cannot be fooled. For example, assuming that everyone is always online, the system is perfect already (under the other assumptions, of course). It's a starting point which shows that the truth can be established at least under some assumptions. Now the next question is how to relax those assumptions, to make the system more fault-tolerant, such that loss of some messages could be compensated, for instance. Etlase2 did some steps in that direction in the detailed descriptions above.
19  Alternate cryptocurrencies / Altcoin Discussion / Re: Proof-of-Consensus is a dead-end, won't work on: June 12, 2013, 06:07:44 PM
Let me try to summarize it again, and then you may tell me which part(s) you need more elaboration on.
...
2. This order needs to be randomized, otherwise it is possible to game the system.
This one please. What exactly do you mean by "randomized", and what kind of attack you imagine if this property is not present?
In cryptography "random" usually means "unpredictable", which cannot be the case here, as you say in point 1. Why can't we just let SHs sign TBs in alphabetical order of their IDs? If this is bad for some reason, there's an infinite number of other ways to do it.

Quote
3. The only way to randomize this order, is for the prospective SH peers to sign a CB, then all those who sign are eligible to be selected to sign TBs in the next CB period. The order of those selected is determined from the entropy of all those signatures on the CB. The first N closest hash keys are selected in a determined order, where N is the number of SHs peers that sign TBs per CB.
Depends on what definition you will give to randomness in this case, but in general "the only way" is always a very strong statement about an algorithm, which can practically never be true. You can only say "the only way I'm aware of currently". The "entropy of signatures" and its use to find the order has to be explained, after you explain the need for it in point 2. above.

But the problem is that there is no way to have consensus on who has signed the CB. If peers (wanting to be SHs on next CB) will separately broadcast their signatures, then who decides which were broadcast within the time limit and compiles it into a CB?
Every peer will decide for himself. Remember the assumption of bounded time guaranteed broadcast.

There is no possible solution. This is why only Proof-of-Work is viable for achieving consensus.
Even if that solution didn't work out, there is no proof of this statement.
20  Alternate cryptocurrencies / Altcoin Discussion / Re: Proof-of-Consensus is a dead-end, won't work on: June 12, 2013, 12:29:46 PM
Those assumptions won't provide the required randomized entropy for deciding the order of signing.
Now you came up with another argument, one which is completely unrelated with what was discussed yesterday I must add, and pretend that you've closed the question. You argument includes no details, just a keyword. That doesn't work that way, you didn't convince me of anything - I didn't follow the entropy talk of the last month. As I said, either an attack is spelled out, in whatever form, or it doesn't exits.

It's ok for me if you don't want to continue the discussion, you don't have to. The final answer should come out of an implementation anyway, not from the arguments.
Pages: [1] 2 3 4 5 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!