Show Posts

Pages: [1] 2 3 4 5 6 »

4

Bitcoin / Development & Technical Discussion / Re: [EDIT] A more 'difficult' algorithm for POW based on area?

on: October 23, 2014, 10:28:52 AM

The hash that comes out of a strong hashing algorithm has a random distribution. Although it is less likely, it doesn't take any more work to find a 000000000000000001.. hash than it does a 0000ffff.. hash, only luck. The blockchain requires each block to meet the proof of work. To replace ten past blocks, you would have to generate ten blocks of your own. This is a much higher bar than a single lucky hash being able to replace ten blocks. With a moredifficulthash chain instantly winning like proposed, it would be an orphan freeforall, you could get one lucky hash attempting to build on blocks from a week ago and replace tons of transactions. As described, a miner could attack for free by 1. constantly be transferring a large balance between new addresses in every block they mine, 2. find a "lucky" hash much smaller than the average and withhold it, and 3. make all sorts of purchases that will be wiped when they publish the chainerasing block find that sends the money back to the miner. OP already annoyed everyone with his great ideas based on a poor understanding of mining here: https://bitcointalk.org/index.php?topic=823544.msg9204175#msg9204175I am a honest miner and lets say i mine on level n. I receive a new valid block (A) at level n+1 so i switch mining on top of this new block. Due to network delay few seconds later i receive another valid block (B) for lever n+1. At that particular moment part of the network is mining on top of (A) and the rest on top of (B) So if our decision (which block to mine on?) is based solely on block's arrival time part of the network would be mining on the 'wrong' block. Is there a way to make nodes agree an what is the most appropriate block to mine on top of it? For example the hash of each block could be used to make all nodes of the network agree and choose either (A) or (B) Do we want a solution in this idiomatic case or we leave it just in luck? PS. How reference Bitcoin Core client behaves in the above case?



5

Bitcoin / Development & Technical Discussion / Re: [EDIT] A more 'difficult' algorithm for POW based on area?

on: October 22, 2014, 07:34:58 PM

I have edited the OP to take advantage of your feedback on this king of attack 16 comfirmation attacks are always possible under normal conditions although you have to be extremely lucky.
What is the issue I try to make more difficult is the possibility of long chains replacing the current
There's nothing magical about the number 6, as I'm sure you're aware. 7confirmation reorgs or attacks could happen, they're just less likely than 6 (and more likely than 8 ). I don't think your idea is bad perse, I just don't think that the advantages it confers outweigh the new vulnerabilities it introduces, but that's just my opinion. Thanks for your review. To sum up the case: Given a block chain(curve) in order for a new block chain to replace it, one currently has to simply stay below the Difficulty bound and make it long enough. We propose a more strict requirement (to achieve), that the new curve has most of the points below the given bock chain(curve) and be of equal length in order to replace it. PS. a)The maths may be much simpler as sum of 1,0,+1 depending on pointwise comparisons. b)A form of mathematical "measure" of the quality between the current curve and a possible replacement is what we seek



6

Bitcoin / Development & Technical Discussion / Re: [EDIT] A more 'difficult' algorithm for POW based on area?

on: October 22, 2014, 06:50:01 PM

[EDIT] You're proposing that the total work be based on the value of the individual hashes, instead of the hash targets, is that correct? This could incentivize a miner who happens to find a hash with an unusually low value to refrain from immediately broadcasting it. See, for example, this attack proposed a few years ago by casascius, which becomes viable with this proposed change. Thanks to btchris for feedback As a measure of performance of a curve/blockchain in order to avoid the above attack we could sum the sign changes between two curves +1,0,1 comparing curve values point wise and assuming max value were a curve lucks a point.
the scores of the curves would then became
(A)(C)=+1+11 (B)(A)=+1+11 (B)(C)=+1+111 I have edited the OP to take advantage of your feedback on this kind of attack 16 comfirmation attacks are always possible even under normal conditions although you have to be extremely lucky. What is the issue I try to make more difficult is the possibility of long chains replacing the current



7

Bitcoin / Development & Technical Discussion / Re: A more 'difficult' algorithm for POW based on area?

on: October 22, 2014, 02:39:42 PM

You're proposing that the total work be based on the value of the individual hashes, instead of the hash targets, is that correct?
Yes but with a little twist. To compare two chains the must include blocks up to the same level. This could incentivize a miner who happens to find a hash with an unusually low value to refrain from immediately broadcasting it. See, for example, this attack proposed a few years ago by casascius, which becomes viable with this proposed change. Thanks for this particular case. To compare two chains they must include blocks up to the same level. So although our friend could through such a block the rest miners lets say if they where 10 blocks ahead would ask him to catch them up by providing the missing 10 blocks each one with hash value equal or smaller of existing ones. PS. I try to think of what should happen when 2 separated block chains merge again.



8

