1 2017-09-20 01:14:24	0|btcdrak|gmaxwell:  We can try again with the security@ email address. I have limited internet access today so cant do it.
  2 2017-09-20 01:16:27	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #11372: Address encoding cleanup (06master...06201709_addr_cleanup) 02https://github.com/bitcoin/bitcoin/pull/11372
  3 2017-09-20 06:28:12	0|kallewoof|achow101: the approach given in the doc I linked is outdated, then? I could write/update docs, but I'm honestly stumped on how to approach this. E.g. I am supposed to give a signer, but I don't want to shuffle private GPG keys around to let the VM sign using a key it doesn't hold (I am guessing wildly here).
  4 2017-09-20 06:32:47	0|esotericnonsense|kallewoof: there's a section in gitian-building.md that references copying out the assert files?
  5 2017-09-20 06:35:41	0|esotericnonsense|(missed most of the conversation, just guessing here)
  6 2017-09-20 07:07:12	0|kallewoof|esotericnonsense: I don't think I saw that. Will look, thanks!
  7 2017-09-20 07:07:35	0|esotericnonsense|:) right at the bottom
  8 2017-09-20 07:08:14	0|kallewoof|Ahh, yeah, I missed that completely. Thanks
  9 2017-09-20 07:18:50	0|bitcoin-git|[13bitcoin] 15Reagent1981 opened pull request #11374: 0.15 (06master...060.15) 02https://github.com/bitcoin/bitcoin/pull/11374
 10 2017-09-20 07:19:23	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #11374: 0.15 (06master...060.15) 02https://github.com/bitcoin/bitcoin/pull/11374
 11 2017-09-20 08:49:46	0|kallewoof|Reading the OP_RETURNTRUE discussion on bitcoin-dev it struck me that if we bump segwit script version at some point, old nodes will all accept the tx without looking, and new nodes will use the new script to verify. A miner running old version could mine txs with invalid scripts and old nodes would accept this block while new nodes would not. This would become a hardfork, no?
 12 2017-09-20 08:51:08	0|kallewoof|Wait, no, it would become a softfork. *headscratch*
 13 2017-09-20 08:51:47	0|kallewoof|I'm confused about Johnson Lau's statement "If we use a softfork to transform OP_RETURNTRUE into OP_17 (pushing the number 17 to the stack), new nodes will collect the (pubkey, message) pair and try to aggregate with other pairs. This becomes a hardfork.
 14 2017-09-20 08:51:52	0|kallewoof|"
 15 2017-09-20 08:53:20	0|kallewoof|Old nodes all accept, new nodes do more. It should be a softfork, no?
 16 2017-09-20 10:08:19	0|luke-jr|kallewoof: he's talking about after some hypothetical signature aggregation scheme
 17 2017-09-20 10:08:24	0|luke-jr|I'm not convinced it's a real blocker
 18 2017-09-20 10:09:14	0|luke-jr|just an additional consideration that needs to be made when such aggregation is introduced
 19 2017-09-20 11:21:54	0|Guest81071|can i get any  useful ideas to implement to develop bitcoin
 20 2017-09-20 11:24:17	0|Guest81071|how can i develop or contribute to bitcoin
 21 2017-09-20 11:36:05	0|StopAndDecrypt_|Guest81071
 22 2017-09-20 11:36:15	0|StopAndDecrypt_|http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html
 23 2017-09-20 11:36:23	0|StopAndDecrypt_|http://codesuppository.blogspot.com/2014/01/how-to-parse-bitcoin-blockchain.html
 24 2017-09-20 11:38:51	0|StopAndDecrypt_|http://www.samlewis.me/2017/06/a-peek-under-bitcoins-hood/
 25 2017-09-20 11:58:19	0|vicenteH|I use addwitnessaddress command to generate a segwit address. To save/restore in cold storage that segwit address should I dump private key from original address, then import that private key, get the original address and execute addwitnessaddress again?
 26 2017-09-20 12:01:24	0|Guest81071|what is the scope of devoloping the applications using bit coins
 27 2017-09-20 12:01:55	0|Guest81071|what applications can be developed
 28 2017-09-20 13:00:18	0|meshcollider|Guest81071: try asking in #bitcoin - this chat is only for discussion on bitcoin core development not general development
 29 2017-09-20 13:03:01	0|meshcollider|vicenteH: yeah I believe so, at least until proper segwit support in wallets is added in 0.15.1
 30 2017-09-20 13:08:58	0|vicenteH|meshcollider: thank you
 31 2017-09-20 14:06:43	0|promag|jnewbery: thanks for #11370, udpated
 32 2017-09-20 14:06:44	0|gribble|https://github.com/bitcoin/bitcoin/issues/11370 | [test] Add getblockchaininfo functional test by promag · Pull Request #11370 · bitcoin/bitcoin · GitHub
 33 2017-09-20 14:42:03	0|promag|jnewbery: is 10740 ready for review?
 34 2017-09-20 14:42:12	0|promag|#10740
 35 2017-09-20 14:42:14	0|gribble|https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
 36 2017-09-20 14:42:59	0|esotericnonsense|#11366 updated
 37 2017-09-20 14:43:01	0|gribble|https://github.com/bitcoin/bitcoin/issues/11366 | [rpc] Fix pruneheight help description in getblockchaininfo by esotericnonsense · Pull Request #11366 · bitcoin/bitcoin · GitHub
 38 2017-09-20 14:50:21	0|jnewbery|promag : just waiting for Travis to complete. There was a bad automatic rebase before. If Travis passes, then I'd definitely appreciate some review at this stage
 39 2017-09-20 15:06:01	0|bitcoin-git|[13bitcoin] 15esotericnonsense closed pull request #11366: [rpc] Fix pruneheight help description in getblockchaininfo (06master...062017-09-getblockchaininfo-docs) 02https://github.com/bitcoin/bitcoin/pull/11366
 40 2017-09-20 15:06:20	0|esotericnonsense|(put the changes in #11367 as it's pretty small).
 41 2017-09-20 15:06:22	0|gribble|https://github.com/bitcoin/bitcoin/issues/11367 | [rpc] getblockchaininfo: add size_on_disk, prune_target_size by esotericnonsense · Pull Request #11367 · bitcoin/bitcoin · GitHub
 42 2017-09-20 15:09:39	0|esotericnonsense|sorry about the repeated pushes, should be done now, missed your style adjustment on while {} promag.
 43 2017-09-20 15:40:35	0|BlueMatt|https://github.com/bitcoin/bitcoin/issues/11373 should just be closed with "Your filesystem permissions have been set to prevent bitcoind from accessing its datadir, which prevents it from starting" (unless someone wants to change it to a "we need a better error message for this bug" issue)
 44 2017-09-20 16:00:40	0|promag|jnewbery: do you think there should be a PR to replace start+stop with restart_node? or you see an incremental change instead?
 45 2017-09-20 16:32:18	0|bitcoin-git|13bitcoin/06master 14e53fa4a 15Andrew Chow: Remove custom fee radio group...
 46 2017-09-20 16:32:18	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/4f7e37e26c5d...44313d82508b
 47 2017-09-20 16:32:19	0|bitcoin-git|13bitcoin/06master 1444313d8 15Wladimir J. van der Laan: Merge #11334: qt: Remove custom fee radio group and remove nCustomFeeRadio setting...
 48 2017-09-20 16:32:58	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11334: qt: Remove custom fee radio group and remove nCustomFeeRadio setting (06master...06rm-nCustomFeeRadio) 02https://github.com/bitcoin/bitcoin/pull/11334
 49 2017-09-20 16:47:29	0|wumpus|BlueMatt: boost::filesystem::create_directory: Permission denied: "/home/user/.bitcoin"     seems clear enough to me
 50 2017-09-20 16:48:59	0|jnewbery|promag: I think it's fine for that to be included in your getblockchaininfo PR
 51 2017-09-20 16:52:16	0|jnewbery|Also, #10740 passes travis after manual rebase fixed the test issue. Ready for initial review
 52 2017-09-20 16:52:18	0|gribble|https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
 53 2017-09-20 16:53:23	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/44313d82508b...28474802758a
 54 2017-09-20 16:53:24	0|bitcoin-git|13bitcoin/06master 14fa2c3b6 15MarcoFalke: doc: Bump manpages to 0.15.99
 55 2017-09-20 16:53:24	0|bitcoin-git|13bitcoin/06master 14fa65dcd 15MarcoFalke: doc: Update release notes for 0.16.0
 56 2017-09-20 16:53:25	0|bitcoin-git|13bitcoin/06master 142847480 15Wladimir J. van der Laan: Merge #11305: [doc] Update release notes and manpages for 0.16...
 57 2017-09-20 16:53:57	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11305: [doc] Update release notes and manpages for 0.16 (06master...06Mf1709-doc016) 02https://github.com/bitcoin/bitcoin/pull/11305
 58 2017-09-20 17:08:11	0|bitcoin-git|13bitcoin/06master 14fdc3293 15practicalswift: Document assumptions that are being made to avoid NULL pointer dereferences
 59 2017-09-20 17:08:11	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/28474802758a...551d7bf604fb
 60 2017-09-20 17:08:12	0|bitcoin-git|13bitcoin/06master 14551d7bf 15Wladimir J. van der Laan: Merge #11132: Document assumptions that are being made to avoid NULL pointer dereferences...
 61 2017-09-20 17:08:41	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11132: Document assumptions that are being made to avoid NULL pointer dereferences (06master...06document-non-nullptr-assumptions) 02https://github.com/bitcoin/bitcoin/pull/11132
 62 2017-09-20 17:42:35	0|ThomasV|is it true that core will let users reuse the same private key in p2pkh, p2wpkh and p2wpkh-in-p2sh ?
 63 2017-09-20 17:42:44	0|ThomasV|sipa: ^
 64 2017-09-20 17:42:47	0|chainhead|if they use addwitnessaddress
 65 2017-09-20 17:47:50	0|jl2012|if it is compressed key, and with addwitnessaddress
 66 2017-09-20 17:50:46	0|sipa|ThomasV: for now, yes, we have no choice
 67 2017-09-20 17:50:57	0|ThomasV|no choice??
 68 2017-09-20 17:51:08	0|sipa|that's how addwitnessafdress already works
 69 2017-09-20 17:51:27	0|ThomasV|sipa: if you release that, you will have to keep supporting that forever
 70 2017-09-20 17:51:44	0|sipa|ThomasV: addwitnessaddress has existed since 0.13.0
 71 2017-09-20 17:51:48	0|ThomasV|because users will expect to see their coins when they import an address
 72 2017-09-20 17:52:30	0|ThomasV|do you plan to do something about that?
 73 2017-09-20 17:52:43	0|sipa|in a future version we plan to redesign the logoc for determining which addresses are ours, and have split chain for each type of address
 74 2017-09-20 17:53:14	0|sipa|and perhaps deprecate importprivkey in favor of importmulti (which requires passing all relevant information)
 75 2017-09-20 17:53:50	0|aashu|join
 76 2017-09-20 17:54:26	0|sipa|i agree it's a bad situation that we accept payments to addresses we didn't create, but it's a too invasive change to make in a minor release
 77 2017-09-20 17:55:08	0|sipa|it's an issue that has existed for a long time too (for example, core also accepts payments to pay to pubkeys for corresponding keys of addresses that were created)
 78 2017-09-20 17:56:53	0|ThomasV|well, p2pk is a bit different, because you do not create a bitcoin address for it
 79 2017-09-20 17:57:23	0|ghost43|so then if a user somehow exports a private key from Core, and tries to import that in another software, what should that other software do with it? try to convert that to all types of outputs?
 80 2017-09-20 17:57:49	0|ThomasV|ghost43: that's what I want to avoid
 81 2017-09-20 17:58:08	0|ThomasV|that would encourage key reuse
 82 2017-09-20 17:58:34	0|sipa|internally, the ismine logic basically decides what is our based on the ability to sign... which is a mistake, but rewriting that code replacing it with something sane will take time
 83 2017-09-20 17:58:44	0|sipa|ThomasV: i understand
 84 2017-09-20 18:01:10	0|sipa|ghost43: i don't think you should associate any type of output with a key... a key is just a key and not an address
 85 2017-09-20 18:01:17	0|sipa|but that's not how things work now
 86 2017-09-20 18:02:10	0|ThomasV|sipa: a key is just a key, but the serialization of a key is not just a key
 87 2017-09-20 18:02:42	0|ThomasV|it has a byte that disambiguates compressed/uncompressed
 88 2017-09-20 18:02:51	0|ThomasV|and that's a good thing
 89 2017-09-20 18:03:00	0|ThomasV|we really need to extend that
 90 2017-09-20 18:03:04	0|sipa|i disagree
 91 2017-09-20 18:03:17	0|goatpig|maybe it's time to agree on a set of identifiers for common script types
 92 2017-09-20 18:03:32	0|sipa|if you want to import an address, give the address; if you want to spend from it, give its associated key
 93 2017-09-20 18:03:57	0|sipa|i think it's unmaintainable to keep implying the address from just the key
 94 2017-09-20 18:04:41	0|goatpig|not as a requirement, but just allow those wallets who want to to forward that information in a standardized fashion?
 95 2017-09-20 18:04:52	0|sipa|give the address + privkey?
 96 2017-09-20 18:05:08	0|sipa|importing addresses doesn't sound like something a normal user would do frequently
 97 2017-09-20 18:05:19	0|goatpig|no they usually import the privkey
 98 2017-09-20 18:05:27	0|ghost43|give the full scriptPubKey + the private key, haha
 99 2017-09-20 18:05:43	0|goatpig|expect the software they using it with to know which scripts to look for on chain
100 2017-09-20 18:06:00	0|goatpig|cant tell if this is just pebkac and should be ignored, or if there is a need to cover this case
101 2017-09-20 18:06:03	0|goatpig|but it exists alright
102 2017-09-20 18:06:20	0|sipa|i expect the same issue does exist at least for importing hd chains, though
103 2017-09-20 18:06:27	0|goatpig|now it does
104 2017-09-20 18:06:33	0|goatpig|before, not necessarely
105 2017-09-20 18:06:33	0|ThomasV|sipa: that's interesting. why dont you post that in the ML?
106 2017-09-20 18:06:40	0|goatpig|if you stick to BIP44, p2pkh is basically implied
107 2017-09-20 18:06:47	0|sipa|ghost43: right
108 2017-09-20 18:06:58	0|sipa|ThomasV: i hate the ml
109 2017-09-20 18:06:59	0|ThomasV|goatpig: please no bip44
110 2017-09-20 18:07:14	0|goatpig|ThomasV: is that a voldermort moment?
111 2017-09-20 18:07:27	0|ThomasV|sipa: if you hate it, why did you answer to my post?
112 2017-09-20 18:07:37	0|sipa|i felt i had to
113 2017-09-20 18:08:03	0|ThomasV|yeah, but you kept the real annsyer until now
114 2017-09-20 18:08:08	0|sipa|hmm?
115 2017-09-20 18:08:21	0|sipa|you're asking my opinion
116 2017-09-20 18:08:21	0|ThomasV|I asked what core plans to do regarding key imports
117 2017-09-20 18:08:30	0|ThomasV|oh come on..
118 2017-09-20 18:08:39	0|sipa|ah, right
119 2017-09-20 18:08:45	0|ThomasV|your opinion counts
120 2017-09-20 18:09:52	0|sipa|let me find the mail
121 2017-09-20 18:10:08	0|ghost43|https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015007.html
122 2017-09-20 18:11:02	0|ThomasV|goatpig: I guess you know what I think of bip44
123 2017-09-20 18:11:17	0|goatpig|oh i do
124 2017-09-20 18:11:26	0|goatpig|i agree with your position on the WIF thing
125 2017-09-20 18:11:29	0|goatpig|extending it would help
126 2017-09-20 18:12:13	0|goatpig|otherwise, id fall back on Lombrozo's BIP124 and flesh that out?
127 2017-09-20 18:12:38	0|ThomasV|goatpig: bip124 is not really specified
128 2017-09-20 18:13:13	0|goatpig|therefor it wont be as resistant to proposals
129 2017-09-20 18:14:33	0|ThomasV|goatpig: I am interested in it too
130 2017-09-20 18:15:07	0|goatpig|i mean the WIF is for single keys
131 2017-09-20 18:15:17	0|goatpig|but at least if we can agree on some stuff for entire chains
132 2017-09-20 18:15:47	0|ThomasV|well, if we had a decent bip124 we could use it for single keys too
133 2017-09-20 18:20:53	0|sipa|ThomasV: thanks for bringing it up. thinking more about it, i think my main issue is that we should start thinking about addresses and keys as orthogonal things (there are some things you consider yours - addresses, and then some things you know how to sign for - keys)... especially with things like hardware wallets, multisig
134 2017-09-20 18:21:08	0|sipa|however, that doesn't mean there can't be a format that encapsulates both
135 2017-09-20 18:21:53	0|sipa|i'll respond on the list
136 2017-09-20 18:21:57	0|ThomasV|well, what is the point of having a serialization format, if it is not to encapsulate ?
137 2017-09-20 18:22:46	0|sipa|ThomasV: well there can be separate formats, i guess
138 2017-09-20 18:23:53	0|ThomasV|sipa: electrum has orthogonal classes for wallets and keystores. a wallet is defined by the type of output script, regardless of how keys are stored
139 2017-09-20 18:24:03	0|sipa|right, sounds great
140 2017-09-20 18:24:45	0|ThomasV|so we can use hardware or software keystores in multisig wallets, with the same wallet class
141 2017-09-20 18:25:39	0|ThomasV|but I believe that what we export and show to users should be encapsulated
142 2017-09-20 18:26:33	0|sipa|right, but you also need a way to export/import a chain or address without revealing the key
143 2017-09-20 18:26:50	0|sipa|for an address that's easy, as it's just an address
144 2017-09-20 18:27:14	0|sipa|though i saw there was talk of including a birthtime too
145 2017-09-20 18:27:14	0|ThomasV|a wallet cannot import an address unless it is a special wallet type
146 2017-09-20 18:27:31	0|sipa|sure
147 2017-09-20 18:27:58	0|sipa|but i'm sure some software will exist that can import arbitrary individual addresses
148 2017-09-20 18:29:04	0|goatpig|and that's fine
149 2017-09-20 18:29:13	0|ThomasV|electrum can do it. my point is that wallet class does not have a keystore
150 2017-09-20 18:29:45	0|ThomasV|there is a wallet class that just means "a set of imported addresses"
151 2017-09-20 18:29:48	0|goatpig|the issue would be importing a private key and failing to find all funds that key can sign for
152 2017-09-20 18:30:10	0|sipa|goatpig: i think it's a terrible idea to treat every output you can sign for as your own
153 2017-09-20 18:30:29	0|ThomasV|there also is a keystore class for imported private keys, but it has nothing to do with imported addresses, and it assumes p2pkh
154 2017-09-20 18:31:11	0|andytoshi|goatpig: taken literally that leads to trivial attacks (e.g. you can sign for a 1-of-2 multisig with me, but that output isn't yours and if you have one you can't consider it as a final payment)
155 2017-09-20 18:31:47	0|sipa|ThomasV: my point is that we should really think about importing something as either an address/chain (something to look for) or as private key (something to sign with) - there can be a convenience method to encode both simultaneously
156 2017-09-20 18:32:05	0|sipa|and i'm not opposed to such a convenience, but i don't have many opinions on it
157 2017-09-20 18:32:52	0|goatpig|sipa: andytoshi: the idea is not for me to support all of these possible script variations, it's to able to tell my user: "my software does not support all of tehse variations, do not use to import from this key"
158 2017-09-20 18:32:53	0|ThomasV|sipa: current wallets allow to import private keys, and they assume p2pkh
159 2017-09-20 18:33:07	0|ThomasV|it is difficult to undo that
160 2017-09-20 18:33:14	0|sipa|ThomasV: we don't need to continue that practice
161 2017-09-20 18:33:35	0|sipa|have a new private key format that does not have any implied address
162 2017-09-20 18:34:22	0|ThomasV|sipa: stop supporting privkey imports in core, and see how users will react :D
163 2017-09-20 18:34:49	0|sipa|ThomasV: i'm not saying we should stop supporting imports
164 2017-09-20 18:34:57	0|ThomasV|sipa: ok, I read you
165 2017-09-20 18:35:06	0|sipa|but the modern way of doing it is using importmulti, where you just give both the address and the private key
166 2017-09-20 18:35:16	0|sipa|(and the import checks that that private indeed can sign for that address)
167 2017-09-20 18:35:55	0|sipa|and if it's P2SH it also requires giving the relevant redeemscript
168 2017-09-20 18:35:58	0|goatpig|sipa: that could turn into a GUI nightmare, just saying
169 2017-09-20 18:36:34	0|sipa|goatpig: perhaps
170 2017-09-20 18:36:47	0|goatpig|well between expecting that much info from the user
171 2017-09-20 18:37:03	0|goatpig|or agreeing to a header byte that refer to a table telling you how to derive the script hash
172 2017-09-20 18:37:09	0|goatpig|obviously i'd pick the easy way out
173 2017-09-20 18:37:44	0|sipa|as said, i'm not opposed to a convenience method to encode all of it
174 2017-09-20 18:38:08	0|ThomasV|sipa: what do you think of bip124?
175 2017-09-20 18:38:10	0|goatpig|i believe that's what we're hinting towards
176 2017-09-20 18:38:15	0|sipa|ThomasV: i haven't looked at it
177 2017-09-20 18:38:24	0|goatpig|it's a bit lean atm
178 2017-09-20 18:39:13	0|ThomasV|goatpig: all it needs is a way to extend script with variables
179 2017-09-20 18:39:15	0|sipa|so for example an issue i see is CLTV/CSV
180 2017-09-20 18:39:37	0|sipa|i expect people at some point will want a standard way of using these in scripts]
181 2017-09-20 18:40:07	0|sipa|an "address import" for one of those will need to include the locktime/sequence requirement number, or you can't derive the scriptPubKey
182 2017-09-20 18:40:14	0|ThomasV|right
183 2017-09-20 18:40:35	0|sipa|an approach that just requires you to pass the full scriptPubKey you're looking for is an elegant, but not perfectly convenient, method
184 2017-09-20 18:41:06	0|sipa|but as a 'raw' export/import function, i think that's totally acceptable
185 2017-09-20 18:42:05	0|goatpig|for cltv you could imply the position on the address chain is the cltv member
186 2017-09-20 18:42:12	0|goatpig|for csv idk if you can sneak around like that
187 2017-09-20 18:43:42	0|sipa|yuck.
188 2017-09-20 18:43:48	0|goatpig|aww
189 2017-09-20 18:44:01	0|sipa|cltv can have a locktime in seconds
190 2017-09-20 18:44:18	0|goatpig|i was thinking on the block count after confirmation variant only
191 2017-09-20 18:44:52	0|ThomasV|sipa: you mean the full script, not its hash?
192 2017-09-20 18:45:42	0|goatpig|sipa: you have to think of backups as well as imports in the case of cltv/csv
193 2017-09-20 18:45:55	0|goatpig|the least user inputed data, the better
194 2017-09-20 18:45:55	0|sipa|ThomasV: yes, that's what importmulti requires
195 2017-09-20 18:46:20	0|sipa|goatpig: well at least everything expect the private keys is much less sensitive
196 2017-09-20 18:46:45	0|sipa|but yes, you're right, that's an issue
197 2017-09-20 18:46:55	0|adiabat|it may also make sense to standardize on an importable utxo format, with optional privatekey field
198 2017-09-20 18:47:12	0|adiabat|I use this in my lightning software between wallet / lightning layer
199 2017-09-20 18:47:51	0|adiabat|could enable imports without rescanning or anything
200 2017-09-20 18:48:01	0|ThomasV|sipa: ok, so Iguess the issue is to find a good serialization for what importmulti needs
201 2017-09-20 18:48:22	0|sipa|ThomasV: for a subset, at least...
202 2017-09-20 18:49:11	0|sipa|unfortunately the checksum properties in bech32 degrade when there are more than 89 characters
203 2017-09-20 18:49:42	0|sipa|ThomasV: did you see my comment on your only-v0-witness commit?
204 2017-09-20 18:49:49	0|goatpig|use several lines, have a counter in each line
205 2017-09-20 18:49:52	0|ThomasV|sipa: yes I saw it
206 2017-09-20 18:50:19	0|sipa|goatpig: yuck :)
207 2017-09-20 18:50:28	0|goatpig|so mean!
208 2017-09-20 18:50:28	0|ThomasV|sipa: but soft forks are not so common, so I have time to think about it :)
209 2017-09-20 18:50:41	0|sipa|ThomasV: depends on how fast your users upgrafe
210 2017-09-20 18:50:55	0|ThomasV|yeah
211 2017-09-20 18:50:58	0|sipa|we saw with p2sh that it took years before every wallet was able to send to it
212 2017-09-20 18:51:27	0|sipa|i expect that for bip173 it will be less time, but i'd rather  ot have that delay for every softfork
213 2017-09-20 18:51:42	0|ThomasV|I understand
214 2017-09-20 18:51:55	0|ThomasV|will do
215 2017-09-20 18:51:59	0|sipa|thanks!
216 2017-09-20 19:00:11	0|ThomasV|ok, dinner time
217 2017-09-20 19:00:32	0|sipa|ok, lunch time
218 2017-09-20 19:08:03	0|gmaxwell|adiabat: have you seen achow's psbt format?  not what you're suggesting but its relevant. It could perhaps incorporate what you're thinking by gaining extra fields to carry around the private key for an input.
219 2017-09-20 19:58:17	0|adiabat|gmaxwell: saw the post; looks interesting and not quite what I have, but something similar
220 2017-09-20 19:58:30	0|adiabat|github link in that doesn't seem to work though
221 2017-09-20 19:58:42	0|adiabat|(link from the mailing list post I mean)
222 2017-09-20 20:12:30	0|tknp|i might be missing something simple but is there a single rpc call to display the btc value of the items in a vin array using 'getblock'
223 2017-09-20 20:15:37	0|sipa|no
224 2017-09-20 20:15:50	0|sipa|bitcoind doesn't have that information
225 2017-09-20 20:17:21	0|tknp|ok thanks. i'll do some more reading. the value i'm after does look to be in the output of gettxout of the txid of the vin in question
226 2017-09-20 20:17:34	0|goatpig|outpoint value?
227 2017-09-20 20:19:08	0|tknp|oh sorry, i don't mean the monetary value of btc but the 'value' key that relates to the number of bitcoins paid for the output
228 2017-09-20 20:19:59	0|achow101|adiabat: which link?
229 2017-09-20 20:20:22	0|meshcollider|adiabat: that's because it was given a BIP number 174 and moved filename, it's here now: https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki
230 2017-09-20 20:20:23	0|goatpig|yeah, you want the value of the outpoint the txin is pointing at
231 2017-09-20 20:20:39	0|goatpig|i dont think the RPC let's you request outpoints at all
232 2017-09-20 20:21:05	0|goatpig|well i guess the proper term is resolving the outpoint
233 2017-09-20 20:22:06	0|tknp|goatpid correct. was hoping to not have to make a secondary rpc call for each tx input with the proper vout value
234 2017-09-20 20:22:50	0|goatpig|that resolution is expensive, you cant expect a call to get a tx would just go ahead and resolve the outpoints on the off chance the caller might want it
235 2017-09-20 20:23:49	0|tknp|yup, was hoping that there was a convenience method cooked in with the understanding that it was expensive to call. like a hidden valid value for the format param that would do the resolving
236 2017-09-20 20:24:10	0|goatpig|im just guessing here
237 2017-09-20 20:24:20	0|goatpig|but i expect core has the dataset necessary to resolve arbitrary outpoints
238 2017-09-20 20:24:28	0|goatpig|or maybe not
239 2017-09-20 20:24:34	0|goatpig|that's just a guess on my part
240 2017-09-20 20:24:38	0|gmaxwell|Bitcoind doesn't have the information.
241 2017-09-20 20:24:45	0|goatpig|you need to resolve outpoints to verify incoming zero conf tx
242 2017-09-20 20:24:53	0|gmaxwell|Providing it would require an additional quite expensive index, or a sequential scan of the blockchain.
243 2017-09-20 20:24:57	0|sipa|it only has the information about unspent outputs
244 2017-09-20 20:25:04	0|gmaxwell|goatpig: yes but he is asking about getblock.
245 2017-09-20 20:25:05	0|goatpig|but you could do that by just maintaining the utxo set and checking outpoints in zc vs that
246 2017-09-20 20:25:09	0|sipa|which is sufficient for validating new blocks
247 2017-09-20 20:25:13	0|goatpig|well then he should use armory =D
248 2017-09-20 20:25:19	0|goatpig|cause it has a supernode teehee
249 2017-09-20 20:25:38	0|gmaxwell|and was unusably slow and will be again eventually. :P
250 2017-09-20 20:26:02	0|goatpig|=( so mean
251 2017-09-20 20:26:04	0|gmaxwell|haha
252 2017-09-20 20:26:28	0|goatpig|man it;s hard to keep up, i wrote the first supernode in 2013, blockchain is like 7 times as large now
253 2017-09-20 20:26:32	0|gmaxwell|Sorry. Just the point there is that it's not provided not because bitcoind is lazy or something, but because it has a real non-trivial cost.
254 2017-09-20 20:27:03	0|goatpig|yes, just maintaining the dataset to resolve arbirtary tx hashes is expensive
255 2017-09-20 20:27:12	0|tknp|understood and thanks. i'll deal with making separate requests through other means
256 2017-09-20 20:29:07	0|achow101|gmaxwell: isn't txindex like that
257 2017-09-20 20:29:27	0|achow101|an index that can be used to grab arbitrary outpoints
258 2017-09-20 20:30:01	0|sipa|achow101: very inefficiently, yes
259 2017-09-20 20:30:15	0|gmaxwell|does it still even work? :( I stopped using it on all my hosts because its such a slowdown.
260 2017-09-20 20:30:25	0|sipa|(it read the entire block for each output you're looking up)
261 2017-09-20 20:30:26	0|achow101|gmaxwell: I use it on my node, seems to work
262 2017-09-20 20:30:47	0|achow101|but the index itself is 12 GB apparently
263 2017-09-20 20:31:52	0|achow101|syncing a new node with txindex is probably a massive slowdown, but I have had it enabled for several years now so when I synced it wasn't that bad
264 2017-09-20 20:41:11	0|adiabat|I run txindex on mainnet and testnet3, it doesn't slow it down too much
265 2017-09-20 20:41:50	0|adiabat|then again I'm running on spinning disks so it's pretty slow no matter what :P
266 2017-09-20 21:44:14	0|Sentineo|I run txindex on an odroid xu4
267 2017-09-20 21:44:28	0|Sentineo|works fine too, usb stick has the blockchain
268 2017-09-20 21:45:04	0|Sentineo|syncing is a pain in the b, but otherwise kt is fine
269 2017-09-20 22:14:08	0|bitcoin-git|[13bitcoin] 15tomasvdw opened pull request #11376: Ensure backupwallet fails when attempting to backup to source file (06master...06core) 02https://github.com/bitcoin/bitcoin/pull/11376
270 2017-09-20 23:47:23	0|bitcoin-git|13bitcoin/06master 1405cae8a 15Marko Bencun: range-based loops and const qualifications in net.cpp...
271 2017-09-20 23:47:23	0|bitcoin-git|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/551d7bf604fb...98212745c8ac
272 2017-09-20 23:47:24	0|bitcoin-git|13bitcoin/06master 149821274 15Pieter Wuille: Merge #10888: range-based loops and const qualifications in net.cpp...
273 2017-09-20 23:47:53	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #10888: range-based loops and const qualifications in net.cpp (06master...06netcpp_cosmetics2) 02https://github.com/bitcoin/bitcoin/pull/10888