I think the problem could perhaps only be solved by some sort of more "random" process (which is not simple with an AT as it is not easy for an AT to actually get *random* data).
I am guessing if we could get enough randomness then our "whale lover's" donation (and I am not against the whales - so replace them with any other creature you like or dislike) could actually be just as likely to go to the "whale eater's" foundation.
That I guess would stop the money going into the "void" but keep anyone from having an "agenda" to not release funds.
Topic: Nxt :: Automated Transactions (AT) - progress and discussion - page 2. (Read 17292 times)
February 26, 2014, 01:20:29 PM
February 26, 2014, 01:15:20 PM
I like your approach of sending to void (perhaps genesis block or Nxt bounty fund), so buyer is committed regardless and seller has no incentive to scam.
Thanks - after some thought it actually is probably better to always send to the void than to anything else.
(someone who "loves the whales" but "hates X tee-shirts" could always make an order for a tee-shirt and then just send the money to the "help the whales" organisation claiming to have been not sent a tee-shirt)
How is "void" defined? Perhaps Genesis Block? Could incorporate AE and DAC later into escrow. For example: Buyer purchases goods. Buyer converts Nxt to "Escrow coin" via AE. Buyer submits Escrow coin to Seller via AT. Buyer receives goods and releases Escrow coins to Seller. Seller then converts Escrow coin to Nxt or any crypto via DAC. That way we are never really losing any Nxt to void, only Escrow coins. Although not sure where Nxt would end up if transaction falls through, perhaps to owner of Escrow Coin Asset.
February 26, 2014, 12:41:28 PM
I like your approach of sending to void (perhaps genesis block or Nxt bounty fund), so buyer is committed regardless and seller has no incentive to scam.
Thanks - after some thought it actually is probably better to always send to the void than to anything else.
(someone who "loves the whales" but "hates X tee-shirts" could always make an order for a tee-shirt and then just send the money to the "help the whales" organisation claiming to have been not sent a tee-shirt)
February 26, 2014, 12:39:51 PM
Hey CIYAM, would an "Escrow" use case be possible with AT? I feel that this would be very useful and have been thinking about how it's possible with AT.
Hmm... I am thinking what might work is this sort of approach (not ideal but still could be useful).
An AT is created that can only send funds to 1 of 2 addresses with 1 of those being to "the void" (or a charity if preferred) and the other being to the person you are buying goods from with an AM (from only its creator) being used to instruct it to send to the vendor (and with a timeout to send to the void after x days/weeks/months).
So once you have funded that AT then the guy selling you the goods can see that your funds are "committed" (i.e. you can't get them back) then he sends you the goods and you release the funds to him.
You'd want to tie this in with a "rating" system I'd guess also but I think we do have another use case here (it's actually just a variation on the Dormant Funds Transfer technically).
Great, I think an Escrow AT would be a great seller, perhaps we can talk to Nexern about adding to his client as his client has a functional reputation system. I like your approach of sending to void (perhaps genesis block or Nxt bounty fund), so buyer is committed regardless and seller has no incentive to scam. Really interesting stuff, perhaps someone has a better approach but I like it.
Furthermore, the 1st account could be a specific market escrow committee, so if the funds end up there and the seller has a case, he can argue for the funds with proof. Great work here CIYAM
February 26, 2014, 12:33:30 PM
Hey CIYAM, would an "Escrow" use case be possible with AT? I feel that this would be very useful and have been thinking about how it's possible with AT.
Hmm... I am thinking what might work is this sort of approach (not ideal but still could be useful).
An AT is created that can only send funds to 1 of 2 addresses with 1 of those being to "the void" (or a charity if preferred) and the other being to the person you are buying goods from with an AM (from only its creator) being used to instruct it to send to the vendor (and with a timeout to send to the void after x days/weeks/months).
So once you have funded that AT then the guy selling you the goods can see that your funds are "committed" (i.e. you can't get them back) then he sends you the goods and you release the funds to him.
You'd want to tie this in with a "rating" system I'd guess also but I think we do have another use case here (it's actually just a variation on the Dormant Funds Transfer technically).
Great, I think an Escrow AT would be a great seller, perhaps we can talk to Nexern about adding to his client as his client has a functional reputation system. I like your approach of sending to void (perhaps genesis block or Nxt bounty fund), so buyer is committed regardless and seller has no incentive to scam. Really interesting stuff, perhaps someone has a better approach but I like it.
February 25, 2014, 08:20:31 PM
Hey CIYAM, would an "Escrow" use case be possible with AT? I feel that this would be very useful and have been thinking about how it's possible with AT.
Hmm... I am thinking what might work is this sort of approach (not ideal but still could be useful).
An AT is created that can only send funds to 1 of 2 addresses with 1 of those being to "the void" (or a charity if preferred) and the other being to the person you are buying goods from with an AM (from only its creator) being used to instruct it to send to the vendor (and with a timeout to send to the void after x days/weeks/months).
So once you have funded that AT then the guy selling you the goods can see that your funds are "committed" (i.e. you can't get them back) then he sends you the goods and you release the funds to him.
You'd want to tie this in with a "rating" system I'd guess also but I think we do have another use case here (it's actually just a variation on the Dormant Funds Transfer technically).
February 25, 2014, 12:30:16 PM
Hey CIYAM, would an "Escrow" use case be possible with AT? I feel that this would be very useful and have been thinking about how it's possible with AT.
February 25, 2014, 01:59:56 AM
Further update - it took a bit of time (to rework the use cases) but now there is no use of "unsigned integers" (except for some "prints") which should make porting to Java easier (most op code values have been changed so no op code > 0x7f).
The next stage is to get some tasks put up on CIYAM Open (http://ciyam.org/open/?cmd=view&data=20140220164742097000&ident=M100V137&chksum=065ecf7d) and organise some people to "put dibs" on them.
The next stage is to get some tasks put up on CIYAM Open (http://ciyam.org/open/?cmd=view&data=20140220164742097000&ident=M100V137&chksum=065ecf7d) and organise some people to "put dibs" on them.
February 23, 2014, 08:28:51 AM
Another update - I've removed four op codes (ADD_VAL, SUB_VAL, MUL_VAL and DIV_VAL) so that the only op code that requires a 64 bit value is SET_VAL.
Other changes were in the description about the stacks (there are two - a "call stack" and a "user stack").
Other changes were in the description about the stacks (there are two - a "call stack" and a "user stack").
February 22, 2014, 08:31:58 AM
Just to note I've updated the specification and the "Crowdfunding Agent" use case after testing it today.
A new op code SET_PCS has been introduced and "pcs" has been added to the "persistent state". Its purpose is to hold the "program counter start" (normally zero) which is where the "pc" will start after a FIN op has occurred (or after the last op has been executed).
This allows an AT to set a new point to begin execution from if/when it is "awoken" by a new tx. In the case of the "crowdfunding agent" this will be conditionally set depending upon whether the balance of the AT had met its target amount by the target time so that if further txs occur then any balance will be either (a) sent to the project because it had met its target or (b) refunded to the sender because it had not.
A new op code SET_PCS has been introduced and "pcs" has been added to the "persistent state". Its purpose is to hold the "program counter start" (normally zero) which is where the "pc" will start after a FIN op has occurred (or after the last op has been executed).
This allows an AT to set a new point to begin execution from if/when it is "awoken" by a new tx. In the case of the "crowdfunding agent" this will be conditionally set depending upon whether the balance of the AT had met its target amount by the target time so that if further txs occur then any balance will be either (a) sent to the project because it had met its target or (b) refunded to the sender because it had not.
February 22, 2014, 05:03:27 AM
When will this be fully functional and implemented?
The plan is to get this ready for release in April (which I think should easily be achieved provided that we can organise a team in the next week or two).
From the technical side there will still need to be quite a bit of further work done on the specification (adding "meat" to the "bones") and then a lot of test cases need to be created (both for the AT interpreter itself and for each of the use cases mentioned in the specification).
The actual coding for the AT interpreter itself is not likely to be a huge job (I'd say a week or two) so the testing is going to probably require the most effort.
February 22, 2014, 04:25:30 AM
When will this be fully functional and implemented?
February 21, 2014, 09:45:08 AM
Just a post to let you guys know that I've updated the documents at http://ciyam.org/nxt and have added the 3rd use case which is a Crowdfunding Agent.
I have yet to create sample data and test this last use case (will do that by early next week) but I think the basic form of the AT concept is taking shape.
I have yet to create sample data and test this last use case (will do that by early next week) but I think the basic form of the AT concept is taking shape.
February 21, 2014, 07:19:10 AM
I'm sorry, I don't think I can. 
Spec needs to be pc = addr3, without the $.
Spec needs to be pc = addr3, without the $.Yup - my bad again - actually the code had it right all the time I just wrote the spec. wrong (twice now).
It will be fixed to: pc = addr3 in the spec. (which is how it actually had been coded in the prototype originally - guess I code better than I write specifications).
February 21, 2014, 07:11:53 AM
Code:
SUB_LEQ 0x89 addr1,addr2,addr3 @addr1 -= $addr2, if $addr1 <= 0 then pc = $addr3 (for James)
Please tell me I've got it right this time!
I'm sorry, I don't think I can.
Spec needs to be pc = addr3, without the $.Maybe it's my use of the variable name "addr3" that's the confusion; addr3 is supposed to be a value representing an address, not the value pointed to by an address. It should behave like JUM_ADR. (I do math mainly, not coding, so I'm not used to naming conventions.) So maybe
Code:
SUB_LEQ 0x89 addr1,addr2,addr_value @addr1 -= $addr2, if $addr1 <= 0 then pc = addr_value (for James)
would remove any confusion?
February 21, 2014, 05:07:13 AM
Actually, that still isn't the subleq branching. SUBLEQ a, b, c means that after you perform a = a - b, if that is <= 0, you goto c, not the address pointed to by c, or advance the code point by c. So you'll want pc = addr3 instead.
Oh - so I changed the code which was actually already correct - doh!
Okay so I'll put the code back the way it was and change the spec. to this:
Code:
SUB_LEQ 0x89 addr1,addr2,addr3 @addr1 -= $addr2, if $addr1 <= 0 then pc = $addr3 (for James)
Please tell me I've got it right this time!
February 21, 2014, 04:52:01 AM
It might also make sense to have an AT "priority" setting (a bit like task priority) so that lower priority ATs might only be run at most every X blocks.
Yeah some form of triage makes sense, since computational resources may be limited. AT coders should be coding ATs in such a way that they don't have to be running every block to successfully complete execution anyways, since things like running out of funds could happen.
Code:
if( state.jumps.count( state.pc + addr3 ) )
state.pc += addr3;
Actually, that still isn't the subleq branching. SUBLEQ a, b, c means that after you perform a = a - b, if that is <= 0, you goto c, not the address pointed to by c, or advance the code point by c. So you'll want pc = addr3 instead.
(I don't know whether to feel proud or guilty about optimizing subleq!)
February 21, 2014, 03:16:10 AM
I missed that. Hopefully I wont have to pay double for all the subleqs.
Strange, I wrote it in the spec as state.pc += $addr3 but didn't actually code it that way in the prototype - anyway I've changed the code (locally for now but will republish soon) to the following:
Code:
if( state.jumps.count( state.pc + addr3 ) )
state.pc += addr3;
state.pc += addr3;
so this ought to be the "subleq" you were expecting James.
I think it would be nice to have the possibility to execute the AT at a specific block height (Time) without the need for a incoming transaction to that AT.
Agreed - so I think part of the AT "header" will include an "execute at" block # (or approx. time). Another related idea is that if an AT is currently hibernating then the extra fee required for sending a tx to an AT (to allow it to execute a minimum # of steps) would be instead added to the AT's balance (i.e. so it is paying for those steps to be executed later).
February 21, 2014, 01:38:19 AM
I think it would be nice to have the possibility to execute the AT at a specific block height (Time) without the need for a incoming transaction to that AT.
February 21, 2014, 01:22:25 AM
After some consideration I am now thinking that a simple "crowd funding" AT could be a better 3rd use case (I was considering an "auction" but it seems to me the VS could probably handle that with some very minor modifications).
The idea would be that this AT would check its balance after n blocks (so it would be a good candidate to use the "sleep until block X") and if it is >= X then it would send all its funds to account Y (being the "project's account") otherwise it would iterate through all the txs it had received and refund the amount back to the sender (minus a small amount to run itself).
What do you guys think?
Pretty much although it actually depends how it had halted - if it had finished running (or reached a "finish" op) then yes it does that but if it hit a "stop" op (or it was halted due to lack of funds) then it continues from that point rather than from the start.
The execution time is in accordance with the AT's balance although a fee (possible mandatory) will cover a small amount of execution (so an AM would actually trigger execution).
The idea would be that this AT would check its balance after n blocks (so it would be a good candidate to use the "sleep until block X") and if it is >= X then it would send all its funds to account Y (being the "project's account") otherwise it would iterate through all the txs it had received and refund the amount back to the sender (minus a small amount to run itself).
What do you guys think?
Do i get this right, everytime a new transaction comes in, the AT is beeing executed from the beginning, but the memory is at the state where it ended last time?
Pretty much although it actually depends how it had halted - if it had finished running (or reached a "finish" op) then yes it does that but if it hit a "stop" op (or it was halted due to lack of funds) then it continues from that point rather than from the start.
From where is execution time purchased from the ATs XNTs or from a fee in the incoming transaction?
The execution time is in accordance with the AT's balance although a fee (possible mandatory) will cover a small amount of execution (so an AM would actually trigger execution).
Jump to: