1 2017-06-02 00:05:44	0|jtimon|gmaxwell: I'm not sure what the implications of your comments about #10195 are, sadly I didn't find time to take more than a glance at it
  2 2017-06-02 00:05:48	0|gribble|https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
  3 2017-06-02 00:07:00	0|gmaxwell|jtimon: huh?
  4 2017-06-02 00:07:45	0|sipa|jtimon: since 10195, at first startup, your chainstate database will be upgraded to a new format
  5 2017-06-02 00:08:07	0|sipa|this may take a while, but only happens once
  6 2017-06-02 00:09:41	0|jtimon|sipa: thank you, and gmaxwell is pointing out that trying to downgrade the chainstate database format would be painful, but there's no good reason to want that besides testing, right?
  7 2017-06-02 00:09:57	0|sipa|indeed
  8 2017-06-02 00:10:48	0|jtimon|but gmaxwell tried anyway, nice
  9 2017-06-02 00:11:13	0|jtimon|and it works
 10 2017-06-02 00:12:22	0|jtimon|I guess I shouldn't have started with the youtube video
 11 2017-06-02 00:22:02	0|jtimon|I know it's selfish, but my plan was to partially review 10195 after squashed and merged all along
 12 2017-06-02 00:26:02	0|sipa|that's a perfectly gine strategy
 13 2017-06-02 00:26:06	0|sipa|*fine
 14 2017-06-02 00:49:04	0|jtimon|mhmm sipa I cannot find where this check went: https://github.com/bitcoin/bitcoin/pull/8498/commits/e1cddd6c57e0b40d63c6ed5ff8d61e2c6b44ad3e#r110544416
 15 2017-06-02 00:50:28	0|sipa|doesn't exist anymore... we can't distinguish already spent from nonexisting
 16 2017-06-02 00:51:25	0|sipa|it was unreliable before
 17 2017-06-02 00:53:37	0|jtimon|thank you, I take that as https://github.com/bitcoin/bitcoin/pull/8498/commits/e1cddd6c57e0b40d63c6ed5ff8d61e2c6b44ad3e#diff-ca81084f62961a188f5c1e86a5ff1d7cL206 still being good (chnaging from 0 to 100 )
 18 2017-06-02 00:53:45	0|jtimon|rebasing just that now
 19 2017-06-02 00:54:37	0|jtimon|anyway, nver mind, new checks right above
 20 2017-06-02 00:55:15	0|jtimon|or are they new? I will figure it out, thanks
 21 2017-06-02 00:55:17	0|cfields|wumpus: forgot to bump version before tag :(
 22 2017-06-02 01:07:04	0|jtimon|sipa: ping https://github.com/bitcoin/bitcoin/pull/8498#issuecomment-305661391
 23 2017-06-02 03:58:53	0|instagibbs|bad timing... https://github.com/drivechain-project/bitcoin/pull/10 just told them about new style guide, haha
 24 2017-06-02 03:59:00	0|instagibbs|guess it's good it's merged now
 25 2017-06-02 05:36:48	0|wumpus|cfields: darn
 26 2017-06-02 05:40:28	0|bitcoin-git|13bitcoin/060.14 144a41de4 15Wladimir J. van der Laan: build: bump version to 0.14.2
 27 2017-06-02 05:40:28	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.14: 02https://github.com/bitcoin/bitcoin/commit/4a41de4585a4dffb451a9be8078abb838235f336
 28 2017-06-02 05:40:38	0|wumpus|well that means there will be a rc2 for sure
 29 2017-06-02 05:43:20	0|gmaxwell|oh damnit we did it again.
 30 2017-06-02 05:43:42	0|gmaxwell|I somehow missed that we were cutting a rc1.
 31 2017-06-02 05:44:00	0|wumpus|another reason it's good that we do rcs in the first place
 32 2017-06-02 05:44:30	0|wumpus|that was discussed in the meeting yesterday
 33 2017-06-02 05:44:47	0|gmaxwell|yea, I missed part of it.
 34 2017-06-02 05:45:29	0|gmaxwell|oh hm. testing is slightly harder because I've upgraded most of my nodes to per txo! :P
 35 2017-06-02 05:45:35	0|wumpus|yes, not your fault
 36 2017-06-02 05:45:56	0|wumpus|... same here
 37 2017-06-02 07:39:31	0|midnightmagic|ô/w 4
 38 2017-06-02 08:59:39	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7cc2c670e3d7...00d369239612
 39 2017-06-02 08:59:40	0|bitcoin-git|13bitcoin/06master 145252827 15Pieter Wuille: Update to latest libsecp256k1
 40 2017-06-02 08:59:40	0|bitcoin-git|13bitcoin/06master 14e7c1b44 15Pieter Wuille: Squashed 'src/secp256k1/' changes from 8225239..84973d3...
 41 2017-06-02 08:59:41	0|bitcoin-git|13bitcoin/06master 1400d3692 15Wladimir J. van der Laan: Merge #10323: Update to latest libsecp256k1 master...
 42 2017-06-02 09:00:06	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10323: Update to latest libsecp256k1 master (06master...06secp_up) 02https://github.com/bitcoin/bitcoin/pull/10323
 43 2017-06-02 09:36:02	0|bitcoin-git|13bitcoin/06master 14930deb9 15John Newbery: [tests] skipped tests should clean up after themselves
 44 2017-06-02 09:36:02	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/00d369239612...1aefc94dd78d
 45 2017-06-02 09:36:03	0|bitcoin-git|13bitcoin/06master 141aefc94 15MarcoFalke: Merge #10423: [tests] skipped tests should clean up after themselves...
 46 2017-06-02 09:36:34	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #10423: [tests] skipped tests should clean up after themselves (06master...06cleanup_skipped) 02https://github.com/bitcoin/bitcoin/pull/10423
 47 2017-06-02 10:13:28	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/1aefc94dd78d...329fc1dce7a1
 48 2017-06-02 10:13:29	0|bitcoin-git|13bitcoin/06master 14a433d8a 15John Newbery: [tests] Update start/stop node functions to be private module functions...
 49 2017-06-02 10:13:29	0|bitcoin-git|13bitcoin/06master 14d8c218f 15John Newbery: [tests] Functional tests call self.start_node(s) and self.stop_node(s)...
 50 2017-06-02 10:13:30	0|bitcoin-git|13bitcoin/06master 1453f6775 15John Newbery: fixup: fix nits
 51 2017-06-02 10:14:00	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #10359: [tests] functional tests should call BitcoinTestFramework start/stop node methods (06master...06test_framework_start_stop_nodes) 02https://github.com/bitcoin/bitcoin/pull/10359
 52 2017-06-02 13:29:52	0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #10508: Run Qt wallet tests on travis (06master...06pr/travqt) 02https://github.com/bitcoin/bitcoin/pull/10508
 53 2017-06-02 13:35:47	0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #10509: Remove xvfb configuration from travis (06master...06pr/rmfb) 02https://github.com/bitcoin/bitcoin/pull/10509
 54 2017-06-02 13:38:22	0|Anduck|https://twitter.com/movrcx/status/870527842789892096
 55 2017-06-02 13:41:18	0|instagibbs|Anduck, I can do the same offer, but only require 499BTC :)
 56 2017-06-02 13:41:58	0|Anduck|apparently this guy is "vouched" by some earlier found 0days. could be bullshit though
 57 2017-06-02 13:42:14	0|Apocalyptic|instagibbs, DoS is a broad term
 58 2017-06-02 13:42:45	0|Lauda|create 300k TXs per day
 59 2017-06-02 13:42:51	0|Lauda|now pay me 498 BTC
 60 2017-06-02 14:50:06	0|kinlo|mja, ge moest u inschrijven, ik ben aant hore of ik wel kan
 61 2017-06-02 14:50:24	0|kinlo|wrong channel :/
 62 2017-06-02 15:26:41	0|jonasschnelli|wumpus: do you intend to directly bump to rc2 or does it make sense to gitian build rc1?
 63 2017-06-02 15:26:52	0|wumpus|I'd prefer to just go on with it
 64 2017-06-02 15:27:18	0|wumpus|I'll just add in the announcement that the version isn't bumped and we'll do that for next rc
 65 2017-06-02 15:28:43	0|jonasschnelli|okay.. fine by me
 66 2017-06-02 15:30:24	0|wumpus|I'd expect something to come up for rc1, and if not, well then we'll do a very short rc2 just to see if the version bump worked
 67 2017-06-02 18:11:05	0|spudowiar|What's the protocol for adding new strings to Bitcoin Core? Do I have to worry about translation or will that be sorted by others?
 68 2017-06-02 18:15:56	0|sipa|spudowiar: don't worry about it
 69 2017-06-02 18:16:10	0|sipa|in the 0.15 release notes there is a string freeze
 70 2017-06-02 18:16:17	0|sipa|eh, release schedule
 71 2017-06-02 18:16:33	0|sipa|after that time, no changes to strings can be made anymore, to give time for translators
 72 2017-06-02 18:17:09	0|spudowiar|Thanks :)
 73 2017-06-02 18:40:07	0|jnewbery|wumpus: please remove #10044 from high priority for review - I'm not actively working on it for now
 74 2017-06-02 18:40:09	0|gribble|https://github.com/bitcoin/bitcoin/issues/10044 | Run functional tests in `make check` by jnewbery · Pull Request #10044 · bitcoin/bitcoin · GitHub
 75 2017-06-02 18:40:22	0|sipa|jnewbery: :(
 76 2017-06-02 18:41:06	0|sipa|jnewbery: done
 77 2017-06-02 18:41:51	0|jnewbery|sipa: do you particularly want it? I didn't sense there was all that much enthusiasm for it
 78 2017-06-02 18:43:11	0|spudowiar|Can I use C++11 std::map::at()?
 79 2017-06-02 18:43:53	0|sipa|spudowiar: yes, but i would advise against relying on exceptions
 80 2017-06-02 18:44:03	0|spudowiar|Why?
 81 2017-06-02 18:45:15	0|sipa|especially in the case of at; you can just use auto it = map.find(key); if (it != map.end()) { ... } else { ... } instead
 82 2017-06-02 18:45:34	0|spudowiar|Ah, I'll do that instead then
 83 2017-06-02 18:45:40	0|spudowiar|Thanks!
 84 2017-06-02 18:46:06	0|sipa|jnewbery: i conceptually like i very much... i think make check should do ~all reasonable checking
 85 2017-06-02 18:46:19	0|sipa|but i understand there are concerns that make the choice of what to run where and when hard
 86 2017-06-02 18:47:12	0|jnewbery|yeah - I couldn't seem to converge with others on what's a sensible choice of what to run
 87 2017-06-02 18:47:55	0|jnewbery|I'll probably pick it up again at some point, but it shouldn't really be in the review priority bucket since there's nothing to review at this point
 88 2017-06-02 18:47:56	0|sipa|perhaps something to bring up as a meeting topic
 89 2017-06-02 18:48:06	0|sipa|agree with removing it from priority review list
 90 2017-06-02 18:59:09	0|spudowiar|Do you have any qualms with executing a command and piping data into it?
 91 2017-06-02 18:59:17	0|spudowiar|Also, are there any examples of this in the Bitcoin Core code?
 92 2017-06-02 19:04:16	0|spudowiar|Before, I was using popen but now I want to clean up this patch in order to submit it
 93 2017-06-02 19:19:39	0|spudowiar|Should I be adding more code using boost? Because I could use boost::process for this
 94 2017-06-02 19:20:04	0|spudowiar|I mean, should I be avoiding using boost?
 95 2017-06-02 21:19:04	0|bitcoin-git|[13bitcoin] 15achow101 opened pull request #10511: [Tests] Include branch coverage info in coverage test (06master...06lcov) 02https://github.com/bitcoin/bitcoin/pull/10511
 96 2017-06-02 22:05:14	0|bitcoin-git|[13bitcoin] 15luke-jr opened pull request #10512: Rework same-chain from abusing DoS banning, to explicit checks (06master...06samechain_rework) 02https://github.com/bitcoin/bitcoin/pull/10512
 97 2017-06-02 22:15:19	0|bitcoin-git|[13bitcoin] 15ABISprotocol opened pull request #10513: Trivial: grammar fix to CONTRIBUTING.md (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/10513
 98 2017-06-02 22:32:05	0|spudowiar|gmaxwell: Is JSON alright for serializing data for hardware wallet support? I think it'll be easier for the external tools than normal Bitcoin serialization
 99 2017-06-02 22:36:41	0|gmaxwell|spudowiar: almost certantly not, needing megabytes of ram to buffer such a thing require several extra dollars in parts.
100 2017-06-02 22:36:59	0|spudowiar|No, not on the actual hardware wallet
101 2017-06-02 22:37:09	0|gmaxwell|spudowiar: existing hardware wallets go through serious work to avoid even having to buffer a single transaction, much less a json encoded one.
102 2017-06-02 22:37:09	0|spudowiar|For the vendor specific tools
103 2017-06-02 22:37:37	0|gmaxwell|uh? perhaps but you have to be able to handle the bitcoin seralization in order to compute any hashes over it.
104 2017-06-02 22:37:54	0|spudowiar|No, because most hardware wallets serialize it themselves
105 2017-06-02 22:38:33	0|spudowiar|Although I have a very complete understanding of Trezor and a very limited ones of others
106 2017-06-02 22:39:03	0|spudowiar|Btw, didn't jonasschnelli's hardware wallet used to use JSON :)
107 2017-06-02 22:39:32	0|spudowiar|Anyway, I was using Protocol Buffers in my PoC but I knew I couldn't submit that because you'd probably kill me ;)
108 2017-06-02 22:41:05	0|spudowiar|Basically my patch takes an argument -hardwarewallet=<cmd>
109 2017-06-02 22:41:48	0|spudowiar|When you spend with the wallet, it executes the command, pipes in the transaction (in Protocol Buffers at the moment) and the command returns the serialized transaction
110 2017-06-02 22:41:55	0|spudowiar|Then Bitcoin Core verifies that
111 2017-06-02 22:42:28	0|spudowiar|If there's an error, it returns a non-zero status and the message on stdin is used as the failure message in Bitcoin Core
112 2017-06-02 22:44:18	0|gmaxwell|I don't see why you wouldn't use the ordinary serialization plus metadata, _any_ hardware wallet needs to be able to handle the serialization of transactions. Plus how would you proprose to handle things like coinjoins and partially signed multsigs?
113 2017-06-02 22:44:20	0|spudowiar|I don't have bitcoind as one, but I have a script that talks to a bitcoind over RPC
114 2017-06-02 22:44:51	0|spudowiar|gmaxwell: Hardware wallets don't deserialize the transactions, they always accept it in a different format
115 2017-06-02 22:45:10	0|spudowiar|JSON is so much easier because, otherwise, each tool has to deserialize the transaction
116 2017-06-02 22:45:55	0|spudowiar|Partially signed multisig, on a TREZOR, is done totally differently to a P2PKH
117 2017-06-02 22:47:00	0|spudowiar|luke-jr: ln -s bitcoind bitcoind-hardwarewallet and do an argv check :)
118 2017-06-02 22:47:44	0|gmaxwell|spudowiar: of course they do, e.g. to pass them the inputs for value checking you must pass them the input transactions exactly.
119 2017-06-02 22:48:26	0|spudowiar|Oh, yeah. But they don't deserialize the to-be-signed transaction
120 2017-06-02 22:50:58	0|sipa|then how do they compute the sighash?
121 2017-06-02 22:51:14	0|spudowiar|They serialize it from their own format
122 2017-06-02 22:51:22	0|spudowiar|e.g. TREZOR uses Protocol Buffers
123 2017-06-02 22:52:24	0|luke-jr|spudowiar: i was thinking more of using JSON-RPC over stdio
124 2017-06-02 22:52:48	0|spudowiar|That's an interesting idea
125 2017-06-02 22:53:20	0|spudowiar|Because a hardware wallet could ask for transactions when it needs them, etc.
126 2017-06-02 22:54:02	0|spudowiar|Anyway, should I be adding more uses of boost? Was thinking of using boost::process
127 2017-06-02 22:54:16	0|spudowiar|In my PoC I used popen and pclose but that's not very C++-esque
128 2017-06-02 22:56:06	0|gmaxwell|it just seems like a total waste of time and effort to define a whole new seralization which has to be completely compatible and able to encode everything a transaction can encode.
129 2017-06-02 22:56:10	0|gmaxwell|Whats the purpose?
130 2017-06-02 22:56:44	0|luke-jr|gmaxwell: HW wallet vendor provides a plugin for Core
131 2017-06-02 22:56:51	0|spudowiar|But then each script has to deserialize the transaction which seems like a total waste of time ;)
132 2017-06-02 22:59:37	0|gmaxwell|spudowiar: that isn't escape by using a _different_ seralization.
133 2017-06-02 23:00:21	0|spudowiar|Python, for example, has built-in JSON support
134 2017-06-02 23:02:19	0|spudowiar|JSON-RPC over stdio seems like a neat idea though
135 2017-06-02 23:06:05	0|spudowiar|gmaxwell: What about using the format for decoderawtransaction (possibly with a bit more metadata, if needed)
136 2017-06-02 23:07:28	0|sipa|whatever you do, please don't try to represent multisig as multiple addresses :)
137 2017-06-02 23:11:02	0|bitcoin-git|13bitcoin/06master 14b9b814a 15Russell Yanofsky: Avoid CWalletTx copies in GetAddressBalances and GetAddressGroupings
138 2017-06-02 23:11:02	0|bitcoin-git|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/329fc1dce7a1...098b01dc58ff
139 2017-06-02 23:11:03	0|bitcoin-git|13bitcoin/06master 14098b01d 15Pieter Wuille: Merge #10500: Avoid CWalletTx copies in GetAddressBalances and GetAddressGroupings...
140 2017-06-02 23:11:34	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #10500: Avoid CWalletTx copies in GetAddressBalances and GetAddressGroupings (06master...06pr/wtxcopy) 02https://github.com/bitcoin/bitcoin/pull/10500
141 2017-06-02 23:12:00	0|luke-jr|hm, 0.14.2 seems to have missed some fixes still :x
142 2017-06-02 23:12:39	0|gmaxwell|spudowiar: but you can't do anything with bitcoin transactions without also having bitcoin transaction ser/des support!  and then you have to worry about that your json format cannot losslessly represent a transaction.  Decoderawtransaction cannot. E.g. it can't encoding different choices for encoding in varints.
143 2017-06-02 23:13:40	0|luke-jr|gmaxwell: the other end would translate the JSON into some hardware interface; the hardware wallet itself does the serialisation
144 2017-06-02 23:13:51	0|luke-jr|ie, there's a middle-man who has no need to understand ser/des
145 2017-06-02 23:14:09	0|spudowiar|^^
146 2017-06-02 23:16:58	0|aj|gmaxwell: (post-segwit you don't want the serialised input tx, you just want the txid, value and some signing key id, no?)
147 2017-06-02 23:17:15	0|luke-jr|spudowiar: note that using JSON-RPC means bitcoind will call signrawtransaction, and you'll have to deserialise (or pass as-is?)
148 2017-06-02 23:17:15	0|sipa|yes
149 2017-06-02 23:18:39	0|spudowiar|What do you mean? I was thinking of sending the current transaction then the hardware wallet could ask for input transactions (and the script would use JSON RPC to grab them)
150 2017-06-02 23:20:19	0|gmaxwell|aj: not for the inputs, but you still want the whole transaction itself.
151 2017-06-02 23:21:41	0|gmaxwell|aj: I think it would be fairly hard and at least wasteful to define a whole new serialization that is a guarenteed superset of the transaction format.  I think spudowiar is thinking that you can just say {pay inputs x,y,z to destination a,b,c}  but that doesn't work if the hw wallet isn't the author of the whole transaction.
152 2017-06-02 23:23:23	0|spudowiar|gmaxwell: that is literally what all hardware wallets do right now
153 2017-06-02 23:23:47	0|spudowiar|Even for multisig, they don't accept a serialized transaction
154 2017-06-02 23:24:18	0|arubi|(this is why I was requesting raw sighash support :) )
155 2017-06-02 23:24:24	0|aj|gmaxwell: yeah, i think i agree; i think you just want to send the serialised partially-filled out tx you want to create/sign, and extra info needed to do the signature (txids, tx values, pre-segwit-serialised-input-txes, SIGHASH params, etc)?
156 2017-06-02 23:24:37	0|gmaxwell|spudowiar: that isn't true; ledger takes seralized transactions.
157 2017-06-02 23:24:51	0|gmaxwell|aj: yes, thats my thinking.
158 2017-06-02 23:24:52	0|spudowiar|Oh, does it? I didn't know
159 2017-06-02 23:41:03	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #10514: Bugfix: missing == 0 after randrange (06master...06fixtests) 02https://github.com/bitcoin/bitcoin/pull/10514
160 2017-06-02 23:42:18	0|spudowiar|I wonder if it's a good to switch from Google's Protocol Buffers implementation to nanopb
161 2017-06-02 23:42:37	0|spudowiar|Google's Protocol Buffers code generator generates an utter mess
162 2017-06-02 23:42:53	0|spudowiar|But nanopb generates some nice code (it's used in TREZOR)
163 2017-06-02 23:43:24	0|spudowiar|s/a good/a good idea/