Topic: [NXT] Testnet for Automated Transactions (AT) - Turing Completeness for Nxt - page 3. (Read 4205 times)
October 07, 2014, 03:29:02 PM
Is there a public branch containing the AT code developed so far?
October 07, 2014, 12:58:45 PM
[Fearful regurgitation of increasing irrelevance from the last 12 months]
Time will tell.
After 3 months of development, Nxt's answer to Ethereum will be on public testnet very soon.
The date is published if you know where to look.
Will it offer every feature Ethereum promises?
October 07, 2014, 10:55:59 AM
What are these ATs?
Here it from the horses mouth here: http://www.nxtcommunity.org/nxt-podcast/whats-nxt-automated-transactions-explained
*Trustless* is the key word.
From http://ciyam.org/nxt/nxt_at.html, here are 3 examples.
****
Use Case #1: Lottery
Create a "lottery" program which will pay out its balance to a "winner" automatically once per week.
To purchase a "ticket" a Nxt user would send X NXT to the "lottery AT account" (where some of this amount may
be needed to pay for running the AT). The "ticket" itself would be the hashed result of the ticket owner's id
(i.e. account #) added with the block id that occurs 1440 blocks *after* the purchase block (as the id of the
block that far ahread is understood to be unpredictable, however, this needs thorough mathematical analysis).
Use Case #2: Dormant Funds Transfer
Create a program that if not notified before a certain period of time will transfer its funds to one specific
account. The notification mechanism will be via an AM transaction and the content of the AM (if not empty) is
a new address to payout to.
Use Case #3: Project Crowdfunding Agent
Create a program that will at a certain time check if it has a balance greater than or equal to a target that
was hard-coded into it. If the required balance level has been reached then all funds will be then sent to an
account hard-coded into it. If the required balance has not been met then each tx sender will be refunded the
amount they sent (tx fees may also need to be considered).
***
October 07, 2014, 10:12:54 AM
What are these ATs? Is this something like a direct debit or something like a trading bot?
October 07, 2014, 08:16:28 AM
[Fearful regurgitation of increasing irrelevance from the last 12 months]
Time will tell.
After 3 months of development, Nxt's answer to Ethereum will be on public testnet very soon.
The date is published if you know where to look.
October 07, 2014, 07:54:57 AM
NXT is a shitcoin. It's kind of laughable. I'm sure the developers know by now that their distributing the entire 1billion NXT that was issued out on Day 1, to under 75 people has doomed NXT from the start....
No matter what features NXT adds, it will always fail because of it's beginnings. Face it, only an extremely small majority of people control most of the NXT coins in existence and by the very small trading volume seen on NXT(even with it's decent sized marketcap), we can all see that those people are reluctant to sell their coins/ease the extreme unfairness present, making NXT one of the most "centralized" alt-coins ever made.
No matter what features NXT adds, it will always fail because of it's beginnings. Face it, only an extremely small majority of people control most of the NXT coins in existence and by the very small trading volume seen on NXT(even with it's decent sized marketcap), we can all see that those people are reluctant to sell their coins/ease the extreme unfairness present, making NXT one of the most "centralized" alt-coins ever made.
October 07, 2014, 07:51:52 AM
Reserved 
July 02, 2014, 04:23:26 PM
For all to think about it and to support the AT Team.
source https://nxtforum.org/general-discussion/so-where-does-at-go-from-now/msg58143/#msg58143
source https://nxtforum.org/general-discussion/so-where-does-at-go-from-now/msg58143/#msg58143
Concerns and issue; compiled from a discussion with JL.
The team around AT needs to answer these questions during the testing period of AT.
0) Problem is not to achieve something with AT, but how to restrict AT scripts to avoid inconsistent results: cf. below
1) We need to make it safe in certain ways:
- restricting AT scripts - transactions validation?
- can a script create other scripts (viruses)?
- access on core resources - querying them
- using core capabilities - like methods of the Account class and so on
2) Scalability:
- re-executing the script on every node?
- better of avoiding it?
- some sort of easy proof that the script was executed correctly?
3) Code complication
- minimizing the core code
- if script is using internal core methods, core modifications will be necessary everywhere -> first step: using regular transactions, second step: creating custom transactions, third step: introducing custom objects
4) How to start a script?
- by transaction?
- by height trigger?
- by what else?
5) Scientific research done?
6) How to do debugging?
- Who called what when and why?
- different languages in use
7) How to do updating a AT script?
How to migrate running/active AT scripts once the underlying program found flawed and a new version is/will be deployed?
9) Atomicity
- Are scripts atomic?
- How to achieve atomicity?
- How to split up atomicity within one script?
- When is the output of a script accepted, i.e. changes balances and the like? (turing complete -> Halting problem etc.)
- rollback necessary?
10) What is the output of a script?
- a sequence of regular Nxt transactions?
- using custom transaction types?
- directly manipulating the Core Objects like Account, Aliases, Orders etc. etc.
11) What is the input of a script?
- block headers?
- confirmed transactions?
- raw transactions?
12) When calling internal methods like DigitalGoodsStore.deliver(), how to we enforce rules that are set by the corresponding transaction type?
That is it for now. Keep you updated.
The team around AT needs to answer these questions during the testing period of AT.
0) Problem is not to achieve something with AT, but how to restrict AT scripts to avoid inconsistent results: cf. below
1) We need to make it safe in certain ways:
- restricting AT scripts - transactions validation?
- can a script create other scripts (viruses)?
- access on core resources - querying them
- using core capabilities - like methods of the Account class and so on
2) Scalability:
- re-executing the script on every node?
- better of avoiding it?
- some sort of easy proof that the script was executed correctly?
3) Code complication
- minimizing the core code
- if script is using internal core methods, core modifications will be necessary everywhere -> first step: using regular transactions, second step: creating custom transactions, third step: introducing custom objects
4) How to start a script?
- by transaction?
- by height trigger?
- by what else?
5) Scientific research done?
6) How to do debugging?
- Who called what when and why?
- different languages in use
7) How to do updating a AT script?
How to migrate running/active AT scripts once the underlying program found flawed and a new version is/will be deployed?9) Atomicity
- Are scripts atomic?
- How to achieve atomicity?
- How to split up atomicity within one script?
- When is the output of a script accepted, i.e. changes balances and the like? (turing complete -> Halting problem etc.)
- rollback necessary?
10) What is the output of a script?
- a sequence of regular Nxt transactions?
- using custom transaction types?
- directly manipulating the Core Objects like Account, Aliases, Orders etc. etc.
11) What is the input of a script?
- block headers?
- confirmed transactions?
- raw transactions?
12) When calling internal methods like DigitalGoodsStore.deliver(), how to we enforce rules that are set by the corresponding transaction type?
That is it for now. Keep you updated.
Jump to: