Like releasing the full source on Jan 3rd?
It was never promised to release full source on Jan 3rd. Why r u still there, all ur posts r troll posts.
Topic: Nxt source code flaw reports - page 5. (Read 113312 times)
It was never promised to release full source on Jan 3rd. Why r u still there, all ur posts r troll posts.
Don't reveal the flaw on 3rd of April, please
Let someone find it.
Are you seriously suggesting to break a promise?Let someone find it.
Like releasing the full source on Jan 3rd?
Don't reveal the flaw on 3rd of April, please
Let someone find it.
Are you seriously suggesting to break a promise?Let someone find it.
Where is the promise that the flaw will be revealed on the 3rd? All I see is the promise of reward before that date.
Don't reveal the flaw on 3rd of April, please
Let someone find it.
Are you seriously suggesting to break a promise?Let someone find it.
Could you make this clearer?
Only after 3rd of April.
Don't reveal the flaw on 3rd of April, please
Let someone find it.
If NXT-copycoin starts from its genesis block, that condition is not causing any problem or risk?
No, don't worry.
ok
*sigh ... the flaw-candidates are running out. Interesting to see the revelation of 3rd of April ...
If NXT-copycoin starts from its genesis block, that condition is not causing any problem or risk?
No, don't worry.
Is this "getLastBlock().height > 303" a flaw?
/code]
condition with "303" : when block height is 1 - 302, transactions' timestamp can be > blockTimestamp.
/code]
condition with "303" : when block height is 1 - 302, transactions' timestamp can be > blockTimestamp.
It's not the flaw. The block contains a transaction that expired before the block timestamp. The corresponding check was added later.
If NXT-copycoin starts from its genesis block, that condition is not causing any problem or risk?
Is this "getLastBlock().height > 303" a flaw?
condition with "303" : when block height is 1 - 302, transactions' timestamp can be > blockTimestamp.
Code:
for (i = 0; i < block.numberOfTransactions; i++) {
Transaction transaction = blockTransactions.get(block.transactions[i]);
if (
transaction.timestamp > curTime + 15 ||
transaction.deadline < 1 ||
(transaction.timestamp + transaction.deadline * 60 < blockTimestamp &&
getLastBlock().height > 303)
||
transaction.fee <= 0 ||
!transaction.validateAttachment() || Nxt.transactions.get(block.transactions[i]) != null ||
(transaction.referencedTransaction != 0 &&
Nxt.transactions.get(transaction.referencedTransaction) == null &&
blockTransactions.get(transaction.referencedTransaction) == null) ||
(unconfirmedTransactions.get(block.transactions[i]) == null && !transaction.verify())
)
{
break;
}
condition with "303" : when block height is 1 - 302, transactions' timestamp can be > blockTimestamp.
It's not the flaw. The block contains a transaction that expired before the block timestamp. The corresponding check was added later.
Is this "getLastBlock().height > 303" a flaw?
condition with "303" : when block height is 1 - 302, transactions' timestamp can be > blockTimestamp.
Code:
for (i = 0; i < block.numberOfTransactions; i++) {
Transaction transaction = blockTransactions.get(block.transactions[i]);
if (
transaction.timestamp > curTime + 15 ||
transaction.deadline < 1 ||
(transaction.timestamp + transaction.deadline * 60 < blockTimestamp &&
getLastBlock().height > 303)
||
transaction.fee <= 0 ||
!transaction.validateAttachment() || Nxt.transactions.get(block.transactions[i]) != null ||
(transaction.referencedTransaction != 0 &&
Nxt.transactions.get(transaction.referencedTransaction) == null &&
blockTransactions.get(transaction.referencedTransaction) == null) ||
(unconfirmedTransactions.get(block.transactions[i]) == null && !transaction.verify())
)
{
break;
}
condition with "303" : when block height is 1 - 302, transactions' timestamp can be > blockTimestamp.
hmmm 302 blocks is less than 1 day
Is this "getLastBlock().height > 303" a flaw?
condition with "303" : when block height is 1 - 302, transactions' timestamp can be > blockTimestamp.
Code:
for (i = 0; i < block.numberOfTransactions; i++) {
Transaction transaction = blockTransactions.get(block.transactions[i]);
if (
transaction.timestamp > curTime + 15 ||
transaction.deadline < 1 ||
(transaction.timestamp + transaction.deadline * 60 < blockTimestamp &&
getLastBlock().height > 303)
||
transaction.fee <= 0 ||
!transaction.validateAttachment() || Nxt.transactions.get(block.transactions[i]) != null ||
(transaction.referencedTransaction != 0 &&
Nxt.transactions.get(transaction.referencedTransaction) == null &&
blockTransactions.get(transaction.referencedTransaction) == null) ||
(unconfirmedTransactions.get(block.transactions[i]) == null && !transaction.verify())
)
{
break;
}
condition with "303" : when block height is 1 - 302, transactions' timestamp can be > blockTimestamp.
Could you make this clearer?
Only after 3rd of April.
This message was too old and has been purged
Is the 3rd flaw still running free out there?
...though NXT source is public?
https://bitbucket.org/JeanLucPicard
U still have time to find it and get 100K reward.
absolutely great.
In that case I start focusing on that flaw, coz I just got my first java code working
and therefore I'm qualified java dev now - I shall have a date with that flaw
: We shall meet in the place where there is no darkness
Is the 3rd flaw still running free out there?
...though NXT source is public?
https://bitbucket.org/JeanLucPicard
U still have time to find it and get 100K reward.
Is the 3rd flaw still running free out there?
...though NXT source is public?
https://bitbucket.org/JeanLucPicard
Building on previous posts.
The previous block is always read from the lastBlock ala getBaseTarget.
If a malicious person were to re-write the client at pushBlock so that previous block was offset by 1 at generation time so then verifyGenerationSignature would honour this previous block and skip the actual previous block, meaning that there would be a block with missing transactions making double spending possible.
And what makes you think, any other peer in network would accept such block...
Building on previous posts.
The previous block is always read from the lastBlock ala getBaseTarget.
If a malicious person were to re-write the client at pushBlock so that previous block was offset by 1 at generation time so then verifyGenerationSignature would honour this previous block and skip the actual previous block, meaning that there would be a block with missing transactions making double spending possible.
Could you please elaborate on how its a feature and not a flaw.
I prefer to wait until someone explains why it's a flaw.
The block hash is excluded from generation signature.
Flaw: Blocks can be mutated after the fact, by the account which generated the block.
Code:
block.payloadHash = digest.digest();
// ???
block.generationSignature = Crypto.sign(Block.getLastBlock().generationSignature, secretPhrase);
Flaw: Blocks can be mutated after the fact, by the account which generated the block.
It's not a flaw, it's a feature.
Jump to: