Bitcoin Forum
August 13, 2020, 02:33:04 PM *
News: Latest Bitcoin Core release: 0.20.0 [Torrent]
 
   Home   Help Search Login Register More  
Warning: One or more bitcointalk.org users have reported that they believe that the creator of this topic displays some red flags which make them high-risk. (Login to see the detailed trust ratings.) While the bitcointalk.org administration does not verify such claims, you should proceed with extreme caution.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 [51] 52 53 54 55 56 57 58 59 60 61 62 63 64 65 »
  Print  
Author Topic: Nxt source code flaw reports  (Read 113134 times)
msin
Legendary
*
Offline Offline

Activity: 1246
Merit: 1001


View Profile
January 15, 2014, 04:41:16 PM
 #1001

Is anyone offering the service of creating an altcoin based on the algorithm of Nxt?

I'm launching a coin based on Nxt soon. It will use AM and Nxt blockchain. Sources will be written in JavaScript and completely open. (https://bitcointalk.org/index.php?topic=415580.0)

Would it be possible for you to translate (English) your first post, just so we have an idea?  Is it going to be built on top of Nxt, so we can use it within Nxt?  Thanks.
Each block is stacked on top of the previous one. Adding another block to the top makes all lower blocks more difficult to remove: there is more "weight" above each block. A transaction in a block 6 blocks deep (6 confirmations) will be very difficult to remove.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1597329184
Hero Member
*
Offline Offline

Posts: 1597329184

View Profile Personal Message (Offline)

Ignore
1597329184
Reply with quote  #2

1597329184
Report to moderator
1597329184
Hero Member
*
Offline Offline

Posts: 1597329184

View Profile Personal Message (Offline)

Ignore
1597329184
Reply with quote  #2

1597329184
Report to moderator
BloodyRookie
Hero Member
*****
Offline Offline

Activity: 687
Merit: 500


View Profile
January 15, 2014, 04:53:15 PM
 #1002

You can use google translater to english, it's good enough to get the main points.

Nothing Else Matters
NEM: NALICE-LGU3IV-Y4DPJK-HYLSSV-YFFWYS-5QPLYE-ZDJJ
NXT: 11095639652683007953
msin
Legendary
*
Offline Offline

Activity: 1246
Merit: 1001


View Profile
January 15, 2014, 05:36:41 PM
 #1003

You can use google translater to english, it's good enough to get the main points.

Of course, thank you
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2128
Merit: 1009

Newbie


View Profile
January 15, 2014, 05:45:31 PM
 #1004

Is it going to be built on top of Nxt, so we can use it within Nxt?  Thanks.

Yes, on top of Nxt using Arbitrary Messages.
CrazyEyes
Full Member
***
Offline Offline

Activity: 137
Merit: 100


View Profile
January 15, 2014, 08:27:32 PM
 #1005

I guess it is not my "birthday", (after some hinting) Wink and i am not going too have my small investment stolen by some 16 year old script kiddie.
Therefore, im creating my own cryptocurrency, whos with me?

Quote
It's been repeated hundred of times already, your account is your PK, which is 256bits,
once you do first trasaction, you're safe.

Hehe, but seriosly, can not find the "rejection" part, show me Smiley Also, why would you create an alt coin of nxt, it is already as good as it gets:D

Humble regards
j0b
msin
Legendary
*
Offline Offline

Activity: 1246
Merit: 1001


View Profile
January 15, 2014, 08:54:16 PM
 #1006

I guess it is not my "birthday", (after some hinting) Wink and i am not going too have my small investment stolen by some 16 year old script kiddie.
Therefore, im creating my own cryptocurrency, whos with me?

Quote
It's been repeated hundred of times already, your account is your PK, which is 256bits,
once you do first trasaction, you're safe.

Hehe, but seriosly, can not find the "rejection" part, show me Smiley Also, why would you create an alt coin of nxt, it is already as good as it gets:D

Humble regards
j0b

Because we may ultimately need more supply and to use coins for different purpose, not necessarily just to buy things.
lr127
Newbie
*
Offline Offline

Activity: 35
Merit: 0


View Profile
January 16, 2014, 04:19:16 AM
 #1007

Whether there is any sense in the generation of an empty (without transactions) block?
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2128
Merit: 1009

Newbie


View Profile
January 16, 2014, 06:40:49 AM
 #1008

Whether there is any sense in the generation of an empty (without transactions) block?

Yes, the same as in Bitcoin.
ZeroTheGreat
Hero Member
*****
Offline Offline

Activity: 644
Merit: 500


View Profile
January 16, 2014, 07:12:02 PM
 #1009

Sounds like multiverse concept. We already have coins and anticoins, superposition of transactions lost in limbo, event horizon that limits rate of the transactions, time warp of transparent forging...
So another slogan here:

Nxt will blow your mind like quantum mechanics did!
xyzzyx
Sr. Member
****
Offline Offline

Activity: 490
Merit: 250


I don't really come from outer space.


View Profile
January 17, 2014, 08:06:44 AM
 #1010