Bitcoin / Development & Technical Discussion / [EDIT] A more 'difficult' algorithm for POW based on area?

on: October 22, 2014, 01:32:57 PM

Block Hash (as big integer value) (y)    +   * ### (C)   \ /   \ / +(Difficulty bound)  \ /  **** (A)  \  \  \  ++ (B)  +++++++++++++++(x) n1 n n+1 n+2 n+3 n  Height
In the above diagram we represent three different block chains as curves where y(Block Hash as integer) and x(block Height n) Correct me if i am wrong but according to current Bitcoin POW Block chain (C) wins as the longest with adequate proof of work (sum of nBits) Chains (A) and (B) although harder to generate don't count, as shorter. What if we measured the area bellow each curve as Proof of work for a chain*? Then a really low hash value in a chain would be taken into account making it further difficult to generate better curves given a known one. *We would then have to minimize the area at given height. [EDIT] You're proposing that the total work be based on the value of the individual hashes, instead of the hash targets, is that correct? This could incentivize a miner who happens to find a hash with an unusually low value to refrain from immediately broadcasting it. See, for example, this attack proposed a few years ago by casascius, which becomes viable with this proposed change. Thanks to btchris for feedback As a measure of performance of a curve/blockchain in order to avoid the above attack we could sum the sign changes between two curves +1,0,1 comparing curve values point wise and assuming max value were a curve lucks a point.
the scores of the curves would then became
(A)(C)=+1+11 (B)(A)=+1+11 (B)(C)=+1+111



12

Bitcoin / Development & Technical Discussion / Re: Difficulty! Do we really need it?

on: October 15, 2014, 01:22:31 AM

This is clear and thank you for clarifying! A bit shift modifies possibility by 50%.
Yes, but the hash target doesn't necessarily move from 135 bits to 136 bits, it moves from 135.1 to 135.4. Just a question if you know for sure. When calculating the total difficulty of a chain we count the values of the actual hashes or the difficulty targets in the blocks?
The total difficulty of a chain (for the purposes of determining which chain is longest) is the sum of the difficulty targets, and has nothing to do with the "luck" of the miners / block hashes. Thanks a lot! Seems you have practiced a lot with difficulty and to tell you the truth my motivation was for a simpler way to model it using two numbers. Bit transitions, dominant zeros and just pure binary operations without any large number maths involved. PS. Was really nice sharing your opinions with me. An other interesting subject is the +2/1 hours range for block inclusion in a chain. Does exist an alternative?



13

Bitcoin / Development & Technical Discussion / Re: Difficulty! Do we really need it?

on: October 15, 2014, 12:24:58 AM

Currently for a block hash to be accepted (proof of work) should have this form XXX....YYYYYYYYYYYYYYYYYYYYYYYYYYY..... where X's : Zeros Y's : Don't cares Difficulty Target demands at least a minimum number of zero X's. This requirement does not adapt well with sadden network hash power changes and the time required to find a hash may vary significantly. We propose a different algorithm as proof of work that adapts well and works without specifying a Difficulty target. Instead of Y's being don't cares we count the bit changes (0 to 1 transitions) within them. So we force a block hash to satisfy two contradictory requirements due to the fixed bit length of the hash (256bits) Counting 0 to 1 transitions a hash could have at max 128 something really rare. Given two hashes with the same number of transitions the one with the most X's being zero wins. I exact starting from the left and comparing the hashes bit by bit the first having 0 where the other hash has 1 wins. (Dominant 0 bit) How the network develops consciousness? A) All participating nodes try to maximize hash 0 to 1 transitions B) At given time intervals nodes publish their best so far C) A node receiving two or more hashes always prefers the one with most transitions and if equal the one with most dominant 0 bits. *A node that finds a really rare block and publishes it on time radically improves the security of the network. This is preliminary work an we would like your comments or suggest similar works from others. This is a wealth of nonsense that shows a complete lack of understanding of how mining, target, difficulty, or even binary math work, which then conjures up a nonexistent issue. This.Also an advice to anyone who thinks he can come up with a better or fundamentally different or even slightly different pow algorithm... Learn the very basics! Thanks for repeating things I all ready know. If you claim than there is never going to exist a better POW algorithm then i can ensure you that you are wrong PS. https://en.wikipedia.org/wiki/Hamming_distanceThe concept of "a better pow algorithm" is relative. Some may argue that "memory hard" pow algorithms are better for crypto currencies. The problem is that you don't understand the very fundamental concept on top of which pow algorithms are based. And that concept can't get any better because it is AS SIMPLE (and elegant) AS IT GETS. Ok I do not understand it I have to admit that. Just a question if you know for sure. When calculating the total difficulty of a chain we count the values of the actual hashes or the difficulty targets in the blocks?



14

Bitcoin / Development & Technical Discussion / Re: Difficulty! Do we really need it?

