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 <d...@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 <d...@refined-audiometrics.com 
>> <mailto:d...@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 <d...@refined-audiometrics.com 
>>> <mailto:d...@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
>> 
> 

Reply via email to