12019-04-13T00:12:08  *** promag has quit IRC
  22019-04-13T00:12:19  *** spinza has quit IRC
  32019-04-13T00:13:30  *** michagogo has quit IRC
  42019-04-13T00:14:17  *** Isthmus has quit IRC
  52019-04-13T00:16:35  *** gleb has quit IRC
  62019-04-13T00:19:15  *** ccook has quit IRC
  72019-04-13T00:22:42  *** Liliaceae has quit IRC
  82019-04-13T00:30:58  *** dviola has quit IRC
  92019-04-13T00:32:26  *** pierre_rochard has quit IRC
 102019-04-13T00:33:13  *** ccook has joined #bitcoin-core-dev
 112019-04-13T00:36:19  *** spinza has joined #bitcoin-core-dev
 122019-04-13T00:38:05  *** Guest24808 has joined #bitcoin-core-dev
 132019-04-13T00:38:48  *** ccook has quit IRC
 142019-04-13T00:40:24  *** ccook has joined #bitcoin-core-dev
 152019-04-13T00:40:39  *** gleb has joined #bitcoin-core-dev
 162019-04-13T00:40:50  *** michagogo has joined #bitcoin-core-dev
 172019-04-13T00:44:02  *** Liliaceae has joined #bitcoin-core-dev
 182019-04-13T00:49:29  *** Isthmus has joined #bitcoin-core-dev
 192019-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.
 202019-04-13T01:08:24  *** justanotheruser has joined #bitcoin-core-dev
 212019-04-13T01:11:33  *** pinheadmz has quit IRC
 222019-04-13T01:35:39  *** millerti has joined #bitcoin-core-dev
 232019-04-13T01:42:13  *** captjakk has joined #bitcoin-core-dev
 242019-04-13T01:46:35  *** captjakk has quit IRC
 252019-04-13T01:50:25  *** captjakk has joined #bitcoin-core-dev
 262019-04-13T01:51:19  *** captjakk has joined #bitcoin-core-dev
 272019-04-13T01:53:45  *** pinheadmz has joined #bitcoin-core-dev
 282019-04-13T02:01:54  *** Randolf has joined #bitcoin-core-dev
 292019-04-13T02:10:00  *** pinheadmz has quit IRC
 302019-04-13T02:11:33  *** ghost43 has quit IRC
 312019-04-13T02:17:00  *** ghost43 has joined #bitcoin-core-dev
 322019-04-13T02:35:48  *** scoop has joined #bitcoin-core-dev
 332019-04-13T02:41:13  *** ghost43 has quit IRC
 342019-04-13T02:41:43  *** riperk has quit IRC
 352019-04-13T02:48:44  *** ghost43 has joined #bitcoin-core-dev
 362019-04-13T02:51:54  *** spinza has quit IRC
 372019-04-13T02:55:56  *** pinheadmz has joined #bitcoin-core-dev
 382019-04-13T02:58:13  *** ghost43 has quit IRC
 392019-04-13T02:59:31  *** pinheadmz has quit IRC
 402019-04-13T03:00:03  *** pinheadmz has joined #bitcoin-core-dev
 412019-04-13T03:05:14  *** ghost43 has joined #bitcoin-core-dev
 422019-04-13T03:13:30  *** pinheadmz has quit IRC
 432019-04-13T03:21:53  *** pinheadmz has joined #bitcoin-core-dev
 442019-04-13T03:36:48  *** pinheadmz has quit IRC
 452019-04-13T03:43:46  *** Eagle[TM] has joined #bitcoin-core-dev
 462019-04-13T03:44:45  *** jonatack has quit IRC
 472019-04-13T03:45:50  *** EagleTM has quit IRC
 482019-04-13T03:49:31  *** scoop has quit IRC
 492019-04-13T03:49:58  *** scoop has joined #bitcoin-core-dev
 502019-04-13T03:56:55  *** scoop has quit IRC
 512019-04-13T04:00:22  *** pinheadmz has joined #bitcoin-core-dev
 522019-04-13T04:03:23  *** ghost43 has quit IRC
 532019-04-13T04:11:27  *** ghost43 has joined #bitcoin-core-dev
 542019-04-13T04:17:31  *** scoop has joined #bitcoin-core-dev
 552019-04-13T04:20:15  *** pinheadmz has quit IRC
 562019-04-13T04:26:03  *** ghost43 has quit IRC
 572019-04-13T04:29:26  *** teardown has joined #bitcoin-core-dev
 582019-04-13T04:35:35  *** ghost43 has joined #bitcoin-core-dev
 592019-04-13T04:37:28  *** riperk has joined #bitcoin-core-dev
 602019-04-13T05:21:54  *** harrymm has quit IRC
 612019-04-13T05:34:52  *** harrymm has joined #bitcoin-core-dev
 622019-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.
 632019-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
 642019-04-13T05:40:16  <gwillen> fanquake: it's worth noting that this never comes up unless you do something stupid
 652019-04-13T05:40:23  <gwillen> I triggered it by putting in 10k for the lulz, basically
 662019-04-13T05:40:30  <gwillen> I'm not aware of anybody ever running into this in actual use
 672019-04-13T05:41:55  <fanquake> gwillen no generating 1'000'000s of addrs then o.0
 682019-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
 692019-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
 702019-04-13T05:48:18  <gmaxwell> 10,000 isn't absurd in any case... esp since it doesn't auto expand as addresses are used.
 712019-04-13T05:51:19  <gwillen> yeah that's fair
 722019-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)
 732019-04-13T05:51:58  <gwillen> of course real descriptor wallets will obviate all of this in the Glorius Future
 742019-04-13T06:49:25  *** ghost43 has quit IRC
 752019-04-13T06:55:13  *** ghost43 has joined #bitcoin-core-dev
 762019-04-13T06:55:19  <fanquake> The node used to generate those numbers has finally finished shutting down after a 2hr 3m wait.
 772019-04-13T07:08:18  *** DeanGuss has joined #bitcoin-core-dev
 782019-04-13T07:09:08  <gwillen> heh!
 792019-04-13T07:10:38  *** pinheadmz has joined #bitcoin-core-dev
 802019-04-13T07:17:23  *** scoop has quit IRC
 812019-04-13T07:43:57  *** Liliaceae has quit IRC
 822019-04-13T07:43:58  *** RubenSomsen has quit IRC
 832019-04-13T07:44:10  *** Liliaceae has joined #bitcoin-core-dev
 842019-04-13T07:44:13  *** RubenSomsen has joined #bitcoin-core-dev
 852019-04-13T07:44:30  *** michagogo has quit IRC
 862019-04-13T07:44:31  *** jl2012 has quit IRC
 872019-04-13T07:44:31  *** moneyball has quit IRC
 882019-04-13T07:44:31  *** jamesob has quit IRC
 892019-04-13T07:45:03  *** Guest24808 has quit IRC
 902019-04-13T07:45:37  *** ccook has quit IRC
 912019-04-13T07:45:37  *** Varunram has quit IRC
 922019-04-13T07:47:24  *** Varunram has joined #bitcoin-core-dev
 932019-04-13T07:47:29  *** michagogo has joined #bitcoin-core-dev
 942019-04-13T07:53:44  *** obsrver has joined #bitcoin-core-dev
 952019-04-13T07:55:43  *** pinheadmz has quit IRC
 962019-04-13T07:58:32  *** ccook has joined #bitcoin-core-dev
 972019-04-13T07:58:58  *** moneyball has joined #bitcoin-core-dev
 982019-04-13T07:59:02  *** jamesob has joined #bitcoin-core-dev
 992019-04-13T07:59:15  *** jl2012 has joined #bitcoin-core-dev
