Topic: Nxt :: Automated Transactions (AT) - progress and discussion - page 6. (Read 17237 times)

Yeah sounds good. Xtnd (like Nxt) is a name that appeals towards users (both casual programmers and regular folks) more. AXs would be more convenient terms for experts.



Hmm... I guess that could work through the use of AM although I wasn't planning on trying to handle AM initially but if enough people are keen on that (I know that James is) then maybe I can work that into a 3rd "use case".
[/quote]

I'm interested too. A lot of possibilities open up if users can send scripts more specific information.

It will be a "Turing complete" language but it will not be able to do much other than examine the blockchain and create transactions so I think Automated Transactions is really "the main point".

If you are thinking that these scripts are going to be sending emails or the like the you have the "wrong idea" about what is being proposed here.

As we are going to end up needing a higher level language above the low-level "assembler" like language we could use that name for it. Good enough?


Hmm... I guess that could work through the use of AM although I wasn't planning on trying to handle AM initially but if enough people are keen on that (I know that James is) then maybe I can work that into a 3rd "use case".

Isn't it more then just automated transactions? Aren't we talking about the scripting language in general also?

Yes, but before the number will be used to seed the random function, it will be hashed together with 100 other numbers of other block forgers. If at least one of these 100 numbers is random then the  whole resulting hash is random

How will everyone else verify that the number was indeed generated randomly? The forger could have used a biased generator, or just chosen it themselves.

If you're calling the scripts Automated Transactions, what about calling (some level of) the scripting language Xtnd?

EDIT: Then we can call the scripts Xtnded Transactions.

Another possible use case is for alias auction, after alias transferring is enabled.

+1

If one change will slow or risk of bugs  i recommend staying away at this point. It's seen by Bitcoin how falling with hack attacks...

Ok now here is the solution to the random data issue:
Every forger creates a very large random number. He hashes this number and adds the hash to to block he is forging.
 
He than creates a transaction that will reveals this random number. This transaction in not yet beeing pusblished to the network. Instead this transaction is beeing sent as encrypted arbitrary message to the 10 previous forgers. These 10 previous forgers decrypt that
 arbitrary message and check the random number against the hash in the blockchain. When everything is ok every previous forger creates an arbitrary message that states that he recieved the correct transaction (these 10 arbitrary message will be added to the blockchain).


After 100 blocks the transaction that reveals the random number is beeing published to the network (and added to the Blockchain).

Now the last known 100 random numbers are hashed together to seed the random function (Only those random numbers are used where short after creation most of the previous forgers stated they have received the revealing transaction).


It's just that easy! 

Note that I've changed the title of this topic - unless we come up with a better name I think Automated Transactions (AT) is what we are going to use (as it fits in nicely along AC, AE, AM, and AS).

Nodecoin might be simple enough. Just need to transfer Nodecoin asset to all accts that were forging that block, but that would require NXTcoins to be there and if you are saying no using AM for your use cases, it seems NXTcoins wont be guaranteed to be done via NXT VM

I will go to plan B then.

James

Having some sort of AM "data feed" would be fine (and at least it would be clear that you are having to trust whoever created it). I'm not quite sure how an AT (Automated Transaction) would "find" the AM but assuming that it could somehow be done via an API call then it should be possible for AT to use such data.

At this stage the only two "use cases" that are being considered are 1) Lottery and 2) Inactive Account Payout. A third use case would need to be no more complicated than either of those for consideration at this stage (we need to walk before we can run).

Something that works with AE could be doable - but it would need to be a really simple bot (so tying in it with AM as well is going too far IMO).

OK, am I allowed to have NXT nodes voluntarily run software and publish AM data with datafeeds that these nodes will peer validate? It wouldnt be in the NXTcore at all, just an application on top of NXT using AM, so I think it is ok, but I wanted to make sure I am not forgetting something and making you upset

James

P.S. Any feedback on NXTcoins is that DOA also?

I think you've already brought that up before and it has already been answered before but I'll answer it again in the hope that you might remember it for next time.

