1 2019-04-13T00:12:08  *** promag has quit IRC
  2 2019-04-13T00:12:19  *** spinza has quit IRC
  3 2019-04-13T00:13:30  *** michagogo has quit IRC
  4 2019-04-13T00:14:17  *** Isthmus has quit IRC
  5 2019-04-13T00:16:35  *** gleb has quit IRC
  6 2019-04-13T00:19:15  *** ccook has quit IRC
  7 2019-04-13T00:22:42  *** Liliaceae has quit IRC
  8 2019-04-13T00:30:58  *** dviola has quit IRC
  9 2019-04-13T00:32:26  *** pierre_rochard has quit IRC
 10 2019-04-13T00:33:13  *** ccook has joined #bitcoin-core-dev
 11 2019-04-13T00:36:19  *** spinza has joined #bitcoin-core-dev
 12 2019-04-13T00:38:05  *** Guest24808 has joined #bitcoin-core-dev
 13 2019-04-13T00:38:48  *** ccook has quit IRC
 14 2019-04-13T00:40:24  *** ccook has joined #bitcoin-core-dev
 15 2019-04-13T00:40:39  *** gleb has joined #bitcoin-core-dev
 16 2019-04-13T00:40:50  *** michagogo has joined #bitcoin-core-dev
 17 2019-04-13T00:44:02  *** Liliaceae has joined #bitcoin-core-dev
 18 2019-04-13T00:49:29  *** Isthmus has joined #bitcoin-core-dev
 19 2019-04-13T00:56:07  <kallewoof> jnewbery: haha, thanks! I really need to learn how to push my own PRs though. I realize it's my own fault, I just don't really know how to do it without sounding demanding.
 20 2019-04-13T01:08:24  *** justanotheruser has joined #bitcoin-core-dev
 21 2019-04-13T01:11:33  *** pinheadmz has quit IRC
 22 2019-04-13T01:35:39  *** millerti has joined #bitcoin-core-dev
 23 2019-04-13T01:42:13  *** captjakk has joined #bitcoin-core-dev
 24 2019-04-13T01:46:35  *** captjakk has quit IRC
 25 2019-04-13T01:50:25  *** captjakk has joined #bitcoin-core-dev
 26 2019-04-13T01:51:19  *** captjakk has joined #bitcoin-core-dev
 27 2019-04-13T01:53:45  *** pinheadmz has joined #bitcoin-core-dev
 28 2019-04-13T02:01:54  *** Randolf has joined #bitcoin-core-dev
 29 2019-04-13T02:10:00  *** pinheadmz has quit IRC
 30 2019-04-13T02:11:33  *** ghost43 has quit IRC
 31 2019-04-13T02:17:00  *** ghost43 has joined #bitcoin-core-dev
 32 2019-04-13T02:35:48  *** scoop has joined #bitcoin-core-dev
 33 2019-04-13T02:41:13  *** ghost43 has quit IRC
 34 2019-04-13T02:41:43  *** riperk has quit IRC
 35 2019-04-13T02:48:44  *** ghost43 has joined #bitcoin-core-dev
 36 2019-04-13T02:51:54  *** spinza has quit IRC
 37 2019-04-13T02:55:56  *** pinheadmz has joined #bitcoin-core-dev
 38 2019-04-13T02:58:13  *** ghost43 has quit IRC
 39 2019-04-13T02:59:31  *** pinheadmz has quit IRC
 40 2019-04-13T03:00:03  *** pinheadmz has joined #bitcoin-core-dev
 41 2019-04-13T03:05:14  *** ghost43 has joined #bitcoin-core-dev
 42 2019-04-13T03:13:30  *** pinheadmz has quit IRC
 43 2019-04-13T03:21:53  *** pinheadmz has joined #bitcoin-core-dev
 44 2019-04-13T03:36:48  *** pinheadmz has quit IRC
 45 2019-04-13T03:43:46  *** Eagle[TM] has joined #bitcoin-core-dev
 46 2019-04-13T03:44:45  *** jonatack has quit IRC
 47 2019-04-13T03:45:50  *** EagleTM has quit IRC
 48 2019-04-13T03:49:31  *** scoop has quit IRC
 49 2019-04-13T03:49:58  *** scoop has joined #bitcoin-core-dev
 50 2019-04-13T03:56:55  *** scoop has quit IRC
 51 2019-04-13T04:00:22  *** pinheadmz has joined #bitcoin-core-dev
 52 2019-04-13T04:03:23  *** ghost43 has quit IRC
 53 2019-04-13T04:11:27  *** ghost43 has joined #bitcoin-core-dev
 54 2019-04-13T04:17:31  *** scoop has joined #bitcoin-core-dev
 55 2019-04-13T04:20:15  *** pinheadmz has quit IRC
 56 2019-04-13T04:26:03  *** ghost43 has quit IRC
 57 2019-04-13T04:29:26  *** teardown has joined #bitcoin-core-dev
 58 2019-04-13T04:35:35  *** ghost43 has joined #bitcoin-core-dev
 59 2019-04-13T04:37:28  *** riperk has joined #bitcoin-core-dev
 60 2019-04-13T05:21:54  *** harrymm has quit IRC
 61 2019-04-13T05:34:52  *** harrymm has joined #bitcoin-core-dev
 62 2019-04-13T05:39:11  <fanquake> Have thrown some numbers up into #15751, the speedup is so significant it might be worth putting into 0.18 given another rc.
 63 2019-04-13T05:39:12  <gribble> https://github.com/bitcoin/bitcoin/issues/15751 | Speed up deriveaddresses for large ranges by sipa · Pull Request #15751 · bitcoin/bitcoin · GitHub
 64 2019-04-13T05:40:16  <gwillen> fanquake: it's worth noting that this never comes up unless you do something stupid
 65 2019-04-13T05:40:23  <gwillen> I triggered it by putting in 10k for the lulz, basically
 66 2019-04-13T05:40:30  <gwillen> I'm not aware of anybody ever running into this in actual use
 67 2019-04-13T05:41:55  <fanquake> gwillen no generating 1'000'000s of addrs then o.0
 68 2019-04-13T05:43:48  <gwillen> oh, my bad, I actually ran into _importmulti_ being slow with a huge range, and I am thinking of #15741, which is a different PR
 69 2019-04-13T05:43:50  <gribble> https://github.com/bitcoin/bitcoin/issues/15741 | Batch write imported stuff in importmulti by achow101 · Pull Request #15741 · bitcoin/bitcoin · GitHub
 70 2019-04-13T05:48:18  <gmaxwell> 10,000 isn't absurd in any case... esp since it doesn't auto expand as addresses are used.
 71 2019-04-13T05:51:19  <gwillen> yeah that's fair
 72 2019-04-13T05:51:38  <gwillen> that's sort of why I hit 10k in the first place (the fact that importmulti will give me a static pool and that's it)
 73 2019-04-13T05:51:58  <gwillen> of course real descriptor wallets will obviate all of this in the Glorius Future
 74 2019-04-13T06:49:25  *** ghost43 has quit IRC
 75 2019-04-13T06:55:13  *** ghost43 has joined #bitcoin-core-dev
 76 2019-04-13T06:55:19  <fanquake> The node used to generate those numbers has finally finished shutting down after a 2hr 3m wait.
 77 2019-04-13T07:08:18  *** DeanGuss has joined #bitcoin-core-dev
 78 2019-04-13T07:09:08  <gwillen> heh!
 79 2019-04-13T07:10:38  *** pinheadmz has joined #bitcoin-core-dev
 80 2019-04-13T07:17:23  *** scoop has quit IRC
 81 2019-04-13T07:43:57  *** Liliaceae has quit IRC
 82 2019-04-13T07:43:58  *** RubenSomsen has quit IRC
 83 2019-04-13T07:44:10  *** Liliaceae has joined #bitcoin-core-dev
 84 2019-04-13T07:44:13  *** RubenSomsen has joined #bitcoin-core-dev
 85 2019-04-13T07:44:30  *** michagogo has quit IRC
 86 2019-04-13T07:44:31  *** jl2012 has quit IRC
 87 2019-04-13T07:44:31  *** moneyball has quit IRC
 88 2019-04-13T07:44:31  *** jamesob has quit IRC
 89 2019-04-13T07:45:03  *** Guest24808 has quit IRC
 90 2019-04-13T07:45:37  *** ccook has quit IRC
 91 2019-04-13T07:45:37  *** Varunram has quit IRC
 92 2019-04-13T07:47:24  *** Varunram has joined #bitcoin-core-dev
 93 2019-04-13T07:47:29  *** michagogo has joined #bitcoin-core-dev
 94 2019-04-13T07:53:44  *** obsrver has joined #bitcoin-core-dev
 95 2019-04-13T07:55:43  *** pinheadmz has quit IRC
 96 2019-04-13T07:58:32  *** ccook has joined #bitcoin-core-dev
 97 2019-04-13T07:58:58  *** moneyball has joined #bitcoin-core-dev
 98 2019-04-13T07:59:02  *** jamesob has joined #bitcoin-core-dev
 99 2019-04-13T07:59:15  *** jl2012 has joined #bitcoin-core-dev