1002019-04-13T07:59:46  *** Guest24808 has joined #bitcoin-core-dev
1012019-04-13T08:23:08  *** laptop500 has joined #bitcoin-core-dev
1022019-04-13T08:51:42  *** riperk has quit IRC
1032019-04-13T09:11:15  *** laptop500 has quit IRC
1042019-04-13T09:17:51  *** scoop has joined #bitcoin-core-dev
1052019-04-13T09:22:22  *** scoop has quit IRC
1062019-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?
1072019-04-13T11:15:11  *** ghost43 has quit IRC
1082019-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
1092019-04-13T11:15:47  *** AaronvanW has joined #bitcoin-core-dev
1102019-04-13T11:21:20  *** ghost43 has joined #bitcoin-core-dev
1112019-04-13T11:59:57  *** ghost43 has quit IRC
1122019-04-13T12:06:34  *** ghost43 has joined #bitcoin-core-dev
1132019-04-13T12:34:27  *** Emcy has quit IRC
1142019-04-13T12:43:07  *** Eagle[TM] has quit IRC
1152019-04-13T12:49:11  *** jonatack has joined #bitcoin-core-dev
1162019-04-13T12:50:54  *** rex4539 has joined #bitcoin-core-dev
1172019-04-13T12:51:25  *** EagleTM has joined #bitcoin-core-dev
1182019-04-13T12:54:40  *** laptop500 has joined #bitcoin-core-dev
1192019-04-13T13:22:45  *** jonatack has quit IRC
1202019-04-13T13:26:05  *** ghost43 has quit IRC
1212019-04-13T13:27:28  *** ghost43 has joined #bitcoin-core-dev
1222019-04-13T13:27:48  *** luke-jr has quit IRC
1232019-04-13T13:32:36  *** luke-jr has joined #bitcoin-core-dev
1242019-04-13T13:43:07  *** Aaronvan_ has joined #bitcoin-core-dev
1252019-04-13T13:43:49  *** rex4539 has quit IRC
1262019-04-13T13:46:12  *** AaronvanW has quit IRC
1272019-04-13T13:56:33  *** tryphe_ has joined #bitcoin-core-dev
1282019-04-13T13:58:52  *** tryphe has quit IRC
1292019-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
1302019-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.
1312019-04-13T14:26:44  *** Victor_sueca has joined #bitcoin-core-dev
1322019-04-13T14:26:44  *** ghost43 has quit IRC
1332019-04-13T14:26:45  *** Victorsueca has quit IRC
1342019-04-13T14:27:57  *** ghost43 has joined #bitcoin-core-dev
1352019-04-13T14:30:54  *** promag has joined #bitcoin-core-dev
1362019-04-13T14:31:17  *** Victor_sueca is now known as Victorsueca
1372019-04-13T14:35:07  *** promag has quit IRC
1382019-04-13T14:47:28  *** dviola has joined #bitcoin-core-dev
1392019-04-13T14:51:00  *** captjakk has quit IRC
1402019-04-13T14:52:46  *** scoop has joined #bitcoin-core-dev
1412019-04-13T14:59:23  *** dviola has quit IRC
1422019-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.
1432019-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
1442019-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
1452019-04-13T15:10:11  *** dviola has joined #bitcoin-core-dev
1462019-04-13T15:11:28  <luke-jr> Miners should never be running old software.
1472019-04-13T15:12:23  <sdaftuar> luke-jr: fine, users running old software
1482019-04-13T15:12:49  <sdaftuar> if coordination of software changes were free, this would be much easier
1492019-04-13T15:14:32  <luke-jr> mempool policies don't strictly need adjustment for non-miners
1502019-04-13T15:14:41  <luke-jr> I mean, it's nice to have, but I don't think it's essential
1512019-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
1522019-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
1532019-04-13T15:20:30  <sdaftuar> ?
1542019-04-13T15:20:43  <sdaftuar> which i guess is just footgun protection
1552019-04-13T15:21:20  <sipa> yeah
1562019-04-13T15:22:12  <sipa> not being able to spend a v1 output is a script execution rule, designed for upgrada safety
1572019-04-13T15:22:38  <sipa> i guess there is a separate standardness rule about sending to v1
1582019-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.
1592019-04-13T15:24:02  <sipa> that's a surprising inconsistency
1602019-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?
1612019-04-13T15:25:48  <sdaftuar> perhaps i misunderstood the deployment goals
1622019-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
1632019-04-13T15:32:58  <sipa> i think?
1642019-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.
1652019-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
1662019-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
1672019-04-13T15:34:19  <sdaftuar> which is sort of terrible?
1682019-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
1692019-04-13T15:38:49  *** promag has joined #bitcoin-core-dev
1702019-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
1712019-04-13T15:41:54  <sipa> and there are plenty of other ways to construct an anyonecanspend address
1722019-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.
1732019-04-13T15:42:49  <sipa> really the protection ought to be in code that creates addresses rather than the code sending to it
1742019-04-13T15:43:43  *** promag has quit IRC
1752019-04-13T15:55:34  *** pinheadmz has joined #bitcoin-core-dev
1762019-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
1772019-04-13T15:59:21  <achow101> also the logic for updating and signing in core are almost exactly the same.
1782019-04-13T15:59:48  <achow101> you can have walletprocesspsbt not sign, there's a parameter to set sign to false.
1792019-04-13T16:15:46  *** atroxes has quit IRC
1802019-04-13T16:16:16  *** atroxes has joined #bitcoin-core-dev
1812019-04-13T16:16:19  *** Randolf has quit IRC
1822019-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?
1832019-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!
1842019-04-13T16:23:28  *** pinheadmz has quit IRC
1852019-04-13T16:29:41  <sipa> achow101, gwillen: in fact making it sign but not update would be kind of hard
1862019-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
1872019-04-13T16:32:31  <achow101> luke-jr: it's nonstandard though. we don't allow sending to nonstandard because nonstandard isn't relayed
1882019-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
1892019-04-13T16:33:42  <sipa> spending definitely needs to be nonstandard, but that's an independent check
1902019-04-13T16:34:11  *** AaronvanW has joined #bitcoin-core-dev
1912019-04-13T16:37:27  *** Aaronvan_ has quit IRC
1922019-04-13T16:48:51  *** instagibbs has quit IRC
1932019-04-13T16:48:51  *** ossifrage has quit IRC
1942019-04-13T16:48:51  *** thaumavorio has quit IRC
1952019-04-13T16:48:51  *** Klox has quit IRC
1962019-04-13T16:48:51  *** a5m0 has quit IRC
1972019-04-13T16:48:51  *** phantomcircuit has quit IRC
1982019-04-13T16:48:51  *** niftynei has quit IRC
1992019-04-13T16:48:51  *** designwish has quit IRC
2002019-04-13T16:48:51  *** marcinja has quit IRC
2012019-04-13T16:48:51  *** baldur has quit IRC
2022019-04-13T16:48:51  *** nehan has quit IRC
2032019-04-13T16:48:51  *** bitconner has quit IRC
2042019-04-13T16:48:52  *** nickler has quit IRC
2052019-04-13T16:48:52  *** treyzania has quit IRC
2062019-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
2072019-04-13T16:52:21  <luke-jr> otoh, accepting it into the wallet and policy-rejecting from mempool doesn't seem too terrible either
2082019-04-13T16:52:32  <luke-jr> it would just sit unconfirmed until some future point where a softfork enables it
2092019-04-13T16:52:52  <luke-jr> and IIRC the GUI displays a warning about it when you send
2102019-04-13T16:58:55  *** qrestlove has joined #bitcoin-core-dev
2112019-04-13T17:00:22  <harding> luke-jr: just tested, there's no warning in the GUI.
2122019-04-13T17:02:42  <luke-jr> hmm, there used to be a generic one for mempool rejecting it
2132019-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)
2142019-04-13T17:05:59  *** marcinja has joined #bitcoin-core-dev
2152019-04-13T17:06:00  *** treyzania has joined #bitcoin-core-dev
2162019-04-13T17:06:01  *** nickler has joined #bitcoin-core-dev
2172019-04-13T17:06:06  *** phantomcircuit has joined #bitcoin-core-dev
2182019-04-13T17:06:07  *** bitconner has joined #bitcoin-core-dev
2192019-04-13T17:06:07  *** nehan has joined #bitcoin-core-dev
2202019-04-13T17:06:16  *** niftynei has joined #bitcoin-core-dev
2212019-04-13T17:06:51  *** ossifrage has joined #bitcoin-core-dev
2222019-04-13T17:07:12  *** Klox has joined #bitcoin-core-dev
2232019-04-13T17:07:12  *** a5m0 has joined #bitcoin-core-dev
2242019-04-13T17:07:13  *** instagibbs has joined #bitcoin-core-dev
2252019-04-13T17:07:15  *** thaumavorio has joined #bitcoin-core-dev
2262019-04-13T17:11:06  *** designwish has joined #bitcoin-core-dev
2272019-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
2282019-04-13T17:14:35  <luke-jr> this level of hand-holding really belongs in GUI only and not in RPC
2292019-04-13T17:25:07  *** qrestlove has quit IRC
2302019-04-13T17:25:47  *** laptop_ has joined #bitcoin-core-dev
2312019-04-13T17:29:09  *** laptop500 has quit IRC
2322019-04-13T17:35:07  *** owowo has quit IRC
2332019-04-13T17:38:17  *** anddam has left #bitcoin-core-dev
2342019-04-13T17:40:20  *** owowo has joined #bitcoin-core-dev
2352019-04-13T17:45:51  <sipa> luke-jr: the first question is whether it shohld be relay policy
2362019-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.
2372019-04-13T17:54:15  *** Emcy has joined #bitcoin-core-dev
2382019-04-13T17:54:55  *** bitcoin-git has joined #bitcoin-core-dev
2392019-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
2402019-04-13T17:54:56  *** bitcoin-git has left #bitcoin-core-dev
2412019-04-13T18:01:06  *** riperk has joined #bitcoin-core-dev
2422019-04-13T18:07:58  *** promag has joined #bitcoin-core-dev
2432019-04-13T18:08:58  *** promag has quit IRC
2442019-04-13T18:09:14  *** promag has joined #bitcoin-core-dev
2452019-04-13T18:09:59  *** promag_ has joined #bitcoin-core-dev
2462019-04-13T18:11:46  *** promag_ has quit IRC
2472019-04-13T18:24:13  *** esotericnonsense has quit IRC
2482019-04-13T18:27:06  *** laptop_ has quit IRC
2492019-04-13T18:27:30  *** laptop_ has joined #bitcoin-core-dev
2502019-04-13T18:28:25  *** Guyver2 has joined #bitcoin-core-dev
2512019-04-13T18:31:22  *** AaronvanW has quit IRC
2522019-04-13T18:43:03  *** scoop has quit IRC
2532019-04-13T18:46:19  *** scoop has joined #bitcoin-core-dev
2542019-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
2552019-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
2562019-04-13T18:47:28  <jnewbery> wallet RPCs that use CommitTransaction() will return true even if AcceptToMemoryPool() fails
2572019-04-13T18:47:37  <jnewbery> (that also includes GUI sends)
2582019-04-13T18:48:29  <sipa> i guess we need to distinguish between permanent and temporary failure
2592019-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
2602019-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
2612019-04-13T18:52:12  *** scoop has quit IRC
2622019-04-13T18:55:59  *** scoop has joined #bitcoin-core-dev
2632019-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
2642019-04-13T19:02:17  <harding> perm_fail, if not more specific classes, seems like a good idea to me.)
2652019-04-13T19:04:10  <luke-jr> temp_fail might not be a good fit for future witness versions though
2662019-04-13T19:04:16  <luke-jr> since it's potentially a long term
2672019-04-13T19:04:27  <luke-jr> condition
2682019-04-13T19:04:37  <instagibbs> policy updates usually aren't activated while running the same software, right?
2692019-04-13T19:04:39  *** AaronvanW has joined #bitcoin-core-dev
2702019-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"
2712019-04-13T19:06:40  *** owowo has quit IRC
2722019-04-13T19:07:52  <instagibbs> problem is here previously nothing non-sendable had an address to decode
2732019-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.
2742019-04-13T19:09:40  *** AaronvanW has quit IRC
2752019-04-13T19:09:44  <harding> probably_wont_help*
2762019-04-13T19:09:48  <instagibbs> it can also happen with a plain old CreateTransaction making a tx that isn't relay-valid
2772019-04-13T19:09:51  <sipa> trying_again_with_the_same_software_wont_helo
2782019-04-13T19:09:51  <instagibbs> ie bug
2792019-04-13T19:10:05  <sipa> also invalid signature e.g. should fail that way
2802019-04-13T19:11:13  <instagibbs> s/IsValidDestination/IsValidRelayDestination/ ? :)
2812019-04-13T19:15:32  *** teardown has quit IRC
2822019-04-13T19:15:47  *** teardown has joined #bitcoin-core-dev
2832019-04-13T19:15:55  <sipa> how do i make a proposed meeti g topic?
2842019-04-13T19:16:03  <instagibbs> moneyball, ^ :D
2852019-04-13T19:16:55  <harding> sipa: say: moneyball: #proposedmeetingtopic <topic>
2862019-04-13T19:17:40  *** AaronvanW has joined #bitcoin-core-dev
2872019-04-13T19:18:38  <sipa> moneyball: #proposedmeetingtopic Should send-to-non-v0-witness be standard (spending such outputs is nonstandard independently)
2882019-04-13T19:20:23  <gmaxwell> thats what I was thinking
2892019-04-13T19:20:49  *** DeanGuss has quit IRC
2902019-04-13T19:21:44  *** teardown has quit IRC
2912019-04-13T19:21:56  *** teardown has joined #bitcoin-core-dev
2922019-04-13T19:22:00  *** AaronvanW has quit IRC
2932019-04-13T19:23:29  <jnewbery> moneyball: #proposedmeetingtopic Bitcoin Core design documentation
2942019-04-13T19:28:12  *** teardown has quit IRC
2952019-04-13T19:37:53  *** qrestlove has joined #bitcoin-core-dev
2962019-04-13T19:39:40  *** rex4539 has joined #bitcoin-core-dev
2972019-04-13T19:45:12  *** qrestlove has quit IRC
2982019-04-13T19:48:13  <moneyball> updated! https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a
2992019-04-13T19:58:11  *** AaronvanW has joined #bitcoin-core-dev
3002019-04-13T20:00:19  *** qrestlove has joined #bitcoin-core-dev
3012019-04-13T20:02:38  *** AaronvanW has quit IRC
3022019-04-13T20:04:09  *** qrest has joined #bitcoin-core-dev
3032019-04-13T20:05:47  *** scoop has quit IRC
3042019-04-13T20:05:54  *** qrestlove has quit IRC
3052019-04-13T20:07:31  *** owowo has joined #bitcoin-core-dev
3062019-04-13T20:10:41  *** ghost43 has quit IRC
3072019-04-13T20:12:05  *** ghost43 has joined #bitcoin-core-dev
3082019-04-13T20:13:01  *** scoop has joined #bitcoin-core-dev
3092019-04-13T20:20:13  *** scoop has quit IRC
3102019-04-13T20:28:36  *** Aaronvan_ has joined #bitcoin-core-dev
3112019-04-13T20:31:10  *** scoop has joined #bitcoin-core-dev
3122019-04-13T20:36:13  *** Guyver2 has quit IRC
3132019-04-13T20:37:00  *** scoop has quit IRC
3142019-04-13T20:41:35  *** rex4539 has quit IRC
3152019-04-13T20:44:01  *** scoop has joined #bitcoin-core-dev
3162019-04-13T20:47:20  *** scoop has quit IRC
3172019-04-13T20:49:58  *** scoop has joined #bitcoin-core-dev
3182019-04-13T21:04:26  *** Aaronvan_ has quit IRC
3192019-04-13T21:11:25  *** DeanGuss has joined #bitcoin-core-dev
3202019-04-13T21:19:19  *** AaronvanW has joined #bitcoin-core-dev
3212019-04-13T21:24:02  *** AaronvanW has quit IRC
3222019-04-13T21:48:21  *** obsrver has quit IRC
3232019-04-13T21:54:57  *** sipa has quit IRC
3242019-04-13T22:01:47  *** sipa has joined #bitcoin-core-dev
3252019-04-13T22:14:56  *** promag_ has joined #bitcoin-core-dev
3262019-04-13T22:33:30  *** AaronvanW has joined #bitcoin-core-dev
3272019-04-13T22:37:44  *** AaronvanW has quit IRC
3282019-04-13T22:39:45  *** Dean_Guss has joined #bitcoin-core-dev
3292019-04-13T22:41:25  *** DeanGuss has quit IRC
3302019-04-13T22:50:29  *** Dean_Guss has quit IRC