Topic: NXT :: descendant of Bitcoin - Updated Information - page 921. (Read 2761655 times)

Someone should compare both implementations now.

this would be a nice addition. i was just planning on releasing as many assets as there are above ground ounces of silver in the world just to be safe. (big aspirations i know ) and only sell what i have in reserve. for this reason though i would put variable assets on the back burner for a while. crowd funding functionality is MUCH more important.

A script is just a transaction. But it can send other transactions. Even ones that invoke it again.

Good photoshopping  

Not very long assuming that community approved the changes and the coder is familiar with Nxt source code.

Got the email too, hopefully it's of use to CFB!

 

I got the original C version of curve2559 from





Here is the link to both files:

https://drive.google.com/folderview?id=0B7kbeA6whDvNUzVMWXVHWGZtdEU&usp=sharing

Regarding scripting: is this supposed to only apply to transactions? Perhaps accounts itself could be scripted in the same way?
Instead of separate account control, just make it so that it's possible to set an account one script. Each outbound transaction would have to be accepted by the script.
It would solve several problems at the same time: complicated escrow/multisig, account security (only allow one withdrawal address), allow a form of 2 factor authentication, allow pooled bets on assets/currencies on decentralized exchange, inheritance, possibly other things I didn't think about

Or was it supposed to apply to accounts from the start?

How long would it take to add support for two types of Assets, fixed and variable, along with the ability to change the amount of variable Asset?

If there was an Asset type field, with 0 for current one, 1 for dynamic, then we can always add other types later with new properties.

I have a solution for fully automated gateways, but it requires people to trust the hardware + software that operates it, so the simpler the code is, the easier for people to understand that the code is clean.

Transactions are very long time

I have transactions pending for 2 days

Whats up with Bter...SCAM??

- 5k testNXT sent

2

Let's try this way. I'll need some time to structurize all this stuff and then will publish another version of opcodes.

@CFB - what is the nr of decimals allowed after comma for price?

2? or unlimited?

Yes, it's hard to predict how much memory u'll need if u heavily exploit stack by using recursions and similar stuff.

wolfe?

I'm not sure about your notation of addresses. So I'm going to assume 'm' is an address of m and [m] is a value under m.

1. All jump instruction with a constant or memory arguments. Why only memory?  
2. All arithmetic and boolean operations with constants also. No point inputting constant values into temporary memory places.
3. call with arguments, push, pop, ret n instruction.
4. Allow indirect indexes. So you could write [m1+[m2]] meaning m1[m2] or [m1+constant]. This will shorten use of arrays considerably.
5. Allow shifting addresses by a constant, ie. multiplying by a power of 2. [m1+[m2]*2] or *4, 8. x86 does this also. This eliminates the need to create a temporary variable, shift it, and then use it as an index.
6. Allow different operand sizes, the way x86 and amd64 does it. Currently to input a byte you would need to first (1) mask your value with and, then (2) shift it, then (3) mask the output with and, then (4) or the value in place. Four instructions for a common operation.

So a move instruction would look like:
mov size[address], constant
mov size[address], [address2]
where size is one of: byte, word, dword, qword.
Same for boolean and arithmetic operations.

7. An instruction which allows calculation of addresses generated by a (4)+(5) form. The equivalent in x86 is called lea.

For stack: just designate memory at address 0 as a 32 bit stack pointer.  

Very simple to implement, and the scripting codes will be drastically shorter and faster due to that.