|
grondilu (OP)
Legendary
Offline
Activity: 1288
Merit: 1080
|
|
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==
|
|
|
|
grondilu (OP)
Legendary
Offline
Activity: 1288
Merit: 1080
|
|
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=
|
|
|
|
bji
Member
Offline
Activity: 112
Merit: 10
|
|
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: ################################################################################ # # 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
Activity: 1288
Merit: 1080
|
|
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++ ; 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. 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
Activity: 70
Merit: 18
|
|
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.
|
|
|
|
grondilu (OP)
Legendary
Offline
Activity: 1288
Merit: 1080
|
|
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. 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
Activity: 70
Merit: 18
|
|
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?
|
|
|
|
hashman
Legendary
Offline
Activity: 1264
Merit: 1008
|
|
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?
|
|
|
|
casascius
Mike Caldwell
VIP
Legendary
Offline
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
|
|
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.
|
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
Activity: 1288
Merit: 1080
|
|
July 10, 2011, 07:25:21 AM Last edit: July 10, 2011, 07:35:39 AM by grondilu |
|
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
|
|
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.
|
|
|
|
patvarilly
Newbie
Offline
Activity: 42
Merit: 0
|
|
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.
|
|
|
|
johanatan
Member
Offline
Activity: 84
Merit: 10
|
|
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.
|
1GjRUzZfDCBHeCyJk6av3pXYS9VKjCvQTQ
|
|
|
|