[PD] cryptocurrency and pd

Jonathan Wilkes jancsika at yahoo.com
Thu Feb 6 20:41:48 CET 2014


On 02/06/2014 11:03 AM, i go bananas wrote:
> >In what way?
>
> that's what i want to know!

I don't know the specifics, but I think both cryptography and finance 
are areas where the feature of "everything is a float" actually gets in 
the way.  In either case you cannot afford to lose precision.

But you can prototype some of the features of a cryptocurrency in Pd.  
For example, Bitcoin uses the hashcash algorithm to verify each block of 
the transaction database.  (If I understand it correctly it's like 
brute-forcing SHA256 keys, although they never completely succeed.)  The 
miners basically start a counter, do a mathematical function on the 
value plus the previous value from the last entry in the transaction 
database, and finally check if the output has a certain number of 
leading zeros.

If you ignore for the moment the counter and the mathematical function, 
you can see how the process works.  Attached is a patch that just keeps 
spitting out pseudo-random numbers between 0 and 1 until all of the 
[random] objects happen to output zeros.  It's essentially like a slot 
machine that keeps playing until you win. Now notice that when you hook 
up another [random] to the chain you double the average time it takes to 
find a "winner".  Add enough [random] objects to the chain and you will 
quickly hit a point where you can't compute a "winner" at all (even if 
you change the patch to compute answers as fast as possible).

Bitcoin's "block difficulty" uses the same principle.  The software has 
a hardcoded rule that it should take 10 minutes to find a "winner".  But 
instead of using a bunch of binary values, it uses a single number and 
requires the "winner" to be below a certain value (which is equivalent 
to counting the leading zeros in the representation of the number).  
Over a certain number of days it measures the average time it takes the 
network to compute a "winner".  If it's way less than 10 minutes on 
average then the software automatically does the equivalent of adding a 
[random] to the patch to make it twice as hard.  If it takes too long 
then the software removes a [random].  The actual algo is probably more 
sophisticated but that's what it boils down to.

Now, let's say you hook up 50 [random] objects in that patch and happen 
to find a "winner".  That'd be pretty spectacular, but how do you 
convince everyone that you are being truthful about your claim? This is 
where the hashing function and the counter come into play. Instead of 
the attached patch, imagine a [hash] abstraction that takes a counter 
value in the left inlet and the previous transaction hash in the right 
inlet.  It will output a seemingly unrelated number in response to the 
input, but that number will be unique to the input you give it (or so 
close to unique that we can just call it unique).  That's what a hashing 
function does.  So you essentially do the same thing you did above, 
except you're looking for leading zeros in a single number rather than 
the collective output of a bunch of [random] objects.

When you hit a "winner" you then broadcast your counter value and the 
new transactions to the rest of the network to add to the database.  The 
rest of the network already has the previous entries in the transaction 
database, so they can take those with your counter value and verify that 
the resulting hash actually has the correct number of leading zeros.  
Then everyone starts working on the next "winner".  And why do they do 
that instead of trying to lie and say they were the one that actually 
found the "winner"?  Because the first new transaction in the database 
is the real winner giving 50 bitcoins to themselves, and that 
transaction uses public key cryptography to ensure that it can't be 
forged or changed.

One last thing-- the hashing function is designed so that it's extremely 
difficult (read: impossible) to start with a hash value that has the 
required number of leading zeros and work backwards to figure out the 
right counter value.  Like a slot machine, you have to just keep trying 
until win.  And just like a slot machine, if someone can figure out how 
get a winner without putting in the same work/money everybody else does, 
then the entire system breaks down.

-Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140206/2393348d/attachment-0001.htm>
-------------- next part --------------
#N canvas -9 19 708 498 10;
#X obj 176 44 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X obj 176 65 metro 50;
#X obj 176 172 random 2;
#X obj 178 218 +;
#X obj 246 172 random 2;
#X obj 316 172 random 2;
#X obj 178 255 +;
#X obj 178 446 moses 1;
#X obj 46 99 t a;
#X obj 386 172 random 2;
#X obj 178 286 +;
#X obj 456 172 random 2;
#X obj 526 172 random 2;
#X obj 176 86 t b b b b b b b;
#X obj 596 172 random 2;
#X obj 178 327 +;
#X obj 178 368 +;
#X obj 178 413 +;
#X text 356 114 connect more to increase the difficulty;
#X text 358 271 ... and connect them here \, too;
#X obj 46 137 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X connect 0 0 1 0;
#X connect 1 0 13 0;
#X connect 2 0 3 0;
#X connect 3 0 6 0;
#X connect 4 0 3 1;
#X connect 5 0 6 1;
#X connect 6 0 10 0;
#X connect 7 0 8 0;
#X connect 8 0 0 0;
#X connect 8 0 20 0;
#X connect 9 0 10 1;
#X connect 10 0 15 0;
#X connect 13 0 2 0;
#X connect 13 1 4 0;
#X connect 13 2 5 0;
#X connect 13 3 9 0;
#X connect 15 0 16 0;
#X connect 16 0 17 0;
#X connect 17 0 7 0;


More information about the Pd-list mailing list