Common Lisp Blockchain - Scheme Coin

Tue Dec 19 04:34:13 UTC 2017

TBH it doesn’t really do anything yet but evaluate ‘code’ transactions that are placed on the blockchain using the (execute …) macro, like this:

CL-USER 20 : 2 > (execute *quester-address* 1 (set! square (lambda (x) (* x x))))
(#S(TRANSACTION :FROM #(82 47 C9 D C8 6F 69 5A 25 3B 8A 6F 44 17 8F A8 EC 6B F8 24 30 3F AC FC D8 B7 20 4 BD F0 4F 8F 39 C1 EA C4 67 1F A2 2A ...) :TO #(FE BA 12 F3 81 48 A2 89 31 7D 9C D5 8D 80 91 C4 F4 CE 6B 7B B6 E7 A8 8F 11 89 8 F6 6E 7E 26 E8 39 95 73 BD 63 B0 4D 54 ...) :VALUE 1 :ACCURACY 1 :DURATION 13D5 :|DATA| (SET! SQUARE #) :HASH #(A5 42 F8 E3 CE 1E 2B 4C BF C2 83 C9 CF 45 38 CF CB 9B CB 85 9A F2 AC D7 26 5A A0 BE D4 C4 6E 37 F3 DD DC 85 A4 50 7B BD ...) :PREVIOUS-HASH NIL))

CL-USER 21 : 2 > (execute *quester-address* 1 (set! double (lambda (x) (+ x x))))
(#S(TRANSACTION :FROM #(82 47 C9 D C8 6F 69 5A 25 3B 8A 6F 44 17 8F A8 EC 6B F8 24 30 3F AC FC D8 B7 20 4 BD F0 4F 8F 39 C1 EA C4 67 1F A2 2A ...) :TO #(FE BA 12 F3 81 48 A2 89 31 7D 9C D5 8D 80 91 C4 F4 CE 6B 7B B6 E7 A8 8F 11 89 8 F6 6E 7E 26 E8 39 95 73 BD 63 B0 4D 54 ...) :VALUE 1 :ACCURACY 1 :DURATION 13D6 :|DATA| (SET! DOUBLE #) :HASH #(65 66 2D CD 38 AD 3D 5C 2 2D 4D 86 CE D2 79 D8 FC 63 B1 45 FF 7E 79 94 EF 82 D2 AD B5 3F B1 DD A5 70 1E E9 4E 6C 4E 1C ...) :PREVIOUS-HASH NIL))

CL-USER 22 : 2 > (execute *quester-address* 1 (set! x (+ (double 4) (square 4))))
(#S(TRANSACTION :FROM #(82 47 C9 D C8 6F 69 5A 25 3B 8A 6F 44 17 8F A8 EC 6B F8 24 30 3F AC FC D8 B7 20 4 BD F0 4F 8F 39 C1 EA C4 67 1F A2 2A ...) :TO #(FE BA 12 F3 81 48 A2 89 31 7D 9C D5 8D 80 91 C4 F4 CE 6B 7B B6 E7 A8 8F 11 89 8 F6 6E 7E 26 E8 39 95 73 BD 63 B0 4D 54 ...) :VALUE 1 :ACCURACY 1 :DURATION 13D7 :|DATA| (SET! X #) :HASH #(21 5C 71 F2 1F 5C B9 4F AE 4D 44 90 3 C8 7 39 51 64 5A D4 39 69 95 C0 4A 9F E6 30 8C 9D 4E DB E4 57 6C 98 31 79 E7 C2 ...) :PREVIOUS-HASH NIL))

CL-USER 23 : 2 > (pprint (car *blockchain*))

#S(BLOCK :INDEX 13D6
         :TIMESTAMP DDE31477
         :|DATA| (#S(TRANSACTION :FROM #
                                 :TO #
                                 :VALUE 1
                                 :ACCURACY NIL
                                 :DURATION NIL
                                 :|DATA| NIL
                                 :HASH #
                                 :PREVIOUS-HASH NIL)
                  #S(TRANSACTION :FROM #
                                 :TO #
                                 :VALUE 0
                                 :ACCURACY NIL
                                 :DURATION NIL
                                 :|DATA| 18
                                 :HASH #
                                 :PREVIOUS-HASH #)
                  #S(TRANSACTION :FROM #
                                 :TO #
                                 :VALUE 1
                                 :ACCURACY 1
                                 :DURATION 13D7
                                 :|DATA| #
                                 :HASH #
                                 :PREVIOUS-HASH NIL))
         :PREVIOUS-HASH #(D8 35 FF D5 4B 42 89 FA D4 E1 BB 16 BA C1 8 70
                          B8 A9 73 64 20 C9 7A D2 20 C1 50 5E 10 38 9E 3
                          D6 DF 95 C3 39 7 F8 74 ...)
         :HASH #(D 33 62 56 1E ED 9D EE 93 A2 53 95 21 39 9F C2 54 40 DE
                 3D D2 4A 90 20 CD 4D FF 4B C2 68 7D 4F FA 4D 4 9 EC 93
                 CC F ...))

