Nxt source code flaw reports - page 54.

Come-from-Beyond

legendary

Activity: 2142

Merit: 1009

Newbie

Quote from: vamdor on January 04, 2014, 10:46:41 AM

No. In PoW the cumulative work clearly decides the valid branch, there is no option that you see two branches and can't decide which one is the "real one" accepted as the consensus.

Sorry, I disagree. U can see 2 branches with 2000 blocks each and u won't be able to decide which branch is legit.

Come-from-Beyond

legendary

Activity: 2142

Merit: 1009

Newbie

Quote from: ricot on January 04, 2014, 10:46:21 AM

But it doesn't work like a check-pointing... it just gives an angle of attack on the network and I can see no benefit at all...

The code was written with TF in mind. When TF is on it's supposed to work as a checkpoint.

vamdor

newbie

Activity: 50

Merit: 0

Quote from: Come-from-Beyond on January 04, 2014, 10:37:19 AM

Could u post ur math plz?

Now I won't be at my computer for a while but I will clean it up and post later.

Come-from-Beyond

legendary

Activity: 2142

Merit: 1009

Newbie

Quote from: gsan1 on January 04, 2014, 10:40:54 AM

Code:

String announcedAddress = (String)request.get("announcedAddress");
if (announcedAddress != null) {
							
    announcedAddress = announcedAddress.trim();
    if (announcedAddress.length() > 0) {

        peer.announcedAddress = announcedAddress;
								
    }
							
}
if (peer != null) {

If announcedAddress is not null, it adds it as a member variable to object peer. Afterwards it checks if peer is not null. Could there be a null pointer exception? Or is announcedAdress only not null when peer is not null?

Looks like a non-critical bug, I'll check it, thx. This is not the flaw.

vamdor

newbie

Activity: 50

Merit: 0

Quote from: Come-from-Beyond on January 04, 2014, 10:43:52 AM

Quote from: vamdor on January 04, 2014, 10:38:05 AM

Then what is rationale behind it? Pretty much the main point of proof-of-work is that this can't be done.

This can be done in PoW too.

No. In PoW the cumulative work clearly decides the valid branch, there is no option that you see two branches and can't decide which one is the "real one" accepted as the consensus.

ricot

newbie

Activity: 56

Merit: 0

Quote from: Come-from-Beyond on January 04, 2014, 10:41:32 AM

Quote from: ricot on January 04, 2014, 10:34:10 AM

But to my other issue:
If you can setup plausible looking fake nodes so easily and cause a blockchain split, users will loose trust in the system...
Why is that 720 block limit even in place? without that, this angle of attack couldn't happen...

It's kind of an automatic checkpointing.

But it doesn't work like a check-pointing... it just gives an angle of attack on the network and I can see no benefit at all...

Come-from-Beyond

legendary

Activity: 2142

Merit: 1009

Newbie

Quote from: vamdor on January 04, 2014, 10:38:05 AM

Then what is rationale behind it? Pretty much the main point of proof-of-work is that this can't be done.

This can be done in PoW too.

Come-from-Beyond

legendary

Activity: 2142

Merit: 1009

Newbie

Quote from: ricot on January 04, 2014, 10:34:10 AM

But to my other issue:
If you can setup plausible looking fake nodes so easily and cause a blockchain split, users will loose trust in the system...
Why is that 720 block limit even in place? without that, this angle of attack couldn't happen...

It's kind of an automatic checkpointing.

gsan1

newbie

Activity: 50

Merit: 0

Code:

String announcedAddress = (String)request.get("announcedAddress");
if (announcedAddress != null) {
							
    announcedAddress = announcedAddress.trim();
    if (announcedAddress.length() > 0) {

        peer.announcedAddress = announcedAddress;
								
    }
							
}
if (peer != null) {

If announcedAddress is not null, it adds it as a member variable to object peer. Afterwards it checks if peer is not null. Could there be a null pointer exception? Or is announcedAdress only not null when peer is not null?

vamdor

newbie

Activity: 50

Merit: 0

Quote from: Come-from-Beyond on January 04, 2014, 10:24:49 AM

That's right. Without Transparent Forging this indeed should isolate part of the nodes. But this is not an injected flaw.

Then what is rationale behind it? Pretty much the main point of proof-of-work is that this can't be done.

ImmortAlex

hero member

Activity: 784

Merit: 501

Quote from: vamdor on January 04, 2014, 10:27:34 AM

No, we can't. Someone in the chain up to our expected block may fall off the network and not publish their block, changing everything afterwards. (if I understand the system correctly)

Yes, every time we have changes in blockchain (new last block, or reorganizing the chain) we need to recalculate hit and target. At the same time we can precisely calculate time when we can generate block and again start to wait: time will pass or block(s) from other nodes will arrive.
I mean: we have no need to do calculations every second, or when transactions arrive or in any other conditions except changing blockchain.

Come-from-Beyond

legendary

Activity: 2142

Merit: 1009

Newbie

Quote from: vamdor on January 04, 2014, 10:33:23 AM

Quote from: Come-from-Beyond on January 04, 2014, 09:04:07 AM

Valid assumption. U could follow my way - try to create a model and run it. My results show that max difference in number of forged blocks between Alice owning 1M of coins and million Bobs with 1 NXT each is less than 1/1000 of the normalized base target.

Instead of running simulations I did the math and the effect is much smaller than I expected. For example someone having 33% stake can get up to 36% of the blocks if the rest of the network are many small non-colluding participants.

Could u post ur math plz?

ricot

newbie

Activity: 56

Merit: 0

Quote from: Come-from-Beyond on January 04, 2014, 10:27:25 AM

Quote from: ricot on January 04, 2014, 10:25:53 AM

But you do increase your chances of generating blocks. This could be a big problem!

Actually not, add some math and u'll see why.

Ah, I see, because you subtract the amount I got in the last block, so I'd have to wait a block and that kills the odds...

But to my other issue:
If you can setup plausible looking fake nodes so easily and cause a blockchain split, users will loose trust in the system...
Why is that 720 block limit even in place? without that, this angle of attack couldn't happen...

vamdor

newbie

Activity: 50

Merit: 0

Quote from: Come-from-Beyond on January 04, 2014, 09:04:07 AM

Valid assumption. U could follow my way - try to create a model and run it. My results show that max difference in number of forged blocks between Alice owning 1M of coins and million Bobs with 1 NXT each is less than 1/1000 of the normalized base target.

Instead of running simulations I did the math and the effect is much smaller than I expected. For example someone having 33% stake can get up to 36% of the blocks if the rest of the network are many small non-colluding participants.

vamdor

newbie

Activity: 50

Merit: 0

Quote from: ImmortAlex on January 04, 2014, 09:55:41 AM

If I understand everything correctly, with this formula we don't need to check hithit and target.

No, we can't. Someone in the chain up to our expected block may fall off the network and not publish their block, changing everything afterwards. (if I understand the system correctly)

On the other hand if we can, then it's possible to "mine" an address 1440 blocks ahead and grab a block. Also if only one or two users stop participating in the next 1440 blocks, we can adjust our "mining" algorithm for that too, especially if we do some data mining to see which accounts are "reliable block generators" and which are not. And this may actually be a problem with enough users playing greedily and optimally.

Come-from-Beyond

legendary

Activity: 2142

Merit: 1009

Newbie

Quote from: ricot on January 04, 2014, 10:25:53 AM

But you do increase your chances of generating blocks. This could be a big problem!

Actually not, add some math and u'll see why.

ImmortAlex

hero member

Activity: 784

Merit: 501

Quote from: FrictionlessCoin on January 04, 2014, 10:22:45 AM

I had thought this was Proof of Stake, so the bigger the stake of the miner, the bigger the reward.

The bigger the stake of the miner, the bigger the chance to get reward, and reward is transactions fee.

ricot

newbie

Activity: 56

Merit: 0

Quote from: ImmortAlex on January 04, 2014, 10:19:11 AM

Quote from: FrictionlessCoin on January 04, 2014, 10:09:11 AM

Quote from: ImmortAlex on January 04, 2014, 09:55:41 AM

What was new for me, is that target doesn't directly depend on time your previous generation. There's no "coin days" like in PPC or NVC.

No coin days, so miners can game the system since with what they call 'transparent mining' they know beforehand if it is there turn to mine, so they can move around their coins to the miner that is going to get its turn.

So to game this system, you have a bunch of say N miners and then you have a balance of M that you move around to the miner that will be mining next. So effectively you get N*M more profitability.

Mmm... Can't understand, why I need to move my M coins from one of my miner to another?
Transparent mining just allow me to give transaction fee to desired account, if it is on mining.

He does have a point:
When it's your turn to generate a block, you can include a transaction to one of your other accounts. The receiving account could be the one that has the highest chance of generating the following block (because you can calculate that beforehand). If you fail, you didn't loose anything. But you do increase your chances of generating blocks. This could be a big problem!

Come-from-Beyond

legendary

Activity: 2142

Merit: 1009

Newbie

FrictionlessCoin

legendary

Activity: 868

Merit: 1000

Cryptotalk.org - Get paid for every post!

Quote from: ImmortAlex on January 04, 2014, 10:19:11 AM

Quote from: FrictionlessCoin on January 04, 2014, 10:09:11 AM

Quote from: ImmortAlex on January 04, 2014, 09:55:41 AM

What was new for me, is that target doesn't directly depend on time your previous generation. There's no "coin days" like in PPC or NVC.

No coin days, so miners can game the system since with what they call 'transparent mining' they know beforehand if it is there turn to mine, so they can move around their coins to the miner that is going to get its turn.

So to game this system, you have a bunch of say N miners and then you have a balance of M that you move around to the miner that will be mining next. So effectively you get N*M more profitability.

Mmm... Can't understand, why I need to move my M coins from one of my miner to another?
Transparent mining just allow me to give transaction fee to desired account, if it is on mining.

I had thought this was Proof of Stake, so the bigger the stake of the miner, the bigger the reward.

Topic: Nxt source code flaw reports - page 54. (Read 113359 times)