Bitcoin Forum
February 21, 2019, 05:07:16 PM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
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 113023 times)
msin
Legendary
*
Offline Offline

Activity: 1176
Merit: 1000


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.
1550768836
Hero Member
*
Offline Offline

Posts: 1550768836

View Profile Personal Message (Offline)

Ignore
1550768836
Reply with quote  #2

1550768836
Report to moderator
1550768836
Hero Member
*
Offline Offline

Posts: 1550768836

View Profile Personal Message (Offline)

Ignore
1550768836
Reply with quote  #2

1550768836
Report to moderator
1550768836
Hero Member
*
Offline Offline

Posts: 1550768836

View Profile Personal Message (Offline)

Ignore
1550768836
Reply with quote  #2

1550768836
Report to moderator
Your Bitcoin transactions
The Ultimate Bitcoin mixer
made truly anonymous.
with an advanced technology.
Mix coins
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1550768836
Hero Member
*
Offline Offline

Posts: 1550768836

View Profile Personal Message (Offline)

Ignore
1550768836
Reply with quote  #2

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

Activity: 683
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: 1176
Merit: 1000


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: 2072
Merit: 1007

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: 1176
Merit: 1000


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: 2072
Merit: 1007

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: 2072
Merit: 1007

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: 1834
Merit: 1063



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: 2072
Merit: 1007

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: 2072
Merit: 1007

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: 2072
Merit: 1007

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: 2072
Merit: 1007

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:  

Bitcointalk.org is not available or authorized for sale. Do not believe any fake listings.
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!