|
Assuming we are talking about Bitcoin signatures and we are not using deterministic k.
My understanding is that signing the same message with the same private key will not yield the same signature because of the random factor k. The odds of two signatures being equal is negligible under these conditions. Could someone confirm or refute this?
Thanks,
--h
|
|
|
|
|
Because what he says is completely bogus.
|
|
|
|
|
Do you really think that they would not be upgraded by then?
|
|
|
|
|
No problem, you're welcome.
|
|
|
|
Ok. It's a bit tricky because the block file doesn't have the expected state of the blockchain, just the block data. In a previous project, I actually did the same thing. You may want to take a look at https://github.com/hhanh00/bitcoin-akka-tutorialI patched the test generator so that it writes out the chain state and hook up a test driver. |
|
|
|
|
The pastbins are truncated. Actually the first 100 blocks are not interesting. You could edit that part out.
|
|
|
|
It creates such a file every time your run it. That's why it takes a while to startup. File blockFile = File.createTempFile("testBlocks", ".dat");
blockFile.deleteOnExit();
Change these lines and you can keep the file around. |
|
|
|
|
The tool uses an ugly hack to work around timing issues. Bitcoind processes commands in sequence so the tool sends a ping and waits for a pong. At that time bitcoind has finished processing previous commands and reorgs have taken place. This won't work if your implementation handles ping/pong in parallel.
The pastbins are truncated. Actually the first 100 blocks are not interesting. You could edit that part out.
|
|
|
|
In that case, the node is supposed to return headers starting from the genesis block. The relevant code of bitcoin core is in main.cpp (line 4886-) if (locator.IsNull())
{
// If locator is null, return the hashStop block
BlockMap::iterator mi = mapBlockIndex.find(hashStop);
if (mi == mapBlockIndex.end())
return true;
pindex = (*mi).second;
}
else
{
// Find the last block the caller has in the main chain
pindex = FindForkInGlobalIndex(chainActive, locator);
if (pindex)
pindex = chainActive.Next(pindex);
}
...
CBlockIndex* FindForkInGlobalIndex(const CChain& chain, const CBlockLocator& locator)
{
// Find the first block the caller has in the main chain
BOOST_FOREACH(const uint256& hash, locator.vHave) {
BlockMap::iterator mi = mapBlockIndex.find(hash);
if (mi != mapBlockIndex.end())
{
CBlockIndex* pindex = (*mi).second;
if (chain.Contains(pindex))
return pindex;
}
}
return chain.Genesis();
}
I have no clue why there is a different behavior if the locator is null. |
|
|
|
Commiting block 0b1c05438c178aa1976b713a0b794d705f955b99236a2bcc9cd8609b68db92bf -> 7cd3ee22eab70c6bc23fe7d43c19a797eb9529e9c9bc71aaca6c8b9f9c3496f4
Undo block 102 748223dc39df65a8c88ef9af80f98cbf130a2f8cfdf1900ff84f1bcf1fcc04b2 0 KB
- New TOP 103
Current last 0b1c05438c178aa1976b713a0b794d705f955b99236a2bcc9cd8609b68db92bf
GetHeaders 1 up to 0000000000000000000000000000000000000000000000000000000000000000
? 748223dc39df65a8c88ef9af80f98cbf130a2f8cfdf1900ff84f1bcf1fcc04b2 found: true
sending back 0 headers
Isn't it supposed to return the new fork? I don't think so, because 748223dc39df65a8c88ef9af80f98cbf130a2f8cfdf1900ff84f1bcf1fcc04b2 has no children. 748223dc39df65a8c88ef9af80f98cbf130a2f8cfdf1900ff84f1bcf1fcc04b2 is no longer on the main chain, so you're supposed to ignore it and try the next locator. getheaders/getblocks are used by your peers to get the main chain, they don't care about forks. |
|
|
|
Oops, you are right. I thought that was b2. How about: Commiting block 0b1c05438c178aa1976b713a0b794d705f955b99236a2bcc9cd8609b68db92bf -> 7cd3ee22eab70c6bc23fe7d43c19a797eb9529e9c9bc71aaca6c8b9f9c3496f4
Undo block 102 748223dc39df65a8c88ef9af80f98cbf130a2f8cfdf1900ff84f1bcf1fcc04b2 0 KB
- New TOP 103
Current last 0b1c05438c178aa1976b713a0b794d705f955b99236a2bcc9cd8609b68db92bf
GetHeaders 1 up to 0000000000000000000000000000000000000000000000000000000000000000
? 748223dc39df65a8c88ef9af80f98cbf130a2f8cfdf1900ff84f1bcf1fcc04b2 found: true
sending back 0 headers
Isn't it supposed to return the new fork? |
|
|
|
Actually, I think the problem comes from B3 (7cd3ee22eab70c6bc23fe7d43c19a797eb9529e9c9bc71aaca6c8b9f9c3496f4). Commiting block 7cd3ee22eab70c6bc23fe7d43c19a797eb9529e9c9bc71aaca6c8b9f9c3496f4 -> 104cbafb5906c7b9fe28eba9b288eea1acec306320c53cd49ac1a5dd0e673ce1
- Orphaned 102
Orphaned block: 102 7cd3ee22eab70c6bc23fe7d43c19a797eb9529e9c9bc71aaca6c8b9f9c3496f4 0 KB
That one shouldn't be orphaned because // We now have the following chain (which output is spent is in parentheses):
// genesis -> b1 (0) -> b2 (1)
//
// so fork like this:
//
// genesis -> b1 (0) -> b2 (1)
// \-> b3 (1)
//
// Nothing should happen at this point. We saw b2 first so it takes priority.
|
|
|
|
|
Search for Error because the tool continues for a while after a failure. You got a problem at block b4. This tool is truly a pain to use though. B4 should have caused a reorganization but your node stayed on the same fork.
|
|
|
|
Does it? Extract from their doc: Progressive Hashing
var sha256 = CryptoJS.algo.SHA256.create();
sha256.update("Message Part 1");
sha256.update("Message Part 2");
sha256.update("Message Part 3");
var hash = sha256.finalize();
|
|
|
|
|
No problem. A few things not covered by the scripts that could be worth checking:
- the best chain is not necessarily the one with the highest height but the one with the most cumulative proof of work,
- difficulty readjustments are capped by +/- n % (I don't remember how much),
|
|
|
|
|
Install a jdk, compile and run.
|
|
|
|
|
With 7 inputs, there is less than a chance in a 100 that it works by luck. You could try out with a wallet that supports multi sig like electrum.
|
|
|
|
|
Use the verify tab and post here what you get.
|
|
|
|
|
If your transaction doesn't change when you re-sign, you will have modify it the hard way
|
|
|
|
|
Show Posts
