Bitcoin Forum
August 17, 2022, 01:21:31 PM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 »
1  Local / Ελληνικά (Greek) / Re: Γιατί υπάρχει όριο στα 21.000.000 Bitcoin; on: January 15, 2015, 05:49:31 AM
Η απάντηση στο παρακατω topic

https://bitcointalk.org/index.php?topic=819656.msg9181812#msg9181812

Μαλιστα σχολιαζει και ενας απο τα ατομα που μιλησε με τον Satoshi,  o Cryddit aka Ray Dillinger

Η επιλογη 21Μ ειναι καθαρα τεχνικη και εχει να κανει με τον μεγιστο ακεραιο που μπορει να χειριστει κανει σε Javascript (web browsers)
2  Local / Ελληνικά (Greek) / Re: Η microsoft αρχίζει να δέχεται bitcoin on: December 12, 2014, 05:45:50 AM
http://www.coindesk.com/professor-susan-athey-people-use-bitcoin-intrinsic-value/
... serves as Microsoft's Chief Economist.

http://en.wikipedia.org/wiki/CEN/XFS
...CEN/XFS or XFS (eXtensions for Financial Services) provides a client-server architecture for financial applications on the Microsoft Windows platform, especially peripheral devices such as EFTPOS terminals and ATMs which are unique to the financial industry.

Τα περισσότερα ΑΤΜς παγκοσμιώς τρέχουν με λογισμικό Windows και τυποποιημενο λογισμικό / περιφεριακά (βασικά Microsoft).
Με ελάχιστες αλλαγές θα μπορούσαν να uποστηριξουν και το Bitcoin.

Ο νοών...νοείτω


ΥΓ. Επισης το zerocoin/zerocash πρέπει να εχει σχέση με την Microsoft χωρις να ειμαι σιγουρος.
3  Bitcoin / Development & Technical Discussion / Re: How difficult is it to generate a half same bitcoin address? on: October 23, 2014, 01:01:02 PM
Elementary probability theory.

Each position has 1/58 probability to be the desired symbol.
So if you fix let say 3 positions the probability to find a matching pattern would be   (1/58)*(1/58)*(1/58)
It is independent of the position you fix in the address. 1ace....xxxx is as difficult as 1axcxex.......

The possibility vanishes very quick as a power of n(positions you fix)

 
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 more-difficult-hash chain instantly winning like proposed, it would be an orphan free-for-all, 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 chain-erasing 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#msg9204175

I 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
1-6 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. 7-confirmation 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 per-se, 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+1-1
(B)-(A)=+1+1-1
(B)-(C)=+1+1-1-1

 

I have edited the OP to take advantage of your feedback on this kind of attack
1-6 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
Code:
Block Hash (as big integer value)
|(y)
|
|  
|       -------------------------------+
|       --- *           #---#---# (C)  |
|            \         /               |
|             \       /               +---------------------(Difficulty bound)
|              \     /    
|               *---*---*---* (A)
|                \
|                 \
|                  \
|                   +---+ (B)
|
+---+---+---+---+---+---+---+---+---+---+---+---+----+---+-(x)
  n-1  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+1-1
(B)-(A)=+1+1-1
(B)-(C)=+1+1-1-1

 
9  Bitcoin / Mining software (miners) / Where in cgminer/BFG miner's src code TARGET is compared with current HASH? on: October 17, 2014, 10:50:46 PM
I don't have much of experience with mining so forgive any mistakes but I am a pro on C++/Hardware.

Basically interested on CPU / GPU mining.
I guess that with ASICs the target is passed as a parameter to the core.


Thanks in advance Smiley

10  Bitcoin / Development & Technical Discussion / Re: Block timestamp must not be more than two hours in the future. What src file? on: October 17, 2014, 09:59:05 AM
Thanks a lot  Roll Eyes

Looked to other places and skipped the obvious!
11  Bitcoin / Development & Technical Discussion / Block timestamp must not be more than two hours in the future. What src file? on: October 17, 2014, 05:46:40 AM

Could some one help me locate where the following protocol rules are enforced in Bitcoin Core src.
What files should i read?

a) Block timestamp must not be more than two hours in the future.
b) Reject if timestamp is the median time of the last 11 blocks or before

PS. Perhaps the answer should be RTFM but I may miss something important.

Thanks in advance.
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. Smiley

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

The 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. Lips sealed

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. Smiley

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. Smiley

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 one-second difference in the two-week 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 thought-out 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
Pages: [1] 2 3 4 5 6 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!