Come-from-Beyond (OP)
Legendary
Offline
Activity: 2142
Merit: 1010
Newbie
|
|
January 09, 2014, 03:01:50 PM |
|
Well, BCNext, "Jean-Luc" and Come-from-Beyond are all three Russian. I'm not entirely sure who is who or whether all three are one, but that makes it more exciting I just leave it here - http://en.wikipedia.org/wiki/Trinity_(The_Matrix)PS: This explains why sometimes we see "The matrix has you..." in NRS
|
|
|
|
gimre
Legendary
Offline
Activity: 866
Merit: 1002
|
|
January 09, 2014, 03:03:29 PM |
|
Not sure if its logic flaw, but somebody could simply change initial allocation in genesis block to give themselves a lot of NXT.
We have seen a case of altered client already, so changing genesis block's hardcoding and hypnotizing jean-luc into signing it as the official release, would be an obvious but effective way to steal a lot of NXT
James
and it would invalidate all existing transactions so it's a "no go"
|
|
|
|
jl777
Legendary
Offline
Activity: 1176
Merit: 1134
|
|
January 09, 2014, 03:07:39 PM |
|
Not if they precalculated a change that ends up with same hash
|
|
|
|
ImmortAlex
|
|
January 09, 2014, 03:08:09 PM |
|
Well, BCNext, "Jean-Luc" and Come-from-Beyond are all three Russian.
C-f-B is from Belarus. ...but it doesn't mean his is not Russian. Like, I'm from Russia, but it doesn't mean that I'm Russian
|
|
|
|
NxtChoice
|
|
January 09, 2014, 03:27:02 PM |
|
Not sure if its logic flaw, but somebody could simply change initial allocation in genesis block to give themselves a lot of NXT.
We have seen a case of altered client already, so changing genesis block's hardcoding and hypnotizing jean-luc into signing it as the official release, would be an obvious but effective way to steal a lot of NXT
James
True, that's why noone knows who Jean-Luc is. Maybe he is BCNext! Well, BCNext, "Jean-Luc" and Come-from-Beyond are all three Russian. I'm not entirely sure who is who or whether all three are one, but that makes it more exciting Come-from-Beyond is BCNext, and Jean-Luc seems to be another guy. Perhaps all those three are one guy.
|
|
|
|
Come-from-Beyond (OP)
Legendary
Offline
Activity: 2142
Merit: 1010
Newbie
|
|
January 09, 2014, 03:30:10 PM |
|
Perhaps all those three are one guy.
Or a gal...
|
|
|
|
Come-from-Beyond (OP)
Legendary
Offline
Activity: 2142
Merit: 1010
Newbie
|
|
January 09, 2014, 03:38:46 PM |
|
We completely derailed this thread.
|
|
|
|
gsan1
Newbie
Offline
Activity: 50
Merit: 0
|
|
January 09, 2014, 04:49:36 PM |
|
When I unlock my account in the client and close the browser window, the client is still forging cause the java client is running. Then why does the client show the account locked, when I close the window and reopen it? Could we use a session/cookie to make this easier? This confuses a lot nxt users.
|
|
|
|
gimre
Legendary
Offline
Activity: 866
Merit: 1002
|
|
January 09, 2014, 05:05:02 PM |
|
stuff that I've checked: classes not actually worth looking at: Alias, AskOrder, Asset, BidOrder, Crypto Curve25519
classes I think are ok: Account, Block, Peer, Transaction, User, UserAsyncListener, (at first four I've looked more than 2 times)
most of anonymous objects (those in scheduledThreadPool.scheduleWithFixedDelay) also look ok (I want to make one more closer look to that big one, where there's block processing).
So IMHO, IF there are injected flaws they are inside main Nxt class.
|
|
|
|
Come-from-Beyond (OP)
Legendary
Offline
Activity: 2142
Merit: 1010
Newbie
|
|
January 09, 2014, 05:19:38 PM |
|
stuff that I've checked: classes not actually worth looking at: Alias, AskOrder, Asset, BidOrder, Crypto Curve25519
classes I think are ok: Account, Block, Peer, Transaction, User, UserAsyncListener, (at first four I've looked more than 2 times)
most of anonymous objects (those in scheduledThreadPool.scheduleWithFixedDelay) also look ok (I want to make one more closer look to that big one, where there's block processing).
So IMHO, IF there are injected flaws they are inside main Nxt class.
Hey, u shouldn't exclude inner classes, we r still interested in their review, what if not all bugs r found?
|
|
|
|
Come-from-Beyond (OP)
Legendary
Offline
Activity: 2142
Merit: 1010
Newbie
|
|
January 09, 2014, 05:24:13 PM |
|
Well, I decided to give a small hint. In this thread we discussed a situation that is very close to the critical flaw. One of the guys asked a question that I didn't answer completely, coz otherwise I would reveal the flaw.
|
|
|
|
gimre
Legendary
Offline
Activity: 866
Merit: 1002
|
|
January 09, 2014, 05:43:15 PM |
|
stuff that I've checked: classes not actually worth looking at: Alias, AskOrder, Asset, BidOrder, Crypto Curve25519
Hey, u shouldn't exclude inner classes, we r still interested in their review, what if not all bugs r found? I mean those initial classes are either tiny or empty. In case of Crypto I was already checking it with pen+paper, as I've written on nextcoin forum. I think we could have better/faster implementation of Curve25519, but it's something that shoulbe further researched
|
|
|
|
|
gsan1
Newbie
Offline
Activity: 50
Merit: 0
|
|
January 09, 2014, 06:57:21 PM |
|
ok, looked at it again: the blockID is a hash over everything in the block (including a payloadHash). so as soon as you change a transaction, your block will get a different id. and the id of the previous block is also saved in a block, because that's the reference to building up the chain. so: everything safe Wait, wait, wait... Back to Bloody Rookies attack from page 37 of this thread. The result was: That attack won't work cause every block has the id of the previous block. And if you change one transaction, payloadHash will change and so the id of the block will change, making the blockchain corrupt. Lets take a look at the method that returns the block id: byte[] hash = MessageDigest.getInstance("SHA-256").digest(getBytes()); BigInteger bigInteger = new BigInteger(1, new byte[] {hash[7], hash[6], hash[5], hash[4], hash[3], hash[2], hash[1], hash[0]}); return bigInteger.longValue();
The hash consists of hash[7], hash[6], ... hash[0]. So it consists of the first 64 bytes of the getByte method. Lets take a look at the initialization of the ByteBuffer that is used: byte[] getBytes() { ByteBuffer buffer = ByteBuffer.allocate(4 + 4 + 8 + 4 + 4 + 4 + 4 + 32 + 32 + 64 + 64); buffer.order(ByteOrder.LITTLE_ENDIAN); buffer.putInt(version); buffer.putInt(timestamp); buffer.putLong(previousBlock); buffer.putInt(numberOfTransactions); buffer.putInt(totalAmount); buffer.putInt(totalFee); buffer.putInt(payloadLength); buffer.put(payloadHash); buffer.put(generatorPublicKey); buffer.put(generationSignature); buffer.put(blockSignature); return buffer.array(); }
The first 64 bytes of the getBytes() method (that are setting the blockID) are: version, timestamp, previousBlock, numberOfTransactions, totalAmount, totalFee, payloadLength AND NOT PAYLOADHASH! SO this attack is possible. So: We can replace the transaction (going to the nxt/btcexchance) with another of the same amount (so numberOfTransactions, totalAmount, totalFee is the same), but we don't send the coins to the exchance anymore but to another account that is mine. Could you follow me? //EDIT: This attack would only be possible in 0.4.7e because now a block contains the hash of the previous one (and not only the id).
|
|
|
|
gimre
Legendary
Offline
Activity: 866
Merit: 1002
|
|
January 09, 2014, 07:12:50 PM |
|
why js not java? bounty still open?
|
|
|
|
minusbalancer
Newbie
Offline
Activity: 56
Merit: 0
|
|
January 09, 2014, 07:21:57 PM |
|
Lets take a look at the method that returns the block id: byte[] hash = MessageDigest.getInstance("SHA-256").digest(getBytes()); BigInteger bigInteger = new BigInteger(1, new byte[] {hash[7], hash[6], hash[5], hash[4], hash[3], hash[2], hash[1], hash[0]}); return bigInteger.longValue();
The hash consists of hash[7], hash[6], ... hash[0]. So it consists of the first 64 bytes of the getByte method. Hash function is calculated based on all of the bytes from the block. Id is taken from first 64 bits of the hash. Not the first 64 bits of the getBytes()
|
|
|
|
BloodyRookie
|
|
January 09, 2014, 07:23:25 PM |
|
The hash consists of hash[7], hash[6], ... hash[0]. So it consists of the first 64 bytes of the getByte method. Could you follow me? //EDIT: This attack would only be possible in 0.4.7e because now a block contains the hash of the previous one (and not only the id). No , the 64 bytes are taken from the hash and the hash is calculated from all the bytes we got from getBytes(). It is not the first 64 bytes of getBytes().
|
Nothing Else Matters NEM: NALICE-LGU3IV-Y4DPJK-HYLSSV-YFFWYS-5QPLYE-ZDJJ NXT: 11095639652683007953
|
|
|
BloodyRookie
|
|
January 09, 2014, 07:24:55 PM |
|
why js not java? bounty still open? Well we already have code writte in java Take a look at class Curve25519.java.
|
Nothing Else Matters NEM: NALICE-LGU3IV-Y4DPJK-HYLSSV-YFFWYS-5QPLYE-ZDJJ NXT: 11095639652683007953
|
|
|
BloodyRookie
|
|
January 09, 2014, 07:26:26 PM |
|
I am on it but I think it will a lot slower than you want
|
Nothing Else Matters NEM: NALICE-LGU3IV-Y4DPJK-HYLSSV-YFFWYS-5QPLYE-ZDJJ NXT: 11095639652683007953
|
|
|
ferment
Full Member
Offline
Activity: 168
Merit: 100
IDEX - LIVE Real-time DEX
|
|
January 09, 2014, 07:26:55 PM |
|
why js not java? bounty still open? two words: thin client
|
|
|
|
|