Bitcoin Forum
April 25, 2024, 02:25:19 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: using Shannon's information to measure proof-of-work  (Read 3793 times)
markm
Legendary
*
Offline Offline

Activity: 2940
Merit: 1090



View Profile WWW
July 02, 2011, 01:41:34 PM
 #21

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-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
1714011919
Hero Member
*
Offline Offline

Posts: 1714011919

View Profile Personal Message (Offline)

Ignore
1714011919
Reply with quote  #2

1714011919
Report to moderator
Unlike traditional banking where clients have only a few account numbers, with Bitcoin people can create an unlimited number of accounts (addresses). This can be used to easily track payments, and it improves anonymity.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714011919
Hero Member
*
Offline Offline

Posts: 1714011919

View Profile Personal Message (Offline)

Ignore
1714011919
Reply with quote  #2

1714011919
Report to moderator
1714011919
Hero Member
*
Offline Offline

Posts: 1714011919

View Profile Personal Message (Offline)

Ignore
1714011919
Reply with quote  #2

1714011919
Report to moderator
1714011919
Hero Member
*
Offline Offline

Posts: 1714011919

View Profile Personal Message (Offline)

Ignore
1714011919
Reply with quote  #2

1714011919
Report to moderator
grondilu (OP)
Legendary
*
Offline Offline

Activity: 1288
Merit: 1076


View Profile
July 06, 2011, 11:57:04 AM
 #22


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==

grondilu (OP)
Legendary
*
Offline Offline

Activity: 1288
Merit: 1076


View Profile
July 08, 2011, 02:22:31 PM
 #23

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=

bji
Member
**
Offline Offline

Activity: 112
Merit: 10


View Profile
July 08, 2011, 09:59:19 PM
 #24

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.
grondilu (OP)
Legendary
*
Offline Offline

Activity: 1288
Merit: 1076


View Profile
July 09, 2011, 08:15:45 AM
 #25

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.

vector76
Member
**
Offline Offline

Activity: 70
Merit: 18


View Profile
July 09, 2011, 09:34:14 AM
 #26

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.
grondilu (OP)
Legendary
*
Offline Offline

Activity: 1288
Merit: 1076


View Profile
July 09, 2011, 10:50:42 AM
 #27

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.

vector76
Member
**
Offline Offline

Activity: 70
Merit: 18


View Profile
July 09, 2011, 01:00:08 PM
 #28

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?
hashman
Legendary
*
Offline Offline

Activity: 1264
Merit: 1008


View Profile
July 09, 2011, 04:38:17 PM
 #29


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?

casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1386
Merit: 1136


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
July 09, 2011, 04:57:02 PM
 #30

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.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper or hardware wallets instead.
grondilu (OP)
Legendary
*
Offline Offline

Activity: 1288
Merit: 1076


View Profile
July 10, 2011, 07:25:21 AM
Last edit: July 10, 2011, 07:35:39 AM by grondilu
 #31

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.

Dusty
Hero Member
*****
Offline Offline

Activity: 731
Merit: 503


Libertas a calumnia


View Profile WWW
July 11, 2011, 06:26:00 AM
 #32

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.

Articoli bitcoin: Il portico dipinto
patvarilly
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
July 11, 2011, 06:46:10 AM
 #33

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.
johanatan
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
July 11, 2011, 08:14:28 AM
 #34

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.

1GjRUzZfDCBHeCyJk6av3pXYS9VKjCvQTQ
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!