jonasschnelli: did you see my remark here: https://github.com/bitcoin/bitcoin/pull/8407/files#r72257114 ... I'm not sure what settings.value(strSettingsVersionKey) returns in the case !settings.contains(strSettingsVersionKey), but if it's garbage or raises an exception this may be problematic
bitcoin/0.13 18b8ee1 Jonas Schnelli: [Wallet] add HD xpriv to dumpwallet...
By blocking I just meant bitcoin core wouldn't open multiple processes.
well I suggested before a general design, where bitcoin-core wallet just has a simple interface to call another process to ask it to get signatures, providing it with the relevant data... and then that external process can implement the approrpiate call out to whatever is in use.
You could import these seeds into your Bitcoin Core to act as hot-wallets.
But having the r value be correct (in accordance to bitcoin core) and the s value incorrect seems like a strange case. Any way I'm going to investigate further and play with core's signing message functionality
you're generating a signature that is different from the one created by bitcoin core
I'm importing the key from bitcoin core's WIF format, I used dumpprivkey. Did I screw something up along the way?
when trying to recreate a digital signature from bitcoin core
do we have any tests of bitcoin-tx at all?
and bitcoin 0.2.10 should be able to sync the full chain (due to a p2p change in 0.2.10)
it's probably fair to say that ever since the concept of backward compatible consensus changes was invented (now called soft forks), bitcoin has not had any hard forks (apart from potentially the march 2013 one, but that's dubious)
I'm doing some stuff for segwit with Armory, and one part of it is sending a getdata message to bitcoin core about a transaction that it just sent. The transaction was clearly accepted by core (I see it in the transaction list) but it keeps returning a notfound message. Any reason why?
OH I was misreading that, looking at the github page it seemed like jtimon was still adding commits to it, but it says "added a commit to jtimon/bitcoin that referenced this pull request", I think that's new?
[bitcoin] jonasschnelli closed pull request #6481: [mining] allow other signal listeners to provide scripts for mining (master...2015/07/enhance_mining_flexibility) https://github.com/bitcoin/bitcoin/pull/6481