on: October 15, 2014, 12:14:29 AM

...
btchris does not find any problem with using the number of initial zero bits as a measure of proof of work. ... Please don't paraphrase what I said... what I said was "we already have a way to slow down hash generation: increase the difficulty. Keep in mind that difficulty is not a bit count [emphasis added], it's more finely granular than that." In other words, I completely agree with deepceleron. This is clear and thank you for clarifying! A bit shift modifies possibility by a factor of 2 (half or double it). Just a question if you know for sure. When calculating the total difficulty of a chain we count the values of the actual hashes or the difficulty targets in the blocks?



15

Bitcoin / Development & Technical Discussion / Re: Difficulty! Do we really need it?

on: October 14, 2014, 11:46:26 PM

Currently for a block hash to be accepted (proof of work) should have this form XXX....YYYYYYYYYYYYYYYYYYYYYYYYYYY..... where X's : Zeros Y's : Don't cares Difficulty Target demands at least a minimum number of zero X's. This requirement does not adapt well with sadden network hash power changes and the time required to find a hash may vary significantly. We propose a different algorithm as proof of work that adapts well and works without specifying a Difficulty target. Instead of Y's being don't cares we count the bit changes (0 to 1 transitions) within them. So we force a block hash to satisfy two contradictory requirements due to the fixed bit length of the hash (256bits) Counting 0 to 1 transitions a hash could have at max 128 something really rare. Given two hashes with the same number of transitions the one with the most X's being zero wins. I exact starting from the left and comparing the hashes bit by bit the first having 0 where the other hash has 1 wins. (Dominant 0 bit) How the network develops consciousness? A) All participating nodes try to maximize hash 0 to 1 transitions B) At given time intervals nodes publish their best so far C) A node receiving two or more hashes always prefers the one with most transitions and if equal the one with most dominant 0 bits. *A node that finds a really rare block and publishes it on time radically improves the security of the network. This is preliminary work an we would like your comments or suggest similar works from others. This is a wealth of nonsense that shows a complete lack of understanding of how mining, target, difficulty, or even binary math work, which then conjures up a nonexistent issue. This.Also an advice to anyone who thinks he can come up with a better or fundamentally different or even slightly different pow algorithm... Learn the very basics! Thanks for repeating things I all ready know. If you claim than there is never going to exist a better POW algorithm then i can ensure you that you are wrong PS. https://en.wikipedia.org/wiki/Hamming_distance



16

Bitcoin / Development & Technical Discussion / Re: Difficulty! Do we really need it?

on: October 14, 2014, 11:22:39 PM

Currently for a block hash to be accepted (proof of work) should have this form XXX....YYYYYYYYYYYYYYYYYYYYYYYYYYY..... where X's : Zeros Y's : Don't cares Difficulty Target demands at least a minimum number of zero X's. This requirement does not adapt well with sadden network hash power changes and the time required to find a hash may vary significantly. We propose a different algorithm as proof of work that adapts well and works without specifying a Difficulty target. Instead of Y's being don't cares we count the bit changes (0 to 1 transitions) within them. So we force a block hash to satisfy two contradictory requirements due to the fixed bit length of the hash (256bits) Counting 0 to 1 transitions a hash could have at max 128 something really rare. Given two hashes with the same number of transitions the one with the most X's being zero wins. I exact starting from the left and comparing the hashes bit by bit the first having 0 where the other hash has 1 wins. (Dominant 0 bit) How the network develops consciousness? A) All participating nodes try to maximize hash 0 to 1 transitions B) At given time intervals nodes publish their best so far C) A node receiving two or more hashes always prefers the one with most transitions and if equal the one with most dominant 0 bits. *A node that finds a really rare block and publishes it on time radically improves the security of the network. This is preliminary work an we would like your comments or suggest similar works from others. This is a wealth of nonsense that shows a complete lack of understanding of how mining, target, difficulty, or even binary math work, which then conjures up a nonexistent issue. A SHA256 hash is 256 bits long. 256 bits can represent a number between 0 and 115792089237316195423570985008687907853269984665640564039457584007913129639935. A hash of arbitrary data will return a hash with a value within this interval, seemingly at random, with equal distribution. Difficulty specifies that a lower number threshold is required to "win", that a found hash value must be significantly smaller than the maximum. If we make the threshold 100 times smaller, only one in 100 hashes will win. The starting point with Bitcoin at difficulty 1 requres a hash value 4295032833.000015 smaller than the maximum, meaning only 1 in ~4.3 billion hashes will meet the difficulty 1 challenge. The actual difference between steps can be easily calculated. Bitcoin encodes the difficulty target with nearly six significant figures in hex. I won't try to explain how it is actually encoded. Here we show the next possible difference increment after difficulty 1 is difficulty 1.000015259254738: >>> (0xffff * 2.0**208) / (0xfffe * 2.0**208) 1.000015259254738 The current difficulty target is: 0x00000000000000001F6973000000000000000000000000000000000000000000 which is difficulty 35002482026.13323 The next possible difficulty target increment is 0x00000000000000001F6972000000000000000000000000000000000000000000 which is difficulty 35002499029.10224 The ratio between these two is 1.0000004857646665, which is enough accuracy that even a onesecond difference in the twoweek mining period measurement will result in a different difficulty. btchris does not find any problem with using the number of initial zero bits as a measure of proof of work. I allready agreed with him that by counting the bit transitions might be to complicated. Thats why we asked for comments because we wanted to spot the implications of the our approach. Lets suppose some one finds by chance a hash with many transitions or initial zeros. How can we take it in consideration? There are possibilities that the system might fork. If as a simple rule require that the branch with most transitions is preferred then all nodes know what to do. Finally yes asking for most transitions may be over killing but a system would perform just fine with out any mention to difficulty That's my personal belief