This might be a silly question 'cause I only just started looking at the Nxt client source and I'm not really familiar with Java, but starting with a null blockchain, couldn't an attacker change program lines 4749-4757 like:

Code: (lines 4749 - 4757)
 int elapsedTime = lastBlock.timestamp + 60;
/* if (elapsedTime > 0) { */

    BigInteger target = BigInteger.valueOf(Block.getBaseTarget()).multiply(BigInteger.valueOf(account.getEffectiveBalance())).multiply(BigInteger.valueOf(elapsedTime));
    if (hits.get(account).compareTo(target) < 0) {

        account.generateBlock(user.secretPhrase);

/*   } */

and comment out the "Peer.sendToAllPeers(request);" on line 300.

Wouldn't the modified program in effect be bootstrapping a blockchain with only a genesis block and all empty transaction blocks?  Once the empty blockchain was longer than the network blockchain (and it will be 'cause it's cranking out empty blocks as fast as it can now that we disabled the time check) stop the modified program, then run a good unmodified client on our empty blockchain which would send that empty blockchain to the network?  Since the empty chain is longer, the empty chain would be favored over the network's chain?  Or am I missing something?

"An awful lot of code is being written ... in languages that aren't very good by people who don't know what they're doing." -- Barbara Liskov
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2128
Merit: 1009

Newbie


View Profile
January 17, 2014, 08:11:31 AM
 #1011

This might be a silly question 'cause I only just started looking at the Nxt client source and I'm not really familiar with Java, but starting with a null blockchain, couldn't an attacker change program lines 4749-4757 like:

Code: (lines 4749 - 4757)
 int elapsedTime = lastBlock.timestamp + 60;
/* if (elapsedTime > 0) { */

    BigInteger target = BigInteger.valueOf(Block.getBaseTarget()).multiply(BigInteger.valueOf(account.getEffectiveBalance())).multiply(BigInteger.valueOf(elapsedTime));
    if (hits.get(account).compareTo(target) < 0) {

        account.generateBlock(user.secretPhrase);

/*   } */

and comment out the "Peer.sendToAllPeers(request);" on line 300.

Wouldn't the modified program in effect be bootstrapping a blockchain with only a genesis block and all empty transaction blocks?  Once the empty blockchain was longer than the network blockchain (and it will be 'cause it's cranking out empty blocks as fast as it can now that we disabled the time check) stop the modified program, then run a good unmodified client on our empty blockchain which would send that empty blockchain to the network?  Since the empty chain is longer, the empty chain would be favored over the network's chain?  Or am I missing something?


This chain will be "shorter" and hence will be rejected.
tyz
Legendary
*
Offline Offline

Activity: 2324
Merit: 1240



View Profile
January 17, 2014, 07:40:50 PM
 #1012

Interesting callenge Grin Ill take a closer look to the source code later. Has someone found a flaw yet or are they sill undiscoverd?

Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2128
Merit: 1009

Newbie


View Profile
January 17, 2014, 07:50:44 PM
 #1013

Interesting callenge Grin Ill take a closer look to the source code later. Has someone found a flaw yet or are they sill undiscoverd?

2 flaws were found. The fatal flaw with 100K reward is still waiting for u.
ricot
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
January 17, 2014, 08:14:34 PM
 #1014

It's time for evil Bob to return once again. Smiley
Not with the fatal flaw, but still, Bob can cause quite a bit of damage with that...

Our friend Bob has some left-over hardware that is too inefficient to mine BTC, so he decides to wreak havok on the NXT blockchain instead...
He tasks his GPUs with finding 64bit collissions in account numbers. It doesn't matter which account, just that there is a 64bit collission.
Because of the birthday phenomenon that's actually not that hard to do.
When he has found enough collissions, e.g. a few, but it starts to work even with 2, so let's say Bob just found 2, he starts with his evil plan.
He makes 2 transactions and signes each with a different key that results in the same account number.
Then he calls "processTransactions" on all the peers he knows, and sends the first transactions to half the peers, and the second transaction to the other half.
What should happen now?
The network should decide on the public key that gets into the blockchain first and invalidate the other transaction, no problem.
But what actually happens?
Each peer analyses the transaction, sees that there was no transaction from that account before and adds the new public key to the account.
Now half the network has a different public key for the account than the other half.
If now any peer generates a block, the other half of the network will not accept that block, because it knows a different public key for one of its transactions, and we have a nice split of the blockchain that can't be resolved. Smiley

If Bob is a bit more patient and waits for a few more collissions (not neccessarily on the same account), he can generate even more separate blockchains and cause some nice chaos.  Roll Eyes
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2128
Merit: 1009

Newbie


View Profile
January 17, 2014, 08:20:53 PM
 #1015

It's time for evil Bob to return once again. Smiley
Not with the fatal flaw, but still, Bob can cause quite a bit of damage with that...

Our friend Bob has some left-over hardware that is too inefficient to mine BTC, so he decides to wreak havok on the NXT blockchain instead...
He tasks his GPUs with finding 64bit collissions in account numbers. It doesn't matter which account, just that there is a 64bit collission.
Because of the birthday phenomenon that's actually not that hard to do.
When he has found enough collissions, e.g. a few, but it starts to work even with 2, so let's say Bob just found 2, he starts with his evil plan.
He makes 2 transactions and signes each with a different key that results in the same account number.
Then he calls "processTransactions" on all the peers he knows, and sends the first transactions to half the peers, and the second transaction to the other half.
What should happen now?
The network should decide on the public key that gets into the blockchain first and invalidate the other transaction, no problem.
But what actually happens?
Each peer analyses the transaction, sees that there was no transaction from that account before and adds the new public key to the account.
Now half the network has a different public key for the account than the other half.
If now any peer generates a block, the other half of the network will not accept that block, because it knows a different public key for one of its transactions, and we have a nice split of the blockchain that can't be resolved. Smiley

If Bob is a bit more patient and waits for a few more collissions (not neccessarily on the same account), he can generate even more separate blockchains and cause some nice chaos.  Roll Eyes

Good catch. What fix do u propose?
opticalcarrier
Full Member
***
Offline Offline

Activity: 238
Merit: 100



View Profile
January 17, 2014, 08:33:02 PM
 #1016

It's time for evil Bob to return once again. Smiley
Not with the fatal flaw, but still, Bob can cause quite a bit of damage with that...

Our friend Bob has some left-over hardware that is too inefficient to mine BTC, so he decides to wreak havok on the NXT blockchain instead...
He tasks his GPUs with finding 64bit collissions in account numbers. It doesn't matter which account, just that there is a 64bit collission.
Because of the birthday phenomenon that's actually not that hard to do.
When he has found enough collissions, e.g. a few, but it starts to work even with 2, so let's say Bob just found 2, he starts with his evil plan.
He makes 2 transactions and signes each with a different key that results in the same account number.
Then he calls "processTransactions" on all the peers he knows, and sends the first transactions to half the peers, and the second transaction to the other half.
What should happen now?
The network should decide on the public key that gets into the blockchain first and invalidate the other transaction, no problem.
But what actually happens?
Each peer analyses the transaction, sees that there was no transaction from that account before and adds the new public key to the account.
Now half the network has a different public key for the account than the other half.
If now any peer generates a block, the other half of the network will not accept that block, because it knows a different public key for one of its transactions, and we have a nice split of the blockchain that can't be resolved. Smiley

If Bob is a bit more patient and waits for a few more collissions (not neccessarily on the same account), he can generate even more separate blockchains and cause some nice chaos.  Roll Eyes

Good catch. What fix do u propose?
I may be missing something.  Bob sends out 2 different colliding transactions , but those 2 transactions are still not on the blockchain yet, right?  They are still out there floating around waiting for a forging node to sign them into a block, right?  Wouldnt eventually one make it and the other wouldnt?  Or assuming they both made their way to the forging node for inclusion into the next block, then I guess the forging node should then have to determine which one to make permanent, and which to reject, right?

Or I could just be smart enough to make myself look dumb here, which is most likely the case...
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2128
Merit: 1009

Newbie


View Profile
January 17, 2014, 08:34:40 PM
 #1017

I may be missing something.  Bob sends out 2 different colliding transactions , but those 2 transactions are still not on the blockchain yet, right?  They are still out there floating around waiting for a forging node to sign them into a block, right?  Wouldnt eventually one make it and the other wouldnt?  Or assuming they both made their way to the forging node for inclusion into the next block, then I guess the forging node would determine which one to make permanent, right?

Full key is set when a transaction is verified, no matter if it's unconfirmed. Removing key setting in unconfirmed transactions solves this issue.
ricot
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
January 17, 2014, 08:42:39 PM
 #1018

Yes, the key should only be saved if it's in a block...
rlh
Hero Member
*****
Offline Offline

Activity: 788
Merit: 1000


View Profile
January 17, 2014, 09:03:42 PM
 #1019

Yes, the key should only be saved if it's in a block...

Yes, my assumption would be that the one that "wins" is the first transaction with the matched key that is received by the node that forges the block.  So, you send out 30 transactions, each with different keys, but which ever node forges the inclusive block should only select the first TX that it received, and ignore all of the others.

Make sense?

A Personal Quote on BTT from 2011:
"I'd be willing to make a moderate "investment" if the value of the BTC went below $2.00.  Otherwise I'll just have to live with my 5 BTC and be happy. :/"  ...sigh.  If only I knew.
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2128
Merit: 1009

Newbie


View Profile
January 17, 2014, 09:06:31 PM
 #1020

Yes, the key should only be saved if it's in a block...

Yes, my assumption would be that the one that "wins" is the first transaction with the matched key that is received by the node that forges the block.  So, you send out 30 transactions, each with different keys, but which ever node forges the inclusive block should only select the first TX that it received, and ignore all of the others.

Make sense?

Yes, just don't forget to reset the key if the block becomes orphaned.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 [51] 52 53 54 55 56 57 58 59 60 61 62 63 64 65 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!