Search content
Sort by
Showing 20 of 27 results by Fry
When i open:
http://127.0.0.1:9085/blocks/FNmyrAKvMZo4BrHFAQveJDacM4ZCuKMxm4qZjrh6ofMPcRjKFB5jzr5hGdRLRuCrRLBarvbNE91USL4WUR4Chq9uNDRanBK1JJcMiD1Yi9XJXSmyYsGqXoyB8BYuHaKzGjMfHp2jYYcgrii6xDiLxwnzhxtDhtfNAsPLHfvjwhfQoEX
i get:
This:
"recipient":0.00000000 - Qc454HfRSVbrdLmhD1d9nmmMe45NbQmRnG
can't be processed by my JSON-simple JSON-parser.
http://qora.co.in/?q=34500
Says the Generator gets 1 Qora fee, but shows no transaction(s).
http://127.0.0.1:9085/blocks/FNmyrAKvMZo4BrHFAQveJDacM4ZCuKMxm4qZjrh6ofMPcRjKFB5jzr5hGdRLRuCrRLBarvbNE91USL4WUR4Chq9uNDRanBK1JJcMiD1Yi9XJXSmyYsGqXoyB8BYuHaKzGjMfHp2jYYcgrii6xDiLxwnzhxtDhtfNAsPLHfvjwhfQoEX
i get:
Code:
{"fee":"1.00000000","timestamp":1411497506336,"transactions":[{"sender":"Qc454HfRSVbrdLmhD1d9nmmMe45NbQmRnG","timestamp":1411497302280,"fee":"1.00000000","confirmations":24503,"payments":[{"amount":"1.00000000","asset":0,"recipient":0.00000000 - Qc454HfRSVbrdLmhD1d9nmmMe45NbQmRnG}],"type":15,"signature":"2uv9pX15TVkwF2fzJRTh1iN4CAzKW2NUDMtCusuoLnfiRyGZVietyaUB8xJ94AAccvpYKuGtq9NpnnA2rXGexyXL","reference":"2zoi8KKxuNpFg6zLgDs4H9fMRBFGgJg4tRjXEXqo3BUdijEJBPyCgWmgwRDMKVga84qKRLTnn2spXJMWnhNnJZZh"}],"generatorSignature":"3ouKp5dnvAYiYJbmq71KNfqt6fkYZBpgZ4R7puBmmBpnxwb2T5ch9LvxsP8WAcKGfqapxCF6FHveyE4pHyTw4GSd","generatingBalance":899562196,"generator":"QPVknSmwDryB98Hh8xB7E6U75dGFYwNkJ4","signature":"FNmyrAKvMZo4BrHFAQveJDacM4ZCuKMxm4qZjrh6ofMPcRjKFB5jzr5hGdRLRuCrRLBarvbNE91USL4WUR4Chq9uNDRanBK1JJcMiD1Yi9XJXSmyYsGqXoyB8BYuHaKzGjMfHp2jYYcgrii6xDiLxwnzhxtDhtfNAsPLHfvjwhfQoEX","transactionsSignature":"3dxiMPGdNasPYm93DtYCU1sNDKvHpMMCxwKCD7WZ2YSiV3Uh7T9o8fivL9rKrhonCWv4wvz8VVwNzGAEbknMpg5d","reference":"ANpvukaingVkVJVvdpMFU82QfxLdQrRvkN3yphnYvFqxsPsMNf6pMM3fppB641aCNSrt5NFFk21QJzJwyx2ws3wK8LM1rgHeuYQptAAsVCWW5TpE8aERoSovUHyczJonW8UfgGWxgHFHDEHbrXGj5W1C8cYEDxad5LYawetNcNGtnLe","version":1}
This:
"recipient":0.00000000 - Qc454HfRSVbrdLmhD1d9nmmMe45NbQmRnG
can't be processed by my JSON-simple JSON-parser.
http://qora.co.in/?q=34500
Says the Generator gets 1 Qora fee, but shows no transaction(s).
Re: Qora | 100% POS | Assets | Names | Voting | Open Source December 9
I haven't been able to figure out what Nxt does. This isn't because of poor Nxt coding. It's because I don't have the time to look into it. If a Nxt guru is around, please comment.
I am not a Nxt guru but i reviewed the Nxt Code and i understand the Nxt forging algo.
Qora's forging Algo is definitely better, if it actually works (safe).
I think the biggest secret is still hidden in these native files.
I am not a crypto-expert, but i think
the problem with ECDSA is that for a specific public key and specific data to sign there are several valid signatures. That makes it normally a bad choice to determinate the next forging account.
Qora must have somehow solved that problem.
But as long as these native libs are not OS we will not know how.
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?
From where is execution time purchased from the ATs XNTs or from a fee in the incoming transaction?
From where is execution time purchased from the ATs XNTs or from a fee in the incoming transaction?
@CIYAM Open I have read the spec document now.
Some suggestions from me:
I would rather like to see some event handling than this blocking with Sleep_Until_Creator or Sleep_For_Blocks or when the script is running out of coins.
The AT running out of coins should be the exception, and not a regular used mechanism. Otherwise in some usecases you don't know how long the script will actually run, so you have to send more coins to it just to keep it in a loop later.
If event handling is used then there also is no need to keep all data persistent, remember that all persistent data will need to be copied about a dozen times with every new block creation.
Here's a example AT with event handling.:
register event handler "block 1000 apeared" :block1000
register event handler "AT received coins" :newcoins
end
:block1000
'do what needs to be done when block 1000 appears
end
:newcoins
'do what needs to be done when at the AT account gets new coins
end
Some suggestions from me:
I would rather like to see some event handling than this blocking with Sleep_Until_Creator or Sleep_For_Blocks or when the script is running out of coins.
The AT running out of coins should be the exception, and not a regular used mechanism. Otherwise in some usecases you don't know how long the script will actually run, so you have to send more coins to it just to keep it in a loop later.
If event handling is used then there also is no need to keep all data persistent, remember that all persistent data will need to be copied about a dozen times with every new block creation.
Here's a example AT with event handling.:
register event handler "block 1000 apeared" :block1000
register event handler "AT received coins" :newcoins
end
:block1000
'do what needs to be done when block 1000 appears
end
:newcoins
'do what needs to be done when at the AT account gets new coins
end
But then a hacker could send a new hash as well we he has stolen a TAN sucessfully.
Yes- fair point.
Tan 4: 5eb6bb157528b365f84c27bb4784031b
Tan 3: 60639a308365b50c6f531b0b05018210
Tan 2: 56600d988bbaa252ac565d57dd1fc686
Tan 1: 0355f7b531a7ccc9d4287b664f1da644
Hash delivered in AT: e2603ffd11ae2f4fce1aa84cb461f6d5
Tan 3: 60639a308365b50c6f531b0b05018210
Tan 2: 56600d988bbaa252ac565d57dd1fc686
Tan 1: 0355f7b531a7ccc9d4287b664f1da644
Hash delivered in AT: e2603ffd11ae2f4fce1aa84cb461f6d5
That doesn't work as the AT would need to know "Secret Key" but I think if we just simplify it then it will work:
md5(secret) = 5ebe2294ecd0e0f08eab7690d2a6ee69
md5(5ebe2294ecd0e0f08eab7690d2a6ee69) = 7022cd14c42ff272619d6beacdc9ffde
md5(7022cd14c42ff272619d6beacdc9ffde) = 19ff59e135cce19e3493402cb3884628
md5(19ff59e135cce19e3493402cb3884628) = b61a3c39ea31f66f0adf883bbc154786
So we give the AT b61a3c39ea31f66f0adf883bbc154786 and the the 1st TAN is 7022cd14c42ff272619d6beacdc9ffde (which we hash and verify) and change the AT's state to say that it is *used* (basically increment the # of hashes counter).
So the next TAN is now 5ebe2294ecd0e0f08eab7690d2a6ee69 which we hash twice and get back to our b61a3c39ea31f66f0adf883bbc154786 value, etc.
The trick being of course that you can't reverse the hash - I like it a lot!
There is no need for AT to know "Secret Key". I think we mean the same!
EDIT: Hmm, but one problem: If an attacker somehow acquires n. TAN, then he gains all of n-1. TAN to 1. TAN.
Actually I think a much simpler approach could be used.
Just send a new TAN hash along with your TAN in the AM (the AT data state is persistent).
But then a hacker could send a new hash as well we he has stolen a TAN sucessfully.
echo "Tan 4: " . md5("Secret Key"). "
";;
echo "Tan 3: " . md5(md5("Secret Key",true)) . "
";
echo "Tan 2: " . md5(md5(md5("Secret Key",true),true)) . "
";
echo "Tan 1: " . md5(md5(md5(md5("Secret Key",true),true),true)) . "
";
echo "Hash delivered in AT: " . md5(md5(md5(md5(md5("Secret Key",true),true),true),true)) . "
";
?>
Tan 4: 5eb6bb157528b365f84c27bb4784031b
Tan 3: 60639a308365b50c6f531b0b05018210
Tan 2: 56600d988bbaa252ac565d57dd1fc686
Tan 1: 0355f7b531a7ccc9d4287b664f1da644
Hash delivered in AT: e2603ffd11ae2f4fce1aa84cb461f6d5
To check wheather the delivered Tan is vaild, the delivered Tan has to be hashed several times. When it results in the "Hash delivered in AT" then the TAN is valid.
But the first TAN you use is the first TAN. Because if you deliver TAN 4 then all other TANs will be known.
EDIT: TAN5=Secret Key
This can even be further optimized on memory usage.
1. TAN = Hash(2. TAN)
2. TAN = Hash(3. TAN)
3. TAN = Hash(4. TAN)
...
30. TAN = Hash(whatever)
So i only have to save the hash of the first TAN in the AT.
If for example the 7. TAN is provided, it has to be hashed 7 times and will result in hash of first TAN.
1. TAN = Hash(2. TAN)
2. TAN = Hash(3. TAN)
3. TAN = Hash(4. TAN)
...
30. TAN = Hash(whatever)
So i only have to save the hash of the first TAN in the AT.
If for example the 7. TAN is provided, it has to be hashed 7 times and will result in hash of first TAN.
...iTAN (Indexed Transaction authentication number)...
I am not familiar with this iTAN idea - was it discussed somewhere else?
No, it wasn't discussed before, it just came to my mind. This is used by Banks.
I try to explain it:
Like a paperwallet you have several keys on a piece of paper (Cold storage).
My Bank has 5 digit numbers, every number can be used for one transaction, after that never again.
When all numbers on a sheet have been used, my Bank sends me a new sheet with new iTANs.
This can be also done with ATs.
But with 5 digit numbers it will not work. My Bank will lock me, when i entered a false iTAN.
In ATs it's not that easy. Because i can see what the AT is doing.
So every iTAN has to be longer - let's say 30 digits.
The hashs of every single iTAN could be safed in the AT.
When i want to transfer from the dormant AT i have to provide one iTAN. The AT can check it against it's hash list only if it's valid it will transfer the funds.
If someone has compromised my computer he probably might steal on iTAN (example: he is running an keylogger while i enter it), but he cannot steal all my funds because the AT will only send funds up to a previous set limit for one iTAN.
So it's a safer Paperwallet.
What could probalbly be considered as well is the use of iTAN (Indexed Transaction authentication number) for access to the dormant funds.
These TAN numbers would have much more than 4 digits, more likely 20 or 30 or so, but it would definitely increase security.
EDIT: Transactions that are authenticated with a iTAN would have a transaction Limit
These TAN numbers would have much more than 4 digits, more likely 20 or 30 or so, but it would definitely increase security.
EDIT: Transactions that are authenticated with a iTAN would have a transaction Limit
I think it would be wise to implement more triggers to AT execution later, like appeareance of a new block with a specific block height (number).
Currently i am not forging with my main stake because i fear losing it when my computer gets compromised.
Probably AT provide a solution to that, where i can forge with my computer while my NXT are in cold storage.
Even if a hacker steals my forging rights from my computer i can recover them with my paper wallet.
Currently i am not forging with my main stake because i fear losing it when my computer gets compromised.
Probably AT provide a solution to that, where i can forge with my computer while my NXT are in cold storage.
Even if a hacker steals my forging rights from my computer i can recover them with my paper wallet.
Sounds good!
2^24 tx per block= 16777216 tx per block or approx. 279620 txs per sceond?
May i ask what events in the blockchain can trigger the execution of the AT code?
Is the "AT owner's account" a usual account that can not control its funds after the AT has been activated? Instead only the AT can access its funds?
Do i get this right?
Note that a "time stamp" is expected to include the transaction # (not id - I mean # of the tx in the block). I have discussed this with CfB and that will likely be the lower 40 bits of a 64 bit "unix time" shifted to the left with the remaining 24 bits for the transaction # (allowing for a max. 640K txs per second which I am assured Bill Gates agrees we'll never need more than).
2^24 tx per block= 16777216 tx per block or approx. 279620 txs per sceond?May i ask what events in the blockchain can trigger the execution of the AT code?
Is the "AT owner's account" a usual account that can not control its funds after the AT has been activated? Instead only the AT can access its funds?
Do i get this right?
If it's only 32K why don't we develope something brand new that perfectly suits our needs?
With optcode thats too low level i see some problems.
Interpreting such code will be slower because it takes longer to interpret many short commands, than to interpret a single long command (assuming optcode in both cases). Especially if you have to count every single command, and check you did not exceed the command limit.
Many small commands also require more space what makes these transactions larger.
In this case i think something that has commands that can directly handle strings, arrays, hashing, encryption and signature functions would be great.
This could be done by a bytecode interpreter as well (we could have bytecode commands that can handle this stuff directly).
I would be interested in creating a concept and code that. But i am a noob in Java so my code might not look that professional.
With optcode thats too low level i see some problems.
Interpreting such code will be slower because it takes longer to interpret many short commands, than to interpret a single long command (assuming optcode in both cases). Especially if you have to count every single command, and check you did not exceed the command limit.
Many small commands also require more space what makes these transactions larger.
In this case i think something that has commands that can directly handle strings, arrays, hashing, encryption and signature functions would be great.
This could be done by a bytecode interpreter as well (we could have bytecode commands that can handle this stuff directly).
I would be interested in creating a concept and code that. But i am a noob in Java so my code might not look that professional.
Every forger creates a very large random number. He hashes this number and adds the hash to to block he is forging.
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.
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
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!
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!
What do you think about random lock times for transactions to make instant transactions safe?
If you have a random lock time for special accounts an attacker can't predict any more who will be the forger of the transaction. So an attacker could not attempt to doulbe spend by replacing the transaction with another.
The transaction would be immediately broadcasted to the Network, but have to wait a random time until added to the Blockchain
Example implementation:
Every forger adds an one random number (only 1 or 0) to his forged block on the Blockchain.
A transaction for these specific accounts can only be added to the Blockchain if the last 8 bits of hash of (the random numbers in the last 100 Blocks plus the accounts public key) are zero.
Advantage of this is that you can spend the entire account balance at once.
If you have a random lock time for special accounts an attacker can't predict any more who will be the forger of the transaction. So an attacker could not attempt to doulbe spend by replacing the transaction with another.
The transaction would be immediately broadcasted to the Network, but have to wait a random time until added to the Blockchain
Example implementation:
Every forger adds an one random number (only 1 or 0) to his forged block on the Blockchain.
A transaction for these specific accounts can only be added to the Blockchain if the last 8 bits of hash of (the random numbers in the last 100 Blocks plus the accounts public key) are zero.
Advantage of this is that you can spend the entire account balance at once.
@Fry - I like your thinking as the forger can't do anything to change that (other than not forge which results in the not allowed to forge for a while penalty), however, it still means that the forger at least knows this value and so might decide whether or not to include their own tx depending upon whether they win (effectively improving their odds vs. non-forgers).
I see the problem with my proposal.
But having true random data would be great.
If we had true randomness on the Blockchain we could even do this:
For specific accounts we could set a random lock time for new outgoing transactions to be added to the Blockchain.
This would make Instant Payments for such accounts possible because an attacker would not know who the forger is, that can add the next transaction for this account to the Blockchain.
The problem is that it doesn't seem possible to get "random" data in Nxt. People can change txid's (due to malleability) and forgers can simply omit transactions including those that run the script making it impossible for such a lottery to be actually "fair". Also TF means that you can actually predict some hashes even in the future (was BCNext trying to tell us "not to gamble"?).
My proposal to solve this issue:
Add a field to every block in the blockchain. This field contains the ECDSA signature of the same field in the previous block (calculated with the forgers private Key).
Use this signature to seed the random function.
Would it be possible to do the Following with these Scripts?
Forgers, Stakholders or some other trusted entitys post regulary what they think the current USD value of NXT is to the Blockchain.
The script Calculates somehow an average USD price.
The Script now uses its own funds to Buy and Sell an NXT Asset called USD at that price.
Which results in having an Asset USD that has a stable USD value without having a Counterparty Risks (at least as long as the Script has enough NXT to buy that USD Asset).
Forgers, Stakholders or some other trusted entitys post regulary what they think the current USD value of NXT is to the Blockchain.
The script Calculates somehow an average USD price.
The Script now uses its own funds to Buy and Sell an NXT Asset called USD at that price.
Which results in having an Asset USD that has a stable USD value without having a Counterparty Risks (at least as long as the Script has enough NXT to buy that USD Asset).