CL-USER 24 : 2 > 

Where *quester-address* is an address that has some ‘value’ (as given to it by the “genesis” transaction in this implementation (aka this is totally premined)), the amount they are sending to ‘give’ to the miner for answering (aka the value that is transferred between accounts upon proof of work).  

—
Burton Samograd

> On Dec 18, 2017, at 2:21 PM, David McClain <dbm at refined-audiometrics.com> wrote:
> 
> Problem with TRANSFER seems to be that its first use was prior to its Macro Definition. Placing the Macro Definition ahead of first use clears up the problem. But system is still hung waiting for a network connection…
> 
> - DM
> 
> 
>> On Dec 18, 2017, at 14:11, David McClain <dbm at refined-audiometrics.com <mailto:dbm at refined-audiometrics.com>> wrote:
>> 
>> okay, my bad… I see that the TRANSFER is part of a CASE construct. But here is the error on initial compile buffer:
>> 
>> The call (#<Function TRANSFER 422001358C> #(58 EF D8 12 7C 50 5F 84 C4 53 B3 DE EB 5E 5 8 CB E2 ED B7 D2 75 7C 34 1D DD 8 6 C0 74 8B 5F B3 13 91 D3 BD A7 FB E4 ...) #(5F 80 7 5C C6 4E 24 BE 27
>> EA EB DE 93 B5 92 E5 27 FF BF 37 40 90 63 D0 F5 38 D5 0 DA 6E 15 62 FA B5 CC 5 84 CC C5 A5 ...) 1) does not match definition (#<Function TRANSFER 422001358C> FROM TO VALUE).
>> 
>> Debugger points to MINE. Happens during COMPILE-FILE.
>> 
>> - DM
>> 
>> 
>>> On Dec 18, 2017, at 13:49, David McClain <dbm at refined-audiometrics.com <mailto:dbm at refined-audiometrics.com>> wrote:
>>> 
>>> seems to be a problem with the use of TRANSFER here:
>>> 
>>> 
>>> (defun process-coin-server-request (stream)
>>>   (let ((request (read stream)))
>>>     (case request
>>>       (transfer (process-transfer-request (cdr request) stream))
>>>       (execute (process-execute-request (cdr request) stream))
>>>       (blocks (process-blocks-request (cdr request) stream)))))
>>> 
>>> Also redefines BLOCK and so we probably need to declare shadowing at the top. 
>>> 
>>> Not sure what the quickload stuff was trying to accomplish, but my resident version of Ironclad kept shadowing anything imported by quickload. No SHA3 digest in my resident version, so I replaced it (for now) with the bleeding edge version from GitHub. That worked, as far as I can tell.
>>> 
>>> Actually had to compile buffer twice in order to get past the TRANSFER error (not sure why that even works?) but the system appears to be hung waiting for some kind of network connection. Perhaps you could give us a usage hint?
>>> 
>>> Cheers,
>>> 
>>> - DM
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20171218/c21f3293/attachment.html>