Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: grondilu on June 25, 2011, 08:31:31 PM



Title: using Shannon's information to measure proof-of-work
Post by: grondilu on June 25, 2011, 08:31:31 PM
Guys, I am so excited about this new idea of mine that I can't wait until tomorrow when I get my usal internet access to tell it to you.  So I'm writing this from a cybercafé.  I hope you'll enjoy.

I was working on my catalaxia project and I was thinking very hard about how I could avoid using Satoshi's compicated algorith for adjusting difficulty.  Somehow I beleived there should be a more elegant, mathematically pure way to do this.

I was troubled by the idea of mesuring the "strengh" of a block chain, and I must confess I never managed to understand exactly how Satoshi does it.  I wanted something much more simple.

Then I remembered my old lessons in physical statistics and information theory.   Then I thought about entropy and Shannon's information concept.

Basically shannon's information is a way to measure unlikelyness of an event.  A bit like probability, but with additive properties.

In probabilities, when two events e1 and e2 occurs in the same time, the probability of this to happen is the product of the probability:

P(e1 & e2) = P(e1) * P(e2)

Shannon wanted to have the same thing, but with additive property:

I(e1 & e2) = I(e1) + I(e2)

Obviously the solution was to use the logarithm function, so he came up with this formula:

I(e) = - ln ( P(e) )

And he called that "the information".  It's measured in bits if you divide by the natural logarithm of two, and it's quite a fascinating concept.

Ok, enough for the theory.

The idea now is to use this as a measure for the "weight" of a block.  Basically all we have to do is to divide 2^256 by the block hash, and take the natural logarithm.  The total information of the block chain is nothing but the sum of each information for each block.

The good news is that we won't have to start the block chain from scratch or whatever, as the longuest block chain currently almost certainly has the highest Shannon's information.

I think there are many advantages on this, such as simplicity and robustness.  There are also many interesting implications such as the possibility to make the information being a inside secondary currency inside the block chain, which could be used to trade between miners in order to avoid chain forks.  I'll explain later.

There are many things to say about why I think this is a good idea, but right now I just wanted to tell it to you before someone else does, so I can claim the glory of being the first to have dropped it, in case it appears as great an idea as I think it is.


Title: Re: using Shannon's information to measure block weights
Post by: dinox on June 25, 2011, 10:21:05 PM
I can assure you that satoshi's method is a lot simpler.


Title: Re: using Shannon's information to measure block weights
Post by: Karmicads on June 26, 2011, 12:11:18 PM
Then I remembered my old lessons in physical statistics and information theory.   Then I thought about entropy and Shannon's information concept.

That Del Shannon guy sure was an underrated hero wasn't he?


Quote
Basically shannon's information is a way to measure unlikelyness of an event.  A bit like probability, but with additive properties.

OH! That Shannon. Now we are talking heroes of another order of magnitude (no offence Del, wherever you are  :D)  Here he is:


How many people realize that in 'coining' the term (pardon the pun) 'bitcoin' Satoshi was actually acknowledging (perhaps inadvertantly) the father of information theory? The 'bit' being the unit of information that halves prior uncertainty of an unknown value. It's generally recognized that Shannon essentially defined the 'bit' if he didn't literally coin the term (again, pardon the pun). I don't understand programming all that well nor mathematics either for that matter, but I do love information theory, so Shannon is a legend in my eyes, in that he devised the mens to quantify redundancy. I don't know how Satoshi's algorithm does the weight calculation, but I assume it's some sort of Bayesian approach, heavy on recursive looping too I expect.

Quote
In probabilities, when two events e1 and e2 occurs in the same time, the probability of this to happen is the product of the probability:

P(e1 & e2) = P(e1) * P(e2)

Shannon wanted to have the same thing, but with additive property:

I(e1 & e2) = I(e1) + I(e2)

Obviously the solution was to use the logarithm function, so he came up with this formula:

I(e) = - ln ( P(e) )

And he called that "the information".  It's measured in bits if you divide by the natural logarithm of two, and it's quite a fascinating concept.

Fascinating indeed. Particularly for it's implications for entropy, but that's another story. BTW, even that explanation helped my mathematics understanding. I can see now, how the cumulative 'surprise value' of each bit, is derived from Shannon's Log function. Thanks for that.
 
Quote
The idea now is to use this as a measure for the "weight" of a block.  Basically all we have to do is to divide 2^256 by the block hash, and take the natural logarithm.  The total information of the block chain is nothing but the sum of each information for each block.

I can't wait till you write a verbose non-mathematical description for us non-mathematical types. It sounds like a very grass roots 'bottom up' approach, to avoid the need to calculate the weight by measuring it directly. But again, I don't know how it's ordinarily done in Satoshi's implementation. 

Quote
The good news is that we won't have to start the block chain from scratch or whatever, as the longuest block chain currently almost certainly has the highest Shannon's information.

I think there are many advantages on this, such as simplicity and robustness.  There are also many interesting implications such as the possibility to make the information being a inside secondary currency inside the block chain, which could be used to trade between miners in order to avoid chain forks.  I'll explain later.

I'll be looking forward to it.  ;)

Quote
There are many things to say about why I think this is a good idea, but right now I just wanted to tell it to you before someone else does, so I can claim the glory of being the first to have dropped it, in case it appears as great an idea as I think it is.

Well done ol' chap. I hope somebody will take note of this. It sounds like an elegant alternative. I don't suppose you ever read Richard Dawkins' article The Information Challenge (http://www.skeptics.com.au/publications/articles/the-information-challenge/), in which he honors Shannon and provides a great layman's explanation of information as an economic commodity and the relevance of redundancy. I particularly like the parallels it draws (in my mind at least), with energy and entropy. He comes tantalizingly close to venturing into this realm, but unfortunately forestalls it. Anyhow, I wish you well with this promising refinement and intuitively, I honestly do think you have a good development refinement to offer. Please, keep us informed.



Title: Re: using Shannon's information to measure block weights
Post by: Pieter Wuille on June 26, 2011, 12:36:00 PM
Bitcoin counts blocks are 'worth' as much as the statically expected number of hashes that have been performed to generate it. As far as I can see, that's the theoretically best criterion possible.


Title: Re: using Shannon's information to measure block weights
Post by: grondilu on June 27, 2011, 07:23:17 PM
I worked hard during two days but I finaly wrote a minimalist distributed timestamp server in bash!!!

Unfortunately I am once again in a cybercafé now so I can't publish it right now.   I'll do it tomorow, I promise.


Stay tuned as I think this is gonna be an MAJOR BREAKTHROUGH in crypto anarchism!


Title: Re: using Shannon's information to measure block weights
Post by: bji on June 27, 2011, 07:55:55 PM
I was working on my catalaxia project and I was thinking very hard about how I could avoid using Satoshi's compicated algorith for adjusting difficulty.  Somehow I beleived there should be a more elegant, mathematically pure way to do this.

I didn't read deeply enough to understand every aspect of Satoshi's algorithm, but I thought the basic idea was to average the block generation time for the previous two weeks and then compute a difficulty which, given the same expected computational power, would have resulted in the target 10 minute average interval.  Basically, adjust the difficulty so that if it had been the difficulty over the prior two weeks, then everything else being equal, a block would have been produced on average once every 10 minutes.

It seems pretty straightforward and "elegant" to me already ...

Quote
I was troubled by the idea of mesuring the "strengh" of a block chain, and I must confess I never managed to understand exactly how Satoshi does it.  I wanted something much more simple.

I don't understand why you think the block difficulty measures the "strength" of the block chain, or even what "strength" means in this context.   Unless I am wrong (and I often am!), the only measure is how many blocks were produced over the past two weeks.  Individual blocks are not considered.  If it took 1 minute to generate 2015 blocks and then the next 1 block took 20159 minutes, there would be no adjustment to difficulty over the next two week period because exactly 2016 blocks had been generated in exactly 20160 minutes, which gives the perfect 10 minute average interval.  The contents of the blocks and the actual time taken to produce the hash for any given block don't matter, so from the difficulty adjustment algorithm's point of view, all blocks are the same, the only metric is the average over 2016 blocks of the time taken to generate the hash.

Quote
The idea now is to use this as a measure for the "weight" of a block.  Basically all we have to do is to divide 2^256 by the block hash, and take the natural logarithm.  The total information of the block chain is nothing but the sum of each information for each block.

The good news is that we won't have to start the block chain from scratch or whatever, as the longuest block chain currently almost certainly has the highest Shannon's information.

What would you use this "weight" for?  If it's for adjusting difficulty, I don't see how it's useful.

Quote
I think there are many advantages on this, such as simplicity and robustness.  There are also many interesting implications such as the possibility to make the information being a inside secondary currency inside the block chain, which could be used to trade between miners in order to avoid chain forks.  I'll explain later.

Please do, as this paragraph confuses me utterly.


Title: Re: using Shannon's information to measure block weights
Post by: patvarilly on June 28, 2011, 08:08:59 AM
From main.h, here's how a block's work gets calculated:

    CBigNum GetBlockWork() const
    {
        CBigNum bnTarget;
        bnTarget.SetCompact(nBits);
        if (bnTarget <= 0)
            return 0;
        return (CBigNum(1)<<256) / (bnTarget+1);
    }


The total work done up to a certain block is the sum of the work of all previous blocks, down to the genesis block

Basically, the "work" the highest possible hash value divided by the maximum acceptable hash value at the block's difficulty.  As Pieter Wuille remarked, this is just the expected number of hashes you'd have to calculate before solving a block.  What you're suggesting calculating is -ln( 1 / "work" ) = ln( "work" ) and adding these up.  Pieter is right to point out that the original definition of total work estimates how much computational power has been invested to date into securing the block chain.  Your definition of total work would be appropriate only if it took a constant amount of calculation to get one an extra bit at the beginning of the hash to be zero.  But it doesn't take a constant amount of work, it takes twice as much work.

Here's a vivid example of what would go wrong.  Say I have 16 block chained together, A1->...->A16, each of which has "work" of 2, and additionally, three blocks X->Y->Z, each of "work" 16.  Under the original definition of aggregate work, the total work in A1->A16 is 32, while the total work in X->Z is 48. These two aggregate works are proportional to the amount of time it would take you to secure each block chain with a constant-speed miner.  Under your definition of work, A1->A16 would have aggregate work 16*ln(2) = 11.1, while X->Y->Z would have aggregate work 8.3, even though X->Y->Z took much longer to secure.


Title: Re: using Shannon's information to measure block weights
Post by: grondilu on June 28, 2011, 11:11:16 AM
From main.h, here's how a block's work gets calculated:

    CBigNum GetBlockWork() const
    {
        CBigNum bnTarget;
        bnTarget.SetCompact(nBits);
        if (bnTarget <= 0)
            return 0;
        return (CBigNum(1)<<256) / (bnTarget+1);
    }


The total work done up to a certain block is the sum of the work of all previous blocks, down to the genesis block

Basically, the "work" the highest possible hash value divided by the maximum acceptable hash value at the block's difficulty.  As Pieter Wuille remarked, this is just the expected number of hashes you'd have to calculate before solving a block.  What you're suggesting calculating is -ln( 1 / "work" ) = ln( "work" ) and adding these up.  Pieter is right to point out that the original definition of total work estimates how much computational power has been invested to date into securing the block chain.  Your definition of total work would be appropriate only if it took a constant amount of calculation to get one an extra bit at the beginning of the hash to be zero.  But it doesn't take a constant amount of work, it takes twice as much work.

Here's a vivid example of what would go wrong.  Say I have 16 block chained together, A1->...->A16, each of which has "work" of 2, and additionally, three blocks X->Y->Z, each of "work" 16.  Under the original definition of aggregate work, the total work in A1->A16 is 32, while the total work in X->Z is 48. These two aggregate works are proportional to the amount of time it would take you to secure each block chain with a constant-speed miner.  Under your definition of work, A1->A16 would have aggregate work 16*ln(2) = 11.1, while X->Y->Z would have aggregate work 8.3, even though X->Y->Z took much longer to secure.

Thanks for your comment.  I'll read that later but it's too late to discourage me, as I have just finished writing a prototype:

http://s0.barwen.ch/~grondilu/cgi-bin/timestamp



Title: Re: using Shannon's information to measure block weights
Post by: grondilu on June 28, 2011, 11:22:21 AM
Well done ol' chap. I hope somebody will take note of this. It sounds like an elegant alternative. I don't suppose you ever read Richard Dawkins' article The Information Challenge (http://www.skeptics.com.au/publications/articles/the-information-challenge/), in which he honors Shannon and provides a great layman's explanation of information as an economic commodity and the relevance of redundancy. I particularly like the parallels it draws (in my mind at least), with energy and entropy. He comes tantalizingly close to venturing into this realm, but unfortunately forestalls it. Anyhow, I wish you well with this promising refinement and intuitively, I honestly do think you have a good development refinement to offer. Please, keep us informed.

Thanks for this reference.  I am a huge fan of Richard Dawkins and I will read the link you provided.  Your description of the subject makes it extremely relevant to this thread, as I realised that the cryptographic timestamp server I have implemented could be used as a currency.  I'll describe how later.  Anyway this would turn information, or time, into a currency.

Crazy stuff, really.

PS.  I'll put the code here as well, just in case:

$ xz < timestamp |xxd -p
fd377a585a000004e6d6b4460200210116000000742fe5a3e04f3f1c3b5d
00118842463df4186aa667af7a9fe191a5205b670958d0ded39d4a4e825c
dfc1110b577a6d0b1e64741032ccd8aa98ace6d7eb38181b1318f591e6ea
5a1ab8468666c061e0478c4749a12e2c4db3ccabc3ae041f58fb29a5b4fd
d74e5c2b81fca3676770810246e0bd2b2689cbfaef6451234ead354d983f
7ec9db6e65ceb2800a180c3674878c2400cf228bef78d69b8fa5bde53035
34e5756196704025897f202322783025df6b9e072f402fafa4450a19a000
b9acefc04c8747b155c14c8be1a1064f05dfb2d038ac1dd0260a8510079f
19334c3b2c2706f815d0fb4efb212b805450052bf0b620ed1a8fc0dd573b
e50edce9d8ac91c6de527dedc7c36b9f86e21178557c92b2dab4825802f3
c02faa9005df9bb723e26af9f37d4fa158556407071719254d49d552ded1
7b145ccbac33064dff680ac7d6b796e5d0c6aee86b8af81343c95695f2fc
bf5c62329e9dd46921c8688f8efc02a284355d10e63db8094902b934a2db
aa7cce51053101a18c097db99ab39bcf23369a56d1ba8c667e38998515d6
8aca6965923965acee90c72c36b4124fc386bc5c625f564abd850795b838
a690d2e159d580ed0b28cefef42f473f64f55c6156399cd2d7b3eb1bebc1
0105a16de999c2bfe8a7dbb12d690b634130028099fb6c446f6f40dcef3f
4c39006377d5e90a3037fc3dad2bdce5c8e611e5f73d5b56466fc67dbf87
e7fa6ac77785750b6089759803013734105714eeb6a5928fa50bbe77c9fb
69a426d947472d2d4a48efddb6fbf261dfd78c6f2fcdcc2aea3c125f3296
57b05295b2917be2446618d581337509069f332a35255132935b6ff04624
72f718564ee776edd758c791a63bf576ca4001de15e8eda5966bfe5e8c33
9c7ddb7d3e4cb184bcddd66e4520f15c8c8b6d8eb5505c83822aab2593a9
7578f4426a99fa67fadcbe54a0b571eccd6e5888cad97ba749ee6713f4d5
69f4bac4cbc09b2ef68148019e57be2931c052e8c83a4fa69818a4fc59fa
8346a0f33aaa22d20cb8cd2ec0ea400607a705a8ae9565a07f87d06a6d72
d0f21365b9450108394e6569a6772321d8fb3adb18891aaf2facb6fd573c
befc1533931da5ee11563eadf5df3622237e59d67ad2693933492a195195
ed7748fbe4f7dad6ef67b7e637d27348acd09480ff3470383a9ca2582dc8
afd412f6e260c9588f366a7c09acdf322533a75680c6bc37a90a66aa2947
b671191c84b42024bfb2c1dbf323daa46776150394c771c8086733db4e6a
ddeee2eb07a415641b51261cade9670577b71cf7511aea2d314ae9b94c5b
49100c2d636a24ec0e2ed936d258407da45bf4ed563274f366e39dd8adc0
6ad4c68a6f59d5e45fe81d95b94830beaf11785edc663eef77a3e623c44f
6a3e798bcbf090a08752b5e015e622f799002e9915009321c69cd7d10983
e1e4f086d2700235067fbd62ba0aacaeefc65959460ae434dd56b61127b5
09982edd10ac7ce3cefdced1e8bc0776ea996f1dd0fa6a628ccf41dfc32c
0793a6bee1d1a7493e18265b527acfd4a7c4770f3fbb5d98bd26b0610da4
8a4da085309784ef7fadea1ed736df0e79ed28da5019ffda92c49a43227d
df509af8f2487541b40f20f0329cc98a89a679d1de4a93466f7ed4a7ba03
37258524d2b8f787b143266812b226322c35669db56a280f358b15e980da
78e811bd70b9dc50870ad2c53ea7bd98ccd246d2d663f70262a1c8349fbc
ff36afdcf2121eadc8fa9184aa73de3588461d27d4c94cf510486c577ded
e143b3dcdd41c0ab3923a8b41a878f99cf3c0c1706da126f29db44988888
071034d755b596caf3f4e907aee74cb6de818f48b63be457c2518c821913
5eb47ed5c3732da94a8b74971ddf7927dc962c181a293d2611f516d36c14
9fb41c677df2da3055d0e135464a1c91f1adfde8042cba3db4b50048f42c
c7b6e36d5fd3610ba1bb4941b0fdfc546df6ce3727cb2327723c66872795
1475ec7c5a507b3dd24c04ac410f95b6c9bc0929f36d9ddd63f4240f0a8a
9869e33c03d8c15e07552b2331ebcf45f95d1844eea6ba0905e0bc5cad85
b65624f5e8415a94b5a3afbabc67bdd5d50a5daae50d5df789c148352904
13812db9596bec7e7adba703bcdaaa8f8f46cdef880f9142ff728ba65121
cb5e8f50d39a9dda2604f8a7f2b968e5b9e9854f82b752a9b2fcf4bf2087
5e2d5369fe8f19cb75aaa2b7d726b1a56057c428899a231841ad938908de
da79b6966282ce9d1fbad64f65ef2396eda5bc0f26917632b974719a4f59
9701d4864ead06b611e9520d2603b26fb2da3781e2bd910597ae690fb469
9f836284a95958ea7381102359bc4e3a43cd4a075783345c83389579f8df
2b374a3b79748a35cedbfb07d3bd1fc6463e271f11b89b2cd1d3f322ce54
f8d325962f1a26aadac0ea3810b9e59c267ba8355e94aa1efb8a9bd0f4d9
09c96bf350b55e9228fbd48a45ff6a17c613fc77c238abaafca3d7d09baf
5966bb7ace3578ff9d45f14c071e8be0269e2f62faf459520897ea389633
4e17387bae1d84f62a49e98c4896d1bb090db81036e4c55e01cd5f6cff8e
4f0fe201278695868e6f0cc3481fa1508349954dcf913f0be22f154f7147
d5a367cace0f63a4b3718fd7f770cec8625110c2e49603103838075fe0df
d491e32f75d0068384d2abd21424cce7d07d8ccd368b68bd001394cd6f5c
894dd7450d358a65a74bb56664c81a1b4df8897aef8179800bb2d741beb7
55c5d164568fa057f921af1d3f9b49a9aa8e659cf2c7fc110ceebdb85d75
226ddf0a0735037a59ff35ef77214950cdbefafb770b04be3a26f8cf6d2a
bb485a16f0c777c8967f6a3f8e6f42f77bc3545182fb285ba66548d6fc79
f1f49af490b97ebc183c30219b82ebfbbf0876e53b71155db178f2891b32
38147263435c00b4d2b776ef764e7f7154ab15269fb97fdb0e50f2b7a64c
1b90e2d5794f4d6dbcf90df8df5cad6bc36f47ec7b981d148a42faf1e1a0
bf952a62102ad8e4c7885b28bea5beb83c17039bf6356b7fd5cd381f622c
614ac4686e28391e9d07cc85df5e469963539a4a2f7de5352c33cdcaf9e2
06da02694e1acf8358bb530d237612a5c16bd9c46f7cbb7489c351db019d
947aef3c72eb8d60941668a4207a8f70a21e464f411b8f794a6a01e1280d
9cae83e85a2fc70abe9fab70fd9d686c81c3b1faf5693344ee7ca128342a
b18c9498734cced62514918163d85aee35b7b5ec93d7a075742150200d4a
47583b08c771682575a2d987846d6f0df4fa64345b2e01c95b58697939ed
9b3aefcefd343abe568eae2b4af826b40e7bed097028d9e0b8963121244e
b297de941409d1efd7e9cae2b547dc30c52fd7327698f8e0cfe7396c7461
4269d4a5c147ea22fff4a8b904112df7ff90f97e76aa0e66d4b3bba9dacd
be394e8f34405862b4a5416d8f8ddaab626bc405e12d96f89ac77413932e
378f710382613ac39956a4044c2c0b3c9693825d01a5e7e6fac225c8ebff
97e9106d78f735906c026e92907e8d2999b28c5d1a44db853c975238bd2a
29c1f889d2920a1b74279d54260c918c335037282088d1f2f461c2b52470
7a82f32e202ec38040dce45e4effeda07c6970147470046b21e1cbadb4fd
26e41ae4b324880d8ca5f238d33bc9bb9f04fc49dcc6f70eb3fbaa2f54bc
7ac4f5eaa3d24b461c33a339c4f2a4d2abb27fec2a991cc06168aa710044
c153ee090bee3ddf79ad15966d294db3230ebe8e94f631cd2396233c5dfd
af80a9b8a73a30f015acca6ec143397142b1f685092dcff083f37435797c
2092cc70d0dee9c6b5e4a82a9540a1c0f30dbc26a8e177c2cc1d8cdf8898
469a50ce6dcd3258f71b6467827ef58cd1169647e989fbd637d9cc83c0e6
9f22b39922067cda32a4d814e96b7cd65fc91129358e2137c5a9929a6a72
0391c31c9873f62bb3e7253412dab79717a925b0938b8702d160a099ef5e
ae5a9e9d33212233f92c160f59890bf893adf940b9f9713ea1bb82e6ed89
7e27ff36ae4ce4c515b72fa4d62a3fbd947da933edc2d1546c10ccffdf7b
ab3ea366dbcc1906c9677cc6ceee38e7f7f1c52c42ffe2b86da30ca295a2
d787f09203f185e00bcff5decc6872f795e478cd86f12165005921f6424b
797a678a6f0257c84933932108155bcf4c7fa2b6fe34709ce74499e0d632
e71db62b8236d840642f0e864b332a1cbb901661cf55aa8fe6c0b21850a7
0d7790b46f5117529355146bd4e6214c5be45fa02c932e804e2a647bcbc1
3ca3c0946acb0720d006f41c69690f2fdecec8a467f8844bf07853495e3e
2206fc633c74be3bacfd02558f7aa974deb6593acab1a92302fabff1d853
92bca15e18e8a0829b2d85159a0b3e25dcdf818d2f1202202453f48ea1f0
265a593fb9f2020fedbedb2f6de151ca70aaba942ea935208a8d1a508da5
ab7e024e45f5c752c0a603da0d0c6c37f218eed13803bc952e051de6f47f
b21ef70d1ad55e185ab197eaa579bf5ab8f7f2874414da3ed4fedf3438e0
f1c8af49d22d7fa781d9455b2d575e48c4f2c4f8d8fea1f8fbf941bbdcce
00f48041f84cad91bdcca8385ff375ab4b503ac5266327bccccca7066f61
23852517953920df6466e12b2bc39af2ef1f307615df5e8dd089583ec631
2e1484be7d4777662f542b63124600f33ff25ec9d8d8b62ae4e435ca7335
3b03928983ea082494402435aeb86a9243ef258e0b517c4af5612a8abf29
04d840ed08888d6e4fe49fcd034c06fb24b8db17dfbf3f2b24b53bde8189
738318ee1ce48a1669138ed95cc000b701d92b676b62a7c3f1115cb103a9
996292569388621982a96a607d7de04f006fa2ae761e5685c2008955a6af
85cb443b55c1856bbac3bdd6d9b0509902af9ceae4c9d8c5d93bf12420af
cf72e2d5654a48aa90ec032c8c08832dd212949931cafaae66114c62d281
3fd1b1ac5660bbd7bb8c310dda9e10f3597f4b469800b4da7c9e70646285
6558dafddb5083b953578985b34489ca5e1928df8626f249af80ccaa5281
b6eceb7c1fd13aed16698852a31db6ff064f4c7d882d1457e05868b3e880
432d1d1637c2a6325dedcd6a2edba41b66d4786568f5bea20d306ddcd469
20a22271594dbfa3262c547c15fd63455bcfa16f4049cb39aed63d03f31c
efc0afe16c994228896bf7c1eff84f0baba0d122a2b70436172d7198a9fc
dd9dd14769191652da452242ef4d3a30483986d8a9cfdd94577b5656e0b6
6acb5e8b9103815940b3276e816c2a327f2f6b82204a1a18b935eaf7bd33
c01ea381a0a83fb1f71c808a07d993728938e219866611c5ade5d3d63c3c
98f55c0fd995626fc9f4ee980f014065c2f10334cb0879dce0c2da8ddf8f
6c84df4bcd62c8d8db21dd770ea32fa9743bc71852c7443040e932471f9d
1f0772fc9eb2e942e95b423b55cb0b6f09ec292916073cb6aa8869b1573a
fe4da08722fefe536f1c5259ae576cbff0ee0690553c2be9cecfac1ae447
204b6e1f8298ab251ee19af24aa3827a84920d7f50099663c8e376de4825
c3c0ff291cdb34235cb8fd6c39f8c0169c37ae53167b8dad53edc3ce3947
c3aab9ee8b2e2797e9c3b45ffb93e42a04c70b8be0f35073c5e9e1966e0b
6560cf2f327af80958837d434d06a1956bcb1ae1bfec6cc9598dc2dbb610
d47a1658c01ca0c0365599429a2129f32af01a3f57924ff9771fafaa0fcf
3278f0f6afb9cab8bb8fd4f0b6cd7a6ce7b80f3d2329bde53c11513db73a
92e83188c1bb56beca59f515e4adeb446cb9181a2239cd83f5a8258c21f4
c1a54ca2eb40b6cca2ca93f4933323eeb5fd8f723da219b0894a734c261c
8cfe9586d7fa70da71da2a173bde3f9250066ac4318ae6ad4ca2f3c144db
657cf75bf766b162ae54522f0b2fa42813472cd1141868333197406a6c05
6ef25d490405b46578c20471100f2c290c1990845f7c71f264c575b97c63
7b424f42e2fdd984439d097a26c2ea14143ba5acdb908c92077f2c489bb7
4b1782fce1341388f09c37eed61251069553a13194f864c3cb1a6ae876d5
822a0e128f7211ff9965790eea47b0349ea2f2ab11ab712fdf5ebb6f688b
6207e18cba921442e7be6ee534ebda7b9d0d8b8bd68152598c46e9931e23
9ee09fcf4a8e7edf47a4077867e00383ca8bc509397598116c073516642c
28e71e27ae2483f60d186d11cdaffb1adf6d3eb0d035dd190c04082a4c72
168a962dcb09cabac9e080122445b7baf8eb158e3508b9afa4bc3a530afe
82a5be2bb1e81b75cef5c227b72740bae4b4ed30836bf1156e1d0dffefbb
ac66a8dcdb244b356e268aa35cc6671d2dc7d6e3d3db297d458564a1f2fb
b293b9871a8bfccd65e5efa78f8cc171f4e2f96b7197bb9b5f3c8b828d29
396a9f4d3d307c2edf9338ff00f88ad68325d11741b952aabe65f05064f7
c2dd4f1ed1d817c3042c3dd7670cdb652ba45da6e17513a5b56e7d825c36
eb69fb29db23a02892e33f2444885e2393e14fd922f49c149f9db44bdaf0
1bb4d0b8ea37df5b2328b3302af8c684b209debc76021b3ea4cf40d1dbff
4c3adcc87a3a66b2cd6fb975c774f94aa853d8f7b1198dd24762554e5e9e
0470105159c68045fe82b3c8fc0518618e0749bd4b8612debec680f1fd24
6758ac2a8e957067cf9318ce67c94b4d76ac20027793a93162ebf146d8eb
bf7c0788354b70c383a60dcef55841a7ad3cb7a6163656267f64bdd2f6a5
2bfbfd872f0d73ccdc7174fad17c7cc7546a9585c9c8da273fd3ac5ed3b2
81bfcf5f14e6e296991b7d5c74e513fa975e7f99ad31eb7fa0415697ccb5
8da93b5b6a2b5e1a82a7c547e092be6c53b543c75e40b406536d9f3764cd
65244c75135ab3aa74fc5bb81c2f9293bae6ba91694cebea4431d254d10b
971ffba1bd9cc937b396134041ed28becf4d28c261a411f494cb8f9a6eed
e49c701fd88fb86aa3a6fff272e30f5ca60c193e5bc67eb9182de8b33f9c
4be8be929ba1a5e931f68d34188013ed9e6ca1d8ccf73bd5e16d220f1bb4
0364b7ca0a319611ba744c2775509f7d47c0c2f668cb9c591b440a678cb8
37db63b09ed426e0173936c282bff77555a19c9e46df3fa8f5c5a59baf65
f62f762fc269b9f94b3f09e50d5f2ab6d80356cfe17e85aae5ea7e6d0239
80bcf1f7be4f042bf4807b38fc7eb66be9a08dd728f32b0ee50ca8deee15
c927203d3eca2503b478926b48dcd2eba594263d9f730d15f9c18f5526bb
7e50e867aacb5b7a78c0ca75b0f746917d6663b435dcffad3bdb224f6d91
e3595eadc9f3d203414d3d0367e869d2321149813b0b69062ec5c936903f
b280770df06b3991708c477a5a74fe0f4d3566751ddc47c3b953d49d66e3
734662a822946007049df8168161aae3038216060dc7f16caefedde08a38
6d3d415fe9d91c67d576982d5acbb95604039e34a829783ecc49ac165579
d5b54db7b2367e0dd2ef565b3e083d0d5e8a015037eb0d1f905f16cfbc52
400c05dd1569d5ac0ee0d8459a64400ca0fcaea8f863c5ceb01756361824
4069cb98cf0f0a205ab40e9c8281a7f61fa7f28d13b188b462a0d33bbdf8
1259bce98e244d657e040cbdb878852eb81f4ce844c32ddefa4045031f66
2eff367621d1c43e26a26f7e9f371e51504ab4f6075b3684b1c9fdff1626
2a455c2ecff94f15131f26261752197959f8649efda7cd38d705c9af64e8
1de650296aee803a55d59926bec513cd02f8d69496b520e55c7ae3415764
d9cd42960deeffff7be53763f033f3198797580f195dba6075e8e36e3b1c
ec5c86efb88393d7b57aeefa738f584305b97f7aa5222621116c9fc29131
c034412aa590ba5edbb54da0faeac0d5304f54877e42b7c13a5eabaf3a15
51c3313dc658b1d570a1bc20ce3ab5ed7c13e6e2e9f5df83d0435cf437ad
45926821a31768515c1a5903a1e1d4377cf7be063b09a9294a68826dabe8
b168711290a4a8916a6f127b122578e90aeb202a049a7f90b7ad02bbafe9
d8944d2415001c1df70c8050cd0ab8095079975d44faf4487a847367cff7
0741fe9eb1755ac2fde288e6444cb2daed42ebb8f6bc704704da9540cf86
b246e3e3984ac827175448d437ff1d1a0d8c4aa92c4430eb0d8a48f89655
5f600d0fe60794787636b94a5098ca1fc285771832fce40a9df70d151822
9114281c7f3e55623b34bc568210505d7df9e884ab15592977064d65c403
4b2b61ac3da52d8476bd8baa17c618c4b92ddf4e748a2b07d41f47378f80
270e5b2974cd569771c92e9c79e7d2ba0cd13f95a7641d6018a29e90acfd
074e3a9c06ef2eafe36371420a14e10634f0f71be652f145bfbf84af7f30
82a3b6101631d3b6059011fc7790a0b37446f210e8ac8e71f428a3c1b33f
aafee0ebcc01c204260a2d64dafa627f10888ad2da9f554f01f181a407ce
fad0764dd9862731ad407c2d23b051dfa723f9ddd2f6ae42b2f9f9d75dc2
fd45a625d9dd40913563c6440d7cfdf2ac6fdf0e1aea59563eac9b8ce0ed
5df0c16bb43dec9546633c6dbe23e3e90459ffb3a769579574e38cadd362
eeaea905c3944ecc01370ac326d847f6e975cbeb6c36193d846cf3eab610
38f1ab1cd588947583a89f2814302575ad498d80a7a585616a54994cf0ae
6f4feb4075107cb6ec78be6f69cfa1c40806c656a79634ab1af07216080b
0bcb7c7e36502f3dca48987b5bfc51f0a4e458a1866830ade6c609b02fa1
470727628df5c3bdb4eea19c69609032c56484edb7374be3ed1bb3b340b5
7a7f16ff1a3dbeae499961199864c00dfd31036a2cbad77eaaa1dd11ea86
fdf41bc83b0601d88bd18b1d8d9a99799d03efa8e425823d3781eed2bd53
4178e602ba9cf8470f19c729063e76bcbe7b8d3e50333e602743ece0bc44
9c3989f47477e1c9ecb4971003250504e3ca25b54115d63dc66a9bc02c8f
7dc79fe318feb186f3196afb49b8eb303372e8c680292019ca67b2277d1a
6bfdd02cded6c48fb56cac86713c881f77f867f9fb29a51708ac8d08ad66
dcb41e985168ada36fc21260de0804da7d6760f8e3aa5f47a090763e8549
143b4494245add36e70e8c1cf1d7957871fa29104dae1a236e91fd246a82
d0e94d44ef5c045e047ba8b7d4eea1cc2f0b962837a0f39a74dd0aa02293
31aa9e172be6c85b1e12a695c5608ece5e9e1bebcd7753caa6231c7db84a
42e26751d2d12b7eea85a2076b186f4a1ee9d033c355358956ee9c48238a
758504527a8c76ae4180a25bc7b2f84f7215ed5c8e9f84be91c1b68d4426
eafcbe0e8326b0b370d965ca9ede450ddb4f373eca49279bd206e27cd1e1
1c65b9c6dc7d739c68675908a2c55779f05db3909ee4ebce174cd982b735
6ddf3831b5677c337f4499729eaaa15ab1c6874bfdd350c08b9d2cca236a
52c01cdeb564372437317e07d3e275004b5e5687997289a4df5a11377eec
d9c80a37922058d96476754bbcfb840c48bc1b209bd8cc389dc9f65682c7
f87a2c0fe303139c69e4e86b3941fb73a4f414c2baedd90f5e6dd5059764
d4df7c154fd0dd71c03aebdd0e6ef7f4becc7482ca207fb50cc67c90966f
ce3a813acda28f006f2ee28425fd1e6a7469aefef17d15e0835dd616a596
f78acd2fa8c8e70fe893b4d2612bba92697ccaaa676f0de231c5a156ee3d
0c9fd4442f3910e118666ebfd006212844abc19aae622005f273a680aafd
61aae7df7214725d2fbdb35f04b928c9491aca80ffad4a61d2041d07edc9
0750142dc97567f4628b557edcd3d4e92f3be9d8b1ecf88305f1d207b98b
05a9e1dd131c980ea459940625f5827c5d5a14576635b70a054a24462757
d4d361b8f866f09434f239bbaaf6469ca16e99eb3ff9b21540e126ed81fb
3d13f5c1be05e47c97101392be6a79f9948cc297eba11283c17b04585e87
a09f27dcacf7a61b0d3edf0b9db479b970c38ef101ee6e3beb6eece1dd51
ef4166aeed15c42fae09cf60387c2a2d2341cd2627898a63e613b0a57ca8
cc90565ac5e457f7790b033759069a57c0ff9b17e9c29bea36e04d96b7b9
cd09a7b9b68b5e1f71158a4a9bb25a3cb3e40b7fb014b8355ad1cbb91f68
525b7b94d047bbb84f2bbba780e2e592a3aa1a38b5afd18671aefc87b993
54852946f74073b0d2b3496951c2ba9e2957002f90cf250c6580d3c40987
8252b648d4ec8f99c735759a2b2034b62bd9de89e4de41fe27933d380000
cc1997d0b2ba9a120001d738c09e0100b041e4c5b1c467fb020000000004
595a