100 2019-04-13T07:59:46  *** Guest24808 has joined #bitcoin-core-dev
101 2019-04-13T08:23:08  *** laptop500 has joined #bitcoin-core-dev
102 2019-04-13T08:51:42  *** riperk has quit IRC
103 2019-04-13T09:11:15  *** laptop500 has quit IRC
104 2019-04-13T09:17:51  *** scoop has joined #bitcoin-core-dev
105 2019-04-13T09:22:22  *** scoop has quit IRC
106 2019-04-13T11:14:27  <gwillen> achow101: can you provide insight into why the Updater and Signer roles in BIP 174 got combined into the single 'walletprocesspsbt' call in Core?
107 2019-04-13T11:15:11  *** ghost43 has quit IRC
108 2019-04-13T11:15:35  <gwillen> it's becoming slightly annoying for some blockstream (Elements) stuff I'm working on, and I am wondering why it wasn't "walletfillpsbt" and "walletsignpsbt" separately
109 2019-04-13T11:15:47  *** AaronvanW has joined #bitcoin-core-dev
110 2019-04-13T11:21:20  *** ghost43 has joined #bitcoin-core-dev
111 2019-04-13T11:59:57  *** ghost43 has quit IRC
112 2019-04-13T12:06:34  *** ghost43 has joined #bitcoin-core-dev
113 2019-04-13T12:34:27  *** Emcy has quit IRC
114 2019-04-13T12:43:07  *** Eagle[TM] has quit IRC
115 2019-04-13T12:49:11  *** jonatack has joined #bitcoin-core-dev
116 2019-04-13T12:50:54  *** rex4539 has joined #bitcoin-core-dev
117 2019-04-13T12:51:25  *** EagleTM has joined #bitcoin-core-dev
118 2019-04-13T12:54:40  *** laptop500 has joined #bitcoin-core-dev
119 2019-04-13T13:22:45  *** jonatack has quit IRC
120 2019-04-13T13:26:05  *** ghost43 has quit IRC
121 2019-04-13T13:27:28  *** ghost43 has joined #bitcoin-core-dev
122 2019-04-13T13:27:48  *** luke-jr has quit IRC
123 2019-04-13T13:32:36  *** luke-jr has joined #bitcoin-core-dev
124 2019-04-13T13:43:07  *** Aaronvan_ has joined #bitcoin-core-dev
125 2019-04-13T13:43:49  *** rex4539 has quit IRC
126 2019-04-13T13:46:12  *** AaronvanW has quit IRC
127 2019-04-13T13:56:33  *** tryphe_ has joined #bitcoin-core-dev
128 2019-04-13T13:58:52  *** tryphe has quit IRC
129 2019-04-13T14:17:23  <harding> If I use sendtoaddress to attempt to pay a bech32 address with a witness version >0, the RPC succeeds (surprising me).  However, the tx isn't added to the mempool and debug.log says "[default wallet] CommitTransaction(): Transaction cannot be broadcast immediately, scriptpubkey (code 64)".  If I try sending the same tx via sendrawtransaction, that fails with the same error code (which I expected).  Is it intentional that
130 2019-04-13T14:17:23  <harding> sendtoaddress returns success despite other commands failing and the transaction not making it to the local node's mempool?  Tested on latest master.
131 2019-04-13T14:26:44  *** Victor_sueca has joined #bitcoin-core-dev
132 2019-04-13T14:26:44  *** ghost43 has quit IRC
133 2019-04-13T14:26:45  *** Victorsueca has quit IRC
134 2019-04-13T14:27:57  *** ghost43 has joined #bitcoin-core-dev
135 2019-04-13T14:30:54  *** promag has joined #bitcoin-core-dev
136 2019-04-13T14:31:17  *** Victor_sueca is now known as Victorsueca
137 2019-04-13T14:35:07  *** promag has quit IRC
138 2019-04-13T14:47:28  *** dviola has joined #bitcoin-core-dev
139 2019-04-13T14:51:00  *** captjakk has quit IRC
140 2019-04-13T14:52:46  *** scoop has joined #bitcoin-core-dev
141 2019-04-13T14:59:23  *** dviola has quit IRC
142 2019-04-13T15:08:52  <sdaftuar> harding: that sounds right to me.  mempool policy rejecting such transactions is intentional; we don't want to start accepting version1 transactions until a future softfork is designed.
143 2019-04-13T15:09:19  <sdaftuar> because the first step to deploying a new softfork is to ensure that policy rules will protect (eg) miners running old software
144 2019-04-13T15:10:01  <sdaftuar> wallet support also makes sense, so that we're not gated on the whole ecosystem upgrading to support sending to new address formats every time new features are deployed in new segwit versions
145 2019-04-13T15:10:11  *** dviola has joined #bitcoin-core-dev
146 2019-04-13T15:11:28  <luke-jr> Miners should never be running old software.
147 2019-04-13T15:12:23  <sdaftuar> luke-jr: fine, users running old software
148 2019-04-13T15:12:49  <sdaftuar> if coordination of software changes were free, this would be much easier
149 2019-04-13T15:14:32  <luke-jr> mempool policies don't strictly need adjustment for non-miners
150 2019-04-13T15:14:41  <luke-jr> I mean, it's nice to have, but I don't think it's essential
151 2019-04-13T15:17:46  <sdaftuar> oh wait, my reasoning is for not being able to spend a v1 output, not for not being able to send to a v1 output
152 2019-04-13T15:20:27  <sdaftuar> the reason not to allow sending to a v1 output is the same i guess as not being able to send to any other anyone can spend output
153 2019-04-13T15:20:30  <sdaftuar> ?
154 2019-04-13T15:20:43  <sdaftuar> which i guess is just footgun protection
155 2019-04-13T15:21:20  <sipa> yeah
156 2019-04-13T15:22:12  <sipa> not being able to spend a v1 output is a script execution rule, designed for upgrada safety
157 2019-04-13T15:22:38  <sipa> i guess there is a separate standardness rule about sending to v1
158 2019-04-13T15:22:49  <harding> Yeah, that's what I assumed.  And testmempoolaccept and sendrawtransaction do prevent me from sending to a witness v1 address; it's just sendtoaddress (and, I'm guessing, sendmany) that succeed as calls unexpectedly.  They add the tx to the wallet, but it doesn't get added to the mempool.
159 2019-04-13T15:24:02  <sipa> that's a surprising inconsistency
160 2019-04-13T15:25:41  <sdaftuar> sipa: i'm surprised you are saying it's surprising -- i thought you wanted it to work that way for the reason i gave above?
161 2019-04-13T15:25:48  <sdaftuar> perhaps i misunderstood the deployment goals
162 2019-04-13T15:31:46  <sipa> sdaftuar: well the not-sending-to-v1-mempool rule should be consistent with the wallet, as they have similar goals
163 2019-04-13T15:32:58  <sipa> i think?
164 2019-04-13T15:33:37  <harding> Third-party software I've investigated (e.g. Electrum) that implement bech32 sending support currently require that the witness version be 0 so that they don't create policy-invalid transactions.
165 2019-04-13T15:33:42  <sdaftuar> sipa: if you put aside the issue that we have no user-friendly way to hand a transaction to someone else except via the p2p network, then i think making the wallet refuse to send creates deployment issues in the future
166 2019-04-13T15:34:07  <sdaftuar> so that when v1 comes out down the road, users will have to p2sh-wrap it in order to use
167 2019-04-13T15:34:19  <sdaftuar> which is sort of terrible?
168 2019-04-13T15:38:08  <sdaftuar> if other software projects are already disabling sending to v1 though, then i guess we're in trouble on that front regardless of what we do
169 2019-04-13T15:38:49  *** promag has joined #bitcoin-core-dev
170 2019-04-13T15:41:23  <sipa> sdaftuar: i'm trying to balance my gut feeling "permitting sendkng to v1 feels like such a footgun!" with the fact that we can't do this for p2sh embedded regardless
171 2019-04-13T15:41:54  <sipa> and there are plenty of other ways to construct an anyonecanspend address
172 2019-04-13T15:41:56  <harding> I take that back; I just re-checked the Electrum code.  It just contains a redundant check that the witness version is 0-16; I remembered that wrongly because it's a redundancy over the reference library code.  Sorry.
173 2019-04-13T15:42:49  <sipa> really the protection ought to be in code that creates addresses rather than the code sending to it
174 2019-04-13T15:43:43  *** promag has quit IRC
175 2019-04-13T15:55:34  *** pinheadmz has joined #bitcoin-core-dev
176 2019-04-13T15:58:35  <achow101> gwillen: to reduce the need to use an excessive number of RPC calls just do to make a transaction. it needed to be less than or equal to the number of step the *rawtransaction RPCs did otherwise people probably wouldn't use them
177 2019-04-13T15:59:21  <achow101> also the logic for updating and signing in core are almost exactly the same.
178 2019-04-13T15:59:48  <achow101> you can have walletprocesspsbt not sign, there's a parameter to set sign to false.
179 2019-04-13T16:15:46  *** atroxes has quit IRC
180 2019-04-13T16:16:16  *** atroxes has joined #bitcoin-core-dev
181 2019-04-13T16:16:19  *** Randolf has quit IRC
182 2019-04-13T16:16:47  <luke-jr> wait, people can't even *send* to unknown witness versions? that seems like a bug and defeats the whole point of Bech32's extensibility in that regard, no?
183 2019-04-13T16:18:13  <luke-jr> sure, it's anyonecanspend for now, but so is a version 0 witness transaction that's simply an OP_TRUE!
184 2019-04-13T16:23:28  *** pinheadmz has quit IRC
185 2019-04-13T16:29:41  <sipa> achow101, gwillen: in fact making it sign but not update would be kind of hard
186 2019-04-13T16:31:32  <harding> luke-jr: yes, that's the case.  https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L62    I don't see any comments about this on the original implementation, https://github.com/bitcoin/bitcoin/pull/11167/files#diff-d22bc3e058f8982972e2eb381a1df668R79
187 2019-04-13T16:32:31  <achow101> luke-jr: it's nonstandard though. we don't allow sending to nonstandard because nonstandard isn't relayed
188 2019-04-13T16:33:22  <sipa> achow101: right, but arguably sending to it should be allowed, and allowing it should help upgrading when v1 is actually introduced
189 2019-04-13T16:33:42  <sipa> spending definitely needs to be nonstandard, but that's an independent check
190 2019-04-13T16:34:11  *** AaronvanW has joined #bitcoin-core-dev
191 2019-04-13T16:37:27  *** Aaronvan_ has quit IRC
192 2019-04-13T16:48:51  *** instagibbs has quit IRC
193 2019-04-13T16:48:51  *** ossifrage has quit IRC
194 2019-04-13T16:48:51  *** thaumavorio has quit IRC
195 2019-04-13T16:48:51  *** Klox has quit IRC
196 2019-04-13T16:48:51  *** a5m0 has quit IRC
197 2019-04-13T16:48:51  *** phantomcircuit has quit IRC
198 2019-04-13T16:48:51  *** niftynei has quit IRC
199 2019-04-13T16:48:51  *** designwish has quit IRC
200 2019-04-13T16:48:51  *** marcinja has quit IRC
201 2019-04-13T16:48:51  *** baldur has quit IRC
202 2019-04-13T16:48:51  *** nehan has quit IRC
203 2019-04-13T16:48:51  *** bitconner has quit IRC
204 2019-04-13T16:48:52  *** nickler has quit IRC
205 2019-04-13T16:48:52  *** treyzania has quit IRC
206 2019-04-13T16:51:39  <luke-jr> yeah, I can't think of any reason not to allow it to be policy-accepted and even mined
207 2019-04-13T16:52:21  <luke-jr> otoh, accepting it into the wallet and policy-rejecting from mempool doesn't seem too terrible either
208 2019-04-13T16:52:32  <luke-jr> it would just sit unconfirmed until some future point where a softfork enables it
209 2019-04-13T16:52:52  <luke-jr> and IIRC the GUI displays a warning about it when you send
210 2019-04-13T16:58:55  *** qrestlove has joined #bitcoin-core-dev
211 2019-04-13T17:00:22  <harding> luke-jr: just tested, there's no warning in the GUI.
212 2019-04-13T17:02:42  <luke-jr> hmm, there used to be a generic one for mempool rejecting it
213 2019-04-13T17:02:51  <harding> luke-jr: just a debug.log entry.  2019-04-13T16:59:27Z [default wallet] CommitTransaction(): Transaction cannot be broadcast immediately, scriptpubkey (code 64)
214 2019-04-13T17:05:59  *** marcinja has joined #bitcoin-core-dev
215 2019-04-13T17:06:00  *** treyzania has joined #bitcoin-core-dev
216 2019-04-13T17:06:01  *** nickler has joined #bitcoin-core-dev
217 2019-04-13T17:06:06  *** phantomcircuit has joined #bitcoin-core-dev
218 2019-04-13T17:06:07  *** bitconner has joined #bitcoin-core-dev
219 2019-04-13T17:06:07  *** nehan has joined #bitcoin-core-dev
220 2019-04-13T17:06:16  *** niftynei has joined #bitcoin-core-dev
221 2019-04-13T17:06:51  *** ossifrage has joined #bitcoin-core-dev
222 2019-04-13T17:07:12  *** Klox has joined #bitcoin-core-dev
223 2019-04-13T17:07:12  *** a5m0 has joined #bitcoin-core-dev
224 2019-04-13T17:07:13  *** instagibbs has joined #bitcoin-core-dev
225 2019-04-13T17:07:15  *** thaumavorio has joined #bitcoin-core-dev
226 2019-04-13T17:11:06  *** designwish has joined #bitcoin-core-dev
227 2019-04-13T17:13:02  <instagibbs> I remember asking for v1+ test in functional suite, guess the only checks that were a createraw/decoderaw round-trip
228 2019-04-13T17:14:35  <luke-jr> this level of hand-holding really belongs in GUI only and not in RPC
229 2019-04-13T17:25:07  *** qrestlove has quit IRC
230 2019-04-13T17:25:47  *** laptop_ has joined #bitcoin-core-dev
231 2019-04-13T17:29:09  *** laptop500 has quit IRC
232 2019-04-13T17:35:07  *** owowo has quit IRC
233 2019-04-13T17:38:17  *** anddam has left #bitcoin-core-dev
234 2019-04-13T17:40:20  *** owowo has joined #bitcoin-core-dev
235 2019-04-13T17:45:51  <sipa> luke-jr: the first question is whether it shohld be relay policy
236 2019-04-13T17:46:31  <harding> I think that, if you want wallets and services to unconditionally accept bech32 addresses even if they use future witness versions, they need to be accepted into the mempool and mined by default.  Otherwise some griefer is going to initiate 0.0001 withdrawals from various services, get their transactions stuck, and then they're going to either refuse to send to bech32 addresses altogether or just >0 witness versions.
237 2019-04-13T17:54:15  *** Emcy has joined #bitcoin-core-dev
238 2019-04-13T17:54:55  *** bitcoin-git has joined #bitcoin-core-dev
239 2019-04-13T17:54:55  <bitcoin-git> [bitcoin] crackercracked opened pull request #15812: not generate coverage report on test failures (master...fix-issue-15648-test-coverage-report) https://github.com/bitcoin/bitcoin/pull/15812
240 2019-04-13T17:54:56  *** bitcoin-git has left #bitcoin-core-dev
241 2019-04-13T18:01:06  *** riperk has joined #bitcoin-core-dev
242 2019-04-13T18:07:58  *** promag has joined #bitcoin-core-dev
243 2019-04-13T18:08:58  *** promag has quit IRC
244 2019-04-13T18:09:14  *** promag has joined #bitcoin-core-dev
245 2019-04-13T18:09:59  *** promag_ has joined #bitcoin-core-dev
246 2019-04-13T18:11:46  *** promag_ has quit IRC
247 2019-04-13T18:24:13  *** esotericnonsense has quit IRC
248 2019-04-13T18:27:06  *** laptop_ has quit IRC
249 2019-04-13T18:27:30  *** laptop_ has joined #bitcoin-core-dev
250 2019-04-13T18:28:25  *** Guyver2 has joined #bitcoin-core-dev
251 2019-04-13T18:31:22  *** AaronvanW has quit IRC
252 2019-04-13T18:43:03  *** scoop has quit IRC
253 2019-04-13T18:46:19  *** scoop has joined #bitcoin-core-dev
254 2019-04-13T18:46:51  <jnewbery> harding: to answer your original question (why does sendtoaddress return success, even if the tx is not added to the mempool?), that was changed here: #9302
255 2019-04-13T18:46:55  <gribble> https://github.com/bitcoin/bitcoin/issues/9302 | Return txid even if ATMP fails for new transaction by sipa · Pull Request #9302 · bitcoin/bitcoin · GitHub
256 2019-04-13T18:47:28  <jnewbery> wallet RPCs that use CommitTransaction() will return true even if AcceptToMemoryPool() fails
257 2019-04-13T18:47:37  <jnewbery> (that also includes GUI sends)
258 2019-04-13T18:48:29  <sipa> i guess we need to distinguish between permanent and temporary failure
259 2019-04-13T18:48:33  <jnewbery> The PR doesn't contain a description/motivation, but I believe the reason is that the transaction exists in the wallet, so the RPC should return the txid so the user can find it
260 2019-04-13T18:50:00  <jnewbery> sipa: yes. It'd be nice if all RPCs returned an object so fields could be added later. In this case a "accepted_to_mempool" boolean would be helpful, for example
261 2019-04-13T18:52:12  *** scoop has quit IRC
262 2019-04-13T18:55:59  *** scoop has joined #bitcoin-core-dev
263 2019-04-13T19:02:17  <harding> jnewbery: thanks.  From the discussion, it looks like the purpose was to allow the wallet to create chains of transactions beyond the default limits and then trickle those into the mempool later as their ancestors got confirmed.  The non-standard witness version error, OTOH, isn't something that's going to resolve itself, so I think the wallet should probably reject what the mempool rejects.  (Distinguishing between temp_fail and
264 2019-04-13T19:02:17  <harding> perm_fail, if not more specific classes, seems like a good idea to me.)
265 2019-04-13T19:04:10  <luke-jr> temp_fail might not be a good fit for future witness versions though
266 2019-04-13T19:04:16  <luke-jr> since it's potentially a long term
267 2019-04-13T19:04:27  <luke-jr> condition
268 2019-04-13T19:04:37  <instagibbs> policy updates usually aren't activated while running the same software, right?
269 2019-04-13T19:04:39  *** AaronvanW has joined #bitcoin-core-dev
270 2019-04-13T19:06:17  <luke-jr> I guess it's a tristate too: "used to be okay, no longer is", "currently okay", "currently not okay, but will be in the future"
271 2019-04-13T19:06:40  *** owowo has quit IRC
272 2019-04-13T19:07:52  <instagibbs> problem is here previously nothing non-sendable had an address to decode
273 2019-04-13T19:09:19  <harding> luke-jr: the main thing being distinguished in this discussion is unconfirmed tx chains longer than 25 (or larger than 100,000 vbytes), which is a temporary issue, versus future segwit versions which is a long-term issue (months, years, maybe never).  You're right that the second category isn't a perm_fail, but a trying_again_later_wont_help_fail.
274 2019-04-13T19:09:40  *** AaronvanW has quit IRC
275 2019-04-13T19:09:44  <harding> probably_wont_help*
276 2019-04-13T19:09:48  <instagibbs> it can also happen with a plain old CreateTransaction making a tx that isn't relay-valid
277 2019-04-13T19:09:51  <sipa> trying_again_with_the_same_software_wont_helo
278 2019-04-13T19:09:51  <instagibbs> ie bug
279 2019-04-13T19:10:05  <sipa> also invalid signature e.g. should fail that way
280 2019-04-13T19:11:13  <instagibbs> s/IsValidDestination/IsValidRelayDestination/ ? :)
281 2019-04-13T19:15:32  *** teardown has quit IRC
282 2019-04-13T19:15:47  *** teardown has joined #bitcoin-core-dev
283 2019-04-13T19:15:55  <sipa> how do i make a proposed meeti g topic?
284 2019-04-13T19:16:03  <instagibbs> moneyball, ^ :D
285 2019-04-13T19:16:55  <harding> sipa: say: moneyball: #proposedmeetingtopic <topic>
286 2019-04-13T19:17:40  *** AaronvanW has joined #bitcoin-core-dev
287 2019-04-13T19:18:38  <sipa> moneyball: #proposedmeetingtopic Should send-to-non-v0-witness be standard (spending such outputs is nonstandard independently)
288 2019-04-13T19:20:23  <gmaxwell> thats what I was thinking
289 2019-04-13T19:20:49  *** DeanGuss has quit IRC
290 2019-04-13T19:21:44  *** teardown has quit IRC
291 2019-04-13T19:21:56  *** teardown has joined #bitcoin-core-dev
292 2019-04-13T19:22:00  *** AaronvanW has quit IRC
293 2019-04-13T19:23:29  <jnewbery> moneyball: #proposedmeetingtopic Bitcoin Core design documentation
294 2019-04-13T19:28:12  *** teardown has quit IRC
295 2019-04-13T19:37:53  *** qrestlove has joined #bitcoin-core-dev
296 2019-04-13T19:39:40  *** rex4539 has joined #bitcoin-core-dev
297 2019-04-13T19:45:12  *** qrestlove has quit IRC
298 2019-04-13T19:48:13  <moneyball> updated! https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a
299 2019-04-13T19:58:11  *** AaronvanW has joined #bitcoin-core-dev
300 2019-04-13T20:00:19  *** qrestlove has joined #bitcoin-core-dev
301 2019-04-13T20:02:38  *** AaronvanW has quit IRC
302 2019-04-13T20:04:09  *** qrest has joined #bitcoin-core-dev
303 2019-04-13T20:05:47  *** scoop has quit IRC
304 2019-04-13T20:05:54  *** qrestlove has quit IRC
305 2019-04-13T20:07:31  *** owowo has joined #bitcoin-core-dev
306 2019-04-13T20:10:41  *** ghost43 has quit IRC
307 2019-04-13T20:12:05  *** ghost43 has joined #bitcoin-core-dev
308 2019-04-13T20:13:01  *** scoop has joined #bitcoin-core-dev
309 2019-04-13T20:20:13  *** scoop has quit IRC
310 2019-04-13T20:28:36  *** Aaronvan_ has joined #bitcoin-core-dev
311 2019-04-13T20:31:10  *** scoop has joined #bitcoin-core-dev
312 2019-04-13T20:36:13  *** Guyver2 has quit IRC
313 2019-04-13T20:37:00  *** scoop has quit IRC
314 2019-04-13T20:41:35  *** rex4539 has quit IRC
315 2019-04-13T20:44:01  *** scoop has joined #bitcoin-core-dev
316 2019-04-13T20:47:20  *** scoop has quit IRC
317 2019-04-13T20:49:58  *** scoop has joined #bitcoin-core-dev
318 2019-04-13T21:04:26  *** Aaronvan_ has quit IRC
319 2019-04-13T21:11:25  *** DeanGuss has joined #bitcoin-core-dev
320 2019-04-13T21:19:19  *** AaronvanW has joined #bitcoin-core-dev
321 2019-04-13T21:24:02  *** AaronvanW has quit IRC
322 2019-04-13T21:48:21  *** obsrver has quit IRC
323 2019-04-13T21:54:57  *** sipa has quit IRC
324 2019-04-13T22:01:47  *** sipa has joined #bitcoin-core-dev
325 2019-04-13T22:14:56  *** promag_ has joined #bitcoin-core-dev
326 2019-04-13T22:33:30  *** AaronvanW has joined #bitcoin-core-dev
327 2019-04-13T22:37:44  *** AaronvanW has quit IRC
328 2019-04-13T22:39:45  *** Dean_Guss has joined #bitcoin-core-dev
329 2019-04-13T22:41:25  *** DeanGuss has quit IRC
330 2019-04-13T22:50:29  *** Dean_Guss has quit IRC