|
valiron (OP)
|
 |
May 02, 2015, 01:21:18 PM
Last edit: May 04, 2015, 09:19:46 AM by valiron |
|
|
|
|
|
|
|
|
|
|
|
|
|
In order to get the maximum amount of activity points possible, you just need to post once per day on average. Skipping days is OK as long as you maintain the average.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
guitarplinker
Legendary
 Offline
Activity: 1694
Merit: 1024
|
|
May 02, 2015, 01:24:41 PM |
|
Nobody has found a trick for fast mining, that's just good luck. Sometimes it can be an hour or two between blocks, other times it can just be seconds between them.
|
|
|
|
|
|
valiron (OP)
|
|
May 02, 2015, 01:29:47 PM
Last edit: May 03, 2015, 03:25:33 PM by valiron |
|
Nobody has found a trick for fast mining, that's just good luck. Sometimes it can be an hour or two between blocks, other times it can just be seconds between them.
Please, compute the probability of having the same length within 1kB, the probability of mining three blocks within 1 min, and the probability of having nearby nounce. Then multiply since these events are independent. Last, don't insult our intelligence. |
|
|
|
|
|
bigasic
|
|
May 02, 2015, 01:34:19 PM |
|
Remember, mining has changed. ITs more centralized.. Did one person or one machine find those four blocks. i guess its hard to say anymore.. people that mine usually have tens or hundred of terabytes of power.. Soon, you will need hundreds of petahashes to find a block, lol... I have mixed feelings when bitcoin price took off. It made me a tidy sum, yet it made it so mining wasn't profitable for me. So, i think I probably lost money. it brought rich people out of the wood work to mine that would have never mined had bitcoin stayed at the 10 to 15 dollar level. too many cooks in the kitchen... When I was doing the math to figure out if spending 30k on a mining rig was worth it back in the day, the most I thought bitcoin could go up in the 4 years that i did the math was about 50 dollars a coin and I thought it would stay sub 20 dolllars for years. so, I was way off, lol..
|
|
|
|
|
|
valiron (OP)
|
|
May 02, 2015, 01:42:36 PM |
|
Remember, mining has changed. ITs more centralized.. Did one person or one machine find those four blocks. i guess its hard to say anymore.. people that mine usually have tens or hundred of terabytes of power.. Soon, you will need hundreds of petahashes to find a block, lol... I have mixed feelings when bitcoin price took off. It made me a tidy sum, yet it made it so mining wasn't profitable for me. So, i think I probably lost money. it brought rich people out of the wood work to mine that would have never mined had bitcoin stayed at the 10 to 15 dollar level. too many cooks in the kitchen... When I was doing the math to figure out if spending 30k on a mining rig was worth it back in the day, the most I thought bitcoin could go up in the 4 years that i did the math was about 50 dollars a coin and I thought it would stay sub 20 dolllars for years. so, I was way off, lol..
You are not addressing the point. |
|
|
|
|
|
bronan
|
|
May 02, 2015, 01:53:25 PM
Last edit: May 02, 2015, 02:10:48 PM by bronan |
|
First of all those 4 are not found by the same address, second look at the places where they supposed to be found.
This happens ofcourse not often but it happens that some people get shortly after another some blocks.
They seldom fall at the same spot but as you can see 2 are at the same spot and the 2 earlier ones elsewhere.
So for as i can see does it look so special
|
|
|
|
|
|
|
cr1776
Legendary
Offline
Activity: 4032
Merit: 1301
|
|
May 02, 2015, 02:20:43 PM |
|
Nobody has found a trick for fast mining, that's just good luck. Sometimes it can be an hour or two between blocks, other times it can just be seconds between them.
... Last, don't insult our intelligence.
There is nothing odd going on here. There is no "pre-mine" or some "trick for fast mining". It is like seeing a dog in the clouds. There isn't really a dog here. |
|
|
|
|
jl2012
Legendary
Offline
Activity: 1792
Merit: 1097
|
|
May 02, 2015, 02:36:26 PM |
|
Nobody has found a trick for fast mining, that's just good luck. Sometimes it can be an hour or two between blocks, other times it can just be seconds between them.
Please, compute the probability of having the same length within 1kB, Miners decide the size of their blocks. It is not a random process. And only 3 out of 4 of your linked blocks are 731kb, and it is not rare: http://www.reddit.com/r/Buttcoin/comments/2sezuu/is_there_a_reason_a_lot_of_blocks_are_731x_kb/ |
Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
|
|
|
Foxpup
Legendary
Offline
Activity: 4354
Merit: 3044
Vile Vixen and Miss Bitcointalk 2021-2023
|
|
May 02, 2015, 02:49:39 PM
Last edit: May 02, 2015, 05:33:17 PM by Foxpup |
|
All 4 blocks with a length of 731 kB
Which happens to be just under 750 metric kilobytes, which is the default maximum block size. All 4 nounces very close by.
Not close at all. A difference of 300,000,000 is about one thirteenth of the maximum range, which means consecutive nonces will be this close together over 10 times a day. (Edited to correct drunken math) Last 3 blocks mined within 1 minute.
 10 minutes, actually. It is clear that someone found a trick for fast mining. I kind of happen to know what might be...
