mrv777
Member
Offline
Activity: 93
Merit: 16
|
|
March 21, 2014, 03:50:43 PM |
|
with AT you can safely trade 1 Asset for another, with AT you can safely lock your savings away while earning interest and with AT you can buy a ticket every week in what will be arguably the world's most efficient lottery!
Are saying you have basically achieved a way to do trustless, peer to peer cross asset trading? If so, Ripple is a dead man walking and there's only Etherium left on the road to Nxt's complete dominance. NXT- Why go to the moon when you've conquered Earth? Are there any thoughts on [SKY] Skycoin and emunie? I've heard some good talk about both of them, but am unsure how they compare. Not trying to start a crazy conversation or anything, just curious. I'm excited for NXT!
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
March 21, 2014, 03:52:59 PM |
|
What are the planned operations in AT?
You can basically think of an AT as a program that owns an account (the AT account which only it controls). As much as possible the AT account should have all the rights that a "normal" account does (although whether we will let it "create other ATs" initially is something we'd have to consider). To "sandbox" an AT it will have to use a Nxt AT API (so it doesn't have access to the "full Nxt API").
|
|
|
|
ChuckOne
Sr. Member
Offline
Activity: 364
Merit: 250
☕ NXT-4BTE-8Y4K-CDS2-6TB82
|
|
March 21, 2014, 03:54:28 PM |
|
Do u have any ideas how it's better to implement Transparent Forging? The goal is to find an optimum where we can predict few blocks in advance but noone could game the system by preparing such accounts that he would be able to forge a lot of blocks in the row.
So, that attack would go this way: 1) attacker creates N accounts 2) attacker receives M raw transactions 3) attacker tries to find a row of blocks by: 3.0) do until no raw transactions are available 3.1) choose X raw transactions 3.2) is the account forging this block one of the N accounts? 3.3) if yes, go to 3.1) and remove X transactions 3.4) if no, go to 3.1) and choose another selection of raw transactions 4) if no combination will lead to the desired output => attacker creates his own raw transactions, go back to 3) 5) choose longest row and submit it to the network Is that the attack vector you have in mind?
|
|
|
|
bitcoinpaul
|
|
March 21, 2014, 03:56:04 PM |
|
What are the planned operations in AT?
You can basically think of an AT as a program that owns an account (the AT account which only it controls). As much as possible the AT account should have all the rights that a "normal" account does (although whether we will let it "create other ATs" initially is something we'd have to consider). To "sandbox" an AT it will have to use a Nxt AT API (so it doesn't have access to the "full Nxt API"). Any sneak peek on how this API will look like? (I meant what are the functions, the syntax, the operators with the question above). You can get as geeky as you want and I will try to understand it.
|
|
|
|
Anon136
Legendary
Offline
Activity: 1722
Merit: 1217
|
|
March 21, 2014, 03:57:36 PM |
|
But maybe since then it became more clear?..
Do u have any ideas how it's better to implement Transparent Forging? The goal is to find an optimum where we can predict few blocks in advance but noone could game the system by preparing such accounts that he would be able to forge a lot of blocks in the row. there is 1 really solid solution that you arnt going to want to hear
|
Rep Thread: https://bitcointalk.org/index.php?topic=381041If one can not confer upon another a right which he does not himself first possess, by what means does the state derive the right to engage in behaviors from which the public is prohibited?
|
|
|
ChuckOne
Sr. Member
Offline
Activity: 364
Merit: 250
☕ NXT-4BTE-8Y4K-CDS2-6TB82
|
|
March 21, 2014, 03:57:39 PM |
|
Thanks in advance!
About the last point: in the mathematical model we are considering, splitting is completely harmless. But, maybe, there are other attacking possibilities that the splitting gives in the real world: spam the network, affect its topology, ..., ... I don't know, I'm not a specialist here. In the case there are such possibilities, we may consider introducing this lower limit, so that the number of accounts that participate in forging cannot become too big.
You are welcome. Okay, got it. But still, an attacker could create raw transactions at will to create new accounts that might lead to a block that he has the highest cummulativeDifficulty of. He could include these txs into blocks that favor him most. So, it will be self-inducing.
|
|
|
|
antanst
|
|
March 21, 2014, 03:57:48 PM |
|
Thanks! There is even one theorem abou Nxt now So I hope your new efforts are going to be rewarded (hint to whales) and that you will also consider modelling the BCNext proposed TF approach (with "penalties" which you can ask CfB about). This sort of scientific work is very beneficial for the Nxt project IMO. +1. Klee, if you see this, I believe mthcl should definitely be awarded a nice sum of NXT from the allocated funds in the pool.
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
March 21, 2014, 03:58:27 PM |
|
Any sneak peek on how this API will look like? (I meant what are the functions, the syntax, the operators with the question above). You can get as geeky as you want and I will try to understand it.
Okay (and you did *ask for it*) - take a look at http://ciyam.org/nxt/nxt_crowdfund.html and in particular the "functions" section (those are some proposed Nxt AT API functions).
|
|
|
|
mthcl
|
|
March 21, 2014, 04:01:07 PM |
|
But maybe since then it became more clear?..
Do u have any ideas how it's better to implement Transparent Forging? The goal is to find an optimum where we can predict few blocks in advance but noone could game the system by preparing such accounts that he would be able to forge a lot of blocks in the row. I think the algorithm can be easily adjusted in such a way that the next N forgers are known at each moment. But I don't dare to propose any solutions about penalizing accounts and things of this sort...
|
|
|
|
igmaca
|
|
March 21, 2014, 04:01:26 PM |
|
For the people that don't know how mining work.Just to let you know, that you can easily mine scrypt coin with cpu, it is not the most efficient way, but it would be a good idea at the moment to beta test the Nxt mining pool. You are welcome to test them. More feedback is always welcome. Still you should be able to get some nxt if you have a fast cpu. The cpu miner can be get at: http://sourceforge.net/projects/cpuminer/You need to create a .bat file in the directory of the miner as follow: add in a start.bat file : START /LOW minerd -o stratum+tcp://hashrate.org:3008 -u 13777396447329170446 -p xxx -t4 For the hashrate.org pool ( http://hashrate.org/). OR START /LOW minerd -o stratum+tcp://p00l.org:3003 -u 13777396447329170446 -p xxx -t4 For the p00l.org pool ( http://www.p00l.org/). Replace the Nxt address with your (-u Nxtadress). Don't change the password (-p xxx). Note also that the argument -t4 will specify the number of cpu thread the miner will use (for example -t4 = 4 threads). Don't put there a number greater than the number of thread of your CPU. You can follow the nxt mining thread at https://nextcoin.org/index.php/topic,4399.135.htmlEnjoy. it seems that my laptop mining I changed my account number instead of 13777396447329170446 I have not changed p xxx-t4. I have 4 cpu thread i run start.bat is it correct?
|
|
|
|
ChuckOne
Sr. Member
Offline
Activity: 364
Merit: 250
☕ NXT-4BTE-8Y4K-CDS2-6TB82
|
|
March 21, 2014, 04:03:03 PM |
|
Do u have any ideas how it's better to implement Transparent Forging? The goal is to find an optimum where we can predict few blocks in advance but noone could game the system by preparing such accounts that he would be able to forge a lot of blocks in the row.
So, that attack would go this way: 1) attacker creates N accounts 2) attacker receives M raw transactions 3) attacker tries to find a row of blocks by: 3.0) do until no raw transactions are available 3.1) choose X raw transactions 3.2) is the account forging this block one of the N accounts? 3.3) if yes, go to 3.1) and remove X transactions 3.4) if no, go to 3.1) and choose another selection of raw transactions 4) if no combination will lead to the desired output => attacker creates his own raw transactions, go back to 3) 5) choose longest row and submit it to the network Is that the attack vector you have in mind? If this is so, I would say it is computationally extremely difficult. We could increase difficulty in such way, that we introduce a Proof of Work element: to create a block you do not need to do sha256 1x but 1000x in a row. How much can sha256, block generation and permutation selection be parallelized?
|
|
|
|
mczarnek
|
|
March 21, 2014, 04:07:30 PM Last edit: March 21, 2014, 04:29:03 PM by mczarnek |
|
But maybe since then it became more clear?..
Do u have any ideas how it's better to implement Transparent Forging? The goal is to find an optimum where we can predict few blocks in advance but noone could game the system by preparing such accounts that he would be able to forge a lot of blocks in the row. Why not have all the forgers constantly throwing around tiny, microscopic amounts of Nxt between each other in order to randomize the account balances? As I understand it, the basic idea now is that you hash all account balances, that hash basically produces a random number which can be used to pick which account will be forging, correct? You'd have to expand how many units it can use but what if you expanded the Nxt units so that you could have units of 0.00000000001Nxt.. or whatever, tiny amounts. 2*10^-6 would cost 1 Nxt per year. So I say maybe 1 millionth of a Nxt. Make the hash sensitive enough to that tiny differences between inputs can wildly swing the output. Point is, you guarantee that there will be account balances constantly changing in a way that can't be predicted. Every block, each forger random chooses how many Nxt to send around and each one sends some tiny random amount them of them to the account of another randomly chosen forger on the network. If a forger has not been sending these tiny amounts of Nxt around, kick him out anytime he becomes one of the top 10 or 100 or whatever forgers in line to forge, maybe also exclude him when choosing who to send that tiny amount of Nxt too. For that matter you only need a few accounts doing this to randomize the accounts balances, and no one can predict which accounts will have which balances. Then you select the next forger off of the top of the queue, use the hash of a block 10 blocks ago, (after all 10 blocks to confirmation right?) to pick the 10th forger in line, then do it again every block. Now you only know 10 minutes in advance if you are going to forge and it also only requires losing the ability to forge with Nxt for 10 minutes in advance.
|
|
|
|
mthcl
|
|
March 21, 2014, 04:09:07 PM |
|
Thanks in advance!
About the last point: in the mathematical model we are considering, splitting is completely harmless. But, maybe, there are other attacking possibilities that the splitting gives in the real world: spam the network, affect its topology, ..., ... I don't know, I'm not a specialist here. In the case there are such possibilities, we may consider introducing this lower limit, so that the number of accounts that participate in forging cannot become too big.
You are welcome. Okay, got it. But still, an attacker could create raw transactions at will to create new accounts that might lead to a block that he has the highest cummulativeDifficulty of. He could include these txs into blocks that favor him most. So, it will be self-inducing. Can you explain the last sentence to me, having in mind that I wrote my last program 20 years ago? In particular, how this cummulativeDifficulty is computed in the math model?
|
|
|
|
|
mthcl
|
|
March 21, 2014, 04:15:27 PM |
|
Can you describe the algorithm of determining the next forgers in terms of the math model? In particular, how exactly this list is updated?
|
|
|
|
ChuckOne
Sr. Member
Offline
Activity: 364
Merit: 250
☕ NXT-4BTE-8Y4K-CDS2-6TB82
|
|
March 21, 2014, 04:23:17 PM |
|
But still, an attacker could create raw transactions at will to create new accounts that might lead to a block that he has the highest cummulativeDifficulty of. He could include these txs into blocks that favor him most. So, it will be self-inducing.
Can you explain the last sentence to me, having in mind that I wrote my last program 20 years ago? In particular, how this cummulativeDifficulty is computed in the math model? Sure. raw = to-be-verified aka to-be-agreed-on The problem with raw transactions are: they are the things we need to find consensus about. That is why we need blocks. Blocks represent the consensus on which transactions occured. But: since we have not found any consensus about these raw transactions they can be added or removed at will. Why? Because we have not agree on them yet, because there is no block verifying them. I hope that is clear. So, an attacker could add raw transactions into his pool of available raw transactions and therefore increase his probability of bundling them into a block that one of his accounts can forge. A new forging account F is created by at least two transactions (3 NXT need in total): 1) funding (2 NXT to F) 2) public key creation (1 NXT form F to somewhere else) => F still holds 1 NXT and is able to forge in 1440 block from 2) Because of that, an attacker could carefully design transactions that create accounts that will forge in the future. So, this attacker could design raw transactions and shuffling existing ones and his artificial ones until he can a row of blocks that is long enough for his purpose.
|
|
|
|
ChuckOne
Sr. Member
Offline
Activity: 364
Merit: 250
☕ NXT-4BTE-8Y4K-CDS2-6TB82
|
|
March 21, 2014, 04:26:38 PM |
|
In particular, how this cummulativeDifficulty is computed in the math model?
Sorry, you asked about the math model for it in particular. cummulativeDifficulty = inverse weights of the blocks if I read section 4 correctly (still have not found time to review that one) The source code talks about 'target', section 4 about 'weight'.
|
|
|
|
BrianNowhere
|
|
March 21, 2014, 04:31:23 PM |
|
Are there any thoughts on [SKY] Skycoin and emunie? I've heard some good talk about both of them, but am unsure how they compare. Not trying to start a crazy conversation or anything, just curious. I'm excited for NXT! Don't know anything about SkyCoin, but Emunie's website has been a graveyard and the natives are getting restless and are reporting lots of bugs, connection issues in the forums there. One delay after another and there's only one guy coding everything. They have promised a launch date at the end of March/Early April that I would not be surprised to see get postponed again. Everyone who has invested better hope Dan (lone programmer) doesn't get hit by a bus because the whole thing is still closed source.
|
NXT: 4957831430947123625
|
|
|
|
BrianNowhere
|
|
March 21, 2014, 04:34:05 PM |
|
I think the algorithm can be easily adjusted in such a way that the next N forgers are known at each moment. But I don't dare to propose any solutions about penalizing accounts and things of this sort...
Wise man.
|
NXT: 4957831430947123625
|
|
|
|