17

Bitcoin / Development & Technical Discussion / Re: Difficulty! Do we really need it?

on: October 14, 2014, 10:54:26 PM

You know CAP theorem. Says that a PARTITIONED system cannot be simultaneously CONSISTENT and AVAILABLE.
So bitcoin network has to enforce periodically some rule for nodes to become CONSISTENT like agreeing on a common time. Else eventually the system will always split in two highly AVAILABLE but not CONSISTENT parts (block chain fork)
Bitcoin is just fine but talking about ways to improve it by relaxing some requirements in favor of a simpler behavior (such as using some external time references widely available over the internet) i think always helps. For example there is an ongoing discussion on increasing transactions volume
I think many would disagree with the premise of the statement that using a central server is an improvement, whether it be for time or anything else. Likewise, most enjoy discussing well thoughtout proposals that could be used. Centralization opens up more attack vectors and is the antithesis of the protocol design, so I think you'll see a lot of resistance to anything that centralizes things and many people wouldn't switch to a fork that includes centralization by design. :) How you discover available nodes to connect to? By using some standard locations an well known nodes Is it the same perhaps more centralized than peaking time from various places around the internet?



18

Bitcoin / Development & Technical Discussion / Re: Difficulty! Do we really need it?

on: October 14, 2014, 08:56:03 PM

You know CAP theorem. Says that a PARTITIONED system cannot be simultaneously CONSISTENT and AVAILABLE.
So bitcoin network has to enforce periodically some rule for nodes to become CONSISTENT like agreeing on a common time. Else eventually the system will always split in two highly AVAILABLE but not CONSISTENT parts (block chain fork)
Bitcoin is just fine but talking about ways to improve it by relaxing some requirements in favor of a simpler behavior (such as using some external time references widely available over the internet) i think always helps. For example there is an ongoing discussion on increasing transactions volume



19

Bitcoin / Development & Technical Discussion / Re: Difficulty! Do we really need it?

on: October 14, 2014, 08:23:20 PM

How the network develops consciousness? A) All participating nodes try to maximize hash 0 to 1 transitions B) At given time intervals nodes publish their best so far C) A node receiving two or more hashes always prefers the one with most transitions and if equal the one with most dominant 0 bits. *A node that finds a really rare block and publishes it on time radically improves the security of the network.
The problem here lies with "at given time intervals". How do you ensure that all miners have synchronized clocks? And how will you deal with network delays, when a miner submits his block but it takes considerable time to cross the network. How long do other nodes wait to collect hashes from miners before they determine a winner? And how do you enforce that all nodes make their decision at the same time? The current system works because it doesn't depend on all players having their clocks properly synced and there are clear rules that establish what happens when, for example due to poor network connectivity or whatever other reason, there are multiple competing branches of the blockchain. I think there is a free time service publicly available at http://time.gov/Many things over the internet depend on it so you CANNOT shut it down so easily Modern pc clocks drift only few seconds daily. So even if the service goes down once synced with it a node can continue functioning for several hours or days without problem.



20

Bitcoin / Development & Technical Discussion / Re: Difficulty! Do we really need it?

on: October 14, 2014, 08:12:29 PM

First i want to make it clear that i agree with you that counting the dominant zeros/integer size in a hash is much simpler and faster.
Point A) It is obvious that you do not forward anything received before you double check it and compare it in case of block hash with your own best result. So a modest performance node can only flood minor performance nodes. Sorry if i did not mention that but i was aware of this practice and should not change it.
Point B) Yes you can set a minimum difficulty in both cases but just to set a minimum performance level so you don't have to much spam. I do't consider problem have each node verify few blocks each round in fact may be beneficial for the hole system instead of spending all processing power chasing the best block.
Point C) What is the max range of possible bit transitions? 128 Is it easy to generate them? not so straight Is it easy to count them? yes simpler than generating a random one of them or calculating a hash