Title: Re: using Shannon's information to measure proof-of-work
Post by: mcqueenorama on June 28, 2011, 03:12:20 PM
Where's the distributed timestamp server in bash?  I want to see that.  And you should add it to the effort of the guys that are doing bitcoin cli tools:

http://forum.bitcoin.org/index.php?topic=2461.0


Title: Re: using Shannon's information to measure block weights
Post by: becoin on June 29, 2011, 07:08:20 AM
I don't suppose you ever read Richard Dawkins' article The Information Challenge (http://www.skeptics.com.au/publications/articles/the-information-challenge/), in which he honors Shannon and provides a great layman's explanation of information as an economic commodity and the relevance of redundancy.

I don't understand this conclusion:
Quote
Shannon’s unit of information is the bit, short for “binary digit”. One bit is defined as the amount of information needed to halve the receiver’s prior uncertainty...
Why is bit defined to remove only 50% of receiver's prior uncertainty? A bit should remove 100% of receiver's prior uncertainty! It is either '1' or '0'. There is no 1/2 binary digit?!

“It rained in Oxford every day this week”  or “It rained in the Sahara desert every day this week” - both remove 100% of receiver's prior uncertainty. What do I miss?


Title: Re: using Shannon's information to measure block weights
Post by: grondilu on June 29, 2011, 10:28:06 AM
I don't suppose you ever read Richard Dawkins' article The Information Challenge (http://www.skeptics.com.au/publications/articles/the-information-challenge/), in which he honors Shannon and provides a great layman's explanation of information as an economic commodity and the relevance of redundancy.

I don't understand this conclusion:
Quote
Shannon’s unit of information is the bit, short for “binary digit”. One bit is defined as the amount of information needed to halve the receiver’s prior uncertainty...
Why is bit defined to remove only 50% of receiver's prior uncertainty? A bit should remove 100% of receiver's prior uncertainty! It is either '1' or '0'. There is no 1/2 binary digit?!

In Shannon's meaning, one bit is an amount, it is not '1' or '0'.  It is one bit.  It halves the uncertainty because if you add one bit, you divide the probability by 2, by definition.
 
Quote
“It rained in Oxford every day this week”  or “It rained in the Sahara desert every day this week” - both remove 100% of receiver's prior uncertainty. What do I miss?

No, because the amount of information is not the same for both sentences, as rain in Sahara is much more of an unlikely event as rain in Oxford.


Title: Re: using Shannon's information to measure block weights
Post by: becoin on June 29, 2011, 12:23:41 PM
Quote
“It rained in Oxford every day this week”  or “It rained in the Sahara desert every day this week” - both remove 100% of receiver's prior uncertainty. What do I miss?

No, because the amount of information is not the same for both sentences, as rain in Sahara is much more of an unlikely event as rain in Oxford.
I'm not discussing the amount of information, but if a bit of information is removing 50% or 100% of receiver's uncertainty. If you've learned about the rain in Sahara that doesn't make you less uncertain about the rain in Oxford!

Same confusion goes here:

Quote
He can’t see any details, so a nurse has agreed to hold up a pink card if it is a girl, blue for a boy. How much information is conveyed when, say, the nurse flourishes the pink card to the delighted father? The answer is one bit -- the prior uncertainty is halved.
My answer is different. My answer is one bit -- the prior uncertainty is removed entirely, because pink card means girl. Unless, I don't understand what does 'flourish' mean in this context?


Title: Re: using Shannon's information to measure proof-of-work
Post by: markm on June 29, 2011, 01:57:18 PM
Okay, how about re-phrasing it by saying that the prior certainty is doubled?

Before the nurse flashed the card, you were 50% certain it was whichever it turned out later to be.

After the nurse flashed the card, you were 2 * 50 = 100 % certain it was whichever it turned out to be.

-MarkM-


Title: Re: using Shannon's information to measure proof-of-work
Post by: becoin on June 29, 2011, 03:03:01 PM
Okay, how about re-phrasing it by saying that the prior certainty is doubled?

Before the nurse flashed the card, you were 50% certain it was whichever it turned out later to be.

After the nurse flashed the card, you were 2 * 50 = 100 % certain it was whichever it turned out to be.

-MarkM-

As a logical block above is okay, but then the entire article should be rewritten as some assumptions won't be correct. You can't double the value of something by multiplying with 1, because 1 bit is, by definition, 1 binary digit - '1' or '0'. Unless, you can prove that 1 bit = 2. But then, what is 2?


Title: Re: using Shannon's information to measure proof-of-work
Post by: markm on June 29, 2011, 04:14:52 PM
It is not really one bit, it is one additional bit.

It was conceptually easy to transpose halving uncertainty into doubling certainty, but trying to then re-write the sensible-sounding story of how your certainty doubled as somehow being a case of your uncertainty having halved was beyond me. It'd seem to imply you were 100% uncertain until the card was flashed then became 50% uncertain, which doesn't sound right at all. So the whole idea that halving uncertainty implies doubling certainty seems dubious. Boolean logic might work better somehow maybe as it smells of one of those "from x implies y we cannot deduce that y implies x" type logic thingies.

Sounded good for a moment though, didn't it? ;)

We were 50% uncertain that it was the one it turned out later not to be, until the card was flashed, then we were 100% uncertain it was the one it turned out not to be... Oops, uncertainty doubled, not halved. :)

-MarkM-
 


Title: Re: using Shannon's information to measure proof-of-work
Post by: johanatan on June 29, 2011, 08:23:31 PM
From this:
http://www.noanswersingenesis.org.au/dawkinschallenge.htm

one can see (in the 3rd and 4th paragraphs of the 'Information' section) that it is the *number of possibilities* (not precisely 'uncertainty') which is halved by the transmission of a single bit.  In your examples, the two possibilities are:

1 - it has rained X number of continuous days in Y
2 - it has not rained X number of continuous days in Y

If instead we had an example where there were 8 possible outcomes, as each additional bit comes in, the number of remaining possibilities is reduced by 1/2.  8 > 4 > 2 > 1.  After receiving 3 bits, we have precisely identified which of the 8 possibilities occurred.


Title: Re: using Shannon's information to measure block weights
Post by: Jaagu on June 30, 2011, 02:07:53 PM
... I realised that the cryptographic timestamp server I have implemented could be used as a currency.  I'll describe how later.  Anyway this would turn information, or time, into a currency.
Crazy stuff, really.

I'm burning with curiosity: did you just devise a new form of freecoin (http://www1.freshmeat.net/projects/freecoin) or you're just suggesting a major upgrade to the existing bitcoin protocol?


Title: Re: using Shannon's information to measure block weights
Post by: grondilu on July 01, 2011, 11:41:55 AM
I'm burning with curiosity: did you just devise a new form of freecoin (http://www1.freshmeat.net/projects/freecoin) or you're just suggesting a major upgrade to the existing bitcoin protocol?

Didn't know about this freecoin thing.  I'll have look someday if I have time.

I had several other ideas, such as using the chain as a data storage, and having nodes pay for each bit of information they store in the chain.

Also, I'll use general bitcoin addresses (with any version number from 0x00 to 0xFF).

Here is the current state of my code (it doesn't work yet but it will give you an idea of where I am):

$ xz < timestamp.sh | base64
/Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4EZuGttdABGIQkY99Bhqpmevep9vaWgy9uJUdLDJuwGD
AzBbm+1fOW26eoYFsF8Nm/I035vPvarX8iWIe9TEJiuDC2RFK5nutHK8tfFHyB7Vatw5Duk/Pdbp
pWtrgU7QPJ4r5SlLCm66N6dTMv+z9YjBRxe/aSYP3OvkaDOn1/20IfuE0tN6hsQAI5ZA1nOhrvc7
Kc1yszEZtcFnDbCTnSdh0J4L8YVx1CGwZPeOzMpTnnlgCyOOIjuQuVspHL/ullwun2zBkabJqeUT
igMcl7WKK4HMlkUNd1bJtafvd+pL0xf1k8MssKFbPRqKewXsKPxOLBW3bCAiUY3TQlTtssocybPV
2meUxIq0OjNiX674DGNKd3rRk+XTRopGhIwAZ2dKfv4nvz/4uAkNpOW+nqyviq+CJQSS94pzJx8w
8OjAMi9j52GnRdcFvcrw9WMHinANzTO6CWNz3nI2W0kWCTw85Xdg+4lNynwwvcDG7Vewjli+M3xj
zsVjPJ1I7JiKI6u/rOUBs+rRnzuDSY9d1jEWEj7tGDZxi5fmmD004FeFmh5tgjYCEeaP7xtrR3hE
0ydDZBoQk+Ynl3n7FBOuc4bFDBvFW0ezJUfARLZicuk2/UrvYppDSij3y6sSfnjODEOIriMOfM1c
Gx/GRYz7VVkgQjhy6cpBZuCAa7VNt9hvgYrSaoCLNSXfHn6JNu1fAbL+0K4x69qereVoyx+aS7US
FwnE1KWemWLP0daXeJOtgplI0cVFySX2Cp87atJIy0l1K31RllGJEC4VjDFa+Mqkj+pEpAGUs8rU
K12yMjJkhNt6tTIrRhbd1RdZlDtxv96+O9Mu8L38vGDd99U7j7NDXynRD+3dSuMNjyTZGBk6OGi8
hELEEwLbQO0/qWOvLtzLR7X6pXG0/1h+P1q9NUlow3Je4hZTN8Mu0TY9OCAOX7Oj57QfCKV0numP
nSKjxMQG6re9a1URp8udj02sY1cd81bSGedwRCT0g+sWm/N57kztxrjuRpB8BWjr52ADMPkLxWeg
OfIrWkkA2izE+dVA1DDVTup8mj6eqrcF7V5gkxbh6KIWRYS+MkpaepPWeMSV8TkGnbjTpRbb6ED8
/nFxJFXLA5fWdT8oEMoDcD8I29oqZmKN4GCanhlzR5qlS5SOteqlgA8+d1wBDG4w+49xbkvzXSBS
hvTfwfazDEHmUr3YXpuRQS27SFI2kV8BKfXX0X5TOm18mlRC66Lg9f2Da1aoc+7+CGJZeBG0Sbfj
bFOtNQ3SFuVYtIacjCgtXYmaHN+JdbHFOZDM2UXdsshA3bHTqEel11LbAJxfJ8WeeRUzYv7WynF1
b0LDuY4hKr4mPNcEheDLWZKUVu2kuQD76CZaT/9qB7mjez7oAz73YUEC25dwhCt56lQm8KRPMcD0
HsiFCunAQ97DJYQ1I/SGUSvhCONmQt9CLYRrZjT4gE1Dd7CYDSX8lbGcjhRorqVd7IPBoOtIGBdv
OBChH0r0N5PofK4aD7d88mn9ySdxje3eajwvOaM14qU0dQx/XEJOje1DmiL/E7+vJAJ3/aPsM7QY
9Nj5eDS39leEgpSRHSH7C1dDuYOLS14f3tyH4uMcqEoahf8wu8XihcUu8XmaDzcpUKptaqGGbuay
p5/MiyQ1x6MaHUIO/+b43Je+r37pi7nzKlj9rpsJT7fWunr9oep1xckI381yhXiQUAg9+WH+oqMt
TzQQ9UL44Qzc5kZiR4L/bIACRDU/Y5SCJ7nssN/iWqd18vq46+SMqi9xatA2nh20I00YJDgvDAgM
bi4BK7cgTwB4PKSGcaw5ZHg3pa7K3TKQ52U1EVDfz1S7ebRRVnsOwjn33l+fwL8h9Og6SpWIfiaS
+lCcZ6YkaK6PHNgBvtZrN4dKQzhyyPZjNtUbKIgM4uJweoeLafpcerDJR9wndMlqL3pMwosI7yzG
hwXFEKDIDobXgEhdKrI3/HtPb81AfAGhXqOnsU+TXYK0U+VrjR+B9bef+GXPiGDsE3G9UtUF7OSF
0xTKqc8Lsl8Y6OGSKG0n6tmI1aoVfG80vGg+VmUeWm9mTAKgu3Gc7orml5gIXSU44+vuKW90gJ5l
JkMGY7/Rc7bVIdXI3au9fdCqr9NA7X4OPywQ82+UAyFJf6kj6EiBUrr77TXsRxHAsJduwKt3KuE9
RgJPefH+GxYgqf6xwbiWsdKuzA7CnHWjFeo89X9wgSUX3sZKFT5aZQTJWZ5dAg4qIjHliatMaRAW
+gXvUqYrAYiKTLyAp5Sbhg7qF0+ywIJrAAmNqe4tuaaF3cJ/Rni2dyB1aWu5XQa8UCaqQEB4jhwR
q8JrCEfNZfg0+XjYuel8HnmnWa3LFd27uOJW1kHTbdT7tRbKkYdUbDVxUch6YdQvJIV/BgIAnDdl
DyWUdWpbPAjWITzKKu3WArcRP2xtRsL1dYj/YAVgaJ9kfTvrk1m+xtwVDU/SfxavN5Te/fskGWlG
JzTCP3Lbgq7KuN9fy3KCx2zjNWKH63HngBXKXkLeldsm4v4RjIFeoA5dsccVbj7v+TQQ0lewKHP8
GO5JQX8JqSxP8CmeE8sK1yk4pcWnIqEpRe5ujCYdostmEedof+Kiq9G3hiCUAVGfsUi0kx1PG7ZJ
38XW7zQrNf18CxWIpon09w94yIovDDD1PWGIeTowGriwYS/O4P2bXHgIC3kzoxIx3PJyJ4Iv2hg0
NwtzZKXbDn+FqBodgIMqLu67udocVvZwrib+6CXA2M6nAsbXn7yACS+P+uIpmQ0BnOoCN0OrZJji
bkLNCHFT7qSbBvkQ9JSJj00mqh7ip0yZtzv7fEtlMZaT5NY5NN170GhP1glOPlJ79K6dhOi5JG3l
KXwMDyXRcZ5Tv0Z11Nkbbj2rUedeKWy/LJbn1PcITs1z7qunlKO2xD0zCJyoTabMU6BBhpabssAV
gpKqoJn8SQHuvIcxeXXirL914er42Zu93jSXzmkwfnL0mtI7dYsbQNSwcFc6S1VuJMkZ/bLzhVQf
cjA1UtJf2pe2Qwgb5dzZxBdrHQnLbIPxCPGA8nH9SmAnl1dfIhM5llcO3aLKU23V/KGdRao/pum3
PlotyLldqHrUQ/YMcjHb1tNUiHFF3lS8UoyksDSiIBq+oDYbCVWbbs2y8Kus9GpVRbTh2+3uLEjU
RoznizSHh7T4SvAR6Ljy5sq2nZlUkdEQxsTBOkqsh33WUbDutQVvVihBwMhNQq8UEsjogVs09V/6
8IljD1iSyW9yGZkZzc6VChVcopkJgn8xaPApTGMmm2vXYh/zC61ydYseQu1AbJ+MuYJQmgleGue7
apE6YRoyHvYxdLNoazvirVLuaNhYilD8hhUCUtg5zP+CbEBcYWoh6/srgWqcLSpgtTamSSZQY00Z
vMJq1w4clWfGlB3Yh/hGAaRk9DVO+kkYZ9en3Wp1HaTvbtW5SNbiV9Fjcfjke95rk8tlKd0I+sCJ
GVEECgDwCJ7uHJk2RdLVDV4mO6+Yqx9LBL4dFese3OY6F5VMnkejGTPBwZkI11ofWaP4BWJWhCwA
ref/ZUvM0sxve908bq0+m0yTjagv+CesmkSFc939NxSNx4zXFnDuSFA4cwy0L/qcFfhHoiUQGe8l
qw2Mzz43rJWedsS+fCErQDqWZ0ntGpkm6KF6I/P6Z0j87AWszp57psXuhVuKTwCgImpp5h72PjJ9
rht1EoDDi5cDZ2h5pZxPfv0Rko77cT1VB3sZctcBCgWO9QoT1on2vFDHxbZXupeYgHznSvmT/eKA
UaHUWp1LsZ8kLsB+G5wrY3j4FyBqdCBOljQYA4rv4rtVh6dXvi9CdFGMDSPOfguj9mXbjJUqYtx9
SiMQU/zNKc75ssvjxJtqpFbL/Ci07rYNvps8S4QxFVPVNpOnc1x82hfB4eRKEjFMtkZ+3AoSoFC8
rU8DosBE9w1d9HWkRFU32yBWG5FXzd5T7qc9jkXW9Z4+qFehGxF/XKOTD11HyWCrQgkE/1IIiDX1
wJOucwW5My2+G88j+D+M21aPM7KEkXHPdiQ7Yws09EQ9PtyN67aElrn6Ekzdj6sf0yUBM07G67GJ
zW80wfFLzJJYnQk7d8MP583h5RqO9NXuK6EGdUwn5tKJWNQuataa6u8efIURvFnbi6FUzB4Yo5z/
itUTcHr5NWxOLgWaOxCau5QRkBZzXxc0MxZae7adR3gMK7ULYtpgy3aBe/gKKXx299k7gZM5PofS
6zFgW3gPP959d9e+oAkHNHQSS1mYJbjVeWV8OaQfBDVVQN5gdFX5vzH78n+7j5O7pHrHmR687HEM
VfcRODJsSEXCNVcmLmGYNlyLzafwYJkfQlKnLOXslZi0RVyLKXHmTxUVqvpke03RSaSd3sXq2xHY
4vp3gknytXIYLWGdkozZK113KOJ7y3Kcs8GB68hzyKfyZ63uuW2Xu9ZoN/uNI8yKm4LRKr+8yf98
pMWLVOORVKDLlL09vrjW99PKPGotNEt/iyE/dNw3y3PqNGgebkAPfD8tNMVqesv/BEcDYT3FpDmK
0bkDu99tIhoTudiQRVpG/I5bYc3CGTY4zBEXqY0bEKnRm9Tk6a/xlZwHEM0js9ta5drkaR5+hHl8
uDQsl4tJ+AnXKc5cZOfc4a+gHQllFz7klkR8nKJa8LlHgzaP/BRRLR4UT0NWoB4GwsEdg6vGeF3c
1sA9ZbQ1n9XPbFpKU2/fk1Er3JMpy4CKtH4jGAh79ErKyZqUd4126rFOlzOgaKMio/EODoV8AFxf
ERhFw3lLxnv+6tdUYfoB1y8nV4OtrejSe3ew/c8AzUhg0Q+Zi52LNQXvPuc+MHUOfkbarXY+wlVg
PH2ZC/hPyH201IJicuz7mciVd9auheZi6ln/oWtLVW+x867FW5GXQUPucxwqXHjwNcxPRLaH+AnH
YrB17A6SXRC3ODSQmaL/XaNJUufcdR1ekLZr6MJ5yzz5SqoR3z771Fpq6qbTsESLNC7R8cq8p6VD
7O59VvZ30GAcLmrtrqlT89t1ZHeNibBga9k1hXLsKiVsz5R2zFcVLSgc69NkIsOGxDm21tG60K1p
6jSvnXxDPZJMPaYa8Yov+F9FYuYkuFx4iaybjJaQ7NlpSkEvt3S8ajbaG88OumJnwaisZiAyYm10
IVd9EMtYgY29VGonqHsp12lF34WO263ofBU0ZauANoAiPxiSfEx5K+ARl2aOYJr3Exf8wXUggZog
W4ICHFg7YMQq9+IRJ4Wuq91eUO/Uz2LzQrkuH+/ipA+8JGU6YCgU+fNN6wv2lmfQVsJ5ZRR/GHEQ
o8LJyAgQnpuXo8/Q6qI38ldsaW5M4Xl1BqMBZpoR8GZpzMR4PvmcrXjxDwrrB/HCb8lRNxrOpbQ1
gngzPk6TDxx0CLr1uUdc9iQw4XQSZT4SZ3T7Y2pvod6NVdiL78xYaHHucA/mcmR/3qKoT3QRdlhC
eZW7kaF6biLCdZjmeUjyKTBB0copqAV85wiyuS0O9nKORwoSym83UKv1+qNI4DZ5upM85zkzxGZH
mMfp2uIjUpSDHfxDCi8MPYX7WuF+vjAAmBd+4D3i7X+ZPefIvFVZpx3rkBkN0lYyBINZW8Yt6aaG
KNM3lh/zV5kx13kyw5W//gJ8lYsgSLpGtrARre3TAwO7357GRsUr9dX5r8hPD68cjKhZyrql2HXv
eC7/CPxUocnIwdaQb7CH20yZH+Me5DkI+33K13bH235sOU7wFvpEk9WkZXez3RZBZkkxX7x/7vXy
XJDhkcpCtowo57uW13qVCZD2KuWTP6+L4vnTRkcJhTKyXztWifce+a0s8XXnUC9pBtuJB6SQaAoN
zUjmRW7B88yIWVOyN/4Um11gQGD1CtplhFtuG2QUYhGVt0XWycsnOnoJYBnNItWz2LDM8lji77Tx
lbLZMdXTvypcwvad183zWohixqxlLIsJiCVziXoMmeNAyuibhloiLO8pwLHegbwzLCA8YAuBZxTz
UI5O038Ta+OJMSnpKp6lb6MelNnhbU1hDp2RJYNzxahBbX1AXm0k5ZMzgf06GvTWGYoEckXWfXqR
aEV2quahMrgJHsi9CW9eUYD/Muh1RAVZ98XwXpSFpGsUH0xQg5SyRWlxZOVzCUkkF0HsKemBadsk
lkG/ZYeUzvpgDf0+NMWvnXbEr1zQntu9ix5R0ij5N6U+jV3P+SjPOhT+wy3EWwYqNmLyAJ820+AQ
ip8EJwfF7/d4j3hKgho+h+Z2CDrfY9ZqlYT1gWByr8O3f4YXzqbKXiGg3mhXtoU6qPxOMZCEjEaH
NIvFuVmBrMoejpogpRyCAMzj/mxYOLcqFcUJTbEaMsUK7cD35ai1pEqe8AfYF8BA/l0cZdBIJdC+
Mj8E7u1bAKulBzWYta69/a48aYfSt9ScIBUdV7QjTnTHi+FdlekOI6pGAYHgyLZ4g97RAf3fGSNm
GEDgaur52C7cGdeneKJs6WhKCEchGXRxWl64+N1q4SImh4dnnJ9YPuxX+Rau9owVfKFjpjPpnAeG
irRsTZSSZuNDpNxO6pp4i8pdx0cKwui3b3UbZitCmrundaHWulCUOyhiC1xXBYuuzm4KYIDfw4ZQ
CnbKZf5wzBnoMFvYliBuvw//JUQFcSoucoYTl87hihX5c+B2CZKsXUAkMR9rXqtzMveg2T/X6+iM
XpEkgNggrXJ8KF3OxtgMJ4pflQi5U+lf9hry8SdCMN5Nzul/3yVNhJKP/56sB/idzxZQc0Vd+aLs
M4gBXfV1Js6fYRQznLwMtiXhVzKcGtamuH/9jvcg/4E/r3W+I99Otm1GlnYY7YhxODZfOwVqrYNM
emVwzqXcmd3wL02A8x6pgIW8sInj9lyfQsB+MZ90zy1NRIdC33GS7VSqyivUMMqkYVjIxFarcn3v
94WQWy6Sg8hGe+PlcTO6H80X8i3TZlfqD6rDnHmtAg/yejqVhDpbM0Q2vC/Vq9nUuCMz+Cn7Sj0K
lvQMth1/2ix5ngBK9vVxSnzl4T/h2eiJUeO34/1W2IlCRxrC8jl7p+EY7Om6X5qMY0fKCmvpCd+l
6V+9K521AP+HGspjE4+jYn6vzpWK0WU+uzcYvwJrrgc5A5gJqp78Jd/zZVVPCW1abSFqO+Pum+FD
DRs/cIs0V5FZDY4JL6isR/DoT3+VscB3ENnEZS26ullBLCc82geQ9xcCeqh7yS0pLYHwcsshnm6i
dl5a3DDXfm4tCHuwTKkyxmeil8cieO2jBBAT1PykQTZT1Hw/r5HBywyeI0tjMGgRIzufcJxgWowQ
fQMu8uVgJpfC9qu58phW97Gd+/LpXIL4m5nHm+VS8WbvPuBfvAPWtD1MeyjnusZ4Wjo91kbAMbsA
ehMwg9kU96ttw7tRkRiFlo4hKCHN9D8C+vgeCBLymxo4pOkQUyvLaedz6rROmWxGhrAF0/t6i6t3
D9utqEH7YMGPd+lKv9xTFUn14zCajviR20eWifzY+UXvrWg9N/57LP5W0zc5wwq8Aq6//um1mko5
Yv6EEKpOFxrj0CNLdiJZoUMVxQAWMUq8uwbtzm6K072GFqEzIGNIxDg1DXV+ytv518vpJL7Tc2Kx
oXmpxGY0KzULlOR6WkytAiZZF3hqEwIiH7BhvKr9coWlufSNaa4DOhQ8zmD9JtgWRbnPPSqakeqC
lx4CvhjmTDjg0Oz248eFal01qAbjT+KMiIYuHTEo2kMhmw0jmx9/UeYvrOQ5sA7vuMoa8aF5Nbwt
rGxwJugDpIQtuWOj9lNoWTIAj87YGI1syqpixTeGfkgWpzA4gLaX69Eu+lwRkenmci3ihDO3yGwv
VFE4UVinQU0HhaJobBJvRyk/Ax+N4jsth9ZX8hP0Oi7IEzeh26izWqCkZyzlktOt8vaYKGZ9dbXT
4Jgmeel6GWs62TRWe3qpHKj8TWTNRvhZ4iLiOZj569d4CAWVN1mWv7GmzziFgVrK21fAAOZL2wvH
WiCX8735V+spio3OnuN9chIxb/C8rQPIJLz7MZNPfNBSfzlHy155CYgPJO0sc86VrYVlwxO3+NHm
RL/aBUYYZuuxQSl4deDAIJ9h092eRfav36HbwU5dG/349iBJ1S5U3dMkgL4kCQufKJ64rQH0XcCg
hSaMnIwo74S6TWF88HiMdtwMyqIDNtHbpI4T2TAe55AjQP18NLkuibcqUkw1ZUIW3Pj0r3YzLoPs
Q3ZN4XHICru8EesvtYX/3qGatSydvFXVonroXO6+6HJ5rYNnYlf5kSd2cTC6HWP8dudV1vpn8rLt
7RjyzkcST9g9PcLqdIkJUUILe24zdcAqC13Am6lJyZecFvEC/SMnazbXUe5TJVTUTHQhj1Ya98wF
M8mRrg4wgkVm+qE+hd91VCf8mQGQ3IXrAIy6kVH6VsCPECTnJSo5Wr9MGcpO0Y7cxfwsgQirj44Q
9SWsBacUIW061eveClZIbGx/1kkjEQ/EatFhL873Z+0sob9RzHnMXCGMyoOSxQ+k12OOc1ruwP0h
6hObBS11d9XGwijaoMWj0CttnusoKL6ss9rHqlxAybljdIgALcEX9+yiYpNEWHFR5H1zKM0dRkke
1nKWKEB8q/Et7fElHROR5RdqxTvVXgxBdZD7BEaLBDkcf6+teta1ToUce6aCS8WfB77hZ3klp8fc
uj3qAbemNvv1T3ux5EuU1Dbq3sZYk+PWgP/J82gbQzfGc2eMoRSHP1F9fyWvoJShSZ1ubI6S8kMn
bFBLKr2Ugmi4cO0tK2VDghuUIhJx9J3VdwviFMYdMdwHhXC9yLp4BM+kQFrqS4JtQ3hpJFF4ak2U
YIM/y2gktArr7uvtDL+8E1+pPAoMmwwUtpJm4lETfe5llL6u4xjEVuYORbTJl2WWyEhM+WVqWsll
/lDNWwz+N5WPHK/37vhu1uacrxO4cMtFgkORnTIBAq+H6ubUQ9OBHSpSa+M9p/wLquxc+5ZBcdNZ
Gs/vMLL6DcjZxs1aEPGzYz4mrXFK/tF+miIjVhrYlu9Jyp91esS399MKIXWHW3b37pdjitXLqg55
Y/jcBX4UwZJ+Ah6DgegnYKd9UM9kShoqiMQpDvADBDqzrY3AVQyLGGUa6kKNV6iQkV+kCt8j1Hd8
zYX9G3etcDtvDxJEo1BgQOJBn7TVh+Mn5XGF3oOyZakkOGjjn/kTM0m636AfPcEGpyv7oe4x77s3
MNlrFySy4aYAAADK/hOZougkewAB9zXvjAEAQUgr3bHEZ/sCAAAAAARZWg==



Title: Re: using Shannon's information to measure proof-of-work
Post by: grondilu on July 01, 2011, 08:37:52 PM

Guys, this stuff is totally blowing my mind.  As I keep modifying my design again and again, I get to think more and more about the whole thing, and the more I do that, the more I realize how deep it is.

I think it goes way beyond currencies and information technology.  I'm starting to get convinced that it is related to fundamental physical concepts such as time, energy, uncertainty principle and Everett's interpretation of quantum mechanics.   I'm really starting to think that I'm up to something big.

The idea of using chained proofs of work to measure time was something that I immediately blew me up when I got to know about bitcoin.  Now I realize why.  This idea is full of profound consequences.

If one agrees to define time as "a causal sequence of events", then it does make sense to use probabilities of these events to measure time.  And if you want to have additive properties for this thing you measure and that you call time, then it's not exactly probabilities you should use, but rather the Shannon information of these probabilities.  Now, instead of saying you are measuring, what if you say that you are actually defining it?

Finally, if you remember that quantum mechanics is all based about probability waves, you're beginning to realize how cool this idea is.


Title: Re: using Shannon's information to measure proof-of-work
Post by: markm on July 02, 2011, 01:41:34 PM
A lot of quantum mechanics purported spookiness rests upon Bell's Theorem.

So before getting too carried away about what quantum stuff can do, it is probably worth checking out

http://front.math.ucdavis.edu/search?a=Joy+Christian&t=bell&q=&c=&n=25&s=Listings

-MarkM-


Title: Re: using Shannon's information to measure proof-of-work
Post by: grondilu on July 06, 2011, 11:57:04 AM

I'm afraid I must confess I am losing motivation on this project, as I struggle to have nodes communicate and synchronize.

It would be *so* much more simple if everyone had a public IP, but we still live in a IPv4 world, so I would have to deal with NAT traversal and stuffs like that.  Using IRC could be a solution but I don't want to spam a irc network.

I publish the current state of my code, though:

$ xz < timestamp.sh |base64
/Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4CdwDrhdABGIQkY99Bhqpmevep9vaWgy9uJUdLDJuwGD
AzBbm+1fOW26eoYFsF8Nm/I035vPvarX8iWIe9TEJiuDC2RFK5nutHK8tfFHyB7Vatw5Duk/Pdbs
YX0MjiHGgjrcDRG11w16MT9B1woA+NBMyShdyZNGpS7b+6NSs1f7czZvdd/PvTl/i4vf/F6fIV9G
yLBs4nvKeVKOTP2rcl8dIIb8me/ruGrFCMMQxekJIZEI0KLY1BzsMWfh4NLUnycRDo2p93vPK72a
MrVObv060LgzOPLbBGhSoLu3SuAXDLnZrKGGWuob16IYTGjfRSDylKJei4ZOi5e6bXZCVhdCSLPe
WGU25gQr2CkIwM6TMBFEsxkqjYRD3n2AYYr7/hljwrMDDe4a9aRJkCm85uEoznx2+rQb7OM9VMER
z2yAONaVu3gRxWdGT43xLDIhAyUDlc07S7MiWmRZd++Tn9eaJZ+Bii8eSzXU8C93lGR1nz5Qc2ju
E5x9cxUwhu5d1w2n+5u9YzMM7lHZl2UYSwKEtyuFTZi8x0M+AHi5WvJBQKz9Q5vb15u0JVE/VEM2
ofiGKkTEFJT2spwLzwDaGKrG3NR35r+LYxD86v6TcrGwq7F0qsHU0W7XkXdwPfo7gso+0TrBg/Bj
ZB7ezOnioE+A7J/NZPfOqJEUIyZpSV1bqT+pSQJBN4I9ACr93PgGyxlHvo0K1y+JVop3lUBSMKzu
UAI4CRt5Lao3opCFSQaIh6WTiszJx7d9A0y7Qgn1BfZmNnR52DTgjFwa852RtHlS5SsLvoD35u43
u651KHbvnK5IwjnHEB+kKU9U8q1W4HYYAsyc7JeDzlboUMvXkWHQubUPq7V0rm0wC+9aK80ybX/b
IHudb12LfU7xhZlaJb8weZNMrNsPq/nZKlo7roQdDb4q3pxVnCKWUHYZUdmzvW8Fs7OPiw0Jb4Pn
Zds69nKxVWvKVUQkp2jEWKafA/X6IyfgjOB1i4Yg3qf1rL+txH4hG7l+BYjvbBglMa2vzOE/lznb
ghz9zX2oUrybkeBSquoVbWpIxa2LP6dNnsznLZughZ1X35o95YPrPh0rW9mR/yT0cIsp4ehDV5BD
WF3LR6afWddsghxCg3Ibww2uCinWj7F72AU5W6nNKiUKOb67RIc25IgDsvegCxMQnwTvDMPXhnXV
o9vTGwR7uxksDM+BXOQYiyvQQL//eWA+bCN3DwgQ9fQPdcQOff0DasEHGtuNq5NN3QkJgBGDrDnp
kn2WiFr/tAFWecfYyT2fvcmrvycuyEuZPgd47jEhOIRYEGbYmn1b5B7HbduEBnbBDRgEkD/Nmxz3
6f41DRp7pA3Mn016/pOhUwcGbgqR8744XQwiZHFK3c+cg+XCr8GpkBbCoecJzLy77fFo+QappUfR
5X6b9ZvAMyVyYItCAA4hFi/vOMnAqJePXh+wxHtVJ3JTg1lvHZFyJpmfc8+4vhOE2/4DVmdvnvgu
FXKexRxKxBnSefiLGwZBe/jAFiKGwE7kUMLGjyKM/fP2GU2XMlK87QY9xWkazldlU6+7+HolP0F4
AflowrSfFSHZ40z6s1ZmJISLhZZL6htjdzPvpP04DDPXYCbHZq6KKdbFjbL3c2Vyz+KcmozK9zcd
ai0PINgDzkWG7OzF2TO+6FOiVX/ZTpjXsR3nT/SkFLJiGeA2TM2PbQMy03EsLSA0s1FcFXBnjy4Z
R4ArUQsl/FpThALdg1gWDMG8R+FE9H7iJLvDjJV+Vtv6ATGY8L/xwaO1ZL4BXkbH1PiWOdhVO58S
1iDXBIyClcc84q7BDZQ22DvKxbU0c1wXc+xx7tkfCVdtxrA2P8SCS0d4iNRNjTS6LURiD4ANgNLi
Fkf8AfBc45qkNCdbVjMCyPxBmPI76gGqd/rakDiQR2c2zz61OIn00Iz5zSY0u8b9sU+H/f0AyY8+
J9nQHFvpJvP6Sc1YXXuAe6xcPTQJxFcmSUhhQc1UwPcBZPMuL4nK/WtG7GKaM5rFlqRQm+tovfZY
LXhsccvfbV/ac0mOBCl7yH3UOvQV5M8Xzr/M4iNHTVsOEXzuo3FxllBEkCHyKuxm8aIqJMpaU1lJ
PhxroiEmMJGfd/MViTvgbd4I4u+b33GcUN30ExQ/WD6J2xd+wZmprvTZkaj3dOPVTgF2IihVr1Jr
+gRzgWqWyE2q6Mg2Cj0QfleLd6TnjFgqYDZtOpGC5YS1E5YaSURMH0HmgS7ag+QRVMpRan8wtz4r
nOU05KxGrTHIAo9gQh/srCqD1xOQxXDoQXrrnVrU1isOOJM4FeSmTw9+C2Heq0doP1R6vKay0ndW
Cp8fishFmIH6jkeReeQpC7FVjxwnLKGQVC76qbzJo9oC8LCcSaVqopsKG9bsAHwdvcMVBhb6cb21
h7SPycGjVIjV5EBOftsbpPIVM35nP9Rsx3Ku3ZpSXvPrbDMpD7F3lf/h1CJfmghztSGKBoxWC5fs
sOHjVtkPNvoiLhf/fLNaV2Ho/MPl0jAwnr4SjCc7yNtkMMulLPxVOyUCfN78Ru//6cT1L+qj2dkM
QQTZ52qXrtHJ6SKxanThvU+keQuEO7x/BnTtkH4QaQ2xCzBSx4nsHxborqC7fWEs95onVhs3n/7r
Vmh6QXOVMuisYWF3IToDaQ8WjhG+sCvVQlnQmW3a/EjQlY97digBO2yPTGuVh7FHbSbSqY2m7SHh
ilR1bhNn48U1w6sqOgC/nu9ZHdjT0JWvANLbG2HkllvfyAKPH35WI0xU6WlL4+HYcrzzwAdNuzkJ
utZr1zG5VdIL8zI8dkPZLBJJc0KeT07AtAIY7w6wgcnoeO1UlVXprpbzNShtXhl6eFdn3WQ4g+Cl
cvOhsRYD/Elqws5V5j3axGrdqW2HTelfr5/4/fO0hTeU/Iy6NCOCxEGBl8anZ7zqUk5VjkiFJA23
koz42zOslXh6H5GDC+Jqx/K5i7F3S8NzEpfROUpBfric45aN1eW1vsqrfg1RQdXS+yjam/yLZVG1
GF6qApbWkDWuNWAV8R4ls9KBozqiXYxnieg6Qy/R0mXqxVh/54p1sItdtyJyQwAX9erJZ8Wj+LKN
8IMqCSMhrzRsYWmHiZSQQ3Faov1M91LEDSIByW0/29fbpuwFLLQoOSrs5TK8Zc4ZuryyMwDO+12H
qP4jOL1669KtlhlHvOwRX9VcZkfmwuww3MWrKFae7MW12aaDUylKVWo44slzWqPeS8DazJOymDmI
LD/TZCZya9Ldf6R3wmebtjVm6UQBilGm99yvEWc4PCc2hL+BP6fl8KA2YEhDFXDkuxqFl3rpHLi0
KmhmYfAorulCBczJXdBou6SBLnFXPmK/CzVWMMFT71CvWkr7GXXOt5BtOpak0eTxpVDv/m1vbmMc
d26XnauRTFYKqzcsjl51TU2LvoizDrHgSVg0GWTjBZ8/rfwEgBtys4aZ9WwRq3voYxyir3cl8H9x
1lRhhgwVm1lIueGiOUd8CNPivzA0Jx9bU1i8ma/AbgQrtj99P37fzRsu65OQYjJTiihsIo8UxgkR
d8fsRLtd7jlfGpKsB9Sjbw/E3HtsWInhAyf3JCLcUk4MKk0Qef6iEmZtHASiOeb+jDZXOWNG70yG
oyS1HQu9+IeAb4SWWjCwBs+SZOdQeUzoLvyQKFGqAZFtG9RoK8tX8ORT2pNqmoAhNv/9QpAj9we9
t5YTT83W8IDmY9h1P80sK5eZTAVCimXlBkqo0JM1OXTQC36gk4laIwt64cyYihLiMeMtl6qvilWQ
3+5nG3kJs5qY258uQyg+KKHlqgyA7IH72gv0BuOTA1F4gYh9ZMkS83tG+Gm0F9F/r+7zEj5U3hbf
S5WzhsVHul8AuvyTJOkik/D9goPynRaw/twnuxXKfbnr/E8VR4lUy9KORxK7HNceLyrMhrrqABJo
sV3+ND6qh0mUu3DXjLKABHYoytxPLGepkyrYUfWAMVVT1XnuV3G5CGy3IiJVwDxM6iFQjeOlRdkb
DA/ZPDAx0colQfEw9WHyCPNXmUa+fIzbZShJb5BaQhVM3JIu1Dgv8NmunV+umGXw5pqubZobSzNG
2HuCIJEv0Q3Vl68hqR8NadaPVwt/LYvGxlryOOLWCwvdLeEk803dMzkiwgJ1sPmYAmTpKZNv2sxu
2vrbeQVAYxq3EX/gapDqPx6xQ5faKzH7f9CVwqU/R3On4F1EASxCdNxAHj3phlH4hgaJiFxnIove
A2+0+Bj6awW3PpshVUmUF9MI14mwfpfGIAJ5SfQCrrTeA9PIoa7MO+48IcdG4Zepaq3FDkqo3Lbj
vIm2QTr4lgJRHMnltzHrBXaYXoEo+ixOvWyIpXNFmD3VplCsUbXMuNVCqCBwLfvXViJy7rUS9pMo
uUAVqoTcvbziHciBGT/4sFRDZY37Wc96nJNExf/bTAO6dvqlFajP9fpQ8Gm974uIaBOCJwHs8fXH
hBTgCbJdjd+GNnR9SWbwHiyyHslcP5mOwyKAjGAMBXbp8xiQ/9cqwdY7ZXT42QIrti5U4H9O1LtD
YbfdXb42lUmvQR9Yis7r8COFxdLcAo7Jj68OTH5OYB3eH0/ciyRMingkvQDeOVmCn6oufFe4tdNx
5KmsjNQ4LPrHugOMGEJzuzlZD0+vX1R/WABWC1mde3/dpd8MMS6dj2qqmbkLD+UAmIVVRdpDszEP
WFiwHC86RyNGJw3P27gghVoGpwc+nILT9XXt9H+yvUuXqAUibjeppNmn1bkZuOBIAF9BIz23NQEZ
j93KOnnCcQo8Hygd7epPiOJ2TKiPXjo/uwwOLWeJFOt1//+OhumwMjZVQLM2vTeM/0VCPQV2Bb9S
nWBWeGPPN67YMBWCdvyk0xoNV9uM+lBEB/Dj5mmbmyyZ7TPx1TZZ0ghjpRndGuFO+0EOKguXjfCl
dIhmMxqhrhnHgtQ+vkOnlBPV1Nli89oA15ns+nGAItz/nFwR1EM2HIaossvMJLMiFmazENKMAdFZ
43VD+35qeYPo0u4yrWYTaAlEFXzacT0jiHWL+CZu1ZcGhd1ujwBulvZ/vZ//wgAB1B3xTgAA3whU
lrHEZ/sCAAAAAARZWg==


Title: Re: using Shannon's information to measure proof-of-work
Post by: grondilu on July 08, 2011, 02:22:31 PM
I'm back on coding, as I am finally happy (more or less) with my networking design.  I won't use IRC or other fancy stuffs finally (I even considered using twitter via twidge).  Instead, I will use a IRC-inspired network.  All nodes will have a full copy of the database, but only those with public IP and CGI-capable webserver will be able to offer synchronization service to other nodes.  With enough servers and enough connectivity, the whole network can be decentralized and uniform.

I also came up with quite a deep idea:  balancing Shannon information with memory size.  It's quite difficult to explain and I don't yet have a clear explanation of why it should be done, but I'm pretty sure it should be done.

I have already implemented this idea for the payload (this is obvious), for the nonce (it's a bit less obvious) and recently I understood I should do it for the timestamp itself (this is not obvious at all, but it might be the most important idea).

Here is my code so far (the timestamp balancing is not implemented yet):

$ xz < timestamp.sh | base64
/Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4CtIDzJdABGIQkY99Bhqpmevep9vaWgy9uJUdLDJuwGD
AzBbm+1fOW26eoYFsF8Nm/I035vPvarX8iWIe9TEJiuDC2RFK5nutHK8tfFHyB7Vatw5Duk/Pdbs
YX0MjiHGgjrcDRG11w16MT9B1woA+NBMyShdyZNGpS7b+6NSs1f7czZvdd/PvTl/i4vf/F6fIV9G
yLBs4nvKeVKOTP2rcl8dIIb8me/ruGrFCMMQxekJIZEI0KLY1BzsMWfh4NLUnycRDo2p93vPK72a
MrVObv060LgzOPLbBGhSoLu3SuAXDLnZrKGGWuob16IYTGjfRSDylKJei4ZOi5e6bXZCVhdCSLPe
WGU25gQr2CkIwM6TMBFEsxkqjYRD3n2AYYr7/hljwrMDDe4a9aRJkCm85uEoznx2+rQb7OM9VMER
z2yAONaVu3gRxWdGT43xLDIhAyUDlc07S7MiNToTPTRKIXY31j74Uf2uq3lJ1Ij/1sFg7yt8iPU+
ilJc/y58GcOb/NRkU225oDDdcl33Hwfjp8SmFXFtj2WA2J1em05TmnhQCjtPbWc2zLMiKAyYpVML
5AmiIMkQx5yqV7BKk6MR2qOKNKXoOsfeVYw1HuC88KATDBC3yTTyJqpXHK1Wevu2voQ10l5QVVSf
5kQArFceICvwIg/FVGr36nd6OSnL4v6/j+V1rENSwvzdf3cYYGj2948HyWyG62NZ2N9pOpUS2eds
ib1tM0UApZnwlsrSm6/FjemihyRiEPecrPPkDsSOlHNeqkNzg1GD7LA+2UV4nSBARWOUzoDj5vja
+0mncxoA/jodFVZq/JbZzoIvN32EmknQ22tI3JN9lF5xz4MuY/0zuoMfLthFV2nAXXd5fV9p03oa
M7r1qi4vjpIPsfXTk8wLEw4+R2sDSrV/Msh7H55em8qkioCI2BYfIUn4uVr/60aiIZ75Ruq1qhIr
M5kk/FsyAJTmoWZuxBdhoqXoow/IM/3UpenDUXDtUalvq1bqwaLzOK28NLgqIlM/MJfJ7Qj9i+KJ
v6taJ/Oqh7jdks46s+Pmv4w+SNlecJbdoqaTTAoWD/fgxukv/qD9Bbp0MrxauZLLusyUj/lExJvb
NLclqqzky1l2ToKAjsKUq5kuEGC4g9aeNjBm9qBE9F7nsmWa7egAHLGWLWmwMHjvBGQ8CDy9fU4E
N8Ku/nL99utETrmbEy1xEWRr8ZCkUnG4utrG89REaCbZbo2psAiklgoWapaH/kY5y0TiV/IxJDbz
rtohA4isjiwiwAxJGXLl9gP5bu67H72cHI3O9+bmVUpBm7S4KMGkBjvALKOwFQdntjWrtK6t1OhL
igipw26rNPYoyY/Md/cp1aNnDeSPo4JyETwx58P/jV4xzdyghIBq9jiTqstPDopKMD7VbBsKphoj
qEoiKbrvNxComA6GHgPlA68MPhSGvvuefdRAn8HdbVVHOcfmoOOUSzozqWXEzTYs4vhixPC3nukf
yQByawYrNdo756ZfCEW2cZ0/P8ECiPEJm7j6cu3wT4dfT8kYkVnuEatSQo2pAkw24tl074pmD5kD
vl2vXUdPBF4rbq4ivTs43BYW0HLET9G2mnw5Qq5KX1Gln/OoNs2L1NmjJXRnw87z1+oAYvTg3AR1
FwBKAZ2DOcnuE2wvIUl7IZonqq1+ShRdHVe8oFTzPr63rV3DQc5L2TH9egc1wfD6bWD/xS4LWWQf
eElUyq3Dkn+pk1AxNwt2f22WLg4xctQbvCAUftWgU7w+6HvkOHl/VCOrxzl8jpjQ+p5IbrebG5gJ
LTdx1PUOSAys1COlwwdVsdrbzSrVEeWZOzKfvAl00e2HhMgumJMayAvnxoKKsZx/gnTYyvnYXmHt
NZWQXtbCVs8BFusDIB1kgHOyOMuFsblruygGJefdwMqs464bTLS/STzJiwAwMdhUb016+Hha8byj
ywuVmQtzqFm3OcU7JthIkmY9Qhk478mingWAlB8XRoiefyVMVt7YVqQoAK+jq5clii9Z3UP32hl6
eTasxDt5cVtOXQ4Y6Lv+VKbsmhYpJWgCWAGEyUIFlyOAVePj2AntSS7z7tlxPwT/TCL5s41CS4T/
TEWXErtCCbL8Eng17OmZ6gS246iR9oFQefaG6RZ3xX6xa7LjwRYDcX9vgHgSdALpPn6jJ5vhfygr
R/03X27T1Hz83/bQRQEK1rnT26a28EOnr/BtjMrO5sagqm1d1v7cZzwiSd7bGm3Wx50eUGHWQ9Y3
URqo2EJ7Bt6VvVrUFPZGwiMsDNIhwVbbYZjIV2VMabiaKPnluLt9zdkiCeIM+GtH8pkfoSdw/x4E
BvoxWBqtGAngcSFnAIJ+/DTlqydxmUXYAJvYsHsen+jrnF4QCP8sE4sb3yZjzvq6vmXMTgMRCEQT
zSBsum2Q44Tp23iYIsV1TEgmkHSWHeqAx6WP1WtMiREoDb9viTGinR7+PLk88MitYwQQ4rZq3cYT
39zJ77jDecGW5ugaMqSNg/4JNL/2ZZawZiiFNaVx82M2X3+NwwZbh8MBjBmlIpQp2vUgIRDVnDyb
uAfFwERL5mRUjapURKfvFloIpZ8eqlGemp5qcXUYKTxiaAKSs+AUMaWfj52TQEIwq8USQE+DfJqe
mzNeknhgR2AiFGEr94zXHe7Cb+g221VVKVNbAzEMACbtXg8yhGQtv6z0zEJvE92r09GeTv9W1wvk
FKGPuZfS/392XQeQ//Vk7L57wZW0xqRrylJkuPcqp+BShwjIFGX4Qld7v6Lnbab87Q6NkHUNM5Vs
W3zyllMZzwsOYVGKdZ2j3HrMLNB/S+fX7YlipJbNmFyd8X+pol3o4RlkHxt/H9tnDtjrFj2+QEYe
kmYo75r2TeC/e2y8RaaZoRjFw3eCbTHU20+vixU41aMZ8HBgSZ61wk50Jul75L2LpKQixgYDkQNE
N/4oKFfvn7klm5IHhZ0PsEE2xnQfCadowm3KspJRgZnH5JQvfrhQf9wcWvFn8Be7MXO/Jtxapo3T
ldyMF4W2kzKO8uc2ApokN1Z3D0U4mYbPe/hGD+RNVOB+oVU+NYdL9yjmvBCUHNzJCjMJjJsT9D+P
e0OUgpvnnmdMDoXNvfrpuPJB17XhzY66RN6Xh392tTAlKI2o6M+mfpNBywRaZiSzPjmxiElYMoNR
W685ZLUZpz0kFJnFCa4gv1b7hAj6BWMo8fDjbAA7HzHfNiquty2VbCrJjDvNvX+1VbbJbCY+8r1r
0aMeGqg8jVF5tjGc1FIIUzM1/M7OK8Z8oig7h5J2+wT2wbeIniEcUXj91MOCYVw1/TDePVpWb2Tp
vyIiAPQaBDTGAOIX8Qr+A6UfWiTLn//NKXJ36Y2rS1+FF6/4ZAWVGHdvitaRM6lSme8di2OaFvwh
tqCdczOyyjLpD1e70UznSjWd4yCe7i9bzPl3PC4SvpZG0wYTJXH8c3aasQdqJW81JqZjsoyRPVK+
GSuNGhvqnQ1nG34sz3/Um95uAyetPpf7maXqPTeTlvLVLP72Q5EmXBoUcSCwtHPeYrr2nquFS0dm
RylFaGQozabydPVT2So8q6HvkZ5bxFBmS72cx8mthtvGf/1GDGoTY2pxkss6Ku04m+RNFe7DpjSq
2z1e12iZyaYBWU2o+eBUkxEKsJgCeA0kieL3kq7+sKZP64xWHI4Cz8D1mKdwrQT48YQEmwYGFWjI
u7BQ/PSu0vpCm4koMLEvQ8mOJv+aPB88HwRCWZUATMLusa5TsNyXQtT49hss+RMDwSLzfq9GSAPG
j0Bw5qWI0WkUIEo3dZuWl+6PIRNFd5vUTGACTHMEpOmjFzPKXAo74P5EMkz93pg1sXfIIbcTnsOD
uVptNJ1JPO/HeFip9cx9GGpcvU8Y32RqIyHJFqz8SR0D+uylLRkzgZrF6DeUFPJYipkMRtlTDd05
Zlm8VBGuFXt2934GOrgqB3mV46i44iMUgLvdovJmKWe/3ZtQv7EpnRaiuMae2FPxVJGTqdvWByxw
b6fa1aePYnYnCAjaLMN1EtVv2+EekzMreaikFcF2McEOooJVtDd/j4G3t6qeMnZvMfF6+lpThuXH
SaUMWvoCtMXZR+KpF8dZtsJri6i0DNSkJXmkyvtrMmvfitgy2syo/SGPl40JCiHv3bRkD8Y4Y0NJ
W+GQgnvYZHIFlgXLgPSnL3LNXughIQQATYCuMikLVkgP5E+r88RfApHJrur9tZGXwSxZBSC9Bp+1
tiTXcnVm3FR3Oe8pQllc+hKqygVWW+5JtdeaZXtaz5mKU+3dSpFyXiidT6a7B8uaFDVdCVtDzUW5
k1WmOnCfQpicekY3/QE89UnbK8TrLlA/fJlDkuXoXKPrhydJq09sCNumV7RkD6BtitBvpBXoiotf
umXCMtH0bUkvHj3o3Bxu/LShYhZ7Mhy/AtkbXNQv1HPQODOw0Pz/kqGFQH5CrL42Lih+7aonMMcU
Cak+rjBR9vOfgPLYyg5Q8zAtd/xxT1tQkFixY1tizJJys0GJegHN1mI87hRHook5NQ5UcWIM3nO4
na8F91NMsF/6hC7xCc/na8y5/43kLT7tXhU30zSmZZd53kNOt02qnvtEBKAGzsKYpyWTugRxIVku
v36/7wg8JsWT7jx2vsaXVM0KplQWJSfI/LRASoQLDK7lzE8wifVxMbTJ70nb0b3isY8yZIOzcrku
YcM7kTf0T0kjDW3DB1WInBMR+B6Jt6KZhled8Q23sDWOjh8rMlzu5BL8XEBuceVpKaIQfpKLZ06i
uW3pbP/hwwoUmkgzID2jkvH3nR9a22DXQm79gZROx7L/cLlW8iAJYuNGaVR3/z4fPTjCbOw1Qd3S
/3JEwSuG6XV7NRKpzlETLnJyIvLilGt+q1zGSjlGoJui3ZnMQq2TZMfM78REoMX6CbPMuPZx+44q
+ls7ClJ/eHM8IghugDj05m9vssglKfS69EWDlI2jCuGoo3vtWpkNSAXWNms0UHNPS5BQl+RyZ7lg
hC6zzRUOlY0Fim7VIr40az+G2nyu9Z1ofT1Q66t/ZdsULtTgzXliuPRGZb0RyHNySnfn1r/eDme7
c9dDXV1rt1bdkqKEZvTmSBG7i7cMBTW3p2oHHp6uaSTp3nzhzKFMOgjJjkx1vGEr7/gogZT0F3+/
zRFim/hdBOwiGOTXvwZwZEgwhK1z5oMPMTUtXd3z5Y5ppkOfh9RhlbRIK1I4AAAA4cDsvGJwmkgA
Ac4eyVYAAHRxE1SxxGf7AgAAAAAEWVo=


Title: Re: using Shannon's information to measure proof-of-work
Post by: bji on July 08, 2011, 09:59:19 PM
Can you explain what you are trying to achieve?  I read the code and I don't really understand the point of it.  Here are the comments that give a brief description of the purpose:

Code:
################################################################################
#
# This code is inspired from Satoshi Nakamoto's bitcoin (see bitcoin.org).
# This is quite a different project, though.
#
# All timestamps should be of the following format:
#
# PREVIOUS_INFORMATION_VALUE NONCE PAYLOAD_DATA
#
# where:
#
# - PREVIOUS_INFORMATION_VALUE is a positive floating number.  It has to have
# many decimals, as it should include the proof of work.
#
# - NONCE is a positive integer in decimal.  Its logarithm must not exceed the
# Shannon information value of the timestmp.
#
# - PAYLOAD_DATA is some data
#
# For each timestamp, the new information value is calculated by adding the
# previous information value and the Shannon information value of the
# timestamp.
#
# In a nutshell, for a string whose sha256 is h, the shannon information value
# is:
#
# ln (2 ^ 256 / h)
#
# It is basically the opposite of the logarithm of the probability for this
# sha256 to be as low as h.
#
# Sizes of payloads are cumulated and new payloads are accepted as long as the
# total size doesn't exceed the total Shannon information of the chain.

It feels like you're trying to create an algorithm for computing proof-of-work that adheres to some rules other than the fairly straightforward proof-of-work rules that Bitcoin uses.  What exactly is the benefit of using "Shannon Information Value" as a metric for sufficiency of the proof-of-work, versus a simple empirical-difficulty approach that Bitcoin uses?

Also, am I reading it correctly - is the data itself included in the hash calculation?  If that's so then it is significantly more expensive to compute hashes than with this than with Bitcoin, that always hashes an 80 byte header regardless of the payload size.  Because of this, 'miners' in your system are incented to include the smallest payload possible because the hashes can be computed faster for them leading to a greater chance of 'beating' other miners to a successful hash.  With bitcoin, there is a greater cost to larger payloads in blocks in that the cost of verifying the transactions is greater; but the cost of verifying transactions pales in comparison to the hash computation work, and so miners can include a reasonable number of transactions without worrying about a negative impact on hash computation time.  If you include the payload in the hash calculation, then you're making the cost of computing hashes more expensive for larger payloads which, as I said, will encourage miners to include the smallest payload possible, and I don't think that's healthy for a distributed work system.


Title: Re: using Shannon's information to measure proof-of-work
Post by: grondilu on July 09, 2011, 08:15:45 AM
It feels like you're trying to create an algorithm for computing proof-of-work that adheres to some rules other than the fairly straightforward proof-of-work rules that Bitcoin uses.  What exactly is the benefit of using "Shannon Information Value" as a metric for sufficiency of the proof-of-work, versus a simple empirical-difficulty approach that Bitcoin uses?


Amongst my objectives:

- separating the distributed timestamping server from the rest of the bitcoin application.  I believe a timestamping server should be an application by itself, as it could be used by other distributed systems ;

- getting rid of the 6 blocks per hour limit ;

- finding a theoretically ideal model for the idea of measuring time using chained proofs-of-work ;

- implementing bitcoin (or a bitcoin alike system) in a higher level language than C++ ;


Quote
Also, am I reading it correctly - is the data itself included in the hash calculation?

Yes, but only if the user wants it to.  He can really put anything he wants, including a hash.

Quote
If that's so then it is significantly more expensive to compute hashes than with this than with Bitcoin, that always hashes an 80 byte header regardless of the payload size.  Because of this, 'miners' in your system are incented to include the smallest payload possible because the hashes can be computed faster for them leading to a greater chance of 'beating' other miners to a successful hash.  With bitcoin, there is a greater cost to larger payloads in blocks in that the cost of verifying the transactions is greater; but the cost of verifying transactions pales in comparison to the hash computation work, and so miners can include a reasonable number of transactions without worrying about a negative impact on hash computation time.  If you include the payload in the hash calculation, then you're making the cost of computing hashes more expensive for larger payloads which, as I said, will encourage miners to include the smallest payload possible, and I don't think that's healthy for a distributed work system.

It will indeed encourage users (and not miners, which are different people), to use the smallest possible payload.  I see this as a healthy way of saving memory space in the database.  Basically instead of puttting Justin Bieber's last concert video in the database, Justin Bieber's fans will instead put the hash of the video.  It will fullfill the purpose of timestamping the data.

It aims to be a timestamping server, not a data storage system.


Title: Re: using Shannon's information to measure proof-of-work
Post by: vector76 on July 09, 2011, 09:34:14 AM
I don't think this information theory thing is a bad idea, but at the core level I'm not really sure how it's different from the bitcoin system.

The only difference I see is that the bitcoin system uses a varying difficulty so that blocks are generated at a somewhat consistent rate even when the total information rate varies wildly.  It is just as hard to find a hash with 30 leading zero bits as finding (approximately) a million hashes with 10 leading zero bits.  The information content is the same, but they are not equally good for timestamping due to other considerations.

I think bitcoin is basically an eternity service combined with a timestamping service.  IMO it is somewhat poor at both, but it is a decent starting point.  I think considering the storage and timestamping sub-functions separately is a move in the right direction.


Title: Re: using Shannon's information to measure proof-of-work
Post by: grondilu on July 09, 2011, 10:50:42 AM
It is just as hard to find a hash with 30 leading zero bits as finding (approximately) a million hashes with 10 leading zero bits.  The information content is the same, but they are not equally good for timestamping due to other considerations.

There are very deep implications behind this assertion.  I'm still struggling to grasp them, but I believe this is the core idea behind using Shannon's information theory to measure time.

Quote
I think bitcoin is basically an eternity service combined with a
timestamping service.  IMO it is somewhat poor at both, but it is a decent
starting point.  I think considering the storage and timestamping sub-functions
separately is a move in the right direction.

I agree.


Title: Re: using Shannon's information to measure proof-of-work
Post by: vector76 on July 09, 2011, 01:00:08 PM
Sometimes when I'm feeling philosophical I think about this.  If the entire future and past of the universe were laid out in a fourth dimension, why do we observe it only going one way?  Most of the laws of physics work equally well with time reversed.  The second law of thermodynamics does not.  Entropy and time are clearly related, but what is the true nature of their relationship?  Does entropy depend on time, or is it the other way around?


Title: Re: using Shannon's information to measure proof-of-work
Post by: hashman on July 09, 2011, 04:38:17 PM

Guys, this stuff is totally blowing my mind.  As I keep modifying my design again and again, I get to think more and more about the whole thing, and the more I do that, the more I realize how deep it is.

I think it goes way beyond currencies and information technology.  I'm starting to get convinced that it is related to fundamental physical concepts such as time, energy, uncertainty principle and Everett's interpretation of quantum mechanics.   I'm really starting to think that I'm up to something big.

The idea of using chained proofs of work to measure time was something that I immediately blew me up when I got to know about bitcoin.  Now I realize why.  This idea is full of profound consequences.

If one agrees to define time as "a causal sequence of events", then it does make sense to use probabilities of these events to measure time.  And if you want to have additive properties for this thing you measure and that you call time, then it's not exactly probabilities you should use, but rather the Shannon information of these probabilities.  Now, instead of saying you are measuring, what if you say that you are actually defining it?

Finally, if you remember that quantum mechanics is all based about probability waves, you're beginning to realize how cool this idea is.

I'm trying to figure out what you are doing here with your timestamp server, and how hashing changes entropy. 
What time is it now?



Title: Re: using Shannon's information to measure proof-of-work
Post by: casascius on July 09, 2011, 04:57:02 PM
Satoshi's algorithm is much better.  If you switch away from weighting with the sum of difficulties, and go to the sum of log of difficulties, you introduce a new vulnerability into easily taking over the block chain.  That's because someone could make a very long chain of "difficulty 1" blocks and they could quickly be made to weigh more than blocks being created at the current difficulty n, because they are n times more difficult to create, but only weigh log n, which is a much smaller proportion of n as n increases.  All while difficulty 1 blocks will weigh the most in proportion to their actual creation difficulty.  So this idea is a bunch of nonsense, merely adds unwarranted complication at the expense of security.


Title: Re: using Shannon's information to measure proof-of-work
Post by: grondilu on July 10, 2011, 07:25:21 AM
Satoshi's algorithm is much better.  If you switch away from weighting with the sum of difficulties, and go to the sum of log of difficulties, you introduce a new vulnerability into easily taking over the block chain.  That's because someone could make a very long chain of "difficulty 1" blocks and they could quickly be made to weigh more than blocks being created at the current difficulty n, because they are n times more difficult to create, but only weigh log n, which is a much smaller proportion of n as n increases.  All while difficulty 1 blocks will weigh the most in proportion to their actual creation difficulty.  So this idea is a bunch of nonsense, merely adds unwarranted complication at the expense of security.

Making a long chain of small difficulties requires time, as this information would be computed in a sequential manner.  That is the whole point, actually.  The other way of computing information is to make parallel calculus.  This would require much more power.  Shannon's information is easier to calculate by cutting it in smaller successive parts, i.e. in long chain of successive events, which is all what time is about.

I actually think there is no qualitative difference between my algorithm and Satoshi's, but I don't understand Satoshi's algorithm well enough.  Anyway, I just think my version is just more "pure", and that it can allow to get rid of the 6 block per hour limit, for instance.


Title: Re: using Shannon's information to measure proof-of-work
Post by: Dusty on July 11, 2011, 06:26:00 AM
I admit I'm not grasping your aim but I'm interested in knowing more.
Anyway, I just think my version is just more "pure", and that it can allow to get rid of the 6 block per hour limit, for instance.
For what I understand the 6 block limit x hour is not a limitation but a design choice, done to balance the number of blocks with the time needed to broadcast them over a global network: the more blocks per unit time, the higher the probability of chain splits and needed reorganizations.


Title: Re: using Shannon's information to measure proof-of-work
Post by: patvarilly on July 11, 2011, 06:46:10 AM
Satoshi's algorithm is much better.  If you switch away from weighting with the sum of difficulties, and go to the sum of log of difficulties, you introduce a new vulnerability into easily taking over the block chain.  That's because someone could make a very long chain of "difficulty 1" blocks and they could quickly be made to weigh more than blocks being created at the current difficulty n, because they are n times more difficult to create, but only weigh log n, which is a much smaller proportion of n as n increases.  All while difficulty 1 blocks will weigh the most in proportion to their actual creation difficulty.  So this idea is a bunch of nonsense, merely adds unwarranted complication at the expense of security.

+1.  This was pretty clear from the start of the thread.  The rest of the thread has just devolved into metaphysical blah-blah nonsense about time, entropy, the universe and everything.  Believe me, I do research in statistical mechanics for a living: I think of entropy long and hard every day.  The full contents of this thread is a hodgepodge of big words patched together with duct-tape.


Title: Re: using Shannon's information to measure proof-of-work
Post by: johanatan on July 11, 2011, 08:14:28 AM
Satoshi's algorithm is much better.  If you switch away from weighting with the sum of difficulties, and go to the sum of log of difficulties, you introduce a new vulnerability into easily taking over the block chain.  That's because someone could make a very long chain of "difficulty 1" blocks and they could quickly be made to weigh more than blocks being created at the current difficulty n, because they are n times more difficult to create, but only weigh log n, which is a much smaller proportion of n as n increases.  All while difficulty 1 blocks will weigh the most in proportion to their actual creation difficulty.  So this idea is a bunch of nonsense, merely adds unwarranted complication at the expense of security.

+1.  This was pretty clear from the start of the thread.  The rest of the thread has just devolved into metaphysical blah-blah nonsense about time, entropy, the universe and everything.  Believe me, I do research in statistical mechanics for a living: I think of entropy long and hard every day.  The full contents of this thread is a hodgepodge of big words patched together with duct-tape.

Surely then you can take a few of the more prominent claims of this thread and debunk [or critique] them then instead of asking us to 'just trust you' TM?  Really, your post adds nothing to a scientific debate as it currently stands.