< GitHub72>
[bitcoin] laanwj closed pull request #8403: Process "notfound" messages, and safeguard against unreasonably long … (master...ProcessNotfound) https://github.com/bitcoin/bitcoin/pull/8403
< GitHub88>
bitcoin/0.13 c3c82c4 Wladimir J. van der Laan: Merge #8389: [0.13] Create a new HD seed after encrypting the wallet...
< GitHub88>
bitcoin/0.13 de45c06 Jonas Schnelli: [Wallet] Add CKeyMetadata record for HDMasterKey(s), factor out HD key generation
< GitHub88>
bitcoin/0.13 f142c11 Jonas Schnelli: [0.13] Create a new HD seed after encrypting the wallet
< GitHub76>
[bitcoin] laanwj closed pull request #8389: [0.13] Create a new HD seed after encrypting the wallet (0.13...2016/07/hd_enc) https://github.com/bitcoin/bitcoin/pull/8389
< GitHub132>
[bitcoin] jtimon opened pull request #8413: Trivial: pass Consensus::Params& instead of CChainParams& in ContextualCheckBlock (master...0.13-consensus-last-params) https://github.com/bitcoin/bitcoin/pull/8413
< GitHub48>
[bitcoin] jtimon opened pull request #8412: libconsensus: Expose a flag for BIP112 (master...0.13-consensus-bip112-flag) https://github.com/bitcoin/bitcoin/pull/8412
< GitHub191>
bitcoin/0.13 0179a39 Wladimir J. van der Laan: qt: periodic translations update
< wumpus>
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
< GitHub42>
bitcoin/0.13 18b8ee1 Jonas Schnelli: [Wallet] add HD xpriv to dumpwallet...
< jonasschnelli>
https://github.com/bitcoin/bitcoin/pull/8206 is featureish and I think we only backport it to 0.13 because of possible complains because of lack of exporting the xpriv
< * gmaxwell>
goes to find the old bitcoin wiki page.
< GitHub182>
[bitcoin] laanwj closed pull request #8365: Treat high-sigop transactions as larger rather than rejecting them (master...unifysigopcost) https://github.com/bitcoin/bitcoin/pull/8365
< GitHub176>
bitcoin/master 618c9dd Wladimir J. van der Laan: Merge #8365: Treat high-sigop transactions as larger rather than rejecting them...
< GitHub176>
bitcoin/master ab942c1 Pieter Wuille: Treat high-sigop transactions as larger rather than rejecting them
< gmaxwell>
By blocking I just meant bitcoin core wouldn't open multiple processes.
< gmaxwell>
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.
< da2ce7_mobile>
You could import these seeds into your Bitcoin Core to act as hot-wallets.
< gmaxwell>
or we could implement some version of the block bloom indexing that was posted about on bitcoin-dev.
< gmaxwell>
wumpus: wallet.dat encryption also gives you an authorization hook. A user doesn't have to worry when screwing around with bitcoin-qt that they're acidentally going to send funds.
< DongSwanson>
so bitcoin-core cannot create CSV escrows but can sign it's outgoing transactions if you provide the correct redeemscript?
< Chris_Stewart_5>
through bitcoin core's wallet UI?
< Chris_Stewart_5>
You can use something like peter todd's python bitcoin library or whatever library there is for your favorite language
< Chris_Stewart_5>
DongSwanson: Bitcoin Core doesn't expose functionality to create custom contracts through a user interface (that I know of...) You need to manually construct the contract
< DongSwanson>
sipa: oh. so if I wanted to create a escrow with timeout for a real world scenario, we cannot use bitcoin-core?
< DongSwanson>
can somebody help me with utilizing CHECKSEQUENCEVERIFY with bitcoin-core? I want to create a "escrow with timeout" with bitcoin-core
< GitHub84>
[bitcoin] rebroad opened pull request #8403: Process "notfound" messages, and safeguard against unreasonably long … (master...ProcessNotfound) https://github.com/bitcoin/bitcoin/pull/8403
< GitHub24>
bitcoin/0.13 73adfe3 Jonas Schnelli: [Wallet] Correct hdmasterkeyid/masterkeyid name confusion...
< Chris_Stewart_5>
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
< sipa>
you're generating a signature that is different from the one created by bitcoin core
< Chris_Stewart_5>
I'm importing the key from bitcoin core's WIF format, I used dumpprivkey. Did I screw something up along the way?
2016-07-24
< Chris_Stewart_5>
when trying to recreate a digital signature from bitcoin core
< gmaxwell>
do we have any tests of bitcoin-tx at all?
< sipa>
and bitcoin 0.2.10 should be able to sync the full chain (due to a p2p change in 0.2.10)
< sipa>
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)
< achow101>
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?
< instagibbs>
while we're improving CB, lets get https://github.com/bitcoin/bitcoin/pull/8235 if for nothing else me not having to scan the source to figure out how to log debug messages :P
< GitHub128>
[bitcoin] jonasschnelli opened pull request #8389: [0.13] Create a new HD seed after encrypting the wallet (0.13...2016/07/hd_enc) https://github.com/bitcoin/bitcoin/pull/8389
< GitHub51>
[bitcoin] luke-jr opened pull request #8388: [0.13] mining: Optimise for typical mining use with blockmaxsize (0.13...blockmaxsize_opti-0.13) https://github.com/bitcoin/bitcoin/pull/8388
< GitHub33>
[bitcoin] luke-jr closed pull request #8387: [0.13] mining: Optimise for typical mining use with blockmaxsize (master...blockmaxsize_opti-0.13) https://github.com/bitcoin/bitcoin/pull/8387
< GitHub184>
[bitcoin] luke-jr opened pull request #8387: [0.13] mining: Optimise for typical mining use with blockmaxsize (master...blockmaxsize_opti-0.13) https://github.com/bitcoin/bitcoin/pull/8387
< GitHub177>
[bitcoin] luke-jr opened pull request #8386: mining: Optimise for typical mining use with blockmaxsize (master...blockmaxsize_opti) https://github.com/bitcoin/bitcoin/pull/8386
< GitHub87>
[bitcoin] laanwj closed pull request #8347: Trivial: Make CBlockIndex param const in ContextualCheckBlockHeader and ContextualCheckBlock (master...0.12.99-consensus-const-lost) https://github.com/bitcoin/bitcoin/pull/8347
< GitHub37>
bitcoin/master 381917f Wladimir J. van der Laan: Merge #8347: Trivial: Make CBlockIndex param const in ContextualCheckBlockHeader and ContextualCheckBlock...
< GitHub37>
bitcoin/master 6f3d616 Jorge Timón: Trivial: Make CBlockIndex param const in ContextualCheckBlockHeader and ContextualCheckBlock
< wumpus>
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?
< GitHub128>
[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