I kind of doubt it... |
Will pretend to do unspeakable things (while actually eating a taco) for bitcoins: 1K6d1EviQKX3SVKjPYmJGyWBb1avbmCFM4I am not on the scammers' paradise known as Telegram! Do not believe anyone claiming to be me off-forum without a signed message from the above address! Accept no excuses and make no exceptions! |
|
|
|
valiron (OP)
|
|
May 02, 2015, 05:02:04 PM
Last edit: May 04, 2015, 09:49:41 AM by valiron |
|
|
|
|
|
|
|
valiron (OP)
|
|
May 02, 2015, 05:11:06 PM |
|
All 4 nounces very close by.
Not close at all. A difference 300,000 is about one thirteenth of the maximum range, which means consecutive nonces will be this close together over 10 times a day. 4Byte nounce is between 1 and 2^32-1=4.294.967.295 right? Where is your 300.000 being 1/13th coming from? |
|
|
|
|
iCEBREAKER
Legendary
Offline
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
|
|
May 02, 2015, 05:16:02 PM |
|
It is clear that someone found a trick for fast mining. I kind of happen to know what might be...
Is it IntelliHash?  |
██████████
██████████████████
██████████████████████
██████████████████████████
████████████████████████████
██████████████████████████████
████████████████████████████████
████████████████████████████████
██████████████████████████████████
██████████████████████████████████
██████████████████████████████████
██████████████████████████████████
██████████████████████████████████
████████████████████████████████
██████████████
██████████████
████████████████████████████
██████████████████████████
██████████████████████
██████████████████
██████████
Monero
|
| "The difference between bad and well-developed digital cash will determine
whether we have a dictatorship or a real democracy." David Chaum 1996
"Fungibility provides privacy as a side effect." Adam Back 2014
|
| | |
|
|
|
|
valiron (OP)
|
|
May 02, 2015, 05:18:39 PM |
|
Last 3 blocks mined within 1 minute.
10 minutes, actually. I thought I posted by the times indicated by blockchain.info at the time. Note that timestamps are malleable and timestamps of reception by blockchain.info don't seem to be accurate. Block timestamp and blockchain.info timestamp for reception are not in chronological order for blocks 354642 and 354643 (this is not strange and happens quite often). Malleability of blocks timestamps may explain this fact but not timestamp of reception by blockchain.info (that may just copy the block timestamp). |
|
|
|
|
|
valiron (OP)
|
|
May 02, 2015, 05:20:15 PM
Last edit: May 04, 2015, 09:18:44 AM by valiron |
|
It is clear that someone found a trick for fast mining. I kind of happen to know what might be...
Is it IntelliHash? ......................... |
|
|
|
|
Foxpup
Legendary
Offline
Activity: 4354
Merit: 3044
Vile Vixen and Miss Bitcointalk 2021-2023
|
|
May 02, 2015, 05:29:41 PM |
|
All 4 nounces very close by.
Not close at all. A difference 300,000 is about one thirteenth of the maximum range, which means consecutive nonces will be this close together over 10 times a day. 4Byte nounce is between 1 and 2^32-1=4.294.967.295 right? Where is your 300.000 being 1/13th coming from? I meant 300,000,000 (that's the closeness we're talking about right?), but I misplaced a few zeros somewhere around the second glass of absinthe. This is why you shouldn't drink and derive.  (that may just copy the block timestamp).
They are. The timestamps are exactly the same, down to very second. |
Will pretend to do unspeakable things (while actually eating a taco) for bitcoins: 1K6d1EviQKX3SVKjPYmJGyWBb1avbmCFM4I am not on the scammers' paradise known as Telegram! Do not believe anyone claiming to be me off-forum without a signed message from the above address! Accept no excuses and make no exceptions! |
|
|
philipma1957
Legendary
Offline
Activity: 4116
Merit: 7862
'The right to privacy matters'
|
|
May 02, 2015, 05:30:53 PM |
|
It is clear that someone found a trick for fast mining. I kind of happen to know what might be...
Is it IntelliHash? It is premining at some extend. Won't disclose more for the moment. you should expose it now bro. if true it needs to be addressed sooner rather then later. |
|
|
|
|
valiron (OP)
|
|
May 02, 2015, 05:37:27 PM
Last edit: May 04, 2015, 09:50:24 AM by valiron |
|
It is clear that someone found a trick for fast mining. I kind of happen to know what might be...
Is it IntelliHash? It is premining at some extend. Won't disclose more for the moment. you should expose it now bro. if true it needs to be addressed sooner rather then later. ............................... |
|
|
|
|
padrino
Legendary
Offline
Activity: 1428
Merit: 1000
https://www.bitworks.io
|
|
May 02, 2015, 05:38:52 PM |
|
It is clear that someone found a trick for fast mining. I kind of happen to know what might be...
Is it IntelliHash? It is premining at some extend. Won't disclose more for the moment. you should expose it now bro. if true it needs to be addressed sooner rather then later. valiron, On pins and needles here, seriously you start the thread asking like you have no idea, realistically only to puff yourself up in the end.. Waiting for the PM me and for 100 BTC I will tell you message next.. |
|
|
|
jl2012
Legendary
Offline
Activity: 1792
Merit: 1097
|
|
May 02, 2015, 05:44:29 PM |
|
Nonce are not uniformly distributed because miners always start scanning from 0. Therefore, small nonce is more likely to be found on the blockchain. https://bitcointalk.org/index.php?topic=985846.0 |
Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
|
|
|
|
valiron (OP)
|
|
May 02, 2015, 05:53:43 PM
Last edit: May 02, 2015, 06:20:56 PM by valiron |
|
All 4 nounces very close by.
Not close at all. A difference 300,000 is about one thirteenth of the maximum range, which means consecutive nonces will be this close together over 10 times a day. 4Byte nounce is between 1 and 2^32-1=4.294.967.295 right? Where is your 300.000 being 1/13th coming from? I meant 300,000,000 (that's the closeness we're talking about right?), but I misplaced a few zeros somewhere around the second glass of absinthe. This is why you shouldn't drink and derive. Be careful with absynthe... Let's look closer at nounces: We assume that nounces are uniformly distributed (not exactly true since if we start increasingly with nounce 0 they follow a Poisson law, but taking into account that nounce cycles many times before finding the solution it is well approximated by the uniform distribution). We look at distance mod 2^32. |nounce(354641)-nounce(354640)| = 19.452.599 probability 19.452.599/(2^32-1)*2 = 1.8% |nounce(354642)-nounce(354641)| = 5.394.922 probability 5.394.922/(2^32-1)*2 = 0.12% |nounce(354642)-nounce(354641)| = 313.864.936 probability 313.864.936/(2^32-1)*2 =7.2% Combined probability 0.000155% that is 1 in 645 161 times. For me, this is just evidence that these blocks are not mined the usual way with repetitive trials. EDIT: Corrected the 645.161. Thanks to jl2012. |
|
|
|
|
|
valiron (OP)
|
|
May 02, 2015, 05:56:43 PM |
|
Sure, but at current difficulty rates the round many times through the whole range. I did take this into account. IF you want to be more accurate you have to average the translated Poisson distribution. In first approximation it is uniform, in particular in the range considered with nounces around 2.1 billion |
|
|
|
|
|
valiron (OP)
|
|
May 02, 2015, 06:02:19 PM
Last edit: May 03, 2015, 03:26:51 PM by valiron |
|
It is clear that someone found a trick for fast mining. I kind of happen to know what might be...
Is it IntelliHash? It is premining at some extend. Won't disclose more for the moment. you should expose it now bro. if true it needs to be addressed sooner rather then later. valiron, On pins and needles here, seriously you start the thread asking like you have no idea, realistically only to puff yourself up in the end.. Waiting for the PM me and for 100 BTC I will tell you message next.. I don't understand your message. |
|
|
|
|
jl2012
Legendary
Offline
Activity: 1792
Merit: 1097
|
|
May 02, 2015, 06:05:53 PM |
|
All 4 nounces very close by.
Not close at all. A difference 300,000 is about one thirteenth of the maximum range, which means consecutive nonces will be this close together over 10 times a day. 4Byte nounce is between 1 and 2^32-1=4.294.967.295 right? Where is your 300.000 being 1/13th coming from? I meant 300,000,000 (that's the closeness we're talking about right?), but I misplaced a few zeros somewhere around the second glass of absinthe. This is why you shouldn't drink and derive. Be careful with absynthe... Let's look closer at nounces: We assume that nounces are uniformly distributed (not exactly true since if we start increasingly with nounce 0 they follow a Poisson law, but taking into account that nounce cycles many times before finding the solution it is well approximated by the uniform distribution). We look at distance mod 2^32. |nounce(354641)-nounce(354640)| = 19.452.599 probability 19.452.599/(2^32-1)*2 = 1.8% |nounce(354642)-nounce(354641)| = 5.394.922 probability 5.394.922/(2^32-1)*2 = 0.12% |nounce(354642)-nounce(354641)| = 313.864.936 probability 313.864.936/(2^32-1)*2 =7.2% Combined probability 0.000155% that is 1 in 64.5 million of times. Are you trolling? 0.000155% is 1 in 645161 And this is nonsense. Just some made up data |nounce(1)-nounce(0)| = 5% |nounce(2)-nounce(1)| = 20% |nounce(3)-nounce(2)| = 10% |nounce(4)-nounce(3)| = 1% |nounce(5)-nounce(4)| = 5% |nounce(6)-nounce(5)| = 10% Combined probability 0.000005% that is 1 in 20 million of times. Bitcoin in broken!!! |
Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
|
|
|
|
valiron (OP)
|
|
May 02, 2015, 06:11:52 PM |
|
All 4 nounces very close by.
Not close at all. A difference 300,000 is about one thirteenth of the maximum range, which means consecutive nonces will be this close together over 10 times a day. 4Byte nounce is between 1 and 2^32-1=4.294.967.295 right? Where is your 300.000 being 1/13th coming from? I meant 300,000,000 (that's the closeness we're talking about right?), but I misplaced a few zeros somewhere around the second glass of absinthe. This is why you shouldn't drink and derive. Be careful with absynthe... Let's look closer at nounces: We assume that nounces are uniformly distributed (not exactly true since if we start increasingly with nounce 0 they follow a Poisson law, but taking into account that nounce cycles many times before finding the solution it is well approximated by the uniform distribution). We look at distance mod 2^32. |nounce(354641)-nounce(354640)| = 19.452.599 probability 19.452.599/(2^32-1)*2 = 1.8% |nounce(354642)-nounce(354641)| = 5.394.922 probability 5.394.922/(2^32-1)*2 = 0.12% |nounce(354642)-nounce(354641)| = 313.864.936 probability 313.864.936/(2^32-1)*2 =7.2% Combined probability 0.000155% that is 1 in 64.5 million of times. Are you trolling? 0.000155% is 1 in 645161 And this is nonsense. Just some made up data |nounce(1)-nounce(0)| = 5% |nounce(2)-nounce(1)| = 20% |nounce(3)-nounce(2)| = 10% |nounce(4)-nounce(3)| = 1% |nounce(5)-nounce(4)| = 5% |nounce(6)-nounce(5)| = 10% Combined probability 0.000005% that is 1 in 20 million of times. Bitcoin in broken!!! I just did a rough approximation, only valid for small probabilities and few events. You are welcome to do the exact computation. |
|
|
|
|
Foxpup
Legendary
Offline
Activity: 4354
Merit: 3044
Vile Vixen and Miss Bitcointalk 2021-2023
|
|
May 02, 2015, 06:14:41 PM |
|
Are you trolling? 0.000155% is 1 in 645161
I was just about to say that. Guess I'm not the only one who needs to be careful. And this is nonsense. Just some made up data
|nounce(1)-nounce(0)| = 5%
|nounce(2)-nounce(1)| = 20%
|nounce(3)-nounce(2)| = 10%
|nounce(4)-nounce(3)| = 1%
|nounce(5)-nounce(4)| = 5%
|nounce(6)-nounce(5)| = 10%
Combined probability 0.000005% that is 1 in 20 million of times. Bitcoin in broken!!!
It is premining at some extend. Won't disclose more for the moment.
|
Will pretend to do unspeakable things (while actually eating a taco) for bitcoins: 1K6d1EviQKX3SVKjPYmJGyWBb1avbmCFM4I am not on the scammers' paradise known as Telegram! Do not believe anyone claiming to be me off-forum without a signed message from the above address! Accept no excuses and make no exceptions! |
|
|
|
valiron (OP)
|
|
May 02, 2015, 06:18:37 PM |
|
Are you trolling? 0.000155% is 1 in 645161
You are right on this one of course. I correct it thanks. |
|
|
|
|
|
smolen
|
|
May 02, 2015, 06:47:06 PM |
|
Nonce are not uniformly distributed because miners always start scanning from 0.
Also Bitfury ASIC (and may be others too) don't scan full nonce range due to h/w optimizations. |
Of course I gave you bad advice. Good one is way out of your price range.
|
|
|
jl2012
Legendary
Offline
Activity: 1792
Merit: 1097
|
|
May 02, 2015, 06:52:24 PM |
|
All 4 nounces very close by.
Not close at all. A difference 300,000 is about one thirteenth of the maximum range, which means consecutive nonces will be this close together over 10 times a day. 4Byte nounce is between 1 and 2^32-1=4.294.967.295 right? Where is your 300.000 being 1/13th coming from? I meant 300,000,000 (that's the closeness we're talking about right?), but I misplaced a few zeros somewhere around the second glass of absinthe. This is why you shouldn't drink and derive. Be careful with absynthe... Let's look closer at nounces: We assume that nounces are uniformly distributed (not exactly true since if we start increasingly with nounce 0 they follow a Poisson law, but taking into account that nounce cycles many times before finding the solution it is well approximated by the uniform distribution). We look at distance mod 2^32. |nounce(354641)-nounce(354640)| = 19.452.599 probability 19.452.599/(2^32-1)*2 = 1.8% |nounce(354642)-nounce(354641)| = 5.394.922 probability 5.394.922/(2^32-1)*2 = 0.12% |nounce(354642)-nounce(354641)| = 313.864.936 probability 313.864.936/(2^32-1)*2 =7.2% Combined probability 0.000155% that is 1 in 64.5 million of times. Are you trolling? 0.000155% is 1 in 645161 And this is nonsense. Just some made up data |nounce(1)-nounce(0)| = 5% |nounce(2)-nounce(1)| = 20% |nounce(3)-nounce(2)| = 10% |nounce(4)-nounce(3)| = 1% |nounce(5)-nounce(4)| = 5% |nounce(6)-nounce(5)| = 10% Combined probability 0.000005% that is 1 in 20 million of times. Bitcoin in broken!!! I just did a rough approximation, only valid for small probabilities and few events. You are welcome to do the exact computation. You calculate in a wrong way. You should define the meaning of "close" a priori. That could be 20%, 10%, or 1%. Let say you choose 10%, the P(1.8%, 0.12%, 7.2%) should be 1/1000, not 1/645161. And let say you choose 2%, the P(1.8%, 0.12%, 7.2%) should be 1/2551 (0.02*0.02*0.98). Therefore, one event of this kind is expected in about 2 weeks. Please stop here (and edit your misleading topic) unless you find something really statistical significantly deviated from the theoretical distribution. |
Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
|
|
|
|
valiron (OP)
|
|
May 02, 2015, 07:50:07 PM |
|
All 4 nounces very close by.
Not close at all. A difference 300,000 is about one thirteenth of the maximum range, which means consecutive nonces will be this close together over 10 times a day. 4Byte nounce is between 1 and 2^32-1=4.294.967.295 right? Where is your 300.000 being 1/13th coming from? I meant 300,000,000 (that's the closeness we're talking about right?), but I misplaced a few zeros somewhere around the second glass of absinthe. This is why you shouldn't drink and derive. Be careful with absynthe... Let's look closer at nounces: We assume that nounces are uniformly distributed (not exactly true since if we start increasingly with nounce 0 they follow a Poisson law, but taking into account that nounce cycles many times before finding the solution it is well approximated by the uniform distribution). We look at distance mod 2^32. |nounce(354641)-nounce(354640)| = 19.452.599 probability 19.452.599/(2^32-1)*2 = 1.8% |nounce(354642)-nounce(354641)| = 5.394.922 probability 5.394.922/(2^32-1)*2 = 0.12% |nounce(354642)-nounce(354641)| = 313.864.936 probability 313.864.936/(2^32-1)*2 =7.2% Combined probability 0.000155% that is 1 in 64.5 million of times. Are you trolling? 0.000155% is 1 in 645161 And this is nonsense. Just some made up data |nounce(1)-nounce(0)| = 5% |nounce(2)-nounce(1)| = 20% |nounce(3)-nounce(2)| = 10% |nounce(4)-nounce(3)| = 1% |nounce(5)-nounce(4)| = 5% |nounce(6)-nounce(5)| = 10% Combined probability 0.000005% that is 1 in 20 million of times. Bitcoin in broken!!! I just did a rough approximation, only valid for small probabilities and few events. You are welcome to do the exact computation. You calculate in a wrong way. You should define the meaning of "close" a priori. That could be 20%, 10%, or 1%. Let say you choose 10%, the P(1.8%, 0.12%, 7.2%) should be 1/1000, not 1/645161. And let say you choose 2%, the P(1.8%, 0.12%, 7.2%) should be 1/2551 (0.02*0.02*0.98). Therefore, one event of this kind is expected in about 2 weeks. Please stop here (and edit your misleading topic) unless you find something really statistical significantly deviated from the theoretical distribution. I don't understand what you mean. OK, let me do the computation and explain things carefully. You can tell me on which point you disagree. (0) Put your 2^32-1 integer values on a circle of perimeter 2. This geometrical representation will help you. (1) We assume uniform distribution of nounces. This is correct as first approximation, but not totally accurate as pointed out before by several people. We may extract the historical distribution and use it. (2) The probability that two consecutive nounces are closer as nounce(354641) and nounce(354640) is 1.8%. It is the minor arc length between the two nounces on the circle. Same for nounce(354642) and nounce(354641), and for nounce(354643) and nounce(354644). Otherwise, please correct me if you disagree. (3) We assume independence of nounces with respect to previous nounces, i.e. we consider nounces as independent random variables. This implies that distance between nounce(n+2) and nounce(n+1) is independent of the distance between nounce(n+1) and nounce(n). (4) Thus, the probability of having three consecutive events of the sort described is just the product of the probabilities, it is 1 over 645161. The probability of seeing this is on average once each 12.27 years at an average production of one block (nounce) every 10 minutes. My conclusion is that the nounces produced by this miner are likely not independent and the mining procedure is not the usual one and it uses previous block computations or doesn't uses much the nounce variable. But this is just one piece of evidence. The second one, about the block size, also points to the fact that it is the same miner who mined the blocks. 731 kB blocks are quite common as noted earlier by someone else, but it is not very likely either to find them consecutively. Moreover I bet that they cluster more often than expected and this can be checked running statistics on the blockchain. The third piece of evidence is how close in time are these blocks. THe probability is not alarmingly small and can be computed by the Poisson distribution that follow times between blocks. The fourth piece of evidence is the non-chronological timestamps that suggest that the timestap maleability is also used as nounce (this fact was already noted for blocks with only one transaction). The fifth piece of evidence is that the first block is mined by AntPool and the next 3 by anonymous. It is not so common to have consecutive anonymous blocks, This indicates that the miner is trying to hide that he is the same one mining. All this "coincidences" are extremely unlikely and point that something is going on there. |
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4158
Merit: 8411
|
|
May 02, 2015, 08:00:10 PM |
|
Also, A lot of hardware only searches a subset of nonces. The size is irrelevant; it's just roughly the soft target most miners use... the size isn't even available to the mining algorithm, which works only on the block header, other than being the amount of data after a dozen layers of sha256 that feed into the tree root hash in the header. |
|
|
|
|
jl2012
Legendary
Offline
Activity: 1792
Merit: 1097
|
|
May 02, 2015, 08:07:28 PM |
|
All 4 nounces very close by.
Not close at all. A difference 300,000 is about one thirteenth of the maximum range, which means consecutive nonces will be this close together over 10 times a day. 4Byte nounce is between 1 and 2^32-1=4.294.967.295 right? Where is your 300.000 being 1/13th coming from? I meant 300,000,000 (that's the closeness we're talking about right?), but I misplaced a few zeros somewhere around the second glass of absinthe. This is why you shouldn't drink and derive. Be careful with absynthe... Let's look closer at nounces: We assume that nounces are uniformly distributed (not exactly true since if we start increasingly with nounce 0 they follow a Poisson law, but taking into account that nounce cycles many times before finding the solution it is well approximated by the uniform distribution). We look at distance mod 2^32. |nounce(354641)-nounce(354640)| = 19.452.599 probability 19.452.599/(2^32-1)*2 = 1.8% |nounce(354642)-nounce(354641)| = 5.394.922 probability 5.394.922/(2^32-1)*2 = 0.12% |nounce(354642)-nounce(354641)| = 313.864.936 probability 313.864.936/(2^32-1)*2 =7.2% Combined probability 0.000155% that is 1 in 64.5 million of times. Are you trolling? 0.000155% is 1 in 645161 And this is nonsense. Just some made up data |nounce(1)-nounce(0)| = 5% |nounce(2)-nounce(1)| = 20% |nounce(3)-nounce(2)| = 10% |nounce(4)-nounce(3)| = 1% |nounce(5)-nounce(4)| = 5% |nounce(6)-nounce(5)| = 10% Combined probability 0.000005% that is 1 in 20 million of times. Bitcoin in broken!!! I just did a rough approximation, only valid for small probabilities and few events. You are welcome to do the exact computation. You calculate in a wrong way. You should define the meaning of "close" a priori. That could be 20%, 10%, or 1%. Let say you choose 10%, the P(1.8%, 0.12%, 7.2%) should be 1/1000, not 1/645161. And let say you choose 2%, the P(1.8%, 0.12%, 7.2%) should be 1/2551 (0.02*0.02*0.98). Therefore, one event of this kind is expected in about 2 weeks. Please stop here (and edit your misleading topic) unless you find something really statistical significantly deviated from the theoretical distribution. I don't understand what you mean. OK, let me do the computation and explain things carefully. You can tell me on which point you disagree. (0) Put your 2^32-1 integer values on a circle of perimeter 2. This geometrical representation will help you. (1) We assume uniform distribution of nounces. This is correct as first approximation, but not totally accurate as pointed out before by several people. We may extract the historical distribution and use it. (2) The probability that two consecutive nounces are closer as nounce(354641) and nounce(354640) is 1.8%. It is the minor arc length between the two nounces on the circle. Same for nounce(354642) and nounce(354641), and for nounce(354643) and nounce(354644). Otherwise, please correct me if you disagree. (3) We assume independence of nounces with respect to previous nounces, i.e. we consider nounces as independent random variables. This implies that distance between nounce(n+2) and nounce(n+1) is independent of the distance between nounce(n+1) and nounce(n). (4) Thus, the probability of having three consecutive events of the sort described is just the product of the probabilities, it is 1 over 645161. The probability of seeing this is on average once each 12.27 years at an average production of one block (nounce) every 10 minutes. If you can't see why you are committing an elementary statistics fallacy, just consider this: 1. P is an uniformly distributed variable from 0 to 1, with mean = 0.5 2. There is 144 blocks per day 3. The probability calculated, in the way you suggest, is about 0.5^144 = 4*10(-44), which should NEVER happen ------------------------------------- For the consecutive 731kb blocks, it just showed there were too many unconfirmed tx and miners had to use the maximum size. |
Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
|
|
|
|
valiron (OP)
|
|
May 02, 2015, 08:13:15 PM |
|
Also, A lot of hardware only searches a subset of nonces. The size is irrelevant; it's just roughly the soft target most miners use... the size isn't even available to the mining algorithm, which works only on the block header, other than being the amount of data after a dozen layers of sha256 that feed into the tree root hash in the header. The distribution of nounces is maybe not uniform in a 10% range of nounce 2.148.000.000. Indeed 2.147.483.648 = 2^31 so the nounces of the blocks are in binary 10000....0000 +/- some small stuff. Also, are there technical descriptions of the algorithms used by different ASICs? |
|
|
|
|
|
valiron (OP)
|
|
May 02, 2015, 08:17:46 PM |
|
All 4 nounces very close by.
Not close at all. A difference 300,000 is about one thirteenth of the maximum range, which means consecutive nonces will be this close together over 10 times a day. 4Byte nounce is between 1 and 2^32-1=4.294.967.295 right? Where is your 300.000 being 1/13th coming from? I meant 300,000,000 (that's the closeness we're talking about right?), but I misplaced a few zeros somewhere around the second glass of absinthe. This is why you shouldn't drink and derive. Be careful with absynthe... Let's look closer at nounces: We assume that nounces are uniformly distributed (not exactly true since if we start increasingly with nounce 0 they follow a Poisson law, but taking into account that nounce cycles many times before finding the solution it is well approximated by the uniform distribution). We look at distance mod 2^32. |nounce(354641)-nounce(354640)| = 19.452.599 probability 19.452.599/(2^32-1)*2 = 1.8% |nounce(354642)-nounce(354641)| = 5.394.922 probability 5.394.922/(2^32-1)*2 = 0.12% |nounce(354642)-nounce(354641)| = 313.864.936 probability 313.864.936/(2^32-1)*2 =7.2% Combined probability 0.000155% that is 1 in 64.5 million of times. Are you trolling? 0.000155% is 1 in 645161 And this is nonsense. Just some made up data |nounce(1)-nounce(0)| = 5% |nounce(2)-nounce(1)| = 20% |nounce(3)-nounce(2)| = 10% |nounce(4)-nounce(3)| = 1% |nounce(5)-nounce(4)| = 5% |nounce(6)-nounce(5)| = 10% Combined probability 0.000005% that is 1 in 20 million of times. Bitcoin in broken!!! I just did a rough approximation, only valid for small probabilities and few events. You are welcome to do the exact computation. You calculate in a wrong way. You should define the meaning of "close" a priori. That could be 20%, 10%, or 1%. Let say you choose 10%, the P(1.8%, 0.12%, 7.2%) should be 1/1000, not 1/645161. And let say you choose 2%, the P(1.8%, 0.12%, 7.2%) should be 1/2551 (0.02*0.02*0.98). Therefore, one event of this kind is expected in about 2 weeks. Please stop here (and edit your misleading topic) unless you find something really statistical significantly deviated from the theoretical distribution. I don't understand what you mean. OK, let me do the computation and explain things carefully. You can tell me on which point you disagree. (0) Put your 2^32-1 integer values on a circle of perimeter 2. This geometrical representation will help you. (1) We assume uniform distribution of nounces. This is correct as first approximation, but not totally accurate as pointed out before by several people. We may extract the historical distribution and use it. (2) The probability that two consecutive nounces are closer as nounce(354641) and nounce(354640) is 1.8%. It is the minor arc length between the two nounces on the circle. Same for nounce(354642) and nounce(354641), and for nounce(354643) and nounce(354644). Otherwise, please correct me if you disagree. (3) We assume independence of nounces with respect to previous nounces, i.e. we consider nounces as independent random variables. This implies that distance between nounce(n+2) and nounce(n+1) is independent of the distance between nounce(n+1) and nounce(n). (4) Thus, the probability of having three consecutive events of the sort described is just the product of the probabilities, it is 1 over 645161. The probability of seeing this is on average once each 12.27 years at an average production of one block (nounce) every 10 minutes. If you can't see why you are committing an elementary statistics fallacy, just consider this: 1. P is an uniformly distributed variable from 0 to 1, with mean = 0.5 2. There is 144 blocks per day 3. The probability calculated, in the way you suggest, is about 0.5^144 = 4*10(-44), which should NEVER happen ------------------------------------- For the consecutive 731kb blocks, it just showed there were too many unconfirmed tx and miners had to use the maximum size. The probability of having 144 independent random variables all smaller that their mean value is what you computed. It is the same as computing the probability of throwing 144 times a coin and seeing all times heads. You are right. It is extremely unlikely and should never happen. Where is the fallacy? |
|
|
|
|
|
|
|
valiron (OP)
|
|
May 02, 2015, 08:36:28 PM |
|
Can you explain the mathematical reason why nounces produced by ASICs are not uniform? The references you provide obviously do not explain that (nice paper by the way). Also, the point here is that the distribution around 2^31 may be not uniform. Any mathematical reason for that? From the pure hashing point of view, all nounces should have the same probability of success. If they appear with a non-uniform distribution is because the mining algorithm do not treat all of them equally, which is quite possible but must have a mathematical reason behind. Anyway, the fact that all 4 blocks have a nounce close to 2^31 is more evidence that they were mined by the same miner. There are many other nounces that are not nearby 2^31. Too many similarities between the numbers of the 4 blocks... |
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4158
Merit: 8411
|
|
May 02, 2015, 08:41:20 PM |
|
FWIW, I think Valiron is engaging in misconduct here. At first there is an "innocent" observational question and then after people point out that the observation is expected (because of hardware that only uses a limited set of nonces, and because of the block soft-target maximum) he had adopted a position of "secret knowing" that substantiates his position and yet he will not explain it.
Of course, it's possible for someone to be innocently ignorant, even likely (especially considering Valiron's posting history; there are plenty of optimizations you could be unaware of, or structure about mining that lay people misunderstand that could be mistaken as some advantage)-- but there is no reason to play secrecy games there, and secrecy is actively poisonous to having your understanding elaborated. Likewise, it's possible to actually know secrets, but then you don't go hinting about them on the forum. One possible way gain from the pattern of posts here would to manipulate the market with FUD about the security of the hashing algorithm, another would be to try to scam greedy buyer into buying these "premining" secrets; so these are my working theories, and I've negatively rated valiron accordingly.
(I'd debated instead locking the thread; as a thread of "Oh whats this" "its that" "oh no its not, it's something else but I won't tell you" "we told you its this" "bad math bad math" isn't a good use of the forum; but I thought giving a chance for a correction would be more useful).
|
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4158
Merit: 8411
|
|
May 02, 2015, 08:48:29 PM |
|
Can you explain the mathematical reason why nounces produced by ASICs are not uniform? The references you provide obviously do not explain that.
Because mining ASIC use "sea of hashers", they take one midstate work unit and broadcast it to hundreds (or even thousands) of SHA256 engines, each one tries a different nonce for the same work. You only have a finite number of engines so only a subset of nonces will get used, also some engines will fail (sometimes the same engine on every chip of a particular make) adding additional gaps. The allocation schemes differ from device to device (e.g. some hardware only produces even nonces or multiple of 64 nonces, some hardware only produces nonces in a range 0-1024, etc.) There is also an optimization you can do where you actually hardwire the engines for given nonces and grind the first half, though I don't know if anyone bothers with it. Anyway, the fact that all 4 blocks have a nounce close to 2^31 is more evidence that they were mined by the same miner.
Same miner or similar hardware, perhaps-- sure? and so what? Its not uncommon for a large miner (or a hardware type with a large share of the hashrate) to find four blocks consecutively; there is effectively a calculator for that in the bitcoin whitepaper. |
|
|
|
|
|
valiron (OP)
|
|
May 02, 2015, 08:55:13 PM
Last edit: May 04, 2015, 09:53:42 AM by valiron |
|
FWIW, I think Valiron is engaging in misconduct here. At first there is an "innocent" observational question and then after people point out that the observation is expected (because of hardware that only uses a limited set of nonces, and because of the block soft-target maximum) he had adopted a position of "secret knowing" that substantiates his position and yet he will not explain it.
Of course, it's possible for someone to be innocently ignorant, even likely (especially considering Valiron's posting history; there are plenty of optimizations you could be unaware of, or structure about mining that lay people misunderstand that could be mistaken as some advantage)-- but there is no reason to play secrecy games there, and secrecy is actively poisonous to having your understanding elaborated. Likewise, it's possible to actually know secrets, but then you don't go hinting about them on the forum. One possible way gain from the pattern of posts here would to manipulate the market with FUD about the security of the hashing algorithm, another would be to try to scam greedy buyer into buying these "premining" secrets; so these are my working theories, and I've negatively rated valiron accordingly.
(I'd debated instead locking the thread; as a thread of "Oh whats this" "its that" "oh no its not, it's something else but I won't tell you" "we told you its this" "bad math bad math" isn't a good use of the forum; but I thought giving a chance for a correction would be more useful).
Sorry, I didn't mean any kind of misconduct or second intention. For the disclaimer I don't participate in active trading. If you want I can edit and erase all hints at what I know (deleted). I don't mind discussing this openly, or if you prefer we can discuss it in a separate thread, but I don't think it is material to be exposed through posts in a forum. It would be better to discuss it in detail after a research paper is published. I am only interested in discussing the mathematical/computational aspects. As said, I can edit and remove everything that could sound alarming. It is not my intention to spread any kind of FUD on bitcoin. |
|
|
|
|
|
inBitweTrust
|
|
May 02, 2015, 08:56:06 PM |
|
FWIW, I think Valiron is engaging in misconduct here. At first there is an "innocent" observational question and then after people point out that the observation is expected (because of hardware that only uses a limited set of nonces, and because of the block soft-target maximum) he had adopted a position of "secret knowing" that substantiates his position and yet he will not explain it.
I suspect as much as well, but to give Valiron the benefit of the doubt and for other lurkers to potentially learn something I will try explaining it as simply as possible. Can you explain the mathematical reason why nounces produced by ASICs are not uniform? The references you provide obviously do not explain that (nice paper by the way).
The papers do explain biases towards certain numbers and why certain sets of numbers appear more often than other numbers and how these probabilistic biases can mislead you into drawing erroneous conclusions. Based upon the quickness of your reply you obviously didn't read the papers so I will provide a video for you to understand this principle- https://www.youtube.com/watch?v=4UgZ5FqdYIQIn the video the bias is created because the sampled numbers are not random but selected based upon our bias to start at 0 or 1 and work in a linear manner as humans. The reason why the nonces produced aren't randomly uniform is because ASIC's search through random numbers in a linear and non random manner within certain ranges. There are many potential nonces that that could satisfy the block to hash given a specific difficulty but since asics search for these nonces in a linear fashion within a given range it greatly increases the probability that similar(contrasted to the potential range of possibilities of potential numbers) nonces will be found for each block. This is further emphasized by the fact that there are now very large mining pools running most of the same exact hardware for most of their hashrate which has the exact same characteristics on how it searches for valid nonces. |
|
|
|
|
valiron (OP)
|
|
May 02, 2015, 09:10:14 PM
Last edit: May 04, 2015, 09:54:11 AM by valiron |
|
FWIW, I think Valiron is engaging in misconduct here. At first there is an "innocent" observational question and then after people point out that the observation is expected (because of hardware that only uses a limited set of nonces, and because of the block soft-target maximum) he had adopted a position of "secret knowing" that substantiates his position and yet he will not explain it.
I suspect as much as well, but to give Valiron the benefit of the doubt and for other lurkers to potentially learn something I will try explaining it as simply as possible. Can you explain the mathematical reason why nounces produced by ASICs are not uniform? The references you provide obviously do not explain that (nice paper by the way).
The papers do explain biases towards certain numbers and why certain sets of numbers appear more often than other numbers and how these probabilistic biases can mislead you into drawing erroneous conclusions. Based upon the quickness of your reply you obviously didn't read the papers so I will provide a video for you to understand this principle- https://www.youtube.com/watch?v=4UgZ5FqdYIQIn the video the bias is created because the sampled numbers are not random but selected based upon our bias to start at 0 or 1 and work in a linear manner as humans. The reason why the nonces produced aren't randomly uniform is because ASIC's search through random numbers in a linear and non random manner within certain ranges. There are many potential nonces that that could satisfy the block to hash given a specific difficulty but since asics search for these nonces in a linear fashion within a given range it greatly increases the probability that similar(contrasted to the potential range of possibilities of potential numbers) nonces will be found for each block. This is further emphasized by the fact that there are now very large mining pools running most of the same exact hardware for most of their hashrate which has the exact same characteristics on how it searches for valid nonces. Still this doesn't provide a mathematical explanation of the clustering around 2^31. I didn't read in detail the MAA paper, but I know exactly what you mean by refering to it. I also know that it doesn't explain the above clustering. If I get the time I will parse the blockchain and do some statistics on the nounces to determine their distribution. |
|
|
|
|
cakir
Legendary
Offline
Activity: 1274
Merit: 1000
★ BitClave ICO: 15/09/17 ★
|
|
May 02, 2015, 09:12:34 PM |
|
I've spotted same things before. https://bitcointalk.org/index.php?topic=1031953.msg11136641#msg11136641What's really happening, I really wanna know. |
|
|
|
|
|
|
,'#██+:
,█████████████'
+██████████████████
;██████████████████████
███████: .███████`
██████ ;█████'
`█████ #████#
████+ `████+
████: ████,
████: .# █ ████
;███+ ██ ███ ████
████ ███' ███. '███,
+███ #████ ,████ ████
████ █████ .+██████: █████+ `███.
,███ ███████████████████████ ████
████ ███████████████████████' :███
███: +████████████████████████ ███`
███ █████████████████████████` ███+
,███ ██████████████████████████ #███
'███ '██████████████████████████ ;███
#███ ███████████████████████████ ,███
████ ███████████████████████████. .███
████ ███████████████████████████' .███
+███ ███████████████████████████+ :███
:███ ███████████████████████████' +███
███ ███████████████████████████. ███#
███. #██████████████████████████ ███,
████ █████████████████████████+ `███
'███ '████████████████████████ ████
███; ███████████████████████ ███;
████ #████████████████████ ████
███# .██████████████████ `███+
████` ;██████████████ ████
████ '███████#. ████.
.████ █████
'████ █████
#████' █████
+█████` ██████
,██████: `███████
████████#;,..:+████████.
,███████████████████+
.███████████████;
`+███████#,
| |
|
|
|
|
inBitweTrust
|
|
May 02, 2015, 09:32:32 PM |
|
OK, judging from the clear lack of interest (he keeps denying the evidence yet doesn't even bother to digest the material) or refute the specific reasons why the evidence or reasons we provide are fallacious I am now more or less convinced he is disingenuous. I understand that some people are interested in hidding the procedure, but I think I will explain and expose how you can partially premine...It is something that I did notice long time ago, and surely other have noticed as well.
It is clear that someone found a trick for fast mining. I kind of happen to know what might be...
It is premining at some extend. Won't disclose more for the moment.
Bitcoin is an open source project where we openly discuss and share ideas. What you are doing by demanding explanations and evidence from us and than not reciprocating on what you claim to understand. This is rude at minimum and at worst an act of setting up a "secret" for some sort of investment scam. I don't mind discussing this openly, or if you prefer we can discuss it in a separate thread, but I don't think it is material to be exposed through posts in a forum. It would be better to discuss it in detail after a research paper is published. I am only interested in discussing the mathematical/computational aspects.
valiron if you don't mind discussing this openly than just do so, If you are concerned about the security of bitcoin than email one of the core developers your secrets. If you won't do either , reframe from hinting at it in the first place. Read this thread , it clearly goes over all the reasons you saw that behavior in your linked thread. |
|
|
|
|
valiron (OP)
|
|
May 02, 2015, 09:34:41 PM |
|
Can you explain the mathematical reason why nounces produced by ASICs are not uniform? The references you provide obviously do not explain that.
Because mining ASIC use "sea of hashers", they take one midstate work unit and broadcast it to hundreds (or even thousands) of SHA256 engines, each one tries a different nonce for the same work. You only have a finite number of engines so only a subset of nonces will get used, also some engines will fail (sometimes the same engine on every chip of a particular make) adding additional gaps. The allocation schemes differ from device to device (e.g. some hardware only produces even nonces or multiple of 64 nonces, some hardware only produces nonces in a range 0-1024, etc.) There is also an optimization you can do where you actually hardwire the engines for given nonces and grind the first half, though I don't know if anyone bothers with it. This makes sense, although I understand that nounces are exhausted pretty kickly. I see no reason why they should restrict nounces. It requires more computation to change extranounces for example. Obviously I can accept that this is an implementation improvement of mining for which we do not have the precise details. Anyway, the fact that all 4 blocks have a nounce close to 2^31 is more evidence that they were mined by the same miner.
Same miner or similar hardware, perhaps-- sure? and so what? Its not uncommon for a large miner (or a hardware type with a large share of the hashrate) to find four blocks consecutively; there is effectively a calculator for that in the bitcoin whitepaper. I also observe that the last 3 blocks are by anonymous miners. Thus if it is the same miner he is trying to conceal his identity, so we should assume that it is the same hardware. It is curious that suddenly the same hardware solves the block in such a short timeframe. It is of course possible. Just inspecting mined blocks there is a high clustering of anonymous miners. It will be interesting to do a statistic on this also. |
|
|
|
|
|
valiron (OP)
|
|
May 02, 2015, 09:42:15 PM |
|
valiron if you don't mind discussing this openly than just do so, If you are concerned about the security of bitcoin than email one of the core developer your secrets.
I just did that (sending a message to a developer), and as posted before I am willing to erase my posts here. It is not about direct security of bitcoin. It is about boosting the mining algorithm. I don't think it is a direct threat to bitcoin security. Were the first GPU miners a threat to bitcoin security? As for discussing this openly I prefer to wait for the answer of the developer. I don't want to be accused of spreading FUD or whatever. |
|
|
|
|
|
inBitweTrust
|
|
May 02, 2015, 09:43:49 PM |
|
I also observe that the last 3 blocks are by anonymous miners. Thus if it is the same miner he is trying to conceal his identity, so we should assume that it is the same hardware.
~20% of the network hashing power is done by unknown miners. Why would you assume they are using all the same hardware? A complete non sequitur. |
|
|
|
|
valiron (OP)
|
|
May 02, 2015, 09:44:38 PM |
|
OK, judging from the clear lack of interest (he keeps denying the evidence yet doesn't even bother to digest the material) or refute the specific reasons why the evidence or reasons we provide are fallacious I am now more or less convinced he is disingenuous.
I will be grateful if you avoid unnecessary ad hominem. So far, you have only contributed by linking to a nice elementary number theoretical paper that has little to do with what we discuss. |
|
|
|
|
|
valiron (OP)
|
|
May 02, 2015, 09:46:00 PM |
|
I also observe that the last 3 blocks are by anonymous miners. Thus if it is the same miner he is trying to conceal his identity, so we should assume that it is the same hardware.
~20% of the network hashing power is done by unknown miners. Why would you assume they are using all the same hardware? A complete non sequitur. It was the observation of gmaxwell because of the clustering of the nounces that seems to indicated similar miner or hardware. Ask him. Since the first block ins mined by AntPool and the others are anonymous, I assume that they use the same hardware. Otherwise we need to ask AntPool why they are anonymizing the next blocks if they are the miners. It is also well known that a miner that mines a block has a higher probability of mining the next one since he can start mining in the time his block is propagating. Also there is a well known advantage in concealing mined blocks and releasing them altogether. This could indicate same miner. |
|
|
|
|
|
inBitweTrust
|
|
May 02, 2015, 09:55:38 PM |
|
I also observe that the last 3 blocks are by anonymous miners. Thus if it is the same miner he is trying to conceal his identity, so we should assume that it is the same hardware.
~20% of the network hashing power is done by unknown miners. Why would you assume they are using all the same hardware? A complete non sequitur. It was the observation of gmaxwell because of the clustering of the nounces that seems to indicated similar hardware. Ask him. Gmaxwell never made that claim, all he did was suggest that is one possibility. Different ASICs also have similar or exactly the same parameters as well for the ranges and order in which nonces are searched for which makes your suggestion that we should assume the same hardware especially incorrect. One should not assume the same miner or the same hardware like you claim. Look at the IP addresses, If anything the default assumption should be that they are 3 different miners. (Sure it might be possible it is one miner using multiple VPNs but that shouldn't be your default assumption) |
|
|
|
|
|
|
valiron (OP)
|
|
May 02, 2015, 10:16:22 PM |
|
We already discussed that in previous posts. Timestamps in the blocks are malleable. Seems that block explorers are taking timestamps from the blocks. It is not the timestamp of the reception time of the blockexplorer since this would be incompatible with having the timestamp of block 354643 earlier than that of 354642. Just read above. |
|
|
|
|
|
valiron (OP)
|
|
May 02, 2015, 10:17:59 PM |
|
I also observe that the last 3 blocks are by anonymous miners. Thus if it is the same miner he is trying to conceal his identity, so we should assume that it is the same hardware.
~20% of the network hashing power is done by unknown miners. Why would you assume they are using all the same hardware? A complete non sequitur. It was the observation of gmaxwell because of the clustering of the nounces that seems to indicated similar hardware. Ask him. Gmaxwell never made that claim, all he did was suggest that is one possibility. Different ASICs also have similar or exactly the same parameters as well for the ranges and order in which nonces are searched for which makes your suggestion that we should assume the same hardware especially incorrect. One should not assume the same miner or the same hardware like you claim. Look at the IP addresses, If anything the default assumption should be that they are 3 different miners. (Sure it might be possible it is one miner using multiple VPNs but that shouldn't be your default assumption) "seems to indicate" is the same as "suggests the possibility" in my poor english. |
|
|
|
|
|
inBitweTrust
|
|
May 02, 2015, 10:27:46 PM |
|
"seems to indicate" is the same as "suggests the possibility" in my poor english.
It isn't a problem with translation. "seems to indicate" and "suggests the possibility" are both completely different statements than: so we should assume that it is the same hardware.
We are dealing with probabilities here. You should never make such assumptions. We already discussed that in previous posts. Timestamps in the blocks are malleable. Seems that block explorers are taking timestamps from the blocks. It is not the timestamp of the reception time of the blockexplorer since this would be incompatible with having the timestamp of block 354643 earlier than that of 354642. Just read above.
One should not assume that all three have malleable timestamps and than assume that they are grouped within 1 minute . So than all your original concerns have been explained except a similar grouping on nonces , which we have also explained but you refuse to accept our answers without giving specific detailed refutations. |
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4158
Merit: 8411
|
|
May 02, 2015, 11:52:51 PM |
|
I just did that (sending a message to a developer), and as posted before I am willing to erase my posts here.
[....]
As for discussing this openly I prefer to wait for the answer of the developer. I don't want to be accused of spreading FUD or whatever.
Are you referring to your message to me 45 minutes ago? You provided no information that wasn't in the thread; and I responded asking you to provide information (either privately or publicly, though I encouraged you to provide it in public.). Still this doesn't provide a mathematical explanation of the clustering around 2^31.
I and multiple others have explained to you multiple times now that various mining devices consider only subsets of nonces for completely boring reasons--; what isn't explained is why you keep alleging that something with a boring explanation which has been provided multiple times hasn't been explained. A few week ago you were making posts that demonstrated that you had no idea how mining worked at all and were not willing or able to do even the most basic research on the subject. Your posts here continue to show a remarkable lack of basic research, yet you expect people to believe that you know something that hasn't been discussed in the hundreds of past threads about low level mining optimizations by experts in the field (including people like the inventor of hashcash; the general scheme used). Moreover, you started this by deceptively asking a question you later claimed to "know the answer to"; so I hope you can understand why people are skeptical here. You're making serious claims that would be concerns for the security of Bitcoin if true; such claims demand serious substantiation... doubly so when they coming form a source which seems to have been clearly deceptive in this very thread and is obviously not very familiar with the subject. In any case, you need do nothing more to defend your reputation than to simply explain what you're thinking. If your ideas are wrong, they'll be corrected; if they're right but not news, old threads will be referenced, if they're new and concerning the issues will be addressed if possible, etc. Right now, though, you're basically trying to convince us of something for which you'll give none of the information which could be used to support your claim. The only content in this thread will be people attacking your methods and motivations as a result, since you are intentionally refusing to provide the only information which could be used to analyze your claim directly. |
|
|
|
|
cr1776
Legendary
Offline
Activity: 4032
Merit: 1301
|
|
May 03, 2015, 12:22:35 AM |
|
valiron if you don't mind discussing this openly than just do so, If you are concerned about the security of bitcoin than email one of the core developer your secrets.
I just did that (sending a message to a developer), and as posted before I am willing to erase my posts here. It is not about direct security of bitcoin. It is about boosting the mining algorithm. I don't think it is a direct threat to bitcoin security. Were the first GPU miners a threat to bitcoin security?
As for discussing this openly I prefer to wait for the answer of the developer. I don't want to be accused of spreading FUD or whatever. Even if there was some way to boost the mining algorithm by some large percentage, at most if would provide a temporary advantage to someone or some group. Difficulty would quickly adjust, and others would discover this "secret." This has been discussed previously too. ;-) You are correct that the switch from CPU to GPU was not a threat to security. Particularly since GPUs were widely available and could be switched relatively quickly. Satoshi attempted to encourage people (with a "gentleman's agreement") to stick with CPUs for as long as possible to encourage the ease of adoption by more people. It was easier to get mining on a CPU than a GPU. During that time at various points there would be people doing some GPU mining, and eventually everyone had to switch to remain in the mining game, but it didn't impact security significantly. Hiding what this temporary advantage is - if you think that is what is going on here - is only helping this party who knows of this purported boost to the mining algorithm. I say "purported" because significant claims require significant proof. |
|
|
|
|
|
valiron (OP)
|
|
May 03, 2015, 12:40:18 AM |
|
I just did that (sending a message to a developer), and as posted before I am willing to erase my posts here.
[....]
As for discussing this openly I prefer to wait for the answer of the developer. I don't want to be accused of spreading FUD or whatever.
Are you referring to your message to me 45 minutes ago? You provided no information that wasn't in the thread; and I responded asking you to provide information (either privately or publicly, though I encouraged you to provide it in public.). Still this doesn't provide a mathematical explanation of the clustering around 2^31.
I and multiple others have explained to you multiple times now that various mining devices consider only subsets of nonces for completely boring reasons--; what isn't explained is why you keep alleging that something with a boring explanation which has been provided multiple times hasn't been explained. A few week ago you were making posts that demonstrated that you had no idea how mining worked at all and were not willing or able to do even the most basic research on the subject. Your posts here continue to show a remarkable lack of basic research, yet you expect people to believe that you know something that hasn't been discussed in the hundreds of past threads about low level mining optimizations by experts in the field (including people like the inventor of hashcash; the general scheme used). Moreover, you started this by deceptively asking a question you later claimed to "know the answer to"; so I hope you can understand why people are skeptical here. You're making serious claims that would be concerns for the security of Bitcoin if true; such claims demand serious substantiation... doubly so when they coming form a source which seems to have been clearly deceptive in this very thread and is obviously not very familiar with the subject. In any case, you need do nothing more to defend your reputation than to simply explain what you're thinking. If your ideas are wrong, they'll be corrected; if they're right but not news, old threads will be referenced, if they're new and concerning the issues will be addressed if possible, etc. Right now, though, you're basically trying to convince us of something for which you'll give none of the information which could be used to support your claim. The only content in this thread will be people attacking your methods and motivations as a result, since you are intentionally refusing to provide the only information which could be used to analyze your claim directly. Dear gmaxwell, You are right, I have no idea of what specific algorithms are using ASICs and that is what I was asking in that previous posts. I don't work on hardware. I guess you had to search through my post in lack of other arguments. This doesn't mean that I can't have some idea of how bitcoin mining works and what classical improvements can be made due to the particular structure of the block headers. You are making up that I am making claims about the security of bitcoin. That's untrue. First of all in order to raise concerns about bitcoin security, you will agree that you would need to boost the performance of the mining algorithm by several orders of magnitude. I never made such a claim. On the other hand it would be worrysome if a number of people had access to a better mining algorithm that is used extensively and kept secret, and only for that reason it is worth analyzing unusual block validations. I have no reputation to defend while I am being accused without grounds of being a scamer. My reputation is well, thank you for your concern. I withdraw any claim that I may have made. So I am not trying to convince you about anything. I stand my claim that I see some unusual statistics on these blocks. Of course this doesn't prove anything and your explanations are most probably correct, so you can continue to sleep well. Be in peace. If you happen to find better explanations I, and others, would be glad to hear about them. I already retracted everything, so I wait you to remove your negative rating and scam accusations : https://bitcointalk.org/index.php?action=trust;u=11425Appears to be dishonestly spreading fud on technical matters.
At first Valiron posts an ignorant but innocent sounding question about why a run of blocks have similar sizes and nonces.
People responded pointing out that there is a default soft-maximum block target size, and that size is common and expected. People also pointed out that nonces are not uniformly searched and similar nonces are expected.
Valiron then changed from his position of ignorance and began responding to his own questions with claims of knowledge which he will not disclose: "It is premining at some extend. Won't disclose more for the moment.", and "Proof of work with double hash as designed is weak. Same problem with blocks with only one transaction. " and more bad statistics.
I suspect Valiron is either trying to scam someone out of paying for his "knowledge" or that he is attempting to manipulate the market price of Bitcoin;
... it's possible that he has just innocently reinvented one of the many known-for-many-years optimizations (e.g. pre-computing the midstate; or hardwiring the initial part of the second compression function run)... or even a more fundamental misunderstanding like not realizing the hashing the block content is intentionally not inside the mining algorithm inner loop. But if so there is no reason to be mysterious here; if he says what he's thinking people will explain how it does or doesn't matter and where it has been discussed in the past.
Accordingly; I'll remove this negative rating (or downgrade it to neutral) when Valiron either retracts or substantiates his position. Best regards. |
|
|
|
|
|
valiron (OP)
|
|
May 03, 2015, 12:45:44 AM |
|
valiron if you don't mind discussing this openly than just do so, If you are concerned about the security of bitcoin than email one of the core developer your secrets.
I just did that (sending a message to a developer), and as posted before I am willing to erase my posts here. It is not about direct security of bitcoin. It is about boosting the mining algorithm. I don't think it is a direct threat to bitcoin security. Were the first GPU miners a threat to bitcoin security?
As for discussing this openly I prefer to wait for the answer of the developer. I don't want to be accused of spreading FUD or whatever. Even if there was some way to boost the mining algorithm by some large percentage, at most if would provide a temporary advantage to someone or some group. Difficulty would quickly adjust, and others would discover this "secret." This has been discussed previously too. ;-) You are correct that the switch from CPU to GPU was not a threat to security. Particularly since GPUs were widely available and could be switched relatively quickly. Satoshi attempted to encourage people (with a "gentleman's agreement") to stick with CPUs for as long as possible to encourage the ease of adoption by more people. It was easier to get mining on a CPU than a GPU. During that time at various points there would be people doing some GPU mining, and eventually everyone had to switch to remain in the mining game, but it didn't impact security significantly. Hiding what this temporary advantage is - if you think that is what is going on here - is only helping this party who knows of this purported boost to the mining algorithm. I say "purported" because significant claims require significant proof. I think you made my point very clear. AS you explained, I don't see any direct threat to bitcoin security. As I said I withdraw any claims and if I have something relevant to say on this mater it will be in a public research paper. I am not trying to scam anyone, to scare anyone, nor to sell anything. On the other hand I don't either play the game of "having to defend my reputation" because Mr gmaxwell decides so. |
|
|
|
|
|
valiron (OP)
|
|
May 03, 2015, 12:53:52 AM |
|
All 4 nounces very close by.
Not close at all. A difference 300,000 is about one thirteenth of the maximum range, which means consecutive nonces will be this close together over 10 times a day. 4Byte nounce is between 1 and 2^32-1=4.294.967.295 right? Where is your 300.000 being 1/13th coming from? I meant 300,000,000 (that's the closeness we're talking about right?), but I misplaced a few zeros somewhere around the second glass of absinthe. This is why you shouldn't drink and derive. Be careful with absynthe... Let's look closer at nounces: We assume that nounces are uniformly distributed (not exactly true since if we start increasingly with nounce 0 they follow a Poisson law, but taking into account that nounce cycles many times before finding the solution it is well approximated by the uniform distribution). We look at distance mod 2^32. |nounce(354641)-nounce(354640)| = 19.452.599 probability 19.452.599/(2^32-1)*2 = 1.8% |nounce(354642)-nounce(354641)| = 5.394.922 probability 5.394.922/(2^32-1)*2 = 0.12% |nounce(354642)-nounce(354641)| = 313.864.936 probability 313.864.936/(2^32-1)*2 =7.2% Combined probability 0.000155% that is 1 in 64.5 million of times. Are you trolling? 0.000155% is 1 in 645161 And this is nonsense. Just some made up data |nounce(1)-nounce(0)| = 5% |nounce(2)-nounce(1)| = 20% |nounce(3)-nounce(2)| = 10% |nounce(4)-nounce(3)| = 1% |nounce(5)-nounce(4)| = 5% |nounce(6)-nounce(5)| = 10% Combined probability 0.000005% that is 1 in 20 million of times. Bitcoin in broken!!! I just did a rough approximation, only valid for small probabilities and few events. You are welcome to do the exact computation. You calculate in a wrong way. You should define the meaning of "close" a priori. That could be 20%, 10%, or 1%. Let say you choose 10%, the P(1.8%, 0.12%, 7.2%) should be 1/1000, not 1/645161. And let say you choose 2%, the P(1.8%, 0.12%, 7.2%) should be 1/2551 (0.02*0.02*0.98). Therefore, one event of this kind is expected in about 2 weeks. Please stop here (and edit your misleading topic) unless you find something really statistical significantly deviated from the theoretical distribution. I don't understand what you mean. OK, let me do the computation and explain things carefully. You can tell me on which point you disagree. (0) Put your 2^32-1 integer values on a circle of perimeter 2. This geometrical representation will help you. (1) We assume uniform distribution of nounces. This is correct as first approximation, but not totally accurate as pointed out before by several people. We may extract the historical distribution and use it. (2) The probability that two consecutive nounces are closer as nounce(354641) and nounce(354640) is 1.8%. It is the minor arc length between the two nounces on the circle. Same for nounce(354642) and nounce(354641), and for nounce(354643) and nounce(354644). Otherwise, please correct me if you disagree. (3) We assume independence of nounces with respect to previous nounces, i.e. we consider nounces as independent random variables. This implies that distance between nounce(n+2) and nounce(n+1) is independent of the distance between nounce(n+1) and nounce(n). (4) Thus, the probability of having three consecutive events of the sort described is just the product of the probabilities, it is 1 over 645161. The probability of seeing this is on average once each 12.27 years at an average production of one block (nounce) every 10 minutes. If you can't see why you are committing an elementary statistics fallacy, just consider this: 1. P is an uniformly distributed variable from 0 to 1, with mean = 0.5 2. There is 144 blocks per day 3. The probability calculated, in the way you suggest, is about 0.5^144 = 4*10(-44), which should NEVER happen ------------------------------------- For the consecutive 731kb blocks, it just showed there were too many unconfirmed tx and miners had to use the maximum size. The probability of having 144 independent random variables all smaller that their mean value is what you computed. It is the same as computing the probability of throwing 144 times a coin and seeing all times heads. You are right. It is extremely unlikely and should never happen. Where is the fallacy? We never heard back of jl2012. I guess he agrees that my argument wasn't fallacious. I withdraw most claims, but I stand by the claim that to see 144 times heads in 144 coin throws is very unlikely. I will run some statistics on nounces. I am now very curious about their distribution. Anyone did study that before? |
|
|
|
|
|
inBitweTrust
|
|
May 03, 2015, 01:01:43 AM |
|
As I said I withdraw any claims and if I have something relevant to say on this mater it will be in a public research paper. I am not trying to scam anyone, to scare anyone, nor to sell anything. On the other hand I don't either play the game of "having to defend my reputation" because Mr gmaxwell decides so.
It has nothing to do with fear of a vulnerability as many of us have heard and researched these discussions many times before. It is merely us being intolerant towards nonsense presented in an arrogant manner or someone setting up a scam by making insinuations and teasing developers that you have a solution but won't disclose it. It is simply bad manners to do with open source projects where we try to share ideas openly. Go ahead and either prove yourself by writing that research paper or mining faster than anyone else. I look forward to seeing your whitepaper or being proven wrong and having to apologize for judging you too quickly because in all honestly it would be really neat if you did find something new we haven't discovered or discussed over the years. I guess he agrees that my argument wasn't fallacious. I withdraw most claims, but I stand by the claim that to see 144 times heads in 144 coin throws is very unlikely.
I will run some statistics on nounces. I am now very curious about their distribution. Anyone did study that before?
You were so close now want to begin discussing matters more without doing your homework. Please just finish that whitepaper that supports your secret claims and than some of us will happily read it and have something to discuss. |
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4158
Merit: 8411
|
|
May 03, 2015, 01:41:55 AM
Last edit: May 03, 2015, 02:19:02 AM by gmaxwell |
|
We never heard back of jl2012.
I guess he agrees that my argument wasn't fallacious. I withdraw most claims, but I stand by the claim that to see 144 times heads in 144 coin throws is very unlikely.
I will run some statistics on nounces. I am now very curious about their distribution. Anyone did study that before?
Is this kind of comment acceptable in the circles you normally travel in? If one of the people I worked with presented an argument of this form my response would be "Shame on you". Perhaps jl2012 has other things to do than click reload constantly and wade through the page and pages of untrimmed quotations in your message? Doubly so when it has been very clearly explained that your statistical argument is outright incorrect already by others. Miners do not select nonces uniformly for boring engineering reasons, this is a fact, it's the behavior of hardware sitting right next to me, it's easily observable on the blockchain. Your statistical argument is that IF nonces were uniform then it would be unlikely to see a run of similar ones. You do not correct for multiple comparisons (we've had some 354k possible runs of 4 for this to be true in), but most importantly you seem to strangely continue to ignore the fact that we know that various hardware does not uniformly select nonces; and instead you suggest this is evidence of your secret hypothesis. Why are you surprised that we reject your reasoning and instead question your motivations? The nonces here aren't even that close-- 2167965896, 2148513297, 2143118375, 2456983311 spans 7% of the nonce range... Since people seem to get caught up on the the analysis, perhaps a numerical example in python might simplify things for people:
import random
trys = 1000000
threshold = 2456983311 - 2143118375
small_rng = 0
for i in xrange(trys):
n = [random.randrange(0,2**32) for ii in xrange(4)]
small_rng += (max(n)-min(n))<=threshold
print("Out of %d tries, %d groups of 4 nonces were spanned a range equal or smaller than %d."%(trys,small_rng,threshold))
print("Since there are 144 blocks (thus 144 overlapping groups of 4)")
print("We'd expect to see this every %f days with _uniform_ nonces."%(1./(float(small_rng)/trys*144.)))
Which yields:
Out of 1000000 tries, 1524 groups of 4 nonces were spanned a range equal or smaller than 313864936.
Since there are 144 blocks (thus 144 overlapping groups of 4)
We'd expect to see this every 4.556722 days with _uniform_ nonces.
Since we also know existing hardware produces a subset of nonces we should probably expect these runs to be even more common than the above reflects. To get a feel for how non-uniformity changes this, switching to an RNG with a linear sloping probability, abs(random.randrange(0,2**32)-random.randrange(0,2**32)), increases the rate of these 'small' spans by about 2.8x. Without a reason to believe the exact criteria was established in advance instead of based on the data we should also probably be correcting for the fact that there are many other possible "patterns" people might find interesting and might use to claim support for some secret theory; e.g. ending with certain digits in some base, or being close mod 2^32, having digits that are cyclic shifts of each other in some base, being close by a larger but also 'small' threshold (E.g. the post originally claimed 6 blocks with a nonce span of 1856814243 which we'd expect to see a bit over 8 times per day.), or having some other simple arithmetic relation, etc. |
|
|
|
|
btcbobby
Newbie
Offline
Activity: 47
Merit: 0
|
|
May 03, 2015, 01:45:08 AM |
|
Why is it always a conspiracy? Flip a quarter 100 million times, you'll eventually get heads 100 times in a row. Now flaw in the quarter, just as it's not a flaw that a few blocks get solved in a short period.
|
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4158
Merit: 8411
|
|
May 03, 2015, 02:24:45 AM
Last edit: May 03, 2015, 02:50:33 AM by gmaxwell |
|
just as it's not a flaw that a few blocks get solved in a short period.
Right, it's a normal and expected property of the exponential distribution (that distribution of interblock gaps) that there are a lot of small values; more than you'd probably expect after being told there was a 10 minute average. E.g. about 10% of blocks are 1minute or less apart (assuming lambda=1/600; in reality because of hashrate increases the expected time is often more like 8 minutes). Other constraints like the minimum value for the time coded in blocks also contribute to making the timestamps have less diversity than you might expect from a first guess. In the case here, they're not even unusually closely timed the times on the four blocks in question are 12:24 13:02 13:12 13:11 (the prior one was 12:03). Note that the times aren't monotonic, which highlights a previously mentioned limitation in trying to reason about time; they're not all drawing from the same clock as there is no singular now in a decentralized system. I personally observed these blocks at the following times:
2015-05-02 12:25:21 UpdateTip: new best=00000000000000000f8d7a12d307ddc717cab90d2ced5c7320624a13714b0aa3 height=354640 log2_work=82.71737 tx=67422028 date=2015-05-02 12:24:26 progress=0.999999 cache=14812
2015-05-02 13:01:37 UpdateTip: new best=00000000000000000a1ebf23947c2dc38f980c66c1fd1303235326e36ea5afae height=354641 log2_work=82.717407 tx=67424094 date=2015-05-02 13:02:15 progress=1.000001 cache=9138
2015-05-02 13:05:29 UpdateTip: new best=00000000000000000f181b8cfb70624cd74bcac01c930657bd1bde85ff59e7fd height=354642 log2_work=82.717444 tx=67424677 date=2015-05-02 13:12:17 progress=1.000007 cache=10305
2015-05-02 13:08:46 UpdateTip: new best=000000000000000015c33a22604bd9c01806c3add1b33d6b8dd1e663da95cbd1 height=354643 log2_work=82.717481 tx=67425354 date=2015-05-02 13:11:28 progress=1.000003 cache=11807
So gaps of 36:16, 3:52, 3:17. Given a ~10 minute expected time about a third of blocks are 3:17 apart or less. |
|
|
|
|
|
valiron (OP)
|
|
May 03, 2015, 02:43:30 AM |
|
We never heard back of jl2012.
I guess he agrees that my argument wasn't fallacious. I withdraw most claims, but I stand by the claim that to see 144 times heads in 144 coin throws is very unlikely.
I will run some statistics on nounces. I am now very curious about their distribution. Anyone did study that before?
Is this kind of comment acceptable in the circles you normally travel in? If one of the people I worked with presented an argument of this form my response would be "Shame on you". Perhaps jl2012 has other things to do than click reload constantly and wade through the page and pages of untrimmed quotations in your message? Doubly so when it has been very clearly explained that your statistical argument is outright incorrect already by others. Miners do not select nonces uniformly for boring engineering reasons, this is a fact, it's the behavior of hardware sitting right next to me, it's easily observable on the blockchain. Your statistical argument is that IF nonces were uniform then it would be unlikely to see a run of similar ones. You do not correct for multiple comparisons (we've had some 354k possible runs of 4 for this to be true in), but most importantly you seem to strangely continue to ignore the fact that we know that various hardware does not uniformly select nonces; and instead you suggest this is evidence of your secret hypothesis. Why are you surprised that we reject your reasoning and instead question your motivations? The nonces here aren't even that close-- 2167965896, 2148513297, 2143118375, 2456983311 spans 7% of the nonce range... Since people seem to get caught up on the the analysis, perhaps a numerical example in python might simplify things for people:
import random
trys = 1000000
threshold = 2456983311 - 2143118375
small_rng = 0
for i in xrange(trys):
n = [random.randrange(0,2**32) for ii in xrange(4)]
small_rng += (max(n)-min(n))<=threshold
print("Out of %d tries, %d groups of 4 nonces were spanned a range equal or smaller than %d."%(trys,small_rng,threshold))
print("Since there are 144 blocks (thus 144 overlapping groups of 4)")
print("We'd expect to see this every %f days with _uniform_ nonces."%(1./(float(small_rng)/trys*144.)))
Which yields:
Out of 1000000 tries, 1524 groups of 4 nonces were spanned a range equal or smaller than 313864936.
Since there are 144 blocks (thus 144 overlapping groups of 4)
We'd expect to see this every 4.556722 days with _uniform_ nonces.
Since we also know existing hardware produces a subset of nonces we should probably expect these runs to be even more common than the above reflects. To get a feel for how non-uniformity changes this, switching to an RNG with a linear sloping probability, abs(random.randrange(0,2**32)-random.randrange(0,2**32)), increases the rate of these 'small' spans by about 2.8x. Without a reason to believe the exact criteria was established in advance instead of based on the data we should also probably be correcting for the fact that there are many other possible "patterns" people might find interesting and might use to claim support for some secret theory; e.g. ending with certain digits in some base, or being close mod 2^32, having digits that are cyclic shifts of each other in some base, being close by a larger but also 'small' threshold (E.g. the post originally claimed 6 blocks with a nonce span of 1856814243 which we'd expect to see a bit over 8 times per day.), or having some other simple arithmetic relation, etc. Dear Mr gmaxwell, Thank you for your interest and your simulation. I don't think your program does simulate what we want to study: It is not the probability of having 4 nounces in a 7% range, it is the probability of having 4 nounces with differences less than 1.8%, 0.12% and 7.2% respectively of the range in this order. Please, try it. You will see that the 0.12% counts for something important here. Usually in the circles I travel I am not accused of fallacius arguments that are not so...nor we need a computer program to compute the probability on your problem (it is just a 4-dimensional volume of a simplex). |
|
|
|
|
|
valiron (OP)
|
|
May 03, 2015, 03:01:00 AM |
|
I personally observed these blocks at the following times:
2015-05-02 12:25:21 UpdateTip: new best=00000000000000000f8d7a12d307ddc717cab90d2ced5c7320624a13714b0aa3 height=354640 log2_work=82.71737 tx=67422028 date=2015-05-02 12:24:26 progress=0.999999 cache=14812
2015-05-02 13:01:37 UpdateTip: new best=00000000000000000a1ebf23947c2dc38f980c66c1fd1303235326e36ea5afae height=354641 log2_work=82.717407 tx=67424094 date=2015-05-02 13:02:15 progress=1.000001 cache=9138
2015-05-02 13:05:29 UpdateTip: new best=00000000000000000f181b8cfb70624cd74bcac01c930657bd1bde85ff59e7fd height=354642 log2_work=82.717444 tx=67424677 date=2015-05-02 13:12:17 progress=1.000007 cache=10305
2015-05-02 13:08:46 UpdateTip: new best=000000000000000015c33a22604bd9c01806c3add1b33d6b8dd1e663da95cbd1 height=354643 log2_work=82.717481 tx=67425354 date=2015-05-02 13:11:28 progress=1.000003 cache=11807
So gaps of 36:16, 3:52, 3:17. Given a ~10 minute expected time about a third of blocks are 3:17 apart or less.
Interesting. Do you have statistics of time lags between your receiving time and block timestamps? How do they compare to the same statistics on other nodes? I guess by comparing timestamps on different nodes one can tell which miners and how much are using the malleability of timestamps. |
|
|
|
|
jl2012
Legendary
Offline
Activity: 1792
Merit: 1097
|
|
May 03, 2015, 03:25:01 AM |
|
We never heard back of jl2012.
I guess he agrees that my argument wasn't fallacious. I withdraw most claims, but I stand by the claim that to see 144 times heads in 144 coin throws is very unlikely.
I will run some statistics on nounces. I am now very curious about their distribution. Anyone did study that before?
I have no obligation to sit here and teach you basic statistics. This is the job of your stat teacher. Anyway, do the following homework: I'm not going to response before you finish the homework. |
Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
|
|
|
|
valiron (OP)
|
|
May 03, 2015, 03:28:24 AM |
|
Why is it always a conspiracy? Flip a quarter 100 million times, you'll eventually get heads 100 times in a row. Now flaw in the quarter, just as it's not a flaw that a few blocks get solved in a short period.
You need some serious probability classes around here. No offense please...it is a joke... If you flip a quarter 100 million times and the probability of getting sometime 100 times heads in a row is 10^8 / 2^100 x(10^8-100) =7.8 10^{-15} pretty small  In order to get heads 100 times in a row you need to flip your quarter about 10^22 times...my guess is that your quarter will disintegrate in the process... |
|
|
|
|
|
valiron (OP)
|
|
May 03, 2015, 03:33:33 AM |
|
We never heard back of jl2012.
I guess he agrees that my argument wasn't fallacious. I withdraw most claims, but I stand by the claim that to see 144 times heads in 144 coin throws is very unlikely.
I will run some statistics on nounces. I am now very curious about their distribution. Anyone did study that before?
I have no obligation to sit here and teach you basic statistics. This is the job of your stat teacher. Anyway, do the following homework: I'm not going to response before you finish the homework. Sorry, I don't understand your homework. Can you be more precise? On the other hand, can we agree that the probability of having independent 144 random variables taking values all below their mean value to be 1/2^144 ? Pretty small uuh? Did I do a good job on that? |
|
|
|
|
jl2012
Legendary
Offline
Activity: 1792
Merit: 1097
|
|
May 03, 2015, 03:41:55 AM |
|
We never heard back of jl2012.
I guess he agrees that my argument wasn't fallacious. I withdraw most claims, but I stand by the claim that to see 144 times heads in 144 coin throws is very unlikely.
I will run some statistics on nounces. I am now very curious about their distribution. Anyone did study that before?
I have no obligation to sit here and teach you basic statistics. This is the job of your stat teacher. Anyway, do the following homework: I'm not going to response before you finish the homework. Sorry, I don't understand your homework. Can you be more precise? On the other hand, can we agree that the probability of having independent 144 random variables taking values all below their mean value to be 1/2^144 ? Pretty small uuh? Did I do a good job on that? This is from you
We assume that nounces are uniformly distributed (not exactly true since if we start increasingly with nounce 0 they follow a Poisson law, but taking into account that nounce cycles many times before finding the solution it is well approximated by the uniform distribution). We look at distance mod 2^32.
|nounce(354641)-nounce(354640)| = 19.452.599 probability 19.452.599/(2^32-1)*2 = 1.8%
|nounce(354642)-nounce(354641)| = 5.394.922 probability 5.394.922/(2^32-1)*2 = 0.12%
|nounce(354642)-nounce(354641)| = 313.864.936 probability 313.864.936/(2^32-1)*2 =7.2%
Combined probability 0.000155% that is 1 in 645 161 times.
Now you are asked to do this: |nounce(200001)-nounce(200000)| = |2,860,276,919 - 4,158,183,488| = 1,297,906,569, probability = 1297906569/(2^32-1)*2 = 60.4% Repeat until block 200049 and multiply all the probabilities as you did |
Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4158
Merit: 8411
|
|
May 03, 2015, 04:02:32 AM
Last edit: May 03, 2015, 04:39:11 AM by gmaxwell |
|
Dear Mr gmaxwell,
Thank you for your interest and your simulation. I don't think your program does simulate what we want to study: It is not the probability of having 4 nounces in a 7% range, it is the probability of having 4 nounces with differences less than 1.8%, 0.12% and 7.2% respectively of the range in this order. Please, try it. You will see that the 0.12% counts for something important here.
Usually in the circles I travel I am not accused of fallacius arguments that are not so...nor we need a computer program to compute the probability on your problem (it is just a 4-dimensional volume of a simplex).
What is the probability, under uniform assumptions, of a single nonce being the specific value _2167965896_? It is one in four billion. And yet, there it is in block 354640--- a nonce with that specific value. Does this mean that I now have evidence for some theory in the forum of a one in four billion event? No. Because criteria of that specific value was selected after the fact based on the data, and so the probability of observing it is 1 and the information content of the observation is absolutely zero. Your suggested study is making the same form of reasoning, but this fact is somewhat hidden by the additional complexity-- yet it clearly was based on observing the data (your threshold are the exact differences in the data), rather than being based on some principle which set in advance and only after was it tested against the data. Putting that aside for a moment, even if I take your back-computed from the data 0.00015552% probability number (without order-- do you really demand ordering?-- if so, you're owed a stern lecture on fallacious arguments); with 354k blocks we would expect to see a 0.00015552%/block event about 55 times; and in the 25 days between your post immediately prior to creating this thread there would be a 42.87% chance of observing it at least once in that window; all with uniform nonce assumptions (obviously the non-uniform nonce reality make it more likely). I provided the program to cut through some noise; rather than arm-waving we've had in this thread the programs operation is clear, and can easily be tinkered with (e.g. as soon as you assume some non-uniform distribution, you must then integrate; much easier and safer to just twiddle the numeric code and get an approximate answer; especially once you start adding any non-linear hypothesis). Interesting. Do you have statistics of time lags between your receiving time and block timestamps? How do they compare to the same statistics on other nodes? I guess by comparing timestamps on different nodes one can tell which miners and how much are using the malleability of timestamps. "using the malleability of timestamps" There isn't any reason to assume from inconsistency of timestamps that miners are intentionally using their generally free control of the timestamps for much of anything. Large latencies in miner hardware/software/pooling (including avoiding bandwidth usage sending new midstates) contribute a lot of inaccuracy, but there is no such thing as a singular definition of time in a decentralized system; miners have their own clocks; they often only vaguely agree, the numbers are all over the place, they've always been more or less all over the place, and its not surprising. Every once in a while someone sees a block with a timestamp an hour in the future and they show up freaking out... its ordinary and not unexpected. As far as my timestamps; I'm reasonably well connected due to connecting to the block relay network. Stats, in seconds for the last 1295 blocks (which I'm reasonably confident is a generally uninterrupted observation), negative times are blocks 'from the future' according to my local timebase:
Min. 1st Qu. Median Mean 3rd Qu. Max.
-1539.000 10.000 26.000 1.989 44.000 1098.000
Absolute differences:
Min. 1st Qu. Median Mean 3rd Qu. Max.
0.00 19.00 34.00 63.73 57.50 1539.00
Stem-and-leaf plot shows that the extrema are outliers:
The decimal point is 2 digit(s) to the right of the |
-15 | 4
-14 |
-13 |
-12 |
-11 |
-10 |
-9 |
-8 | 3
-7 | 2110
-6 | 76430
-5 | 866631
-4 | 976633332211100
-3 | 99986433321000
-2 | 99999888666655444443333221000
-1 | 9999998888777765554443333222111110000000
-0 | 99999988888777777777666666555555555554444444444444433333333333333333+42
0 | 00000000000000000001111111111111111111111111111111111111111111111111+938
1 | 00011112222233334444555666677788899
2 | 02
3 |
4 | 5
5 |
6 |
7 |
8 |
9 |
10 | 1
11 | 0
A density chart of the (-120, 120):
+-------+-------------+-------------+-------------+------------+---------+
| *** |
| ** *** |
| * ** |
0.015 + * ** +
| * ** |
| ** ** |
| * * |
0.01 + * ** +
| * ** |
| ** ** |
| * ** |
| * ** |
0.005 + ** ** +
| * *** |
| ***** ***** |
| ********** * *** |
0 + ********************* ******** +
+-------+-------------+-------------+-------------+------------+---------+
-100 -50 0 50 100
|
|
|
|
|
|
Mt. Gox
|
|
May 03, 2015, 08:01:37 AM |
|
Why is it always a conspiracy? Flip a quarter 100 million times, you'll eventually get heads 100 times in a row. Now flaw in the quarter, just as it's not a flaw that a few blocks get solved in a short period.
You need some serious probability classes around here. No offense please...it is a joke... If you flip a quarter 100 million times and the probability of getting sometime 100 times heads in a row is 10^8 / 2^100 x(10^8-100) =7.8 10^{-15} pretty small In order to get heads 100 times in a row you need to flip your quarter about 10^22 times...my guess is that your quarter will disintegrate in the process... It's slightly more complicated as it involves Bayesian probability although you're close. A run of 20 heads is a roughly 1 in a million occurrence and the required rolls goes up exponentially the higher you get. For more information, see: http://www.drdobbs.com/architecture-and-design/20-heads-in-a-row-what-are-the-odds/229300217 |
Dear GOD/GODS and/or anyone else who can HELP ME (e.g. MEMBERS OF SUPER-INTELLIGENT ALIEN CIVILIZATIONS): The next time I wake up, please change my physical form to that of FINN MCMILLAN of SOUTH NEW BRIGHTON at 8 YEARS OLD and keep it that way FOREVER. I am so sick of this chubby Asian man body! Thank you! - CHAUL JHIN KIM (a.k.a. A DESPERATE SOUL) P.S. If anyone is reading this then please pray for me! [ www.chauljhin.com ] |
|
|
|
valiron (OP)
|
|
May 03, 2015, 10:16:25 AM
Last edit: May 03, 2015, 10:34:35 AM by valiron |
|
Dear Mr gmaxwell,
Thank you for your interest and your simulation. I don't think your program does simulate what we want to study: It is not the probability of having 4 nounces in a 7% range, it is the probability of having 4 nounces with differences less than 1.8%, 0.12% and 7.2% respectively of the range in this order. Please, try it. You will see that the 0.12% counts for something important here.
Usually in the circles I travel I am not accused of fallacius arguments that are not so...nor we need a computer program to compute the probability on your problem (it is just a 4-dimensional volume of a simplex).
What is the probability, under uniform assumptions, of a single nonce being the specific value _2167965896_? It is one in four billion. And yet, there it is in block 354640--- a nonce with that specific value. Does this mean that I now have evidence for some theory in the forum of a one in four billion event? No. Because criteria of that specific value was selected after the fact based on the data, and so the probability of observing it is 1 and the information content of the observation is absolutely zero. Your suggested study is making the same form of reasoning, but this fact is somewhat hidden by the additional complexity-- yet it clearly was based on observing the data (your threshold are the exact differences in the data), rather than being based on some principle which set in advance and only after was it tested against the data. Putting that aside for a moment, even if I take your back-computed from the data 0.00015552% probability number (without order-- do you really demand ordering?-- if so, you're owed a stern lecture on fallacious arguments); with 354k blocks we would expect to see a 0.00015552%/block event about 55 times; and in the 25 days between your post immediately prior to creating this thread there would be a 42.87% chance of observing it at least once in that window; all with uniform nonce assumptions (obviously the non-uniform nonce reality make it more likely). I provided the program to cut through some noise; rather than arm-waving we've had in this thread the programs operation is clear, and can easily be tinkered with (e.g. as soon as you assume some non-uniform distribution, you must then integrate; much easier and safer to just twiddle the numeric code and get an approximate answer; especially once you start adding any non-linear hypothesis). Ordering of the events "probability of closeness of consecutive nounces" should not be taken into account since this is an artificial restriction. The point is to see such a short streak of close consecutive nounces. The difference between ordering or not is multiplying by a factor of (n-1)! where n is the number of consecutive mined blocks. It is fairly irrelevant for the order of magnitude for 4 blocks but it is nonsense for a long streak as the one suggest jl2012. It will always be hard to see a predetermined pattern so that each consecutive pair is below a given threshold. It is exactly the same with the 144 coin flips I described. So, I guess we can agree that if nounces are uniformly distributed is not common to see consecutive nounces which are within 1.8%, 0.12%, 7.2% then this is 1 event in 107.527 and you will see it on average once every two years. This is just one unusual fact of several other independent coincidences in this streak of block validation. "Independent" only if the validation are not "miner related". The other "unusual" facts just multiply on this small probability to make this event ridiculously unlikely. I think it is relevant to ask some questions about this type of event (among many other that occur). You don't need to be a "conspiracy" theorist. I think the numbers show that it is a fair question. For the "nounce" equidistribution, we can do the numbers with the actual empirical historical distribution of nounces to see exactly by how much it changes the probabillities. Interesting. Do you have statistics of time lags between your receiving time and block timestamps? How do they compare to the same statistics on other nodes? I guess by comparing timestamps on different nodes one can tell which miners and how much are using the malleability of timestamps. "using the malleability of timestamps" There isn't any reason to assume from inconsistency of timestamps that miners are intentionally using their generally free control of the timestamps for much of anything. Large latencies in miner hardware/software/pooling (including avoiding bandwidth usage sending new midstates) contribute a lot of inaccuracy, but there is no such thing as a singular definition of time in a decentralized system; miners have their own clocks; they often only vaguely agree, the numbers are all over the place, they've always been more or less all over the place, and its not surprising. Every once in a while someone sees a block with a timestamp an hour in the future and they show up freaking out... its ordinary and not unexpected. As far as my timestamps; I'm reasonably well connected due to connecting to the block relay network. Stats, in seconds for the last 1295 blocks (which I'm reasonably confident is a generally uninterrupted observation), negative times are blocks 'from the future' according to my local timebase:
Min. 1st Qu. Median Mean 3rd Qu. Max.
-1539.000 10.000 26.000 1.989 44.000 1098.000
Absolute differences:
Min. 1st Qu. Median Mean 3rd Qu. Max.
0.00 19.00 34.00 63.73 57.50 1539.00
Stem-and-leaf plot shows that the extrema are outliers:
The decimal point is 2 digit(s) to the right of the |
-15 | 4
-14 |
-13 |
-12 |
-11 |
-10 |
-9 |
-8 | 3
-7 | 2110
-6 | 76430
-5 | 866631
-4 | 976633332211100
-3 | 99986433321000
-2 | 99999888666655444443333221000
-1 | 9999998888777765554443333222111110000000
-0 | 99999988888777777777666666555555555554444444444444433333333333333333+42
0 | 00000000000000000001111111111111111111111111111111111111111111111111+938
1 | 00011112222233334444555666677788899
2 | 02
3 |
4 | 5
5 |
6 |
7 |
8 |
9 |
10 | 1
11 | 0
A density chart of the (-120, 120):
+-------+-------------+-------------+-------------+------------+---------+
| *** |
| ** *** |
| * ** |
0.015 + * ** +
| * ** |
| ** ** |
| * * |
0.01 + * ** +
| * ** |
| ** ** |
| * ** |
| * ** |
0.005 + ** ** +
| * *** |
| ***** ***** |
| ********** * *** |
0 + ********************* ******** +
+-------+-------------+-------------+-------------+------------+---------+
-100 -50 0 50 100
What would be relevant would be to to compare your timestamps lags to other nodes and to see if the lagging timestamps are common for certain miners. You cannot deny that there is an advantage in using the timestamp field partly as nounce for mining. |
|
|
|
|
|
valiron (OP)
|
|
May 03, 2015, 10:30:17 AM
Last edit: May 03, 2015, 11:05:12 AM by valiron |
|
Why is it always a conspiracy? Flip a quarter 100 million times, you'll eventually get heads 100 times in a row. Now flaw in the quarter, just as it's not a flaw that a few blocks get solved in a short period.
You need some serious probability classes around here. No offense please...it is a joke... If you flip a quarter 100 million times and the probability of getting sometime 100 times heads in a row is 10^8 / 2^100 x(10^8-100) =7.8 10^{-15} pretty small In order to get heads 100 times in a row you need to flip your quarter about 10^22 times...my guess is that your quarter will disintegrate in the process... It's slightly more complicated as it involves Bayesian probability although you're close. A run of 20 heads is a roughly 1 in a million occurrence and the required rolls goes up exponentially the higher you get. For more information, see: http://www.drdobbs.com/architecture-and-design/20-heads-in-a-row-what-are-the-odds/229300217Your guy in the blog is enumerating all possibilities of coin flips. In order to have the actual probability for the problem it is much simpler: You start flipping your coin and you stop when you end up with a streak of n=100 or reach the maximum number of throws N=10^8. The starting point of your n=100 streak can be any point between 1 and N-100=10^8-100. The probability streak of n consecutive heads is 1/2^n and the probability to reach the k-throw is about 1 (it is 1-(prob of finding the streak before we reach k)) and this explains my formula, which is accurate except for the slight approximation. You only need the recursive analysis if n is much smaller (or N much larger). |
|
|
|
|
becoin
Legendary
Offline
Activity: 3431
Merit: 1233
|
|
May 03, 2015, 11:45:16 AM |
|
Why are people so ferociously attacked every time they say there are some unusual patterns in mining? Do we try to hide something disturbing? In my view valiron has a valid point. This deserves getting a closer look.
|
|
|
|
|
Foxpup
Legendary
Offline
Activity: 4354
Merit: 3044
Vile Vixen and Miss Bitcointalk 2021-2023
|
|
May 03, 2015, 12:36:52 PM |
|
Why are people so ferociously attacked every time they say there are some unusual patterns in mining?
They aren't. They're only ferociously attacked when they continue to say so after it is repeatedly explained to them why such patterns are, in fact, not unusual in the slightest. Do we try to hide something disturbing?
Only valiron does. He claims there's something wrong with the mining process but won't explain what. Nobody else is trying to hide it, whatever "it" is. In my view valiron has a valid point. This deserves getting a closer look.
He hasn't and it doesn't. |
Will pretend to do unspeakable things (while actually eating a taco) for bitcoins: 1K6d1EviQKX3SVKjPYmJGyWBb1avbmCFM4I am not on the scammers' paradise known as Telegram! Do not believe anyone claiming to be me off-forum without a signed message from the above address! Accept no excuses and make no exceptions! |
|
|
|
valiron (OP)
|
|
May 03, 2015, 02:55:13 PM |
|
Do we try to hide something disturbing?
Only valiron does. He claims there's something wrong with the mining process but won't explain what. Nobody else is trying to hide it, whatever "it" is. I withdrew any claim. So, stop repeating the same thing over and over. Already Mr gmaxwell rated me as a scammer (at the same level as other people having stolen bitcoins to others) and has tried to bullshit my expertise, which I think at this point says more about him than about me. But I do believe and I will repeat that some unusual patterns do deserve attention, in particular when the numbers show that these events are extremely rare. Without being paranoic it is conceivable that some people found a boost on the mining performance (it wouldn't be the first time this happens), and they try to hide it for their own interest. I fully agree that this possibility has to be treated with caution, but it cannot be ignored and we should be on the look up. If this appears to be the case at the end, some people in this forum will have collaborated concealing this fact. They will bear that responsibility. On my side I would restrict my comments to statistical facts. |
|
|
|
|
|
valiron (OP)
|
|
May 03, 2015, 03:08:16 PM
Last edit: May 03, 2015, 03:24:28 PM by valiron |
|
Why are people so ferociously attacked every time they say there are some unusual patterns in mining?
They aren't. They're only ferociously attacked when they continue to say so after it is repeatedly explained to them why such patterns are, in fact, not unusual in the slightest. Until further notice I believe it has been shown that the pattern detected can only appear every several years. For me this is unusual. Maybe not for you, maybe not for gmaxwell that claims from his knowledge that the odd distribution of nounces can be due to mining hardware. I am willing to believe that but I am waiting for the links to algorithms in the mining hardware that produce this type of bias in the nounces. If these links do not exist it means that these facts are not in the public knowledge. And the nounce is just one of the facts that make this sequence of validations unusual. A related question is: Are the algorithms in different ASICs in the public domain or are they proprietary? And then if they are not, I ask you guys asking for transparency if you didn't ask to the ASIC manufacturers for transparency. Did you? Where you as aggressive? Did the moderators label them as scammers for not revealing the inside proprietary algorithms? Or on the contrary were they allowed to advertise their products in the forum? |
|
|
|
|
|
valiron (OP)
|
|
May 03, 2015, 03:22:52 PM |
|
Why are people so ferociously attacked every time they say there are some unusual patterns in mining? Do we try to hide something disturbing? In my view valiron has a valid point. This deserves getting a closer look.
I also don't understand so much aggressivity. It is disturbing to say the least. If a charlatan comes to me and tells me that he has a 2 page proof of the Riemann Hypothesis, this doesn't really disturbs me much... I guess I will thank him and let him know that I will read his extraordinary proof... For the record: My conclusion is that the nounces produced by this miner are likely not independent and the mining procedure is not the usual one and it uses previous block computations or doesn't uses much the nounce variable.
But this is just one piece of evidence.
The second one, about the block size, also points to the fact that it is the same miner who mined the blocks. 731 kB blocks are quite common as noted earlier by someone else, but it is not
very likely either to find them consecutively. Moreover I bet that they cluster more often than expected and this can be checked running statistics on the blockchain.
The third piece of evidence is how close in time are these blocks. THe probability is not alarmingly small and can be computed by the Poisson distribution that follow times between blocks.
The fourth piece of evidence is the non-chronological timestamps that suggest that the timestap maleability is also used as nounce (this fact was already noted for blocks with only one transaction).
The fifth piece of evidence is that the first block is mined by AntPool and the next 3 by anonymous. It is not so common to have consecutive anonymous blocks,
This indicates that the miner is trying to hide that he is the same one mining.
|
|
|
|
|
|
smolen
|
|
May 03, 2015, 03:59:32 PM
Last edit: May 03, 2015, 04:16:33 PM by smolen |
|
I also don't understand so much aggressivity. It is disturbing to say the least.
Huh, you found nothing special in blockchain (yes, I could be wrong here) but the reaction to your post is very, very interesting. For reference: Redesign of bitcoin block headerPotentially faster method for mining on the CPUEDIT: Do we try to hide something disturbing?
Only valiron does. He claims there's something wrong with the mining process but won't explain what. Nobody else is trying to hide it, whatever "it" is. Did Sergio_Demian_Lerner published details about found attacks? Today is the third time I find an attack to the way Bitcoin uses SHA-256 to perform mining. Two of the attacks belong to a new family of attacks that involve terribly technical details about the inner workings of SHA-256. These are attacks that may impact on Bitcoin probably not before 5 years, and they could even never have a real impact on Bitcoin. I will talk openly about them when I can really tell if they could affect Bitcoin.
|
Of course I gave you bad advice. Good one is way out of your price range.
|
|
|
|
achow101_alt
|
|
May 03, 2015, 04:08:23 PM |
|
A related question is: Are the algorithms in different ASICs in the public domain or are they proprietary? And then if they are not, I ask you guys asking for transparency if you didn't ask to the ASIC manufacturers for transparency. Did you? Where you as aggressive? Did the moderators label them as scammers for not revealing the inside proprietary algorithms? Or on the contrary were they allowed to advertise their products in the forum?
The ASICs don't have algorithms per se to hash SHA256d. From what I understand, the ASIC chips are just a bunch of physical circuits that perform a SHA256 hash. These are mostly not public domain. I also thought that the nonces were determined by the software from the computer that the miner is connected to e.g. cgminer or bfgminer. These software are open source. |
|
|
|
|
virtualx
|
|
May 03, 2015, 04:30:22 PM |
|
A related question is: Are the algorithms in different ASICs in the public domain or are they proprietary? And then if they are not, I ask you guys asking for transparency if you didn't ask to the ASIC manufacturers for transparency. Did you? Where you as aggressive? Did the moderators label them as scammers for not revealing the inside proprietary algorithms? Or on the contrary were they allowed to advertise their products in the forum?
The ASICs don't have algorithms per se to hash SHA256d. From what I understand, the ASIC chips are just a bunch of physical circuits that perform a SHA256 hash. These are mostly not public domain. I also thought that the nonces were determined by the software from the computer that the miner is connected to e.g. cgminer or bfgminer. These software are open source. The algorithm to do the SHA256d could be in software but it does make sense to put the entire algorithm on the chip to have dedicated bitcoin mining hardware. |
...loteo...
DIGITAL ERA LOTTERY | ║
║
║ | | r |
▄▄███████████▄▄
▄███████████████████▄
▄███████████████████████▄
▄██████████████████████████▄
▄██ ███████▌ ▐██████████████▄
▐██▌ ▐█▀ ▀█ ▐█▀ ▀██▀ ▀██▌
▐██ █▌ █▌ ██ ██▌ ██▌ █▌ █▌ ██▌
▐█▌ ▐█ ▐█ ▐█▌ ▐██ ▄▄▄██ ▐█ ▐██▌
▐█ ██▄ ▄██ █▄ ██▄ ▄███▌
▀████████████████████████████▀
▀██████████████████████████▀
▀███████████████████████▀
▀███████████████████▀
▀▀███████████▀▀
| r | | ║
║
║ | RPLAY NOWR
BE A MOON VISITOR! |
[/center] |
|
|
crazyearner
Legendary
Offline
Activity: 1820
Merit: 1001
|
|
May 03, 2015, 04:54:20 PM |
|
Just pot luck with them blocks being mined had it myself when mining other tpyes of crypto mining shead loads blocks then a drout of mining and no blocks and then a burst of blocks. often not is just pure luck to get something like that happen. Having a lot of hash power does help too
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4158
Merit: 8411
|
|
May 03, 2015, 09:02:33 PM
Last edit: May 03, 2015, 09:19:03 PM by gmaxwell |
|
Until further notice I believe it has been shown that the pattern detected can only appear every several years. Did you not read and understand the point I made about your post-hoc rule selection? (First half of https://bitcointalk.org/index.php?topic=1045381.msg11268595#msg11268595) One cannot define rules after the fact that match the data then use that to argue that there was some improbable effect; e.g. "the last 4 nonces were 3091427529, 3627164536, 545428875, 138911025 ... what is the probability that those four specific nonces would arise in a row? 1/2^128!!!!!". No, the probability is _one_ because I picked the criteria out of blocks 354823, 354824, 354825, 354826. We learned _nothing_ from that observation. This works similarly for more complex tests, for example "A run of 4 nonces where exactly one of the 6 unique pairs constructable from the set doesn't have coprime nonces, and the non-coprime pair is the second and last nonce with a GCD of 3" is a rarely met criteria which also matches your data; but that doesn't mean there there is some evil almost-but-not-entirely-coprime conspiracy... or your differences between nonces test. The extra complexity doesn't make the reasoning any less fallacious, it just makes it harder for people to notice that its poorly reasoned. For me this is unusual. Maybe not for you, maybe not for gmaxwell that claims from his knowledge that the odd distribution of nounces can be due to mining hardware. I am willing to believe that but I am waiting for the links to algorithms in the mining hardware that produce this type of bias in the nounces. If these links do not exist it means that these facts are not in the public knowledge.
I explained specifically how and why miners select nonces non-uniformly-- I would ask if you missed the post, but you responded to it; https://bitcointalk.org/index.php?topic=1045381.msg11266349#msg11266349. You gave no indication that you were "waiting" on anything-- you even responded "This makes sense"--, if I didn't see this post would you just go ahead and declare default as you did earlier in this thread to jl2012? I've already wasted an incredible amount of time responding to you, but I won't make claims and fail to back them up if someone finds them implausible. However, you're not going to get a compact "algorithm" because there isn't a compact description for it, as the behavior is a product of the physical geometry of the part, random decisions decisions, and even the failed engines on particular chips; ranges are also truncated for load distribution across chips, and to control latency. The behavior is well known, documented in various data sheets (see, for example register 0x7f), and even sometimes used for device autodetection by some pools and mining software (Even for just mode detection, E.g. the icarus driver sends a dummy work task to the miner which was chosen to have 4 different solutions, and figures out what mode the chip is in based on which solution it returns). Historically, before extranonce rolling existed, nonce restrictions were used to reduce work on pools. Of course, it's not the _most_ commonly discussed thing; because its fundamentally uninteresting-- all nonces are equally good so if some device only uses some subset of them the response of an engineer working on software for them is just "okay, thanks for telling me.", they write it into their implementation, and they move on with life; they don't go and author a press release. And yes, reducing the range it results in some additional extranonce work, but extranonce work is trivial already-- a single cheap micocontroller can do the extranonce work for many TH/s of mining. And the nounce is just one of the facts that make this sequence of validations unusual. And what are your other _exact_ criteria? Please lay out the exact test you suggest which shows those blocks to be improbable in a single post in a list so there is no confusion... I've not seeing _anything_ exceptional about these blocks, excepting the fallacious post-hoc selection of criteria to exactly fit them around nonces. |
|
|
|
|
bitcoinbeliever
Newbie
Offline
Activity: 54
Merit: 0
|
|
May 03, 2015, 09:15:10 PM |
|
A node of mine received these blocks at the following times
2015-05-02 12:29:45 height=354640
2015-05-02 13:06:01 height=354641
2015-05-02 13:09:46 height=354642
2015-05-02 13:12:59 height=354643
2015-05-02 13:17:45 height=354644
meh.
|
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4158
Merit: 8411
|
|
May 03, 2015, 09:25:00 PM
Last edit: May 03, 2015, 10:39:21 PM by gmaxwell |
|
A node of mine received these blocks at the following times
As an aside-- I suspect your time is somewhat off, since there is basically a constant offset of a couple minutes between your and my numbers. (My clock is timed off a local atomic clock which is wsynced to UTC with a GPS timing receiver; it agrees with a remote stratum 1 NTP server by better than 1ms). meh. Indeed. |
|
|
|
|
lontivero
Full Member
Offline
Activity: 164
Merit: 128
Amazing times are coming
|
|
May 03, 2015, 11:49:14 PM |
|
I've already wasted an incredible amount of time responding to you
Clearly you did it but I don't believe it was in vain, the discussion have very useful information and many of us are learning from this. Furthermore, your explanations were absolutely necessary. |
|
|
|
|
|
inBitweTrust
|
|
May 04, 2015, 12:16:10 AM |
|
I've already wasted an incredible amount of time responding to you
Clearly you did it but I don't believe it was in vain, the discussion have very useful information and many of us are learning from this. Furthermore, your explanations were absolutely necessary. Agreed, there were a few new things I learned from gmaxwell's posts. He is a gentleman and scholar. What is amazing about Bitcoin is that there is so much information to absorb and so many nuances and developments that you really should approach it with a bit of humility. I learn something new almost everyday. |
|
|
|
|
valiron (OP)
|
|
May 04, 2015, 12:55:18 AM
Last edit: May 04, 2015, 01:25:02 AM by valiron |
|
I also don't understand so much aggressivity. It is disturbing to say the least.
Huh, you found nothing special in blockchain (yes, I could be wrong here) but the reaction to your post is very, very interesting. For reference: Redesign of bitcoin block headerPotentially faster method for mining on the CPUEDIT: Do we try to hide something disturbing?
Only valiron does. He claims there's something wrong with the mining process but won't explain what. Nobody else is trying to hide it, whatever "it" is. Did Sergio_Demian_Lerner published details about found attacks? Today is the third time I find an attack to the way Bitcoin uses SHA-256 to perform mining. Two of the attacks belong to a new family of attacks that involve terribly technical details about the inner workings of SHA-256. These are attacks that may impact on Bitcoin probably not before 5 years, and they could even never have a real impact on Bitcoin. I will talk openly about them when I can really tell if they could affect Bitcoin.
Thank you for the links. The second link hints at something but it is not implementable as described (this is well known to any cryptographer and I am not hinting at any secret knowledge. If workable as described it could be used to find collisions of the hashing algorithm). If I understand properly Sergio Demian states the weakness of the current mining algorithm and proposes a partial solution modifying the block headers. So, since this information is in a public blog, this weakness, or people claiming it, is also public knowledge, thus there is no reason any one gets mad when someone mentions it. Right? |
|
|
|
|
|
valiron (OP)
|
|
May 04, 2015, 12:57:24 AM |
|
A related question is: Are the algorithms in different ASICs in the public domain or are they proprietary? And then if they are not, I ask you guys asking for transparency if you didn't ask to the ASIC manufacturers for transparency. Did you? Where you as aggressive? Did the moderators label them as scammers for not revealing the inside proprietary algorithms? Or on the contrary were they allowed to advertise their products in the forum?
The ASICs don't have algorithms per se to hash SHA256d. From what I understand, the ASIC chips are just a bunch of physical circuits that perform a SHA256 hash. These are mostly not public domain. I also thought that the nonces were determined by the software from the computer that the miner is connected to e.g. cgminer or bfgminer. These software are open source. The algorithm to do the SHA256d could be in software but it does make sense to put the entire algorithm on the chip to have dedicated bitcoin mining hardware. Is it the case? |
|
|
|
|
|
valiron (OP)
|
|
May 04, 2015, 01:17:22 AM
Last edit: May 04, 2015, 01:51:01 AM by valiron |
|
Until further notice I believe it has been shown that the pattern detected can only appear every several years. Did you not read and understand the point I made about your post-hoc rule selection? (First half of https://bitcointalk.org/index.php?topic=1045381.msg11268595#msg11268595) One cannot define rules after the fact that match the data then use that to argue that there was some improbable effect; e.g. "the last 4 nonces were 3091427529, 3627164536, 545428875, 138911025 ... what is the probability that those four specific nonces would arise in a row? 1/2^128!!!!!". No, the probability is _one_ because I picked the criteria out of blocks 354823, 354824, 354825, 354826. We learned _nothing_ from that observation. This works similarly for more complex tests, for example "A run of 4 nonces where exactly one of the 6 unique pairs constructable from the set doesn't have coprime nonces, and the non-coprime pair is the second and last nonce with a GCD of 3" is a rarely met criteria which also matches your data; but that doesn't mean there there is some evil almost-but-not-entirely-coprime conspiracy... or your differences between nonces test. The extra complexity doesn't make the reasoning any less fallacious, it just makes it harder for people to notice that its poorly reasoned. You are manipulating and you know it. Let me formulate this in a different manner: What would you consider out of normal for the proximity of the nounces of consecutive blocks? For example, 100 consecutive blocks with nounces nearby 1% of their range would this be out of normal to you? If it is (as for 99.99% of normal people), how would you go about proving that is out of normal? Won't you compute the probability of seeing this occurence? But then it will be fallacious according to your comment since it is "after the fact"!!! Nonsense!! Otherwise empirical knowledge won't exist!! Come on....what is not allowed is to pick an artificial or stupid complicate criteria. To look at nounce dispersion is natural. For me this is unusual. Maybe not for you, maybe not for gmaxwell that claims from his knowledge that the odd distribution of nounces can be due to mining hardware. I am willing to believe that but I am waiting for the links to algorithms in the mining hardware that produce this type of bias in the nounces. If these links do not exist it means that these facts are not in the public knowledge.
I explained specifically how and why miners select nonces non-uniformly-- I would ask if you missed the post, but you responded to it; https://bitcointalk.org/index.php?topic=1045381.msg11266349#msg11266349. You gave no indication that you were "waiting" on anything-- you even responded "This makes sense"--, if I didn't see this post would you just go ahead and declare default as you did earlier in this thread to jl2012? I've already wasted an incredible amount of time responding to you, but I won't make claims and fail to back them up if someone finds them implausible. However, you're not going to get a compact "algorithm" because there isn't a compact description for it, as the behavior is a product of the physical geometry of the part, random decisions decisions, and even the failed engines on particular chips; ranges are also truncated for load distribution across chips, and to control latency. The behavior is well known, documented in various data sheets (see, for example register 0x7f), and even sometimes used for device autodetection by some pools and mining software (Even for just mode detection, E.g. the icarus driver sends a dummy work task to the miner which was chosen to have 4 different solutions, and figures out what mode the chip is in based on which solution it returns). Historically, before extranonce rolling existed, nonce restrictions were used to reduce work on pools. Of course, it's not the _most_ commonly discussed thing; because its fundamentally uninteresting-- all nonces are equally good so if some device only uses some subset of them the response of an engineer working on software for them is just "okay, thanks for telling me.", they write it into their implementation, and they move on with life; they don't go and author a press release. And yes, reducing the range it results in some additional extranonce work, but extranonce work is trivial already-- a single cheap micocontroller can do the extranonce work for many TH/s of mining. Thanks for the links. I will take the time to study them. It is a bit disappointing that there are no technical description of the inner working of ASICs or more precise description how miners work. And the nounce is just one of the facts that make this sequence of validations unusual. And what are your other _exact_ criteria? Please lay out the exact test you suggest which shows those blocks to be improbable in a single post in a list so there is no confusion... I've not seeing _anything_ exceptional about these blocks, excepting the fallacious post-hoc selection of criteria to exactly fit them around nonces. I guess you missed this post: For the record: My conclusion is that the nounces produced by this miner are likely not independent and the mining procedure is not the usual one and it uses previous block computations or doesn't uses much the nounce variable.
But this is just one piece of evidence.
The second one, about the block size, also points to the fact that it is the same miner who mined the blocks. 731 kB blocks are quite common as noted earlier by someone else, but it is not
very likely either to find them consecutively. Moreover I bet that they cluster more often than expected and this can be checked running statistics on the blockchain.
The third piece of evidence is how close in time are these blocks. THe probability is not alarmingly small and can be computed by the Poisson distribution that follow times between blocks.
The fourth piece of evidence is the non-chronological timestamps that suggest that the timestap maleability is also used as nounce (this fact was already noted for blocks with only one transaction).
The fifth piece of evidence is that the first block is mined by AntPool and the next 3 by anonymous. It is not so common to have consecutive anonymous blocks,
This indicates that the miner is trying to hide that he is the same one mining.
We can compute/estimate the probability of all the other "pieces of evidence" that are independent events with small probabilities. What is astonishing is the coincidence of all these facts. I believe they prove that all 4 blocks were mined by the same miner (then these facts would not be independent and it makes more sense that they occur simultaneously). Let me ask you something simple: Do you think these four blocks were mined by the same miner? Finally, I remind you what you wrote: https://bitcointalk.org/index.php?action=trust;u=30991Accordingly; I'll remove this negative rating (or downgrade it to neutral) when Valiron either retracts or substantiates his position. I have retracted and erased all claims. I wait for your gentleman's word of removing your negative rating. (also, I understood that the forum "Trust system" is for trading (since the first thing you see is "Trade with extreme caution!"). I doesn't seem to be designed to be used for academic discrepancy. I haven't traded anything with you, and everybody with whom I have traded are 100% satisfied. I would appreciate that you don't use your trustworthy position in order to discredit me for disagreeing academically with you. Moreover your comments "I suspect Valiron is either trying to scam someone out of paying for his "knowledge" or that he is attempting to manipulate the market price of Bitcoin; " are diffamatory and without ground. Also it is ridiculous to pretend that I can manipulate the market by discussing anomalies in the block validations! I believe that the bitcoin market is a bit more robust...). |
|
|
|
|
|
smolen
|
|
May 04, 2015, 02:10:46 AM |
|
If I understand properly Sergio Demian states the weakness of the current mining algorithm and proposes a partial solution modifying the block headers. So, since this information is in a public blog, this weakness, or people claiming it, is also public knowledge, thus there is no reason any one gets mad when someone mentions it. Right?
I was unable to reconstruct suspected vulnerability from proposed defense. The discussion in the linked thread was mostly about compatibility, not about cryptography. Also, new Sergio's idea about approximation of double SHA256 is not discussed here, as well as his guess about Satoshi using Gray code optimization for early mining. Strange. |
Of course I gave you bad advice. Good one is way out of your price range.
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4158
Merit: 8411
|
|
May 04, 2015, 03:08:31 AM |
|
If I understand properly Sergio Demian states the weakness of the current mining algorithm and proposes a partial solution modifying the block headers. So, since this information is in a public blog, this weakness, or people claiming it, is also public knowledge, thus there is no reason any one gets mad when someone mentions it. Right?
I mentioned it non-specifically in my first response in this thread; (actually some things even more powerful than that). The objection was always the claim of "secret" knowledge supposedly supported by these very non-specifically identified blocks. Sergio actually described the optimizations he was talking about; as have a great many people. Not said they were keeping them secret and then "oh yea that" when other people play guessing games with other already known optimizations (which there have been easily a dozen discussed over the years); especially not using alarming words like "premining" (which is a term used for a oft-perceived dishonest move in pump-and-dump altcoins). |
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4158
Merit: 8411
|
|
May 04, 2015, 04:53:35 AM
Last edit: May 04, 2015, 08:09:45 AM by gmaxwell |
|
You are manipulating and you know it.
I'm not, I am making the most simplistic of statistical arguments against a logical fallacy. To say it technically you've adopted a model so complex that we cannot tell if you've overfit and can not reject the null hypothesis. I can demonstrate this another way; lets take your proposed tests: "having 4 nounces with differences less than 1.8%, 0.12% and 7.2% respectively of the range in this order." "the block size, also points to the fact that it is the same miner who mined the blocks. 731 kB blocks are quite common as noted earlier by someone else, but it is not very likely either to find them consecutively. " you haven't given a numerical threshold, so I'll just take that to be sizes within 10% "The third piece of evidence is how close in time are these blocks."-- they're not actually unusually close, given hashrate changes, but I'll apply the softer limit of allow below 10 minutes. "The fourth piece of evidence is the non-chronological timestamps " -- these are also fairly common through Bitcoin's history; but I'll go ahead and apply it too. "The fifth piece of evidence is that the first block is mined by AntPool and the next 3 by anonymous." -- I can't mechanically apply this one, since it's just bc.i's opinion; but as you'll see leaving out a constraint only aids your argument now. This is your test for a specific non-disclosed mining optimization. Since you won't disclose the optimization I cannot argue with that point, though it sounds implausibly over-complex. Now we're going to ask the related question: "How much of the network is using the optimization identified by this test?"; There are _no_ there matches in the blockchain meeting that criteria other than the single range you've named. What should we then assume the proportion of hashrate using your optimization is? Approximately 0. If it is (as for 99.99% of normal people), how would you go about proving that is out of normal? Won't you compute the probability of seeing this occurence?
But then it will be fallacious according to your comment since it is "after the fact"!!!
Nonsense!! Otherwise empirical knowledge won't exist!! It's well established that normal people routinely engage in completely defective statistical reasoning. Statistics are unintuitive to people, virtually everyone finds qualitative reasoning more intuitive than quantitative reasoning. An ideal way to reason about things is to first understand the process; form a hypothesis and from the hypothesis develop a model without looking at the data: "If vulnerability X is being exploited I will see blocks of with structures and probabilities X, if X is not exploited I will see blocks with structures and probabilities !X". You can then ask what the KL divergence of these two distributions are, and if it is very small then you will gain almost no confidence even with many observations; the question may be undecidable. If there is a separation between the probabilities then observations one can then apply a statical test to reject one alternative or another with a intentional level of chance of error. An example of this would be "From the structure of SHA256, and the fact that the 80 byte input requires two runs of the compression function; someone could create slightly more efficient specialized hardware which hardcodes much of the message expansion and initial rounds from the second compression function run-- and scans by rolling the block version. If this optimization were at play I would expect to find that the block version would have very high entropy, perhaps 32 bits though anything more than a few bits would be suspicious; blocks exploiting this behavior would be expected to have uniform version numbers, rather than a constant in non-exploiting blocks" We could then apply this test to the blockchain, and because of the big gap between two cases we could decide pretty quickly if the test was indicating. This isn't a definitive test; there could be other reasons for the strange behavior, like miners trying to reduce their network bandwidth usage; we could try to make it more specific by adding a rule like "and we expect blocks with random versions to have nonces with far less entropy". ---- unfortunately, keeping the reasoning private prevents that kind of thoughtful analysis; all we can go on is how "weird" blocks are in the absence of a reasoned model, and thats not very useful since every block is "weird" by some definition. Its like if you look for the number 11 you'll find it everywhere. Sometimes there are free parameters-- we want to ask a question like "does weight over some threshold cause heart attacks? and if so what is that threshold?", without knowing the parameter in advance. This had the danger of fitting the model to the data and telling us nothing at all (like my example of "predicting" the nonces that just happened); one tool used to address this problem with parametric models is cross validation: You split your observations up and use one subset to train the model and the other to test. If the effectiveness goes away during cross-validation the model is likely overfit. The protection isn't perfect because if you tweak the scheme based on the results you miss overfitting the "meta"-parameters.. This is effectively the test I applied above: You fit a model (a set of gap differences, block timstamps, inter-arrival times) and I excluded a single hit which you appear to have used to set your parameters from the testing set and found your model matched _no_ blocks at all. Come on....what is not allowed is to pick an artificial or stupid complicate criteria. To look at nounce dispersion is natural. What shouldn't be allowed is bad statistical reasoning, which can happen no matter how "natural" your model is, what primarily matters is how many degrees of freedom it has. What you are looking at there is _not_ dispersion; I tried to give you the benefit of the doubt and assume you meant one of the standard metrics for dispersion (_range_) and you insisted on a complex polytope shape constraint; with probably something on the order of 34 bits of parameter space (three percentages to 0.1 precision without permutation), plus some more model freedom in that its looking at differences instead of absolute values. If I instead use the standard deviation (another common dispersion metric) we that 0.1875% of 4-block sets (given uniform nonces) would have a standard deviation as low as your selected one; so again, something we'd see every few days. or more precise description how miners work. There is huge amounts of information; everything is open source except for the RTL and mask images of common hardware; though most follow not too far from prior FPGA designs in their overall structure. Let me ask you something simple: Do you think these four blocks were mined by the same miner? It appears unlikely, all four are miners that appear to constantly reuse a static address for their income, but they're each different. Walletexplorer does an overly aggressive 'taint' analysis and links many addresses to each, but they're disjoint. The lowest number appears to be antpool, the next appears to be AnxPro.com, the next is likely Polmine.pl (it frequently pays addresses connected with polmine.pl). We can compute/estimate the probability of all the other "pieces of evidence" that are independent events with small probabilities. What is astonishing is the coincidence of all these facts.
There is nothing astonishing that when you pick criteria to fit the data, you find that it fits the data. There is also nothing astonishing that when a model created this way seems unlikely on a uniform basis that it will fail to generalize to anything but the data you fit it on. I believe they prove that all 4 blocks were mined by the same miner (then these facts would not be independent and it makes more sense that they occur simultaneously). Great; so you'll accept concrete proof that these blocks were mined by independent parties as a definitive proof that you were incorrect? I have retracted and erased all claims. I wait for your gentleman's word of removing your negative rating.
(also, I understood that the forum "Trust system" is for trading (since the first thing you see is "Trade with extreme caution!"). I doesn't seem to be designed to be used for academic discrepancy.
I'm having a hard time figuring out what you mean by retracted and erased; your posts in this thread continue to claim "It is clear that someone found a trick for fast mining. I kind of happen to know what might be.", "It is premining at some extend. Won't disclose more for the moment." and so on. You continue to hold that you have "secret" knowledge which you will not disclose so that it can be discussed on its merits or lack thereof-- this entire thread is a great big advertisement for this claim and seems to have served you little other purpose; which the experienced professionals on this forum find to be non-credible and not supported by the evidence you've presented. I haven't traded anything with you, and everybody with whom I have traded are 100% satisfied. I would appreciate that you don't use your trustworthy position in order to discredit me for disagreeing academically with you.
Moreover your comments "I suspect Valiron is either trying to scam someone out of paying for his "knowledge" or that he is attempting to manipulate the market price of Bitcoin; " are diffamatory and without ground. Also it is
ridiculous to pretend that I can manipulate the market by discussing anomalies in the block validations! I believe that the bitcoin market is a bit more robust...).
As I explained privately, your behavior so far is indistinguishable from a person who is willfully and fraudulently claiming to know of non-public mining optimizations in the hope of selling them to some greedy sucker who is unable to assess their merit except on the your misleading qualitative claim that the blocks look 'weird'. Protecting the forum's participants from being deceived themselves or from suffering the traffic from a flood of hopeful scammers demands that we call it out when we see the potential of it-- I say this not as the subfourm moderator or a developer of the Bitcoin system, but just as a community member... There is plenty of room for doubt; I'd say it's even more likely that you're just confused by the statistics of it, but the benefit of doubt can't be given freely, since those looking to exploit people will just sail through that opening. I offered you a simple mechanism which you can use to distinguish yourself-- share your complete theory with (ideally) the thread or privately with a respected member of the community; in doing so you gain the ability to refine it against the forge of experience, discover what (if any) parts are already known; and, in the possibility that there is something to be concerned about, gain the ability to protect Bitcoin from any potential harm if required. (I think you greatly underestimate the potential harm of privately held substantial mining optimizations-- beyond some threshold they would result in the complete centralization of the bitcoin system) The forum trust is a metric of trust; I explained in the rating where the distrust comes from. Your claims here are not credible to any of the subject matter experts and as far as we can tell they're based on erroneous statistical reasoning, you're shielding your theories from criticism by hiding behind secrecy, forcing a debate around statistical minutia and how "weird" the blocks feel qualitatively, rather than the merits of your idea. Only a few weeks ago you were asking questions (using asics to hash files) that showed a profound lack of research and understanding of Bitcoin mining. I want to be sure someone considering trading with you over these ideas is aware that other community members do not currently consider your claims credible or likely to be well founded. Anyone is free to read the rating and come to their own conclusions. I'm sorry that you find it heavy-handed. I would prefer if there were a way to make ratings which were more targeted or conditional. In consideration of this, I'll go and reduce it to neutral to avoid triggering the red flag on you. I am not seeking to cause you distress. |
|
|
|
|
|
valiron (OP)
|
|
May 04, 2015, 08:16:23 AM
Last edit: May 04, 2015, 08:30:26 AM by valiron |
|
You are manipulating and you know it.
I'm not, I am making the most simplistic of statistical arguments against a logical fallacy. To say it technically you've adopted a model so complex that we cannot tell if you've overfit and can not reject the null hypothesis. I can demonstrate this another way; lets take your proposed tests: "having 4 nounces with differences less than 1.8%, 0.12% and 7.2% respectively of the range in this order." "the block size, also points to the fact that it is the same miner who mined the blocks. 731 kB blocks are quite common as noted earlier by someone else, but it is not very likely either to find them consecutively. " you haven't given a numerical threshold, so I'll just take that to be sizes within 10% "The third piece of evidence is how close in time are these blocks."-- they're not actually unusually close, given hashrate changes, but I'll apply the softer limit of allow below 10 minutes. "The fourth piece of evidence is the non-chronological timestamps " -- these are also fairly common through Bitcoin's history; but I'll go ahead and apply it too. "The fifth piece of evidence is that the first block is mined by AntPool and the next 3 by anonymous." -- I can't mechanically apply this one, since it's just bc.i's opinion; but as you'll see leaving out a constraint only aids your argument now. This is your test for a specific non-disclosed mining optimization. Since you won't disclose the optimization I cannot argue with that point, though it sounds implausibly over-complex. Now we're going to ask the related question: "How much of the network is using the optimization identified by this test?"; There are _no_ there matches in the blockchain meeting that criteria other than the single range you've named. What should we then assume the proportion of hashrate using your optimization is? Approximately 0. You will agree that this facts are independent by themselves. You will agree that they happen rarely with a small probability. The probability of seeing them simultaneously is small. You add: "This is your test for a specific non-disclosed mining optimization." No, it is not. This is my test to detect that something out of normal is happening. Don't insist on this line. I have withdraw any claim about mining optimization. Why are you insisting into something that I won't discuss? If it is (as for 99.99% of normal people), how would you go about proving that is out of normal? Won't you compute the probability of seeing this occurence?
But then it will be fallacious according to your comment since it is "after the fact"!!!
Nonsense!! Otherwise empirical knowledge won't exist!! It's well established that normal people routinely engage in completely defective statistical reasoning. Statistics are unintuitive to people, virtually everyone finds qualitative reasoning more intuitive than quantitative reasoning. I did ask a very simple question and you are unable to answer it in simple form: "how would you go about proving that this is out of normal?". Let me rephrase: What is sufficient evidence to infer that something out of your knownledge is going on? This is a question that ask working scientists ask themselves all the time. What you do is to explain that in order to detect something out of normal going on you need to have a working hypothesis. This would be great but it is not always the case. Indeed most of the time is not the case. For example, astronomers detected anomalies provoked by Pluton before knowing its existence, or noticed the advance of the perihelion of Mercury well before having a clue about General Relativity. So, from what you tell, for you to see 100 nounces in consecutive blocks won't be out of normal? How many do you need? 1.000? 10.000? And then how will you go about proving that this is anomalous? i.e. what will be your test? Very simple question to which you don't provide a simple answer. From what you tell you seem to refuse that there is any anomaly if you don't have a working hypothesis (!). I guess that that's exclusively your problem. On top of that you deny anyone else the possibility of inferring that something out of normal is going on, even when confronted with ridiculous probabilities. This seems to me pretty short sighted. An ideal way to reason about things (...)
There is no "ideal way to reason about thing". We reason with what we have and observe and we cannot choose it. (...)is to first understand the process;
Yea...so astronomers noticing the advance of the Mercury perihelion would be treated as sacrilegious...or those noticing the heliocentric system will be accused of heresy..."Eppur si muove"... form a hypothesis and from the hypothesis develop a model without looking at the data: "If vulnerability X is being exploited I will see blocks of with structures and probabilities X, if X is not exploited I will see blocks with structures and probabilities !X". You can then ask what the KL divergence of these two distributions are, and if it is very small then you will gain almost no confidence even with many observations; the question may be undecidable. If there is a separation between the probabilities then observations one can then apply a statical test to reject one alternative or another with a intentional level of chance of error.
An example of this would be "From the structure of SHA256, and the fact that the 80 byte input requires two runs of the compression function; someone could create slightly more efficient specialized hardware which hardcodes much of the message expansion and initial rounds from the second compression function run-- and scans by rolling the block version. If this optimization were at play I would expect to find that the block version would have very high entropy, perhaps 32 bits though anything more than a few bits would be suspicious; blocks exploiting this behavior would be expected to have uniform version numbers, rather than a constant in non-exploiting blocks" We could then apply this test to the blockchain, and because of the big gap between two cases we could decide pretty quickly if the test was indicating. This isn't a definitive test; there could be other reasons for the strange behavior, like miners trying to reduce their network bandwidth usage; we could try to make it more specific by adding a rule like "and we expect blocks with random versions to have nonces with far less entropy". ---- unfortunately, keeping the reasoning private prevents that kind of thoughtful analysis; all we can go on is how "weird" blocks are in the absence of a reasoned model, and thats not very useful since every block is "weird" by some definition. Its like if you look for the number 11 you'll find it everywhere.
Obviously we can make such assumptions with more knowledge. Let me try something that can pass your censorship: I guess we agree that the main variable for mining a block is the header of the (double) hash of the previous block. If you knew the hash in advance you would be able to premine the block. By "premine" I mean doing most of the computation work well in advance (nothing spurious suggested by "premine", just "pre"-doing the work). The Merkel root tree hash can be kept static except maybe for impact of the extranounce (for example when you mine 1 transaction blocks). You will agree that someone with a performing mining algorithm will have a lot of advantage by witholding mined blocks in order to speed up the mining of the next ones and then releasing them in a short time. leading to sequences of nearby mined blocks. If he wants to conceal this fact he will mine the blocks anonymously (or with another miner that he controls). This means that we have to pay particular attentiion to close by mined blocks of anonymous origin. And we have to pay special attention to similarities that can reveal that the same miner is behind these blocks (in our case, nearby nounces could indicate similar hardware, or same block size similar algorithms). Sometimes there are free parameters-- we want to ask a question like "does weight over some threshold cause heart attacks? and if so what is that threshold?", without knowing the parameter in advance. This had the danger of fitting the model to the data and telling us nothing at all (like my example of "predicting" the nonces that just happened); one tool used to address this problem with parametric models is cross validation: You split your observations up and use one subset to train the model and the other to test. If the effectiveness goes away during cross-validation the model is likely overfit. The protection isn't perfect because if you tweak the scheme based on the results you miss overfitting the "meta"-parameters.. This is effectively the test I applied above: You fit a model (a set of gap differences, block timstamps, inter-arrival times) and I excluded a single hit which you appear to have used to set your parameters from the testing set and found your model matched _no_ blocks at all. Come on....what is not allowed is to pick an artificial or stupid complicate criteria. To look at nounce dispersion is natural. What shouldn't be allowed is bad statistical reasoning, which can happen no matter how "natural" your model is, what primarily matters is how many degrees of freedom it has. What you are looking at there is _not_ dispersion; I tried to give you the benefit of the doubt and assume you meant one of the standard metrics for dispersion (_range_) and you insisted on a complex polytope shape constraint; with probably something on the order of 34 bits of parameter space (three percentages to 0.1 precision without permutation), plus some more model freedom in that its looking at differences instead of absolute values. If I instead use the standard deviation (another common dispersion metric) we that 0.1875% of 4-block sets (given uniform nonces) would have a standard deviation as low as your selected one; so again, something we'd see every few days. Could you cut this short, don't divagate, and just let us know how you will proceed in order to prove that a sequence of nearby consecutive nounces is out of normal? How many nounces and with what proximity your criteria will show that they are our of normal? I have provided my answer on this. We are still waiting yours. Your answer must contain a number and a % proximity. For me n=3 events and a geometric mean of prob of the order of 1% starts to trigger my interest, and light a red flag if this occurs combined with other unusual coincidences. or more precise description how miners work. There is huge amounts of information; everything is open source except for the RTL and mask images of common hardware; though most follow not too far from prior FPGA designs in their overall structure. Can you point to relevant threads in the forum? Let me ask you something simple: Do you think these four blocks were mined by the same miner? It appears unlikely, all four are miners that appear to constantly reuse a static address for their income, but they're each different. Walletexplorer does an overly aggressive 'taint' analysis and links many addresses to each, but they're disjoint. The lowest number appears to be antpool, the next appears to be AnxPro.com, the next is likely Polmine.pl (it frequently pays addresses connected with polmine.pl). We can compute/estimate the probability of all the other "pieces of evidence" that are independent events with small probabilities. What is astonishing is the coincidence of all these facts.
There is nothing astonishing that when you pick criteria to fit the data, you find that it fits the data. There is also nothing astonishing that when a model created this way seems unlikely on a uniform basis that it will fail to generalize to anything but the data you fit it on. I believe they prove that all 4 blocks were mined by the same miner (then these facts would not be independent and it makes more sense that they occur simultaneously). Great; so you'll accept concrete proof that these blocks were mined by independent parties as a definitive proof that you were incorrect? It would be great to prove that this miners are distinct and independent, but they may be collaborating. Event if these miners are independent they may be using the same algorithm that produces similar output. In any case it won't prove that what we have seen is a rare event, it will give evidence that is pure coincidence. I have retracted and erased all claims. I wait for your gentleman's word of removing your negative rating.
(also, I understood that the forum "Trust system" is for trading (since the first thing you see is "Trade with extreme caution!"). I doesn't seem to be designed to be used for academic discrepancy.
I'm having a hard time figuring out what you mean by retracted and erased; your posts in this thread continue to claim "It is clear that someone found a trick for fast mining. I kind of happen to know what might be.", "It is premining at some extend. Won't disclose more for the moment." and so on. You continue to hold that you have "secret" knowledge which you will not disclose so that it can be discussed on its merits or lack thereof-- this entire thread is a great big advertisement for this claim and seems to have served you little other purpose; which the experienced professionals on this forum find to be non-credible and not supported by the evidence you've presented. You are wrong. I have retracted and erased all comments (if I have overlooked any, please let me know), in particular those that you quote (where did you get the quote?). Obviously I cannot erase people quoting me. You should ask them. I haven't traded anything with you, and everybody with whom I have traded are 100% satisfied. I would appreciate that you don't use your trustworthy position in order to discredit me for disagreeing academically with you.
Moreover your comments "I suspect Valiron is either trying to scam someone out of paying for his "knowledge" or that he is attempting to manipulate the market price of Bitcoin; " are diffamatory and without ground. Also it is
ridiculous to pretend that I can manipulate the market by discussing anomalies in the block validations! I believe that the bitcoin market is a bit more robust...).
As I explained privately, your behavior so far is indistinguishable from a person who is willfully and fraudulently claiming to know of non-public mining optimizations in the hope of selling them to some greedy sucker who is unable to asset their merit except on the your misleading qualitative claim that the blocks look 'weird'. Protecting the forum's participants from being deceived themselves or from suffering the traffic from a flood of hopeful scammers demands that we call it out when we see the potential of it-- I say this not as the subfourm moderator or a developer of the Bitcoin system, but just as a community member... There is plenty of room for doubt; I'd say it's even more likely that you're just confused by the statistics of it, but the benefit of doubt can't be given freely, since those looking to exploit people will just sail through that opening. I offered you a simple mechanism which you can use to distinguish yourself-- share your complete theory with (ideally) the thread or privately with a respected member of the community; in doing so you gain the ability to refine it against the forge of experience, discover what (if any) parts are already known; and, in the possibility that there is something to be concerned about, gain the ability to protect Bitcoin from any potential harm if required. (I think you greatly underestimate the potential harm of privately held substantial mining optimizations-- beyond some threshold they would result in the complete centralization of the bitcoin system) That's funny. How easy you condemn people without ground or any evidence, and how exigent and narrow minded you are in recognizing statistical evidence on blockchain validations. I haven't tried to sell anything nor scam anyone and everyone who has followed the thread knows that. I never scammed anyone in my life and I hate scammers that are around the Bitcoin project because the image damage they cause to the Bitcoin project. What we have seen is your extreme aggressivity at me for mentioning the possibility that algorthms boosting the performance of mining may exist. You have been manipulative from the beginning accusing me of threatening bitcoin security. Well, my friend, some people reading us are not that naive as you might think. What is worrisome, really worrisome, is your attitude. People may think that you know about these boosting algorithms and you are just trying to conceal them from public knowledge using your power position as moderator. In particular, you admitted that you are actively mining, therefore you are incurring in an obvious conflict of interest: I can state, as disclaimer, that I don't mine.. If I was evil-minded as you I would think that way. But I am not. I trust your good faith. Even though...I don't like to go into maters discussed in private messages, but since you go into it, I could also go into it and remind you that you wrote something that sounds very disturbing...(and to what I don't give a fuck as I explained to you by choosing the precise wording). The forum trust is a metric of trust; I explained in the rating where the distrust comes from. Your claims here are not credible to any of the subject matter experts and as far as we can tell they're based on erroneous statistical reasoning, you're shielding your theories from criticism by hiding behind secrecy, forcing a debate around statistical minutia and how "weird" the blocks feel qualitatively, rather than the merits of your idea. Only a few weeks ago you were asking questions (using asics to hash files) that showed a profound lack of research and understanding of Bitcoin mining. I want to be sure someone considering trading with you over these ideas is aware that other community members do not currently consider your claims credible or likely to be well founded. Anyone is free to read the rating and come to their own conclusions.
You attribute yourself the privilege to talk in the name of the whole community. On which grounds? Your position as moderator and developer gives a valuable opinion (more than mine in the eyes of the community, no question about that), but you cannot talk for other people, nor predetermine that they have your same opinion. We all have seen posts of people disagreeing with you and willing to understand what is going on. There are people around here that know more math than you do. are open minded, and understand perfectly well the arguments I gave. Speak for yourself as I do and let others speak for themselves. With respect to "matter experts" what we have discovered is that you don't have any serious background on statistics or probabilities. And in your case, you don't know how research inference works. As for me I do recognize that I know little about mining hardware, certainly you know more, but I probably can teach you some lessons about cryptography and hashing. I'm sorry that you find it heavy-handed. I would prefer if there were a way to make ratings which were more targeted or conditional. In consideration of this, I'll go and reduce it to neutral to avoid triggering the red flag on you. I am not seeking to cause you distress.
I thank you. No distress caused, just unfairness felt. Your groundless defamation is still there: "I suspect Valiron is either trying to scam someone out of paying for his "knowledge" or that he is attempting to manipulate the market price of Bitcoin; " |
|
|
|
|
|
spin
|
|
May 04, 2015, 08:49:40 AM |
|
Valiron write down your "secret" or stop. Though I think the secret is that you don't understand the statistics of the situation and you are not willing to admit it. This is my lay understanding of what you are doing: 1. Someone is picking a "random" number between 1 and 100 a 1000 times. 2. Then you see 4 9s in a row. 3. Based on 4 9s in a row you decide the "random" number generator is broken. But it's actually worse than that. People are telling you the nonce "random" number generator is biased for several reasons (miner/asic optimisations) etc. So there is even less reason to suspect issues. I think gmaxwell has spent enough time on this. I'd rather see more other/interesting points from him than address your misunderstanding or lack of a secret. As others I have learnt from this thread, but the marginal utility is dropping fast now. If you really had a "secret" you'd either reveal it to someone responsible or you'd be using it to gain an advantage (but not too much as to destroy bitcoin, if you were sneaky about it). You certainly won't be posting smoke on the forum. You attribute yourself the privilege to talk in the name of the whole community. On which grounds? Your position as moderator and developer gives a valuable opinion (more than mine in the eyes of the community, no question about that),
but you cannot talk for other people, nor predetermine that they have your same opinion. We all have seen posts of people disagreeing with you and willing to understand what is going on. There are people around here that know more math
than you do. are open minded, and understand perfectly well the arguments I gave. Speak for yourself as I do and let others speak for themselves.
gmaxwell did nothing of the sort. With respect to "matter experts" what we have discovered is that you don't have any serious background on statistics or probabilities. And in your case, you don't know how research inference works. As for me I do recognize that
I know little about mining hardware, certainly you know more, but I probably can teach you some lessons about cryptography and hashing. You are not even recognising that he's trying to teach you. |
If you liked this post buy me a beer. Beers are quite cheap where I live!
bc1q707guwp9pc73r08jw23lvecpywtazjjk399daa
|
|
|
|
valiron (OP)
|
|
May 04, 2015, 09:04:29 AM |
|
Valiron write down your "secret" or stop.
I don't have any secret. I just observed what I believe is an unusual pattern in block validation that I wanted to discuss. Can I or is this a forbidden topic? I also have better things to do than to try to teach how scientific inference works. Though I think the secret is that you don't understand the statistics of the situation and you are not willing to admit it.
This is my lay understanding of what you are doing:
1. Someone is picking a "random" number between 1 and 100 a 1000 times.
2. Then you see 4 9s in a row.
3. Based on 4 9s in a row you decide the "random" number generator is broken.
I see these 4 9's and several other independent facts with small probability, thus it is more like choosing a random numbers between 1 and 100.000. Please, you, that claims to understand probability, teach us how many 9's you need to see to believe that there is a chance that there is something broken? |
|
|
|
|
jl2012
Legendary
Offline
Activity: 1792
Merit: 1097
|
|
May 04, 2015, 09:12:54 AM |
|
Please, you, that claims to understand probability, teach us how many 9's you need to see to believe that there is a chance that there is something broken?
My second homework for you: read the Prosecutor's fallacy article on Wikipedia, http://en.wikipedia.org/wiki/Prosecutor%27s_fallacy |
Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
|
|
|
Foxpup
Legendary
Offline
Activity: 4354
Merit: 3044
Vile Vixen and Miss Bitcointalk 2021-2023
|
|
May 04, 2015, 09:13:47 AM |
|
You are wrong. I have retracted and erased all comments (if I have overlooked any, please let me know), in particular those that you quote (where did you get the quote?). Obviously I cannot erase people quoting me. You should ask them.
You are a liar. If you really wondered where the quotes came from, you would have searched the thread and discovered that they were quoted from the first and fifteenth posts in this thread, which you never edited to remove your outrageous claims. Nor did you ever change the inflammatory subject of this thread. At first I though you were honestly mistaken and really bad at math, then I thought you were a kook, but kooks don't generally lie about retracting their outrageous claims, which makes me question your motives. I agree with gmaxwell - you're trying to sell something, and we're not buying it. I suggest you give up now before you embarrass yourself further. |
Will pretend to do unspeakable things (while actually eating a taco) for bitcoins: 1K6d1EviQKX3SVKjPYmJGyWBb1avbmCFM4I am not on the scammers' paradise known as Telegram! Do not believe anyone claiming to be me off-forum without a signed message from the above address! Accept no excuses and make no exceptions! |
|
|
|
valiron (OP)
|
|
May 04, 2015, 09:17:38 AM |
|
You are not even recognising that he's trying to teach you.
Yes, I can and do recognize that he is teaching many of us facts about mining hardware algorithms. No, I am afraid he cannot teach about scientific inference. Certainly not to a professional researcher. He is unable to conceive that there might be irregularities caused by his lack of knowledge. This is typical from people that believe to be the Masters of the Universe and that they know everything in their subject and that they look from above the rest of the world, even when they don't know with whom they are dealing. I am feed up of seeing this every day. No news here. I have some work to do now. Have a good day. |
|
|
|
|
becoin
Legendary
Offline
Activity: 3431
Merit: 1233
|
|
May 04, 2015, 09:27:39 AM |
|
But it's actually worse than that. People are telling you the nonce "random" number generator is biased for several reasons (miner/asic optimisations) etc. So there is even less reason to suspect issues. If a random number generator is 'biased' then this random number generator is flawed. This is why it's better to not describe it as random number generator! Miner/asic 'optimisations' are optimizations if they help miners mine faster and cheaper, not mine less! This is the whole point of having PoW, right? |
|
|
|
|
|
valiron (OP)
|
|
May 04, 2015, 09:29:27 AM |
|
You are wrong. I have retracted and erased all comments (if I have overlooked any, please let me know), in particular those that you quote (where did you get the quote?). Obviously I cannot erase people quoting me. You should ask them.
You are a liar. If you really wondered where the quotes came from, you would have searched the thread and discovered that they were quoted from the first and fifteenth posts in this thread, which you never edited to remove your outrageous claims. Nor did you ever change the inflammatory subject of this thread. You are right that I overlooked these two and I have erased them. I did erase others, but apparently I missed these two or weren't erased properly. Sorry that you accuse me of being a liar when it was just an overlook. I added a question mark to the title: Does it passes now the censorship? At first I though you were honestly mistaken and really bad at math, then I thought you were a kook, but kooks don't generally lie about retracting their outrageous claims, which makes me question your motives. I agree with gmaxwell - you're trying to sell something, and we're not buying it. I suggest you give up now before you embarrass yourself further.
Your only explanations are evil-minded. I guess that's your problem, not mine. Also what you claim doesn't makes sense. If anyone had a boosting performing algorithm for mining and he wanted to make money, why he would sell it? Why not use it directly? Obviously people falling in such a scam of buying a miraculous algorithms are just dumbheads that don't think twice about it for 5 seconds. On the other hand, I think it is legit to monitor block validations in order to see any indication if someone found something. |
|
|
|
|
|
valiron (OP)
|
|
May 04, 2015, 09:37:04 AM |
|
I have been called a liar, a scammer, an ignorant, a dishonest person, you have insulted me several times...
You look really respectful of others opinions and open minded around here....
I would like to discuss only technical facts and statistics. After all this is a subforum for "Technical discussions". So, please, stop it. I demand some respect. I wonder why all this hostility...
|
|
|
|
|
jl2012
Legendary
Offline
Activity: 1792
Merit: 1097
|
|
May 04, 2015, 10:25:16 AM |
|
I have been called a liar, a scammer, an ignorant, a dishonest person, you have insulted me several times...
You look really respectful of others opinions and open minded around here....
I would like to discuss only technical facts and statistics. After all this is a subforum for "Technical discussions". So, please, stop it. I demand some respect. I wonder why all this hostility...
If you want some respect the best thing to do is to be honest. Have you ever tried to do the homework ( https://bitcointalk.org/index.php?topic=1045381.msg11268521#msg11268521) I gave you? If that's too trouble to collect the nonce here you are: 4158183488 (nonce of block 200000)
2860276919 (nonce of block 200001)
2252958492
619775756
3774121230
3636235506
3517855708
3242731889
240962551
2138681678
1898904060
2854313953
256488735
3529624388
2088744053
1058371964
2074059591
3090615686
859604587
514733020
3032482115
3326677299
2009843466
2309937512
3789741370
3082448470
3423290971
667706083
3079938352
34655536
1759366602
899695936
2628433707
507660531
3269002158
2870486318
1411929976
375422824
4001934220
4268389206
636717826
2937229565
2139816771
1039519852
3786229309
1365075112
1020876771
958912963
3452443159
1473171346 (nonce of block 200049) As soon as you do it you will see why your claims were ridiculous. |
Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4158
Merit: 8411
|
|
May 04, 2015, 10:26:58 AM
Last edit: May 04, 2015, 11:20:27 AM by gmaxwell |
|
You will agree that this facts are independent by themselves. You will agree that they happen rarely with a small probability. The probability of seeing them simultaneously is small.
You add: "This is your test for a specific non-disclosed mining optimization." No, it is not. This is my test to detect that something out of normal is happening.
Don't insist on this line. I have withdraw any claim about mining optimization. Why are you insisting into something that I won't discuss?
You accuse me of divagating but here you chase the optimization tangent which to say you've dropped at the expense of completely ignoring my argument that your own overfit criteria actually precludes your hypothesis that something "out of normal going on"; since exclusion of your training sample from the test observations results in no hits against your proposed criteria. I did ask a very simple question and you are unable to answer it in simple form: "how would you go about proving that this is out of normal?". Let me rephrase: What is sufficient evidence to infer that something out of your knownledge is going on?
This is a question that ask working scientists ask themselves all the time.
And I thought I answered it adequately, I would only find behavior rare if it was surprising in light of a model that wasn't already fit to the self-same data. From what you tell you seem to refuse that there is any anomaly if you don't have a working hypothesis When the behavior can also be explained by "yes, these numbers could have arisen by chance", then I do expect to have a model before I conclude that they're actually surprising. There is no "ideal way to reason about thing". I didn't say it was the only way to do so, it was a suggested example idealized approach; offered with the hope of being constructive and not merely repeating that your reasoning was defective without offering an alternative approach. Yea...so astronomers noticing the advance of the Mercury perihelion
Mercury's precession isn't noticeable or interesting at all without some kind of model. If your theory of the solar system is that the planets just wander around, any sequence of moves doesn't seem especially surprising. Obviously we can make such assumptions with more knowledge. Let me try something that can pass your censorship: I guess we agree that the main variable for mining a block is the header of the (double) hash of the previous block. If you knew the hash in advance you would be able to premine the block. By "premine" I mean doing most of the computation work well in advance (nothing spurious suggested by "premine", just "pre"-doing the work). The Merkel root tree hash can be kept static except maybe for impact of the extranounce (for example when you mine 1 transaction blocks).
Awesome! So we can finally talk about something specific and technical! You're talking about using the midstate, as it's normally called; hashing a block header involves running the SHA256 compression function 3 times. One to ingest the first part, leaving the 64 byte midstate, one to digest the end, and then a final one on the output. Because the nonce is at the end of the header one can perform 4 billion runs of the latter two compression runs without repeating the first. The midstate optimization was mentioned in the second page of this thread. It's an optimization exists in every miner, it was used in the original Bitcoin software while CPU mining; it's enshrined into the getwork protocol (the original remote mining protocol); it's established in the publicly documented interfaces of mining asics-- they are usually setup to receive midstates, not headers from their control systems. It is effectively impossible to write miner software without being comfortable working with a midstate plus a tail. P2Pool even uses this characteristic of the merkle damgard design to reduce its communications costs (it needs to prove a piece of data with a particular hash ends with a particular suffix, so it communicates just the midstate and the final piece). As an aside, the merkel root cannot be kept static across multiple blocks, it must be recomputed every block, even if you are mining a one transaction block, because the block height is required in the coinbase transaction; and of course changing that or the extranonce or anything else in the block changes the merkel root completely. If you were able to keep it static, it would mean creating a duplicate coinbase transaction; which is prohibited by the network; but if it weren't prohibited it would destroy the prior one and deprive you of your newly mined Bitcoins from it. You will agree that someone with a performing mining algorithm will have a lot of advantage by witholding mined blocks in order to speed up the mining of the next ones and then releasing them in a short time. I will not. This is now unrelated to the point you made above: The computation to generate the midstate is generally insignificant. My laptop can generate something on the order of 40 million midstates per second, with the factor of ~4 billion increase from nonce rolling, this one laptop could support midstate generation for nearly the entire network; if anyone worried too much about midstate generation speed, they'd move it onto an ASIC (or just a FPGA); and a single part could easily have 10 or 100 times what my laptop can generate;-- since midstate generation work is 1:2^33 that of the mining in total (assuming the whole nonce range is used, but you can see that taking a factor of 2 or 4 here or there doesn't change things much-- and thus my point before about miners not using the whole nonce range; there is no need to because midstate generation is still cheap). Generally by withholding blocks you disadvantage yourself because you will lose a race (the network prefers the first in the face of ties, specifically to avoid incentives to delay blocks); without an information advantage (e.g. MITM other participants) you must have a very significant total fraction of the hashrate before any delay of your announcements is not a spectacular loss. This has been studied to some extent in the literature; the most optimistic simulations which assume no latency show in the no information advantage has no amount of withholding avoids being a loss until over the 1/3rd of total hashrate case. leading to sequences of nearby mined blocks. If he wants to conceal this fact he will mine the blocks anonymously (or with another miner that he controls). This means that we have to pay particular attentiion to close by mined blocks of anonymous origin. And we have to pay special attention to similarities that can reveal that the same miner is behind these blocks
It would be great to prove that this miners are distinct and independent, but they may be collaborating. Event if these miners are independent they may be using the same algorithm that produces similar output.
It seems nothing can disprove your belief. You say it would be the same miner producing the blocks but when presented with evidence that it is different miners, you argue that he would conceal it. Why did we even look to apparently non-anonymous miners in the first place? While doing so, you ignore strong evidence against your theory: That at least two people independently observed those blocks arriving on the network minutes apart; not in a bunch as your block withholding model would predict (and not as you initially believed them to be). If you were willing to argue that the blocks arriving at the same time, when you were mislead by the data on BC.i, was strong evidence; you ought to be willing to admit that when you find they arrived without bunching that this undermines your theory. Could you cut this short, don't divagate, and just let us know how you will proceed in order to prove that a sequence of nearby consecutive nounces is out of normal?
How many nounces and with what proximity your criteria will show that they are our of normal?
I have provided my answer on this. We are still waiting yours. Your answer must contain a number and a % proximity. For me n=3 events and a geometric mean of prob of the order of 1% starts to trigger my interest, and light a red flag if
this occurs combined with other unusual coincidences.
Well... I know from past experience that encountering events with probability under 1:2^90, without my expectation being fixed by the data in advance, when I expected a random outcome triggered in me fairly strong confidence that something structured was happening and spent time searching for an answer; but I still did not exclude the possibility that it could be a coincidence. This is all irrelevant because you're ignoring the model complexity and that is an absolutely critical term which cannot be discounted: I would not be surprised by a complex model I just fit against the data that I'm testing it on. It will always match. If I were to be surprised by this I would be making an error in judgement. I have made similar errors in judgement in the past but I would be unlikely to do so now unless I was tired or ill. Your comment here of "1% starts to trigger my interest, and light a red flag" makes me laugh out loud. There are 144 blocks in a day (and thus 144 overlapping three block windows). If you really have your attention caught by 1% events then you would be constantly exhausted by them occurring almost every day, often multiple times. I am imagining a movie conspiracy theorist with a bunch of sticky notes on a wall and string run between them. "ITS ALL CONNECTED", ... sorry. Please don't waste the forums time with observations at the once a day level; none of us have the patience for it. If you really want to work yourself up over some criteria that will happen constantly by chance, in private-- thats your own decision, but please don't inflict it on the rest of us. You are wrong. I have retracted and erased all comments (if I have overlooked any, please let me know), in particular those that you quote (where did you get the quote?). Obviously I cannot erase people quoting me. You should ask them.
I think you must have overlooked them, I quoted-- they should be easy to find. One is in the very first message. Please note the forum logs edits. Edit: Thanks they're gone now. extreme aggressivity at me for mentioning the possibility that algorthms boosting the performance of mining may exist I've participated and contributed to many minining optimizations discussions-- at least back when they were frequently interesting; I have no objection to that. I have made crystal clear what my complaint was at every instant and moment: You pointed to some random, uninteresting blocks, alleged on a flimsy basis that they were evidence for a secret mining optimization, known to you but which you wouldn't discuss. I'm glad you're retracting your statements now. But this smelled like a scam, it's nothing personal. You have been manipulative from the beginning accusing me of threatening bitcoin security. Secret substantial mining optimizations would be a threat to Bitcoin security (if they were real), the level depending on how significant they were; because if significant enough they could undermine the decentralization of mining which is critical to the system's security assumptions. I have always thought it was unlikely that there was an actual threat there which you were aware of-- initially on the basis that not so long ago you were asking very uninformed questions about mining, but its not impossible that someone new to the subject might discover something that has evaded the analysis of so many others over the past 6 years. My comment there was if I were to accept your belief then it was an additional reason why you should disclose. Well, my friend, some people reading us are not that naive as you might think. I'm really not sure how I should understand that. What is worrisome, really worrisome, is your attitude. People may think that you know about these boosting algorithms and you are just trying to conceal them
from public knowledge Oh how perfectly diabolical of me to use reverse psychology! You've uncovered my true plan: to conceal the secrets of mining by insisting you reveal them to the public if you're going sulk about claiming to know things! How could you have figured me out! oh no! using your power position as moderator. In particular, you admitted that you are actively mining, therefore you are incurring in an obvious conflict of interest: I can state, as disclaimer, that I don't mine.. LOL. It almost makes up for all the irritation, so funny; Actually my comment was "it's the behavior of hardware sitting right next to me"; I was referring to a Bitmain S1 which my foot was propped up on at the time and which hasn't been turned on in months. But again I should be awed by your incredible sleuthing-- I am actually mining, with downclocked SP20 at 1.27TH/s. With my $0.35/kwh marginal power this costs me somewhat under $200/mo to operate. The P2Pool stats page says that the income is ~0.0107btc/day. So you've totally caught me in my evil plot to prevent people from competing with me for my $130/month _loss_; where by I must spin an elaborate information concealing campaign on the forum in order to lose less money, because simply _pressing an off switch_ is far too difficult for my feeble brain to handle. I truly have been educated stupid, and my participating in mining could have nothing to do with my support for the Bitcoin system and my @#$@# development of the @$#@$ Bitcoin software. Not a chance. It's all a conspiracy. You caught me. (I'm thankful for your confession of non-participation; always good to know when the writer doesn't have direct experience in the subject!  ) But I am not. I trust your good faith. Even though...I don't like to go into maters discussed in private messages, but since you go into it, I could also go into it and remind you that you wrote something that sounds very disturbing...(and to what I don't give a fuck as I explained to you by choosing the precise wording).
Feel free to quote my whole messages if you like; though I expect they'll reflect poorly on you-- not me. You attribute yourself the privilege to talk in the name of the whole community. On which grounds? I don't-- I speak to my personal responsibility and the what I feel is my share of the collective responsibility. But-- if I were to speak for others... Your position as moderator and developer gives a valuable opinion (more than mine in the eyes of the community, no question about that),
... these might be some pretty good reasons to do so. But, as I said-- I'm not. I even specifically called out in my prior message that I was just speaking as an ordinary community member. Anyone is free to disagree as you have so vigorously done. we have discovered is that you don't have any serious background on statistics or probabilities. Among other professional pursuits which required a strong command of probabilities, I spent over a decade working on the design of compression formats; so this is a bit amusing too. While none of my formally peer reviewed publications have been squarely statistically directed, many things I've published professionally or casually have also required fairly significant statistical work-- such as fault tolerance design for large scale communications networks and predictive failure monitoring-- this may be part of why I quickly observed the flawed reasoning like failing to compensate for drawing your parameters from your data, or the impact of multiple comparisons-- none of it is a mystery but its surprising to laymen without a working experience with probability. There is much that I do not know, thats for sure-- and I am constantly learning new things... and while I'm also sure that there are many things I could learn from you, on the particular subject of working with this kind of data, it seems that most of that would come in the form of observing your errors. I hope you could share this learning with me, but I fear your credentials have blinded you to recognizing the possibility that you're actually far off the mark this time-- you're resorting to increasingly tortured adhomenem, and at this point I can only laugh at it. Ah, I missed this earlier (it was burred under an untrimmed quote of my graphs): You cannot deny that there is an advantage in using the timestamp field partly as nounce for mining. I most certainly can! I did above, in my comments related to mid-state, which apply just as well to recomputing a new merkle root. Some amount of mining gear is able to do ntime rolling, I don't believe many (or any) use it anymore; and I think its actually incompatible with most stratum pools, but I'd have to check to be sure. It isn't a useful advantage because the savings it provides is so enormously removed from the scale of mining that it doesn't matter. Any improvement prior to the nonce increment is effectively reduced several billion fold-- it's like saving 90% of a drop of water relative to the ocean, 90% is a lot of the drop, but nothing of the ocean. Ntime rolling was historically interesting because prior to getblocktemplate and stratum, a remote miner required network traffic every time the nonce space was exhausted and this could produce high load on pools; the ability for remote miners to increment an extranonce themselves in both of the newer remote miner protocols largely made ntime rolling obsolete. I would like to discuss only technical facts and statistics. After all this is a subforum for "Technical discussions". Thats what the subforum is for; I'm glad you've now joined its purpose. The complaint all along was that your posts were not conducive to that but instead to something else. Now that thats cleared up, I'm not sure what else is there to say-- in the post I'm responding to here you seem to be saying that 1% events with unspecified other coincidences are deserving your attention. With moderator hat on-- I'm going to ask you to not create threads in this subforum for 1%/block level events without a good, clearly stated, technical analysis that gives a rational basis to believe they're not a once a day pure chance false alarm. ... Your first abrasive message to the thread was the second post with "Last, don't insult our intelligence."-- many people have read and responded patiently. My passive patience ran out at about your dozenth post in the thread. It happens some times, I'm sure all of us are warn out from the argument. |
|
|
|
|
jl2012
Legendary
Offline
Activity: 1792
Merit: 1097
|
|
May 04, 2015, 10:31:30 AM |
|
You accuse me of divagating......................
I think you have spent too much time on this nonproductive thread. |
Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
|
|
|
Foxpup
Legendary
Offline
Activity: 4354
Merit: 3044
Vile Vixen and Miss Bitcointalk 2021-2023
|
|
May 04, 2015, 10:36:50 AM |
|
I demand some respect.
Respect is earned, not given. You have already received a great deal more respect than you rightly deserve, and you did not return the excess. Your demand is unreasonable. |
Will pretend to do unspeakable things (while actually eating a taco) for bitcoins: 1K6d1EviQKX3SVKjPYmJGyWBb1avbmCFM4I am not on the scammers' paradise known as Telegram! Do not believe anyone claiming to be me off-forum without a signed message from the above address! Accept no excuses and make no exceptions! |
|
|
becoin
Legendary
Offline
Activity: 3431
Merit: 1233
|
|
May 04, 2015, 11:21:11 AM |
|
You will agree that this facts are independent by themselves. You will agree that they happen rarely with a small probability. The probability of seeing them simultaneously is small.
You add: "This is your test for a specific non-disclosed mining optimization." No, it is not. This is my test to detect that something out of normal is happening.
Don't insist on this line. I have withdraw any claim about mining optimization. Why are you insisting into something that I won't discuss?
You accuse me of divagating but here you chase the optimization tangent which to say you've dropped at the expense of completely ignoring my argument that your own overfit criteria actually precludes your hypothesis that something "out of normal going on"; since exclusion of your training sample from the test observations results in no hits against your proposed criteria. I did ask a very simple question and you are unable to answer it in simple form: "how would you go about proving that this is out of normal?". Let me rephrase: What is sufficient evidence to infer that something out of your knownledge is going on?
This is a question that ask working scientists ask themselves all the time.
And I thought I answered it adequately, I would only find behavior rare if it was surprising in light of a model that wasn't already fit to the self-same data. From what you tell you seem to refuse that there is any anomaly if you don't have a working hypothesis When the behavior can also be explained by "yes, these numbers could have arisen by chance", then I do expect to have a model before I conclude that they're actually surprising. There is no "ideal way to reason about thing". I didn't say it was the only way to do so, it was a suggested example idealized approach; offered with the hope of being constructive and not merely repeating that your reasoning was defective without offering an alternative approach. Yea...so astronomers noticing the advance of the Mercury perihelion
Mercury's precession isn't noticeable or interesting at all without some kind of model. If your theory of the solar system is that the planets just wander around, any sequence of moves doesn't seem especially surprising. Obviously we can make such assumptions with more knowledge. Let me try something that can pass your censorship: I guess we agree that the main variable for mining a block is the header of the (double) hash of the previous block. If you knew the hash in advance you would be able to premine the block. By "premine" I mean doing most of the computation work well in advance (nothing spurious suggested by "premine", just "pre"-doing the work). The Merkel root tree hash can be kept static except maybe for impact of the extranounce (for example when you mine 1 transaction blocks).
Awesome! So we can finally talk about something specific and technical! You're talking about using the midstate, as it's normally called; hashing a block header involves running the SHA256 compression function 3 times. One to ingest the first part, leaving the 64 byte midstate, one to digest the end, and then a final one on the output. Because the nonce is at the end of the header one can perform 4 billion runs of the latter two compression runs without repeating the first. The midstate optimization was mentioned in the second page of this thread. It's an optimization exists in every miner, it was used in the original Bitcoin software while CPU mining; it's enshrined into the getwork protocol (the original remote mining protocol); it's established in the publicly documented interfaces of mining asics-- they are usually setup to receive midstates, not headers from their control systems. It is effectively impossible to write miner software without being comfortable working with a midstate plus a tail. P2Pool even uses this characteristic of the merkle damgard design to reduce its communications costs (it needs to prove a piece of data with a particular hash ends with a particular suffix, so it communicates just the midstate and the final piece). You will agree that someone with a performing mining algorithm will have a lot of advantage by witholding mined blocks in order to speed up the mining of the next ones and then releasing them in a short time. I will not. This is now unrelated to the point you made above: The computation to generate the midstate is generally insignificant. My laptop can generate something on the order of 40 million midstates per second, with the factor of ~4 billion increase from nonce rolling, this one laptop could support midstate generation for nearly the entire network; if anyone worried too much about midstate generation speed, they'd move it onto an ASIC (or just a FPGA); and a single part could easily have 10 or 100 times what my laptop can generate;-- since midstate generation work is 1:2^33 that of the mining in total (assuming the whole nonce range is used, but you can see that taking a factor of 2 or 4 here or there doesn't change things much-- and thus my point before about miners not using the whole nonce range; there is no need to because midstate generation is still cheap). Generally by withholding blocks you disadvantage yourself because you will lose a race (the network prefers the first in the face of ties, specifically to avoid incentives to delay blocks); without an information advantage (e.g. MITM other participants) you must have a very significant total fraction of the hashrate before any delay of your announcements is not a spectacular loss. This has been studied to some extent in the literature; the most optimistic simulations which assume no latency show in the no information advantage has no amount of withholding avoids being a loss until over the 1/3rd of total hashrate case. leading to sequences of nearby mined blocks. If he wants to conceal this fact he will mine the blocks anonymously (or with another miner that he controls). This means that we have to pay particular attentiion to close by mined blocks of anonymous origin. And we have to pay special attention to similarities that can reveal that the same miner is behind these blocks
It would be great to prove that this miners are distinct and independent, but they may be collaborating. Event if these miners are independent they may be using the same algorithm that produces similar output.
It seems nothing can disprove your belief. You say it would be the same miner producing the blocks but when presented with evidence that it is different miners, you argue that he would conceal it. Why did we even look to apparently non-anonymous miners in the first place? While doing so, you ignore strong evidence against your theory: That at least two people independently observed those blocks arriving on the network minutes apart; not in a bunch as your block withholding model would predict (and not as you initially believed them to be). If you were willing to argue that the blocks arriving at the same time, when you were mislead by the data on BC.i, was strong evidence; you ought to be willing to admit that when you find they arrived without bunching that this undermines your theory. Could you cut this short, don't divagate, and just let us know how you will proceed in order to prove that a sequence of nearby consecutive nounces is out of normal?
How many nounces and with what proximity your criteria will show that they are our of normal?
I have provided my answer on this. We are still waiting yours. Your answer must contain a number and a % proximity. For me n=3 events and a geometric mean of prob of the order of 1% starts to trigger my interest, and light a red flag if
this occurs combined with other unusual coincidences.
Well... I know from past experience that encountering events with probability under 1:2^90, without my expectation being fixed by the data in advance, when I expected a random outcome triggered in me fairly strong confidence that something structured was happening and spent time searching for an answer; but I still did not exclude the possibility that it could be a coincidence. This is all irrelevant because you're ignoring the model complexity and that is an absolutely critical term which cannot be discounted: I would not be surprised by a complex model I just fit against the data that I'm testing it on. It will always match. If I were to be surprised by this I would be making an error in judgement. I have made similar errors in judgement in the past but I would be unlikely to do so now unless I was tired or ill. Your comment here of "1% starts to trigger my interest, and light a red flag" makes me laugh out loud. There are 144 blocks in a day (and thus 144 overlapping three block windows). If you really have your attention caught by 1% events then you would be constantly exhausted by them occurring almost every day, often multiple times. I am imagining a movie conspiracy theorist with a bunch of sticky notes on a wall and string run between them. "ITS ALL CONNECTED", ... sorry. Please don't waste the forums time with observations at the once a day level; none of us have the patience for it. If you really want to work yourself up over some criteria that will happen constantly by chance, in private-- thats your own decision, but please don't inflict it on the rest of us. You are wrong. I have retracted and erased all comments (if I have overlooked any, please let me know), in particular those that you quote (where did you get the quote?). Obviously I cannot erase people quoting me. You should ask them.
I think you must have overlooked them, I quoted-- they should be easy to find. One is in the very first message. Please note the forum logs edits. extreme aggressivity at me for mentioning the possibility that algorthms boosting the performance of mining may exist I've participated and contributed to many minining optimizations discussions-- at least back when they were frequently interesting; I have no objection to that. I have made crystal clear what my complaint was at every instant and moment: You pointed to some random, uninteresting blocks, alleged on a flimsy basis that they were evidence for a secret mining optimization, known to you but which you wouldn't discuss. I'm glad you're retracting your statements now. But this smelled like a scam, it's nothing personal. You have been manipulative from the beginning accusing me of threatening bitcoin security. Secret substantial mining optimizations would be a threat to Bitcoin security (if they were real), the level depending on how significant they were; because if significant enough they could undermine the decentralization of mining which is critical to the system's security assumptions. I have always thought it was unlikely that there was an actual threat there which you were aware of-- initially on the basis that not so long ago you were asking very uninformed questions about mining, but its not impossible that someone new to the subject might discover something that has evaded the analysis of so many others over the past 6 years. My comment there was if I were to accept your belief then it was an additional reason why you should disclose. Well, my friend, some people reading us are not that naive as you might think. I'm really not sure how I should understand that. In the light of the weak hypothesis that you were trying to find a suckerbuyer for your theories... What is worrisome, really worrisome, is your attitude. People may think that you know about these boosting algorithms and you are just trying to conceal them
from public knowledge Oh how perfectly diabolical of me to use reverse psychology! You've uncovered my true plan: to conceal the secrets of mining by insisting you reveal them to the public if you're going sulk about claiming to know things! How could you have figured me out! oh no! using your power position as moderator. In particular, you admitted that you are actively mining, therefore you are incurring in an obvious conflict of interest: I can state, as disclaimer, that I don't mine.. LOL. It almost makes up for all the irritation, so funny; Actually my comment was "it's the behavior of hardware sitting right next to me"; I was referring to a Bitmain S1 which my foot was propped up on at the time and which hasn't been turned on in months. But again I should be awed by your incredible sleuthing-- I am actually mining, with downclocked SP20 at 1.27TH/s. With my $0.35/kwh marginal power this costs me somewhat under $200/mo to operate. The P2Pool stats page says that the income is ~0.0107btc/day. So you've totally caught me in my evil plot to prevent people from competing with me for my $130/month _loss_; where by I must spin an elaborate information concealing campaign on the forum in order to lose less money, because simply _pressing an off switch_ is far too difficult for my feeble brain to handle. I truly have been educated stupid, and my participating in mining could have nothing to do with my support for the Bitcoin system and my @#$@# development of the @$#@$ Bitcoin software. Not a chance. It's all a conspiracy. You caught me. (I'm thankful for your confession of non-participation; always good to know when the writer doesn't have direct experience in the subject! ) But I am not. I trust your good faith. Even though...I don't like to go into maters discussed in private messages, but since you go into it, I could also go into it and remind you that you wrote something that sounds very disturbing...(and to what I don't give a fuck as I explained to you by choosing the precise wording).
Feel free to quote my whole messages if you like; though I expect they'll reflect poorly on you-- not me. You attribute yourself the privilege to talk in the name of the whole community. On which grounds? I don't-- I speak to my personal responsibility and the what I feel is my share of the collective responsibility. But-- if I were to speak for others... Your position as moderator and developer gives a valuable opinion (more than mine in the eyes of the community, no question about that),
... these might be some pretty good reasons to do so. But, as I said-- I'm not. I even specifically called out in my prior message that I was just speaking as an ordinary community member. Anyone is free to disagree as you have so vigorously done. we have discovered is that you don't have any serious background on statistics or probabilities. Among other professional pursuits which required a strong command of probabilities, I spent over a decade working on the design of compression formats; so this is a bit amusing too. While none of my formally peer reviewed publications have been squarely statistically directed, many things I've published professionally or casually have also required fairly significant statistical work-- such as fault tolerance design for large scale communications networks and predictive failure monitoring-- this may be part of why I quickly observed the flawed reasoning like failing to compensate for drawing your parameters from your data, or the impact of multiple comparisons-- none of it is a mystery but its surprising to laymen without a working experience with probability. There is much that I do not know, thats for sure-- and I am constantly learning new things... and while I'm also sure that there are many things I could learn from you, on the particular subject of working with this kind of data, it seems that most of that would come in the form of observing your errors. I hope you could share this learning with me, but I fear your credentials have blinded you to recognizing the possibility that you're actually far off the mark this time-- you're resorting to increasingly tortured adhomenem, and at this point I can only laugh at it. Ah, I missed this earlier (it was burred under an untrimmed quote of my graphs): You cannot deny that there is an advantage in using the timestamp field partly as nounce for mining. I most certainly can! I did above, in my comments related to mid-state, which apply just as well to recomputing a new merkle root. Some amount of mining gear is able to do ntime rolling, I don't believe many (or any) use it anymore; and I think its actually incompatible with most stratum pools, but I'd have to check to be sure. It isn't a useful advantage because the savings it provides is so enormously removed from the scale of mining that it doesn't matter. Any improvement prior to the nonce increment is effectively reduced several billion fold-- it's like saving 90% of a drop of water relative to the ocean, 90% is a lot of the drop, but nothing of the ocean. Ntime rolling was historically interesting because prior to getblocktemplate and stratum, a remote miner required network traffic every time the nonce space was exhausted and this could produce high load on pools; the ability for remote miners to increment an extranonce themselves in both of the newer remote miner protocols largely made ntime rolling obsolete. I would like to discuss only technical facts and statistics. After all this is a subforum for "Technical discussions". Thats what the subforum is for; I'm glad you've now joined its purpose. The complaint all along was that your posts were not conducive to that but instead to something else. Now that thats cleared up, I'm not sure what else is there to say-- in the post I'm responding to here you seem to be saying that 1% events with unspecified other coincidences are deserving your attention. With moderator hat on-- I'm going to ask you to not create threads in this subforum for 1%/block level events without a good, clearly stated, technical analysis that gives a rational basis to believe they're not a once a day pure chance false alarm. ... Your first abrasive message to the thread was the second post with "Last, don't insult our intelligence."-- many people have read and responded patiently. My passive patience ran out at about your dozenth post in the thread. It happens some times, I'm sure all of us are warn out from the argument. Wow. What an ego?! It's even bigger than mine. gmaxwell, have you ever in your life confessed when you're wrong? Well, just asking... |
|
|
|
|
lontivero
Full Member
Offline
Activity: 164
Merit: 128
Amazing times are coming
|
|
May 04, 2015, 03:19:52 PM |
|
You accuse me of divagating......................
I think you have spent too much time on this nonproductive thread. This thread is not more interesting and doesn't provide any new information nor learning issues. It is clear for me that Valiron won't share any secret algorithm. It is also very clear he didn't have a question but a theory instead. Also, the arguments are changing continuously. I think this is not productive at all. It's enough for me (and probably for others too). |
|
|
|
|
RodeoX
Legendary
Offline
Activity: 3066
Merit: 1147
The revolution will be monetized!
|
|
May 04, 2015, 03:33:21 PM |
|
Thank you gmaxwell. As always bringing the facts. Tip sent!
|
|
|
|
Razick
Legendary
Offline
Activity: 1330
Merit: 1003
|
|
May 04, 2015, 08:06:22 PM |
|
The time between blocks is random, 10 minutes is the *average.* Theoretically, we could be very unlucky and not find a block for a year. |
ACCOUNT RECOVERED 4/27/2020. Account was previously hacked sometime in 2017. Posts between 12/31/2016 and 4/27/2020 are NOT LEGITIMATE.
|
|
|
JeromeL
Member
Offline
Activity: 554
Merit: 11
CurioInvest [IEO Live]
|
|
May 04, 2015, 10:42:39 PM
Last edit: May 04, 2015, 11:19:42 PM by JeromeL |
|
Lol. At least this thread proves that gmaxwell is not satoshi.
"Sorry if you don't believe me, I don't have time to convince you".
He knew how to get rid of trolls.
|
|
|
|
|
valiron (OP)
|
|
May 06, 2015, 01:37:05 AM
Last edit: May 06, 2015, 07:25:25 AM by valiron |
|
Statistics of nounces since 2013 =================== Min. 1st Qu. Median Mean 3rd Qu. Max. 8.130e+03 1.079e+09 2.147e+09 2.144e+09 3.208e+09 4.295e+09 Distribution of the 140411 nounces appears uniformly distributed (except slighty off at the very end of the range) Histogram of nounces:  Nounce of block 354641 is within 0.048% of the total range from 2^31. There are 159 occurences of nounces within an interval of length 2x0.048=0.096% centered at 2^31 which count for 0.11% of the total of 140411. Nounce of block 354642 is within 0.20% of the total range from 2^31. There are 577 occurences of nounces within an interval of length 2x0.20=0.4% centered at 2^31 which count for 0.41% of the total of 140411. There are 14194 nonces within an interval of length 10% from 2^31 whcih count for 10% of the total of 140411. Nounces appear to be uniformly distributed, in particular around 2^31. |
|
|
|
|
-ck
Legendary
Offline
Activity: 4102
Merit: 1632
Ruu \o/
|
|
May 06, 2015, 01:49:04 AM |
|
For the love of god, make this thread stop. At the very least, stop calling them nounces. I penned numerous responses to this thread and deleted them every time when I reminded myself of how this thread progresses...
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
|
|
|
2112
Legendary
Offline
Activity: 2128
Merit: 1068
|
|
May 06, 2015, 01:57:53 AM |
|
For the love of god, make this thread stop. At the very least, stop calling them nounces. I penned numerous responses to this thread and deleted them every time when I reminded myself of how this thread progresses...
Why stopping? It is fun and educational read about how to become a crackpot. It isn't very interesting technically or mathematically, but it is quite educational from the psychological point of view. The cryptocoin community will soon probably need an equivalent of the well-know "crackpot index" from the physics community. http://math.ucr.edu/home/baez/crackpot.html |
|
|
|
|
valiron (OP)
|
|
May 06, 2015, 07:24:18 AM |
|
Whatever, but nonces appear uniformly distributed contradicting the arbitrary claims of some people that pretend to be knowledgeable.
Anyone is free to interpret the data and the facts as he wish. From my part I will only provide data and no comments.
(this is a subforum on "Technical Discussion")
|
|
|
|
|
jl2012
Legendary
Offline
Activity: 1792
Merit: 1097
|
|
May 06, 2015, 07:30:07 AM |
|
Whatever, but nonces appear uniformly distributed contradicting the arbitrary claims of some people that pretend to be knowledgeable.
Anyone is free to interpret the data and the facts as he wish. From my part I will only provide data and no comments.
("Technical Discussion" vs. "trolling")
With all these data, how do you arrive the question in your topic, i.e. "WTF is this? Someone found a trick for fast mining?" |
Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
|
|
|
|
valiron (OP)
|
|
May 06, 2015, 07:35:14 AM |
|
With all these data, how do you arrive the question in your topic, i.e. "WTF is this? Someone found a trick for fast mining?"
As said; "Anyone is free to interpret the data and the facts as he wish." Some knowledgeable people argued using the non-uniformity of the distribution of nonces. Ask them why this was necessary. Have a good day Sir. |
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4158
Merit: 8411
|
|
May 06, 2015, 09:00:00 AM |
|
Whatever, but nonces appear uniformly distributed contradicting the arbitrary claims of some people that pretend to be knowledgeable.
HAH. You seem to forget even your own posts so quickly "(except slighty off at the very end of the range)". And I provided specific, concrete examples of the very software and hardware that produces those effects. I also countered your points _assuming_ uniformity, only noting that the distribution was known to be non-uniform and pointing out why; to point out that this assumption was known to be approximate. You might note that I never attempted to characterize the actual non-uniformity, and all the examples I gave were based on uniform numbers. I note, several more days have passed and no more blocks have again matched your criteria--- I was sad to see that you declined to further discuss the "optimization" you discussed after I pointed out that midstate handling is universally used in all mining systems and has for the life of the system. provide data and no comments. Funny, I guess contradicting yourself about uniformity and insulting the knowledge of others must not be comments. Bringing me to why I actually came here to post: Why stopping? It is fun and educational read about how to become a crackpot. It isn't very interesting technically or mathematically, but it is quite educational from the psychological point of view. The cryptocoin community will soon probably need an equivalent of the well-know "crackpot index" from the physics community. http://math.ucr.edu/home/baez/crackpot.htmlActually this was already done a long time ago; https://www.wpsoftware.net/andrew/crackpot.html |
|
|
|
|
|
valiron (OP)
|
|
May 06, 2015, 01:22:33 PM |
|
Whatever, but nonces appear uniformly distributed contradicting the arbitrary claims of some people that pretend to be knowledgeable.
HAH. You seem to forget even your own posts so quickly "(except slighty off at the very end of the range)". And I provided specific, concrete examples of the very software and hardware that produces those effects. I also countered your points _assuming_ uniformity, only noting that the distribution was known to be non-uniform and pointing out why; to point out that this assumption was known to be approximate. You might note that I never attempted to characterize the actual non-uniformity, and all the examples I gave were based on uniform numbers. I note, several more days have passed and no more blocks have again matched your criteria--- I was sad to see that you declined to further discuss the "optimization" you discussed after I pointed out that midstate handling is universally used in all mining systems and has for the life of the system. provide data and no comments. Funny, I guess contradicting yourself about uniformity and insulting the knowledge of others must not be comments. Bringing me to why I actually came here to post: Why stopping? It is fun and educational read about how to become a crackpot. It isn't very interesting technically or mathematically, but it is quite educational from the psychological point of view. The cryptocoin community will soon probably need an equivalent of the well-know "crackpot index" from the physics community. http://math.ucr.edu/home/baez/crackpot.htmlActually this was already done a long time ago; https://www.wpsoftware.net/andrew/crackpot.html Dear Mr Maxwell, Let's try to not make it personal and focus on Technical Discussion for the benefit of the Technical Discussion. I will do my part. The non-uniformity of the nonce distribution at the end of the range is expected because many miners increase the nonce from 0 to 2^32-1 stopping when they find a match, thus it is expected that the end of the range is less frequent. This is what we already pointed out from the beginning jl2012 and myself: Let's look closer at nounces:
We assume that nounces are uniformly distributed (not exactly true since if we start increasingly with nounce 0 they follow a Poisson law, but taking into account that nounce cycles many times before finding the solution it is well approximated by the uniform distribution).
But this non-uniformity at the end of the range on which you focussed is irrelevant for the question discussed. What is relevant for the discussion is to know if the nonce distribution is uniform in the small range where the nonces of these blocks do cluster, which is not at the end near 2^32, but at the middle range around 2^31. This is the reason why I carried further analysis in the neighborhood of this middle point at 2^31 Nounce of block 354641 is within 0.048% of the total range from 2^31.
There are 159 occurences of nounces within an interval of length 2x0.048=0.096% centered at 2^31 which count for 0.11% of the total of 140411.
Nounce of block 354642 is within 0.20% of the total range from 2^31.
There are 577 occurences of nounces within an interval of length 2x0.20=0.4% centered at 2^31 which count for 0.41% of the total of 140411.
There are 14194 nonces within an interval of length 10% from 2^31 whcih count for 10% of the total of 140411.
Nounces appear to be uniformly distributed, in particular around 2^31.
I hope this clarifies things. |
|
|
|
|
jl2012
Legendary
Offline
Activity: 1792
Merit: 1097
|
|
May 06, 2015, 01:33:52 PM |
|
.............
I hope this clarifies things.
I hope everyone don't go off-topic and focus on the question "Someone found a trick for fast mining?" I can't see any clues for supporting this hypothese with your latest data |
Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
|
|
|
|
btchris
|
|
May 06, 2015, 06:11:09 PM |
|
valiron, Nobody's perfect. Everyone is wrong sometimes, even gmaxwell, and even you. But consider for a moment this bar graph:  Either: - You are wrong, and everyone else is right
- You are right, and everyone else is wrong
- Someone has launched a Sybil attack against you
It takes an enlightened individual to conclude that they are likely in err despite that they may not realize why. If 10 people I respect tell me I am wrong, I have to accept that conclusion even if I do not understand why. Of course, I would seek to understand why I am wrong, but it is not the onus of these other 10 people to be my teacher. (The fact that gmaxwell has voluntarily chosen to try to teach you, and has shown so much patience in the process, certainly says something about his character.) I mean no disrespect. I only hope that you can be this type of enlightened individual. |
|
|
|
|
becoin
Legendary
Offline
Activity: 3431
Merit: 1233
|
|
May 06, 2015, 08:39:47 PM |
|
Either: - You are wrong, and everyone else is right
- You are right, and everyone else is wrong
- Someone has launched a Sybil attack against you
Or... Someone has launched a Sybil attack against gmaxell's fan club. |
|
|
|
|
|
altcoinex
|
|
May 06, 2015, 08:44:58 PM |
|
valiron, Either: - You are wrong, and everyone else is right
- You are right, and everyone else is wrong
- Someone has launched a Sybil attack against you
It takes an enlightened individual to conclude that they are likely in err despite that they may not realize why. If 10 people I respect tell me I am wrong, I have to accept that conclusion even if I do not understand why. Of course, I would seek to understand why I am wrong, but it is not the onus of these other 10 people to be my teacher. (The fact that gmaxwell has voluntarily chosen to try to teach you, and has shown so much patience in the process, certainly says something about his character.) I mean no disrespect. I only hope that you can be this type of enlightened individual. As this forum doesn't run on blockchain technology, we cant be sure large corporations or nation state governments havn't affected the data that has gone into this chart. |
╓╢╬╣╣╖
┌║██████║∩
]█████████
╜██████╝`
╙╜╜╜`
╓╥@@@@@@╥╓
╓╖@@╖, ,@║██████████╢@, ,╓@@╖╓
╓╢██████╢. ╓╢███████████████╖ ║╢█████║╓
║█████████ ,,╓╓,, ┌║█████████████████┐ ,,╓╓,, ]█████████
└╢██████║` ╓╢║██████╢║∩``╙╙╙╙╙╙╙╙╙╙╙╙╙╙╙╙╙`»╢╢██████╢║╖ ║███████╜
"╜╜╜╜` ╖╢█████████╣╜ └╢██████████@ `╜╜╜╜╜
║██████████╜ ╙╢██████████
┌█████████╜ ╙╢█████████
└███████╨` ╜████████
║████╨╜ `╢█████
╙╢╣╜ └╢█╜
,, ,,
╓@║██┐ ┌██║@╓
╢██████ ]█████H
╢███████∩ ┌████████
╓@@@@╓ █████████ ║████████` ╓@@@@╖
╓╢██████║. █████████∩ ┌█████████ ,║███████╖
██████████ └█████████ ██████████ ]█████████
`║██████╜` └╢████████ ┌███████╣╜ ╙██████╨`
`╙╜╜╙` `╙╨╢████ █████╝╜` `╙╜╜`
]@╓ ╓╖H
███╢║@╓, ,╓@╢╢███`
████████╢@╖╓. ╓╖@║████████`
]███████████╢║@╓, ,╓@╢╢████████████
╙╢█████████████╨` ╜██████████████╜
╙╝╢███████║╜` `╜║████████╝╜`
,╓@@@╓ `²╙`` `╙²` ╓@@@╖,
║╢█████╢H ╓╢██████H
█████████ █████████`
╙╢██████╜ ╙╢██████╜
└╨╩╝┘ └╨╩╝╜ | WINFLOW | . |
██
██
██
██
██
██
██
██
██
██
██
██
██
| . | | . |
██
██
██
██
██
██
██
██
██
██
██
██
██
| . | |
|
|
|
|
btchris
|
|
May 06, 2015, 09:00:10 PM |
|
- [or] Someone has launched a Sybil attack against you [valiron]
Or...
Someone has launched a Sybil attack against gmaxell's fan club.
I don't understand.... I was trying to imply "we're all alts of of gmaxwell" as being the third option (however unlikely IMO). As this forum doesn't run on blockchain technology, we cant be sure large corporations or nation state governments havn't affected the data that has gone into this chart.
Into my "chart"? I'd rather think that if a government wanted to pollute this thread with puppets, they'd all be in support of valiron's FUD, not against it. |
|
|
|
|
becoin
Legendary
Offline
Activity: 3431
Merit: 1233
|
|
May 06, 2015, 09:44:10 PM |
|
If 10 people I respect tell me I am wrong, I have to accept that conclusion even if I do not understand why. Couple of years ago when I said BFL are crooks and low life 10 people I respected (incl. mods) told me I was wrong. They were just bribed by BFL to do so. At that time mods were not in a hurry to label BFL as scammers. If we brush off all the pseudo scientific gibberish what gmaxell is basically saying we should treat all the irregularities as regular because of the big figures. Do we have to accept this knowledgeable explanation and move on just for the sake of protecting bitcoin from possible FUD? |
|
|
|
|
|
valiron (OP)
|
|
May 06, 2015, 09:51:00 PM
Last edit: May 06, 2015, 10:03:00 PM by valiron |
|
Scanning the blockchain for nearby consecutive nonces we find 1 more ocurrence (starting at block 323246) of three consecutive closeness of less than 1.8% and 0.12% and 7.2% among the 140411 post 2013 blocks. The expected value is to not find any 4 out of 5 times since 144411*0.0012*0.018*0.072=0.218.
Now we relax the search and look for only 2 consecutive closeness. Scanning the blockchain for nearby consecutive nounces we find 15 ocurrences of two consecutive closeness of less than 1.8% and 0.12% among the 140411 post 2013 blocks. The expected value is 140411*0.0012*0.018=3, thus there are 5 times more occurrences than expected.
Some of these occurrences like to be abnormally near 2^30. For example:
Block 237144 nonce 1076288193
Block 237145 nonce 999124565
Block 237146 nonce 997353929
|nonce(237144)-nonce(2372145)|= 1.8% of total range
|nonce(237145)-nonce(2372146)|= 0.04% of total range
and....nonce(237144) is within 0.059% of total range from 2^30=1073741824
...nonce(237145) is within 1.74% of total range from 2^30
...nonce(237146) is within 1.78% of total range from 2^30
Block 345506 nonce 1121422642
Block 345507 nonce 1050751563
Block 345508 nonce 1052220753
|nonce(345506)-nonce(345507)|= 1.6% of total range
|nonce(345507)-nonce(345508)|= 0.03% of total range
and....nonce(345506) is within 1.11% of total range from 2^30=1073741824
...nonce(345507) is within 0.53% of total range from 2^30
...nonce(345508) is within 0.50% of total range from 2^30
|
|
|
|
|
|
valiron (OP)
|
|
May 06, 2015, 10:12:09 PM
Last edit: May 06, 2015, 10:55:02 PM by valiron |
|
If 10 people I respect tell me I am wrong, I have to accept that conclusion even if I do not understand why. Couple of years ago when I said BFL are crooks and low life 10 people I respected (incl. mods) told me I was wrong. They were just bribed by BFL to do so. At that time mods were not in a hurry to label BFL as scammers. If we brush off all the pseudo scientific gibberish what gmaxell is basically saying we should treat all the irregularities as regular because of the big figures. Do we have to accept this knowledgeable explanation and move on just for the sake of protecting bitcoin from possible FUD? Bribed mods? I mean no disrespect. I only hope that you can be this type of enlightened individual.
Sorry, but I can't agree. Enlightened individual is whoever thinks by himself, and not who follows blindly a leader or guru. I believe the proper thing to do is to have a brain and think by yourself. "The majority is always wrong; the minority is rarely right." Henrik Ibsen. "To doubt everything or to believe everything are two equally convenient solutions; both dispense with the necessity of reflection." Henry Poincaré The data is there for anyone to analyze and reach conclusions if these are normal statistical anomalies or far out of normal. Statistics are tricky and one needs to have some intuition and expertise about it to not confuse normal rare statistical deviations from irregular ones. Irregular ones are detected because of coincidence of various independent indications. Someone can come and claim that he found a collision with a bitcoin address in the blockchain. We know that mathematically speaking this is imposible and we may call this guy a liar and a fool. But we know that defective implementations of wallets with not enough entropy can indeed duplicate addresses. I don't want to enter into the question if gmaxwell or I are right or wrong. This always deviates into a stupid fight of egos. The data is there and everyone can reach its own conclusions about the possibilities. No hardfeelings. No stress. Don't need to get your blood boiling.And finally...if you don’t believe me or don’t get it, I don’t have time to try to convince you, sorry. |
|
|
|
|
|
btchris
|
|
May 06, 2015, 10:40:12 PM |
|
If 10 people I respect tell me I am wrong, I have to accept that conclusion even if I do not understand why. Couple of years ago when I said BFL are crooks and low life 10 people I respected (incl. mods) told me I was wrong. They were just bribed by BFL to do so. That's a good first step, you've just admitted that you are capable, like the rest of us, of making mistakes (nobody should be respecting 10 people all of whom are easily bribed). If we brush off all the pseudo scientific gibberish what gmaxell is basically saying we should treat all the irregularities as regular because of the big figures. Do we have to accept this knowledgeable explanation and move on
Absolutely not! However your rational are choices are limited. As with any argument based in science or logic, you can either: - Educate/fund yourself to the point where you can make investigations and an assessment on your own, or
- Ask someone you trust who has the relevant education/funding for their opinion.
I have never, not once, been into space. Yet I still believe there is (practically) no air in space. This is mostly as a result of the second choice above. When it comes to this particular thread, I have enough of a background in math to easily follow gmaxwell's reasoning, and to largely dismiss valiron's. The larger problem is the hubris which valiron seems to be displaying. If valiron were a troll, this would be expected. If valiron is simply having trouble following gmaxwell's reasoning, s/he should take a moment to consider that maybe s/he wrong, given the number of opponents there are. |
|
|
|
|
|
altcoinex
|
|
May 07, 2015, 01:54:57 AM |
|
Is it just me, or is it silly to consider the nonce without considering the rest of the data in the block header?
Edit: Perhaps OP could provide detail on the merkleroot and transactions of the blocks in question.... I mean, if they were empty blocks it would indeed be suspect, but to produce a valid nonce and still manage to include a solid transaction set from the pool, come on now....
|
╓╢╬╣╣╖
┌║██████║∩
]█████████
╜██████╝`
╙╜╜╜`
╓╥@@@@@@╥╓
╓╖@@╖, ,@║██████████╢@, ,╓@@╖╓
╓╢██████╢. ╓╢███████████████╖ ║╢█████║╓
║█████████ ,,╓╓,, ┌║█████████████████┐ ,,╓╓,, ]█████████
└╢██████║` ╓╢║██████╢║∩``╙╙╙╙╙╙╙╙╙╙╙╙╙╙╙╙╙`»╢╢██████╢║╖ ║███████╜
"╜╜╜╜` ╖╢█████████╣╜ └╢██████████@ `╜╜╜╜╜
║██████████╜ ╙╢██████████
┌█████████╜ ╙╢█████████
└███████╨` ╜████████
║████╨╜ `╢█████
╙╢╣╜ └╢█╜
,, ,,
╓@║██┐ ┌██║@╓
╢██████ ]█████H
╢███████∩ ┌████████
╓@@@@╓ █████████ ║████████` ╓@@@@╖
╓╢██████║. █████████∩ ┌█████████ ,║███████╖
██████████ └█████████ ██████████ ]█████████
`║██████╜` └╢████████ ┌███████╣╜ ╙██████╨`
`╙╜╜╙` `╙╨╢████ █████╝╜` `╙╜╜`
]@╓ ╓╖H
███╢║@╓, ,╓@╢╢███`
████████╢@╖╓. ╓╖@║████████`
]███████████╢║@╓, ,╓@╢╢████████████
╙╢█████████████╨` ╜██████████████╜
╙╝╢███████║╜` `╜║████████╝╜`
,╓@@@╓ `²╙`` `╙²` ╓@@@╖,
║╢█████╢H ╓╢██████H
█████████ █████████`
╙╢██████╜ ╙╢██████╜
└╨╩╝┘ └╨╩╝╜ | WINFLOW | . |
██
██
██
██
██
██
██
██
██
██
██
██
██
| . | | . |
██
██
██
██
██
██
██
██
██
██
██
██
██
| . | |
|
|
|
|
valiron (OP)
|
|
May 07, 2015, 05:38:56 AM |
|
Is it just me, or is it silly to consider the nonce without considering the rest of the data in the block header?
Edit: Perhaps OP could provide detail on the merkleroot and transactions of the blocks in question.... I mean, if they were empty blocks it would indeed be suspect, but to produce a valid nonce and still manage to include a solid transaction set from the pool, come on now....
These blocks are not empty, empty blocks are another business. You don't fabricate the nonce from the rest of the block, these nonces could be not the main dynamic variable for the purpose of mining, and you may start testing nonces starting from some nonce with many zero bits for some reason. |
|
|
|
|
|
altcoinex
|
|
May 07, 2015, 04:28:21 PM |
|
Is it just me, or is it silly to consider the nonce without considering the rest of the data in the block header?
Edit: Perhaps OP could provide detail on the merkleroot and transactions of the blocks in question.... I mean, if they were empty blocks it would indeed be suspect, but to produce a valid nonce and still manage to include a solid transaction set from the pool, come on now....
These blocks are not empty, empty blocks are another business. You don't fabricate the nonce from the rest of the block, these nonces could be not the main dynamic variable for the purpose of mining, and you may start testing nonces starting from some nonce with many zero bits for some reason. But you DO fabricate the block hash from the Block Header, which includes the other data in addition to the nonce. It is this hash, not a hash of the nonce itself that has to beat the Target. I am not sure if you understand how hashing works to suggest that with entirely different block header data a similar nonce could be exploiting the end hash. |
╓╢╬╣╣╖
┌║██████║∩
]█████████
╜██████╝`
╙╜╜╜`
╓╥@@@@@@╥╓
╓╖@@╖, ,@║██████████╢@, ,╓@@╖╓
╓╢██████╢. ╓╢███████████████╖ ║╢█████║╓
║█████████ ,,╓╓,, ┌║█████████████████┐ ,,╓╓,, ]█████████
└╢██████║` ╓╢║██████╢║∩``╙╙╙╙╙╙╙╙╙╙╙╙╙╙╙╙╙`»╢╢██████╢║╖ ║███████╜
"╜╜╜╜` ╖╢█████████╣╜ └╢██████████@ `╜╜╜╜╜
║██████████╜ ╙╢██████████
┌█████████╜ ╙╢█████████
└███████╨` ╜████████
║████╨╜ `╢█████
╙╢╣╜ └╢█╜
,, ,,
╓@║██┐ ┌██║@╓
╢██████ ]█████H
╢███████∩ ┌████████
╓@@@@╓ █████████ ║████████` ╓@@@@╖
╓╢██████║. █████████∩ ┌█████████ ,║███████╖
██████████ └█████████ ██████████ ]█████████
`║██████╜` └╢████████ ┌███████╣╜ ╙██████╨`
`╙╜╜╙` `╙╨╢████ █████╝╜` `╙╜╜`
]@╓ ╓╖H
███╢║@╓, ,╓@╢╢███`
████████╢@╖╓. ╓╖@║████████`
]███████████╢║@╓, ,╓@╢╢████████████
╙╢█████████████╨` ╜██████████████╜
╙╝╢███████║╜` `╜║████████╝╜`
,╓@@@╓ `²╙`` `╙²` ╓@@@╖,
║╢█████╢H ╓╢██████H
█████████ █████████`
╙╢██████╜ ╙╢██████╜
└╨╩╝┘ └╨╩╝╜ | WINFLOW | . |
██
██
██
██
██
██
██
██
██
██
██
██
██
| . | | . |
██
██
██
██
██
██
██
██
██
██
██
██
██
| . | |
|
|
|
|
valiron (OP)
|
|
May 07, 2015, 06:20:55 PM |
|
Is it just me, or is it silly to consider the nonce without considering the rest of the data in the block header?
Edit: Perhaps OP could provide detail on the merkleroot and transactions of the blocks in question.... I mean, if they were empty blocks it would indeed be suspect, but to produce a valid nonce and still manage to include a solid transaction set from the pool, come on now....
These blocks are not empty, empty blocks are another business. You don't fabricate the nonce from the rest of the block, these nonces could be not the main dynamic variable for the purpose of mining, and you may start testing nonces starting from some nonce with many zero bits for some reason. But you DO fabricate the block hash from the Block Header, which includes the other data in addition to the nonce. It is this hash, not a hash of the nonce itself that has to beat the Target. I am not sure if you understand how hashing works to suggest that with entirely different block header data a similar nonce could be exploiting the end hash. I don't think you understand my previous message. What I am saying is that a reason to have these nonces near some value is that you don't change too much the nonce and you start from this value, and for solving the block you change other fields. |
|
|
|
|
DannyHamilton
Legendary
Offline
Activity: 3388
Merit: 4653
|
|
May 07, 2015, 06:51:02 PM |
|
- snip -
for solving the block you change other fields.
There aren't very many other fields to change. That's why the block has a nonce in the first place. There's nothing special or magical about changing the nonce, it's just 4 bytes added to the header specifically for the purpose of being very fast and easy to change. The other fields of the block header are: - The block version number. This 4 byte field cannot be changed without invalidating the block you are mining.
- The hash of the previous block in the chain. This 32 byte field cannot be changed without invalidating the block you are mining.
- The merkle root of the transaction list. This 32 byte field cannot be changed without modifying or rearranging the transactions in your transaction list. This would be a MUCH slower and more complicated thing to change than the nonce. However, a pool will create MANY different merkle roots (by modifying the extranonce in the coinbase transaction) so that they can give a different block header to each miner. This allows each individual miner to only need to deal with the nonce (and timestamp) and not need to recompute the entire merkle root. It is also possible for the pool to provide enough information for individual miners to modify the extranonce themselves along with the nonce. Keep in mind though that modfying the extranonce increases the time and effort involved, so it makes more sense to exhaust the nonce range available to the equipment before making any effort to move on to a new extranonce.
- The timestamp. This is a 4 byte field that some miners change after they've run out of nonces. It essentially becomes a secondary nonce. However, it is very limited on allowable ranges. Since the miner would need to test to make sure a value is within the allowable range before hashing the block, it very slightly increases the effort as compared to simply using the usual nonce. If someone chooses to modify this instead of the nonce (or while keeping the nonce in a tight range), then this field BECOMES a nonce. There is no benefit of manipulating these 4 bytes instead of the other 4 bytes.
- The current difficulty (represented as "bits"). This 4 byte field cannot be changed without invalidating the block you are mining.
- The nonce. This 4 byte field exists solely so that is is fast and easy to modify the header before hashing it again. It serves no other purpose, and has no restrictions on its value. This is also the field that you are saying NOT to change when "you change other fields".
That's 4 bytes + 32 bytes + 32 bytes + 4 bytes + 4 bytes + 4 bytes = 80 bytes. That's it. There's the 80 bytes that are hashed during mining. I'm very curious to know which of those fields you think might be better to change instead of the nonce? Those in red cannot be changed without invalidating the block. Those in green are already manipulated as part of the typical mining process, and the typical mining process already manipulates them in the most efficient order. If there is a benefit to manipulating the timestamp or merkle root INSTEAD of the nonce, I'd be very curious to know what you think that benefit might be. I'm not certain, but I don't think you can adjust the merkle root without needing to recompute the midstate as well? |
|
|
|
|
|
btchris
|
|
May 07, 2015, 10:16:11 PM |
|
I'm not certain, but I don't think you can adjust the merkle root without needing to recompute the midstate as well?
You're right, the merkle root spans both SHA-256 (512-bit) blocks, so you must recalc the entire SHA-256 from scratch. | Byte len | Byte pos | Bit pos | SHA block | Field | | 4 | 0 | 0 | 1 | version | | 32 | 4 | 32 | 1 | previous block header hash | | 32 | 36 | 288 | 1-2 | merkle roothash | | 4 | 68 | 544 | 2 | time | | 4 | 72 | 576 | 2 | nBits | | 4 | 76 | 608 | 2 | nonce | | 80 | 640 | | (end) |
|
|
|
|
|
timothythomas
Newbie
Offline
Activity: 27
Merit: 0
|
|
May 08, 2015, 12:18:51 AM |
|
i have always wondered about this thing also ... like i wanted to ask about pools how f2pool is always finding more blocks then antpool and others .. is it merely coz of it having a more hash power ? or its just being lucky ?
|
|
|
|
|
|
smolen
|
|
May 08, 2015, 01:09:29 AM |
|
The block version number. This 4 byte field cannot be changed without invalidating the block you are mining.
Hmm, this 32 bit signed integer must be greater or equal to the current block version. Plenty of space here. Discussed on github: No forking Extra nonce added to Bitcoin headerThe merkle root of the transaction list. This 32 byte field cannot be changed without modifying or rearranging the transactions in your transaction list. This would be a MUCH slower and more complicated thing to change than the nonce.
Swapping nodes in Merkle tree seems to be cheaper than increasing extranonce2, but worse than increasing nonce or time. |
Of course I gave you bad advice. Good one is way out of your price range.
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4158
Merit: 8411
|
|
May 08, 2015, 01:30:11 AM |
|
I believe Danny's point was that it invalidated the midstate to change it. |
|
|
|
|
|
smolen
|
|
May 08, 2015, 02:24:34 AM |
|
I believe Danny's point was that it invalidated the midstate to change it. Oh, wait, I'm not going to prove someone wrong. This thread become quite nice mix of math and conspirology, that's very fine, let's continue If there exist some algebraic attack that breaks two rounds of SHA256 (and OP is hunting for it with statistics), it's quite possible that the variant of such attack will bypass midstate and break 3 rounds, from 640 bit header to nonce. So the next suspicious thing are unusual block versions in the blockchain. |
Of course I gave you bad advice. Good one is way out of your price range.
|
|
|
2112
Legendary
Offline
Activity: 2128
Merit: 1068
|
|
May 08, 2015, 03:17:42 AM |
|
quite nice mix of math and conspirology, that's very fine, let's continue I'm not satisfied with calling the psychological aspect "conspirology". My current thinking is that many people here can't really understand either mathematical or software engineering aspects of Bitcoin. For them it becomes a sort of gnostic theological experience, even if they claim to be atheistic. In this thread they will search for a (bad) influence of demiurge who corrupts their ideal. In the nearby threads by no-ice-please we observe a dissatisfaction with insufficiently immaculate conception of SHA256 algorithms. I hate to call them all "trolls". I can settle for "crackpots", because this seems to be the prevailing practice in the scientific fields. But theologians would simply call them "heretics", purveyors of the "bad theology". In very broad term, what we are searching in those threads is a way to communicate with people who'll never have time, knowledge, skills and motivation to completely understand the inner details of Bitcoin. Is there way to maintain the dialogue between the two groups? |
|
|
|
DannyHamilton
Legendary
Offline
Activity: 3388
Merit: 4653
|
|
May 08, 2015, 04:19:12 AM |
|
I believe Danny's point was that it invalidated the midstate to change it. Nah, I'll own up to making a mistake there. For some reason, I thought that there were specific Block version numbers that were acceptable under the consensus rules. I guess I just learned something new. I'll read up on it a bit more. So, you guys are saying that the block version number CAN be used as a nonce? In that case, as gmaxwell states, it still has the effect of forcing you to recompute the midstate, so there isn't a benefit to modifying this INSTEAD of the nonce. |
|
|
|
|
|
Sergio_Demian_Lerner
|
|
May 08, 2015, 04:42:42 AM |
|
I think gmaxwell is right, there is not enough evidence in those 4 blocks to suggest that there has been a breakthrough in mining ASICs.
On the other hand I guess valiron is also right, he knows (and probably can't disclose) that some mining companies may be testing new tricks to improve their ASIC hashing power. Maybe he hacked into one company computer or he was told by a friend who works in one of them and he promised not to say anything.
Mining companies want to maximize their profits and they are not obligated to disclose their engineering achievements. Those are trade secrets and nobody has ever complained about ASIC Mining companies having close designs. I don't even think that the Bitcoin community can even enforce ASIC companies to open their designs, because they are already using other companies IPs that they can't disclose, and because they can always go anonymous to avoid disclosing anything.
There is plenty of technical information put together in this long thread (given by gmaxwell explicitly, and DannyHamilton's analysis on which parts of the block header can be used as nonce, and my very old posts about modifications to the Bitcoin header) to ease you discover one of such tricks. Take some time to think about it, take aside all posts with personal insults, and you'll probably find the solution right in front of your eyes.
I'm not that clever so there may be more tricks to discover.
However, a trick can only give you a certain speedup, say 20%, based on a reorganization of the SHA256D operations, or the pre-computation of some operations that change less often. Other changes (such as reducing the fabrication node) can give you much higher speedups. So this isn't alarming.
A completely different thing is to find a way to invert SHA256D, which I'm absolutely sure nobody will ever be able to do without some revolutionary quantum computer that does not exists even in theory.
The only attack I was thinking of when I wrote the Bitcoin header post, was all mining companies adopting tricks that give them some little advantage, but at the same time they degrade the performance of the network as a by-product. One of such attacks is cited when I posted about using approximate adders, and the danger that a monoculture of approximate ASICs can get stuck in a header that always generates a faulty addition.
If such problem ever arises, the community will probably find the way out by doing the right hard fork to prevent it.
IMHO the cryptographic security of SHA256D function of Bitcoin will never be seriously compromised.
However if there were a single mining company manufacturing ASICs being 200% faster than the competition, that would clearly hurt Bitcoin in a practical econo-socio-political way. The good news is that the accumulation of tricks probably will never reach such an improvement.
Best regards,
Sergio.
|
|
|
|
|
|
valiron (OP)
|
|
May 08, 2015, 09:24:51 AM
Last edit: May 08, 2015, 09:57:03 AM by valiron |
|
- snip -
for solving the block you change other fields.
There aren't very many other fields to change. That's why the block has a nonce in the first place. There's nothing special or magical about changing the nonce, it's just 4 bytes added to the header specifically for the purpose of being very fast and easy to change. The other fields of the block header are: - The block version number. This 4 byte field cannot be changed without invalidating the block you are mining.
- The hash of the previous block in the chain. This 32 byte field cannot be changed without invalidating the block you are mining.
- The merkle root of the transaction list. This 32 byte field cannot be changed without modifying or rearranging the transactions in your transaction list. This would be a MUCH slower and more complicated thing to change than the nonce. However, a pool will create MANY different merkle roots (by modifying the extranonce in the coinbase transaction) so that they can give a different block header to each miner. This allows each individual miner to only need to deal with the nonce (and timestamp) and not need to recompute the entire merkle root. It is also possible for the pool to provide enough information for individual miners to modify the extranonce themselves along with the nonce. Keep in mind though that modfying the extranonce increases the time and effort involved, so it makes more sense to exhaust the nonce range available to the equipment before making any effort to move on to a new extranonce.
- The timestamp. This is a 4 byte field that some miners change after they've run out of nonces. It essentially becomes a secondary nonce. However, it is very limited on allowable ranges. Since the miner would need to test to make sure a value is within the allowable range before hashing the block, it very slightly increases the effort as compared to simply using the usual nonce. If someone chooses to modify this instead of the nonce (or while keeping the nonce in a tight range), then this field BECOMES a nonce. There is no benefit of manipulating these 4 bytes instead of the other 4 bytes.
- The current difficulty (represented as "bits"). This 4 byte field cannot be changed without invalidating the block you are mining.
- The nonce. This 4 byte field exists solely so that is is fast and easy to modify the header before hashing it again. It serves no other purpose, and has no restrictions on its value. This is also the field that you are saying NOT to change when "you change other fields".
That's 4 bytes + 32 bytes + 32 bytes + 4 bytes + 4 bytes + 4 bytes = 80 bytes. That's it. There's the 80 bytes that are hashed during mining. I'm very curious to know which of those fields you think might be better to change instead of the nonce? Those in red cannot be changed without invalidating the block. Those in green are already manipulated as part of the typical mining process, and the typical mining process already manipulates them in the most efficient order. If there is a benefit to manipulating the timestamp or merkle root INSTEAD of the nonce, I'd be very curious to know what you think that benefit might be. I'm not certain, but I don't think you can adjust the merkle root without needing to recompute the midstate as well? The intention of my comment was that if mining in a classical way with repetitive trials it doesn't make sense to not change the nonce for that purpose. What I was observing is that if we find evidence of someone fast mining without changing much the nonce, it probably means that he is mining in a non-classical way. As pointed out the version number can be changed quite freely, but be safe, gmaxwell will fork if this happens, you can find a discusion of header malleability here: https://bitcointalk.org/index.php?topic=563913.0 |
|
|
|
|
|
valiron (OP)
|
|
May 08, 2015, 09:55:09 AM |
|
I think gmaxwell is right, there is not enough evidence in those 4 blocks to suggest that there has been a breakthrough in mining ASICs.
On the other hand I guess valiron is also right, he knows (and probably can't disclose) that some mining companies may be testing new tricks to improve their ASIC hashing power. Maybe he hacked into one company computer or he was told by a friend who works in one of them and he promised not to say anything.
Mining companies want to maximize their profits and they are not obligated to disclose their engineering achievements. Those are trade secrets and nobody has ever complained about ASIC Mining companies having close designs. I don't even think that the Bitcoin community can even enforce ASIC companies to open their designs, because they are already using other companies IPs that they can't disclose, and because they can always go anonymous to avoid disclosing anything.
There is plenty of technical information put together in this long thread (given by gmaxwell explicitly, and DannyHamilton's analysis on which parts of the block header can be used as nonce, and my very old posts about modifications to the Bitcoin header) to ease you discover one of such tricks. Take some time to think about it, take aside all posts with personal insults, and you'll probably find the solution right in front of your eyes.
I'm not that clever so there may be more tricks to discover.
However, a trick can only give you a certain speedup, say 20%, based on a reorganization of the SHA256D operations, or the pre-computation of some operations that change less often. Other changes (such as reducing the fabrication node) can give you much higher speedups. So this isn't alarming.
A completely different thing is to find a way to invert SHA256D, which I'm absolutely sure nobody will ever be able to do without some revolutionary quantum computer that does not exists even in theory.
The only attack I was thinking of when I wrote the Bitcoin header post, was all mining companies adopting tricks that give them some little advantage, but at the same time they degrade the performance of the network as a by-product. One of such attacks is cited when I posted about using approximate adders, and the danger that a monoculture of approximate ASICs can get stuck in a header that always generates a faulty addition.
If such problem ever arises, the community will probably find the way out by doing the right hard fork to prevent it.
IMHO the cryptographic security of SHA256D function of Bitcoin will never be seriously compromised.
However if there were a single mining company manufacturing ASICs being 200% faster than the competition, that would clearly hurt Bitcoin in a practical econo-socio-political way. The good news is that the accumulation of tricks probably will never reach such an improvement.
Best regards,
Sergio.
Thank you for your post Sergio. In particular for focussing on the technical part. First, let me disclaim: I have any no inside information nor I have hacked into anyone's computer. I just use my brain and my mathematical background. Second, I subscribe your comments, in particular that these statistical facts are not proof of anything. They are only indications. Also that, as you stated and I have repeated, bitcoin security will not be compromised by a boost in mining performance. Third, I thank you for the humility of your post. We are not all that clever and there may be tricks that we never dreamed of. Thus I think the community must be on the lookup for statistical anomalies that may reveal a breakthrough. |
|
|
|
|
|
valiron (OP)
|
|
May 08, 2015, 10:04:38 AM |
|
There is plenty of technical information put together in this long thread (given by gmaxwell explicitly, and DannyHamilton's analysis on which parts of the block header can be used as nonce, and my very old posts about modifications to the Bitcoin header) to ease you discover one of such tricks. Take some time to think about it, take aside all posts with personal insults, and you'll probably find the solution right in front of your eyes.
Be careful...you are stating that you known things that you are not disclosing...this will infuriate some people that will accuse you of threatening bitcoin security. Do you mean also that gmaxwell knows some tricks and he is not discussing them? I believe anyone is free to discuss or not discuss whatever he knows. I also believe that the only way to discuss freely anything is not to be put in the position "You must prove that you are not a charlatan" position. |
|
|
|
|
2112
Legendary
Offline
Activity: 2128
Merit: 1068
|
|
May 08, 2015, 03:49:52 PM |
|
The only attack I was thinking of when I wrote the Bitcoin header post, was all mining companies adopting tricks that give them some little advantage, but at the same time they degrade the performance of the network as a by-product. One of such attacks is cited when I posted about using approximate adders, and the danger that a monoculture of approximate ASICs can get stuck in a header that always generates a faulty addition.
Thinking out-of-the-box has both good and bad aspects: +) on the positive side it allows novel and unusual solutions to enter the field, like your idea of intentionally breaking the topmost level in the carry-look-ahead login of a 32-bit parallel adder, which you called "approximate addition" -) on the negative side it disconnects one from the already known solutions in the field. Some EDA tools already can split a 32-bit adder in a critical path into a pipelined pair of 16-bit parallel adders. The general methodology is called "register balancing" or "delay balancing". You've made a far-reaching statements about a possibility or necessity of changing Bitcoin hashing algorithm in the face of your discovery. Have you consulted your discovery in private with somebody knowledgeable with digital logic design? What did they say? |
|
|
|
|
altcoinex
|
|
May 08, 2015, 05:52:54 PM |
|
I believe anyone is free to discuss or not discuss whatever he knows. I also believe that the only way to discuss freely anything is not to be put in the position "You must prove that you are not a charlatan" position.
If I recall this started because you suggested in your original thread you uniquely 'knew' something but for the security of bitcoin wern't yet ready to reveal... Now it is simply 'there are some nonces near eachother, that means someones exploiting mining clearly' with out any technical proof or explanation on how it would be possible. You might not have to prove your not a charlatan, but if your going to make an accusation, and even go as far as to allude you know a secret, then you have to prove it has some validity.... |
╓╢╬╣╣╖
┌║██████║∩
]█████████
╜██████╝`
╙╜╜╜`
╓╥@@@@@@╥╓
╓╖@@╖, ,@║██████████╢@, ,╓@@╖╓
╓╢██████╢. ╓╢███████████████╖ ║╢█████║╓
║█████████ ,,╓╓,, ┌║█████████████████┐ ,,╓╓,, ]█████████
└╢██████║` ╓╢║██████╢║∩``╙╙╙╙╙╙╙╙╙╙╙╙╙╙╙╙╙`»╢╢██████╢║╖ ║███████╜
"╜╜╜╜` ╖╢█████████╣╜ └╢██████████@ `╜╜╜╜╜
║██████████╜ ╙╢██████████
┌█████████╜ ╙╢█████████
└███████╨` ╜████████
║████╨╜ `╢█████
╙╢╣╜ └╢█╜
,, ,,
╓@║██┐ ┌██║@╓
╢██████ ]█████H
╢███████∩ ┌████████
╓@@@@╓ █████████ ║████████` ╓@@@@╖
╓╢██████║. █████████∩ ┌█████████ ,║███████╖
██████████ └█████████ ██████████ ]█████████
`║██████╜` └╢████████ ┌███████╣╜ ╙██████╨`
`╙╜╜╙` `╙╨╢████ █████╝╜` `╙╜╜`
]@╓ ╓╖H
███╢║@╓, ,╓@╢╢███`
████████╢@╖╓. ╓╖@║████████`
]███████████╢║@╓, ,╓@╢╢████████████
╙╢█████████████╨` ╜██████████████╜
╙╝╢███████║╜` `╜║████████╝╜`
,╓@@@╓ `²╙`` `╙²` ╓@@@╖,
║╢█████╢H ╓╢██████H
█████████ █████████`
╙╢██████╜ ╙╢██████╜
└╨╩╝┘ └╨╩╝╜ | WINFLOW | . |
██
██
██
██
██
██
██
██
██
██
██
██
██
| . | | . |
██
██
██
██
██
██
██
██
██
██
██
██
██
| . | |
|
|
|
|
Sergio_Demian_Lerner
|
|
May 08, 2015, 07:14:51 PM |
|
The only attack I was thinking of when I wrote the Bitcoin header post, was all mining companies adopting tricks that give them some little advantage, but at the same time they degrade the performance of the network as a by-product. One of such attacks is cited when I posted about using approximate adders, and the danger that a monoculture of approximate ASICs can get stuck in a header that always generates a faulty addition.
Thinking out-of-the-box has both good and bad aspects: +) on the positive side it allows novel and unusual solutions to enter the field, like your idea of intentionally breaking the topmost level in the carry-look-ahead login of a 32-bit parallel adder, which you called "approximate addition" -) on the negative side it disconnects one from the already known solutions in the field. Some EDA tools already can split a 32-bit adder in a critical path into a pipelined pair of 16-bit parallel adders. The general methodology is called "register balancing" or "delay balancing". You've made a far-reaching statements about a possibility or necessity of changing Bitcoin hashing algorithm in the face of your discovery. Have you consulted your discovery in private with somebody knowledgeable with digital logic design? What did they say? No many people read my blog, so nothing I say is "far-reaching" And I still think it would be better to change the Bitcoin header. But every bitcoiner wants to change Bitcoin in some way or the other, so I'm not alone. I promise I will write why I still think so in less than a month. I don't have time now. Regarding consulting about discoveries, I hadn't consulted with anybody regarding the approximate adders, and that was not a good idea. I received a call the next day from the CEO of a well-known Bitcoin ASIC company telling me that my idea combined with their own optimizations would make their chips a lot faster. If I had consulted with an expert about the advantages of approximate addition in some designs I would have tried to sell the idea for some bucks instead of just publishing it Best regards, |
|
|
|
|
2112
Legendary
Offline
Activity: 2128
Merit: 1068
|
|
May 08, 2015, 08:24:47 PM |
|
I received a call the next day from the CEO of a well-known Bitcoin ASIC company telling me that my idea combined with their own optimizations would make their chips a lot faster.
My experience now shows that a necessary condition for being a "CEO of a well-known Bitcoin ASIC company" is to understand very little about digital logic design and compensate this with chutzpah. All publicly available information points to them having only part-time design talent or to making drastic shortcuts to the design workflow. In particular the statement about "a lot faster" in a "next day" call, without running the simulations, points me to some bullshit artist. I can only commiserate with you about not having any trusted friend to discuss your ideas without being worried about them being stolen. Thankfully I'm not in this position and have some contacts who wouldn't jeopardize friendship for a quick sale. |
|
|
|
bitcoinbeliever
Newbie
Offline
Activity: 54
Merit: 0
|
|
May 09, 2015, 10:39:49 PM |
|
No many people read my blog, so nothing I say is "far-reaching" More should read your blog Sergio, original thinking deserves a loud voice. At least post the link next time! I'll do it for you this time... https://bitslog.wordpress.com/ |
|
|
|
|
|
valiron (OP)
|
|
May 10, 2015, 08:46:05 AM |
|
Now about one transaction blocks...
Some statistics about post 2013 one transaction blocks
=========================================
Mean blocktime validation of one transaction blocks: 106 sec (with sd 300 sec)
Mean blocktime validation of post 2013 blocks: 525 sec (with sd 557 sec)
One transaction blocks are validated 5 times faster than regular blocks.
17.4% of one transaction blocks have non chronological timestamps vs. 4.6% of all blocks (post 2013) (about 4 times more)
Anyone running a node can provide a database of reception timestamps of validated blocks? (local reception timestamp)
Shorter validation time for one transaction blocks is expected for miners that start mining the empty block then keep adding transactions. Abundance of non-chronological timestamp may indicate that timestamp is partially used as nonce in these blocks.
|
|
|
|
|
BlueInCoin
Newbie
Offline
Activity: 14
Merit: 0
|
|
May 10, 2015, 03:43:46 PM |
|
This person just have the luckiest day in his life  |
|
|
|
|
crazyearner
Legendary
Offline
Activity: 1820
Merit: 1001
|
|
May 10, 2015, 08:37:19 PM |
|
Think this is all due to luck in all honesty than a brake though in asic mining. If it happens several times and continues to happen then maybe a trick indeed but right now seems just pre lucky to me with the findings and what is being said on here.
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4158
Merit: 8411
|
|
May 10, 2015, 09:00:07 PM |
|
Mean blocktime validation of one transaction blocks:
[...]
Shorter validation time for one transaction blocks is expected for miners
It is unclear to me what you are talking about. What specifically are you referring to by "blocktime validation"? Are you talking about the ntime gaps? Blocks of very slow miners should have lower timestamps because they do not frequently update their midstate (e.g. they would claim older times because that was when they started); modern fast miners blow through the range quickly, and thus have plenty of opportunities to increment their time. (Much of the single tx blocks back then were believed to be a botnet that verified nothing). If you are saying smaller blocks take less time to validate largely. This is mostly untrue at the tip of the chain. Leave your node running for 24-48 hours and then look at the block verification times. You'll see that the actual blocks, in spite of being huge, typically verify in a few milliseconds (-benchmark will enable ms resolution timing results in the logs). This is because almost all the verification is cached from the transactions being relayed earlier. |
|
|
|
|
|
btchris
|
|
May 10, 2015, 09:45:37 PM |
|
Shorter validation time for one transaction blocks is expected for miners
It is unclear to me what you are talking about. I believe one thing valiron is talking about is the practice (which I recall reading about, I've no idea if it's still in use, or ever has been) of pool operators sending out work for empty blocks to their miners immediately after a new block is found, to get the miners working on the new chain ASAP, and then creating a non-empty block & merkle tree at their leisure and updating miners once it's ready. |
|
|
|
|
|
valiron (OP)
|
|
May 10, 2015, 10:07:02 PM |
|
Mean blocktime validation of one transaction blocks:
[...]
Shorter validation time for one transaction blocks is expected for miners
It is unclear to me what you are talking about. What specifically are you referring to by "blocktime validation"? Are you talking about the ntime gaps? Blocks of very slow miners should have lower timestamps because they do not frequently update their midstate (e.g. they would claim older times because that was when they started); modern fast miners blow through the range quickly, and thus have plenty of opportunities to increment their time. (Much of the single tx blocks back then were believed to be a botnet that verified nothing). If you are saying smaller blocks take less time to validate largely. This is mostly untrue at the tip of the chain. Leave your node running for 24-48 hours and then look at the block verification times. You'll see that the actual blocks, in spite of being huge, typically verify in a few milliseconds (-benchmark will enable ms resolution timing results in the logs). This is because almost all the verification is cached from the transactions being relayed earlier. It is not what you think. I probably didn't explain myself well. A miner can start working on the POW(=validating the block) before including any transaction. When you include transactions or update your transactions you need to recompute the hash of the merkel root, thus it is faster to start working with empty blocks (this doesn't mean that they are not quickly updated into a non-empty block). This may be an explanation of why the average validation time of blocks with only the coinbase transaction is 5 times shorter than the average, because when these blocks are solved it is at an early stage. There may be other reasons...for example...start validating the next block before broadcasting the solved block to gain some advantage...and start validating an empty block because most of the transactions were included in the validated block. If you can give other reasons you are welcome... BTW...there are one transaction 1204 blocks since 2013, thus the average computed is meaningful. If you can provide the data of local timestamps I can run more statistics on the discrepancies of timestamps. Anyone running a node since 2013 with that data? Shorter validation time for one transaction blocks is expected for miners
It is unclear to me what you are talking about. I believe one thing valiron is talking about is the practice (which I recall reading about, I've no idea if it's still in use, or ever has been) of pool operators sending out work for empty blocks to their miners immediately after a new block is found, to get the miners working on the new chain ASAP, and then creating a non-empty block & merkle tree at their leisure and updating miners once it's ready. I think you explained it well. |
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4158
Merit: 8411
|
|
May 11, 2015, 12:01:25 AM |
|
Indeed, yes it is the case that the work first issued right after a new block often has no transactions, since createnewblock can create a couple hundred milliseconds--- the time isn't actually the verification, but just the time it takes to build a candidate block... Since 2013 or so many pool programs will generate a long poll event (or equivalent) to cause updates so that miners will move to new transaction-containing work even before finishing their current work unit; but they will spent some time on the empty work.
|
|
|
|
|
|