You cannot prove anything outside of the blockchain as their is no true way to achieve consensus about that - if you are wanting to say "check the result of a Google search" then every node would have to do the same search and get the same result to "confirm" it *but* in practice they will not get the same result (some might just get an error due to the IP being blocked or some might get a different result due to geographic location, etc., etc.).

Also you would be putting a "huge" burden on every node to have to be doing an arbitrary number of perhaps slow or costly requests just to attempt said verification.

It isn't going to happen James - so please just drop it.

I think a nice use case would be obtaining data from a public website. If we can do this in a decentralized way, it solves the whole trustless broadcast of data feed problem. Once that problem is solved, then betting against the data feeds becomes possible. Once that is possible, CFD and other derivatives can be created.

If the forging node published an AM of what it thought the website said, it could be verified by a "randomly" selected subset of forgers (dont want to Ddos the website!) and as long as a super-majority agreed with the data, it would be officially place in the NXT blockchain

I think we would need a way for a script to do an http get or post call, alternatively, the NXT core needs to provide this support directly. i hope we are open to such radical and crazy ideas. If we can solve this, it will open up a lot of possibilities.

James

I think the Killer App for NXT VM would be a reference implementation of a coin built on top of NXT, using AM and Asset Exchange. I envision a whole set of NXTcoins built on top of NXT, each addressing a specific market niche. Like it or not, the altcoin concept is here to stay for a bit and there are so much mining resources, I want to create a bridge for all the miners to become NXT'ers, without feeling any pain.

Maybe such functionality will be built into NXT core itself, but in general we can see what sort of NXT VM scripts are popular enough to warrant conversion and inclusion into the NXT core.

A NXTcoin should be able to be PoW or PoS, or maybe even a hybrid with a certain percentage PoS for initial investors and the rest PoW. One thing that bothers me about the usual setup where the initial investors get 100% of their share upfront, while the miners can only get incremental amounts. There is always the big amount from IPO investors waiting for a decent price to dump.

My idea around that is to sell presale amounts in the form of a future dividend flow. For example, if 10% of a coin is presold or reserved for coin creators, and the rest for miners. At first the 10% of investors would have 0 coins. for every 10 coins that are mined, the investors would share 1 coin proportionally. This could be implemented as an automatic dividend each time coins are created via mining. we would need a special dividend version of the coin and that is what would be presold, but it would be linked to the coin.

To implement this using AE, I was hoping for a method to increase the coin supply via API, but CfB politicized that request by requiring it to be a test of NXT change request process. So, my workaround is to issue 1 billion of the coin Asset and have the DAC (or whatever it is we are calling the automated process) originally own all of them. We need to somehow restrict usage of these coins or we need to trust the DAC from sending them without permission. Not sure of the right mechanism. One crazy way I thought of was to also seed the DAC with anti-coins. The restriction would be only net positive amounts of coins could be transferred. Then the mining process triggers via validated AM to distribute coins to a set of accts. This number of anti-coins are sent to genesis acct and the freed up coins sent to the specified accts

Since this method uses AE to keep track of the coins, there isnt any worry about 51% attack, etc. Just need to make sure the AM that triggers coin "issuance" is secure. Still working on more details, but I thought this would be a good use case for you to ponder as it doesnt require voodoo magical maths, or anything fancy, but is complicated enough to make sure NXT VM will be able to be used to make useful things.

James

P.S. I just got a suggestion about a Nodecoin, which would simply issue a coin if somebody was forging at the time of a block. Maybe we need to limit it to prevent explosion in number of coins, but some intangible thing that people got just for forging. Who knows, a market could even develop for this and people might find it profitable to get low cost computers that are able to forge.

I think it would be a potential use case although it would need likely need a large amount of NXT to even get close to "pegging" the price.

Indeed it would be great but unfortunately the very nature of TF makes this rather tricky.

We have decided to employ the help of a math expert to study what we have come up with so far and work out whether or not it is going to be close enough to random.

Autonomous pegging is it even possible?

USD Asset price can be set extremely low...