1 2017-12-11 00:47:51	0|phantomcircuit|running master with txindex=1 i just had an oom crash blocksonly mode dbcache=128
  2 2017-12-11 00:54:00	0|phantomcircuit|im now up to 5GB of resident memory
  3 2017-12-11 00:54:20	0|phantomcircuit|something is wrong here i believe
  4 2017-12-11 01:04:58	0|phantomcircuit|yeah there's a memory leak with this configuration
  5 2017-12-11 03:08:33	0|BlueMatt|phantomcircuit: on master?
  6 2017-12-11 03:08:44	0|BlueMatt|phantomcircuit: you want #11824
  7 2017-12-11 03:08:46	0|gribble|https://github.com/bitcoin/bitcoin/issues/11824 | Block ActivateBestChain to empty validationinterface queue by TheBlueMatt · Pull Request #11824 · bitcoin/bitcoin · GitHub
  8 2017-12-11 03:08:49	0|BlueMatt|should fix it right up for you
  9 2017-12-11 03:09:25	0|BlueMatt|(plz review)
 10 2017-12-11 04:09:30	0|phantomcircuit|BlueMatt, so what there's just some queue that's being consumed much much slower than produced?
 11 2017-12-11 04:09:41	0|BlueMatt|phantomcircuit: yes, cause cs_main
 12 2017-12-11 04:13:46	0|phantomcircuit|BlueMatt, wait it's a queue of shared pointers?
 13 2017-12-11 04:13:53	0|BlueMatt|phantomcircuit: yes?
 14 2017-12-11 04:14:05	0|phantomcircuit|oh to the full CBlock yeah ok so it's the full block staying in memory nvm
 15 2017-12-11 04:14:10	0|BlueMatt|yupyup
 16 2017-12-11 04:24:48	0|sipa|poll: when applying validateaddress to a (known) native witness multisig address, should it (A) not show the keys in it (B) show the keys in it as pubkeys (C) show the keys in it as legacy addresses (like P2SH multisig now) or (D) show the keys in it as native segwit addresses
 17 2017-12-11 04:26:16	0|luke-jr|I think B? C and D are ugly.
 18 2017-12-11 04:26:39	0|sipa|luke-jr: i agree
 19 2017-12-11 04:27:26	0|sipa|though in the case of B, should be also do that for non-segwit?
 20 2017-12-11 04:27:41	0|luke-jr|probably; can it do so compatibly?
 21 2017-12-11 04:28:04	0|sipa|yeah, would need to be in a separate key
 22 2017-12-11 04:28:12	0|sipa|"pubkeys" instead of "addresses"
 23 2017-12-11 04:28:26	0|luke-jr|ah
 24 2017-12-11 04:58:32	0|phantomcircuit|BlueMatt, is promise being used elsewhere?
 25 2017-12-11 07:19:40	0|mryandao|hmm, i'm trying to compile an older version of core (v0.7.0rc3), checked out the branch and did a clean, but there's no build instructions :(
 26 2017-12-11 07:22:24	0|sipa|https://github.com/bitcoin/bitcoin/blob/v0.7.0rc3/doc/build-unix.txt
 27 2017-12-11 07:23:09	0|mryandao|sipa: thanks :)
 28 2017-12-11 08:02:44	0|warren|Does anyone use gitian with qemu-kvm instead of lxc?
 29 2017-12-11 08:03:04	0|warren|MarcoFalke: have you tested your gitian instructions on Fedora 27?  both with qemu-kvm and lxc?
 30 2017-12-11 08:03:41	0|warren|Does anyone using gitian with qemu-kvm particularly on Ubuntu or Debian?
 31 2017-12-11 08:04:30	0|Randolf|warren:  You might also ask in the #qemu channel, just in case someone there can be helpful too.  :)
 32 2017-12-11 08:04:46	0|warren|Randolf: no, this is very gitian and bitcoin specific
 33 2017-12-11 08:04:51	0|Randolf|Oh, okay.
 34 2017-12-11 08:05:17	0|Randolf|I was merely thinking of a potentially wider audience.  :)
 35 2017-12-11 08:05:18	0|warren|The Bitcoin gitian instructions say to use only lxc but the way I've used it for the past few years is with qemu-kvm instead
 36 2017-12-11 08:05:30	0|Randolf|Cool!
 37 2017-12-11 08:05:39	0|Randolf|Having more than one way to do things is always a plus.
 38 2017-12-11 08:05:40	0|warren|Randolf: the way we qemu or lxc is very different from what most other people are familiar with
 39 2017-12-11 08:06:56	0|Randolf|I'm familiar with qemu, and have implemented it for various clients (primarily to run MS-Windows on NetBSD hosts), but lxc is something I should probably look into then.
 40 2017-12-11 08:07:05	0|Randolf|...and also qemu-kvm.
 41 2017-12-11 08:08:10	0|warren|qemu-kvm is just hardware accelerated qemu
 42 2017-12-11 08:08:28	0|warren|using kvm as a hypervisor, I think is the terminology
 43 2017-12-11 08:10:27	0|warren|http://wtogami.blogspot.com/2013/05/gitian-for-fedora.html  I had been updating tools to make gitian work on Fedora since 2013 ... I used it with qemu-kvm since then.
 44 2017-12-11 08:11:23	0|warren|But base-trusty-amd64.qcow2 generated on Fedora 25+ seems to be broken in some way that gets stuck with 100% CPU during qemu startup. If I copy a base-trusty-amd64.qcow2 image generated from Ubuntu onto my Fedora machine then gitian works.
 45 2017-12-11 08:11:53	0|warren|So curious if MarcoFalke tested the qemu method of gitian
 46 2017-12-11 08:12:16	0|warren|My packaged python-vm-builder is different than the "pip" method he uses to install it from Ubuntu
 47 2017-12-11 08:12:37	0|Randolf|Does qcow (as opposed to qcow2) also exhibit the same problematic behaviour?
 48 2017-12-11 08:13:23	0|warren|I don't think that's the issue. It's something installed or configured in the image file when it is generated.
 49 2017-12-11 08:14:56	0|Randolf|Oh.
 50 2017-12-11 08:15:22	0|warren|gitian qemu-kvm works just fine if I copy that base image from an Ubuntu machine
 51 2017-12-11 08:15:28	0|Randolf|(Thanks for the link, by the way.  I've opened it and will read it soon.)
 52 2017-12-11 08:15:49	0|warren|something is wrong with that tool on Fedora, it worked in Fedora 24 last i know
 53 2017-12-11 08:18:38	0|warren|I suspect it's grub2 or something not installing in the image file
 54 2017-12-11 08:20:27	0|TD-Linux|have you tried both efi and bios boot with qemu?
 55 2017-12-11 08:29:37	0|warren|it's something in the image file ...
 56 2017-12-11 08:29:45	0|warren|image copied from Ubuntu works fine
 57 2017-12-11 12:56:53	0|Provoostenator|mryandao: there may be some useful hints here too: https://gist.github.com/Sjors/70f14baf1f834f3547bf35553faff610
 58 2017-12-11 12:58:46	0|AdilibA|Hi
 59 2017-12-11 13:00:34	0|AdilibA|i want to share a scalling solution that i was thinking about it lately
 60 2017-12-11 13:00:53	0|AdilibA|Is anyone there?
 61 2017-12-11 13:03:45	0|AdilibA|The solution i was thinking about is by adding compression work in addition to minning work
 62 2017-12-11 13:04:27	0|AdilibA|Add the compression limit is the block size
 63 2017-12-11 13:08:19	0|AdilibA|I was searching for a compression that is luck based like mining, and isuggest the decomposition of the data to a permutable list of Superior Highly Composite Numbers.
 64 2017-12-11 13:20:14	0|Provoostenator|AdilibA: I think this is more appropriate for e.g. #bitcoin-wizards or the bitcoin-dev mailinglist. Unless you have a proof-of-concept patch ready to go specifically for the Bitcoin Core client (which this channel is about).
 65 2017-12-11 14:14:41	0|morcos|adiabat: can you email me or othwerise send me that fee_estimates.dat.  i think it makes sense that happened, but just will take a look to confirm
 66 2017-12-11 14:56:59	0|BlueMatt|phantomcircuit: promise? you mean std::promise, or the shared_ptr to the block?
 67 2017-12-11 15:19:27	0|bitcoin-git|[13bitcoin] 15promag opened pull request #11864: wallet: Make fund transaction atomic (06master...062017-12-atomic-fundtransaction) 02https://github.com/bitcoin/bitcoin/pull/11864
 68 2017-12-11 15:21:29	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f60b4ad57912...8ab6c0b09e4e
 69 2017-12-11 15:21:30	0|bitcoin-git|13bitcoin/06master 146697a70 15Gregory Sanders: add test for unconfirmed balance between restarts
 70 2017-12-11 15:21:30	0|bitcoin-git|13bitcoin/06master 146ba8f30 15Gregory Sanders: don't attempt mempool entry for wallet transactions on startup if already in mempool
 71 2017-12-11 15:21:31	0|bitcoin-git|13bitcoin/06master 148ab6c0b 15Wladimir J. van der Laan: Merge #11839: don't attempt mempool entry for wallet transactions on startup if alr…...
 72 2017-12-11 16:27:16	0|bitcoin-git|[13bitcoin] 15promag closed pull request #11865: wallet: Improve ReacceptWalletTransactions performance (06master...062017-12-improve-reaccept-wallet-transactions) 02https://github.com/bitcoin/bitcoin/pull/11865
 73 2017-12-11 17:05:53	0|cluelessperson|I have a serious question.  What are thoughts on seperating the Bitcoin Core wallet and Bitcoin Core node?
 74 2017-12-11 17:06:56	0|cluelessperson|Reason I suggest it?  1. Layman cannot be trusted/bothered to run their own nodes by default.  2.  I think it will healthily promote SPV development.
 75 2017-12-11 17:07:42	0|cluelessperson|3.  When someone uses multiple wallets, as some users do, they have difficulty switching between the wallets and rescanning, which takes a lot of time
 76 2017-12-11 17:08:08	0|wumpus|isn't there a PR that adds SPV functionality to the wallet?
 77 2017-12-11 17:08:27	0|wumpus|I don't think bringing this up as a discussion topic yet again is productiv
 78 2017-12-11 17:08:40	0|wumpus|it's been discussed zillions of times since 2012 or so
 79 2017-12-11 17:09:05	0|wumpus|every time the conclusion was that yes, it's desirable, if you want it, work toward it
 80 2017-12-11 17:09:15	0|cluelessperson|I understand the frustration.  It just keeps coming up for me because I keep getting morons that can't seem to understand how it works in #bitcoin
 81 2017-12-11 17:09:25	0|wumpus|feel free to work on it
 82 2017-12-11 17:09:34	0|cluelessperson|I'll do what I can.
 83 2017-12-11 17:09:41	0|cluelessperson|my skill sets are limited, I'm sorry
 84 2017-12-11 17:09:50	0|cluelessperson|I ask for broader shoulders
 85 2017-12-11 17:09:52	0|wumpus|#10794 is jonasschnelli's PR in that direction
 86 2017-12-11 17:09:55	0|gribble|https://github.com/bitcoin/bitcoin/issues/10794 | Add simple light-client mode (RPC only) by jonasschnelli · Pull Request #10794 · bitcoin/bitcoin · GitHub
 87 2017-12-11 17:33:30	0|Provoostenator|cluelessperson: as for multiple wallets: #10740 and #11383
 88 2017-12-11 17:33:33	0|gribble|https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
 89 2017-12-11 17:33:36	0|gribble|https://github.com/bitcoin/bitcoin/issues/11383 | Basic Multiwallet GUI support by luke-jr · Pull Request #11383 · bitcoin/bitcoin · GitHub
 90 2017-12-11 17:34:23	0|Provoostenator|There's several pull requests that make small steps in this direction, mostly just improving the code quality and separating stuff better.
 91 2017-12-11 17:35:26	0|cluelessperson|Provoostenator: unfortunately, I'm not a coding expert, and I don't know C++.  I have no power here.
 92 2017-12-11 17:35:35	0|cluelessperson|I wish I could actually help
 93 2017-12-11 17:36:02	0|cluelessperson|I'm stuck with documentation and community support. DEVOPs and the like
 94 2017-12-11 17:36:19	0|Provoostenator|Well, both can be learned.
 95 2017-12-11 17:36:35	0|Provoostenator|And these other contributions also help, as they take work off the shoulders of developers.
 96 2017-12-11 17:37:56	0|Provoostenator|Or you could stalk your friends with C++ skills and manipulate them into becoming interested in Bitcoin, quitting their current job and helping out :-)
 97 2017-12-11 17:59:18	0|cluelessperson|Provoostenator: I'm trying but I have no path forward
 98 2017-12-11 17:59:42	0|cluelessperson|I'm taking college classes, but not sure where this is leading honestly
 99 2017-12-11 18:00:09	0|alcipir|How long does it take for a seasoned web developer to get into C++?
100 2017-12-11 18:02:25	0|Randolf|alcipir:  It probably depends partly on which languages they already know.  For example, if they haven't done anything with Object Oriented Programming, then that will be a learning curve for them too.
101 2017-12-11 18:03:09	0|alcipir|Hm, I've been doing object-oriented PHP for years now, although I don't like it as a language
102 2017-12-11 18:03:14	0|alcipir|also know a bit of Java and C#
103 2017-12-11 18:03:31	0|alcipir|but C++ seems pretty daunting at first, seems like it changes a lot over time
104 2017-12-11 18:04:24	0|Randolf|alcipir:  I suspect that the folks in the #c++ channel can probably be very helpful to getting you started based on what you already have a background in.  :)
105 2017-12-11 18:05:28	0|Randolf|alcipir:  My suggestion is to learn C++ first, and then learn about programming Bitcoin/blockchain.  The reason is that both have learning curves that are probably better-studied separately.
106 2017-12-11 18:05:39	0|alcipir|I see, thanks for the tip :)
107 2017-12-11 18:05:44	0|Randolf|You're welcome.
108 2017-12-11 18:13:28	0|Provoostenator|acipir: that's roughly my background as well, although I did dabble in C(++)  15 years ago and worked a lot with ObjectiveC. Here's some book recommendations depending on your background: https://stackoverflow.com/a/388282
109 2017-12-11 18:14:44	0|sipa|i think the discussion is getting a bit offtopic
110 2017-12-11 18:18:59	0|alcipir|thanks Provoostenator, and sorry for the offtopic discussion
111 2017-12-11 18:26:15	0|michagogo|Why do we still have a "Pay only the required fee of 1 satoshi/byte" checkbox?
112 2017-12-11 18:27:28	0|michagogo|I mean, now that we have RBF, it's probably not quite as bad as it used to be, but it still seems like it's likely to be misleading
113 2017-12-11 18:28:12	0|michagogo|Yeah, it's under the Custom radio button and not under Recommended, but it feels like it's saying that that's okay and has a chance at working
114 2017-12-11 18:37:43	0|wumpus|I don't know, feel free to file a PR to remove it and see if there's interest / pushback
115 2017-12-11 18:38:42	0|wumpus|by far most people will simply use the recommended fee (which is the default), and those that don't generally know better what they're doing, so I doubt it matters much
116 2017-12-11 19:05:34	0|gmaxwell|Bluematt: re: transaction delayed bundles:
117 2017-12-11 19:05:34	0|gmaxwell|re: for wallet encryption, I think you can just sign the current best batch when each rpc comes in, so you don't need
118 2017-12-11 19:05:37	0|gmaxwell|to keep the key around. The downside is that it can't use the fee-estimation at the point of send, but that seems like
119 2017-12-11 19:05:40	0|gmaxwell|a small loss.
120 2017-12-11 19:05:43	0|gmaxwell|Interface wise, you'll need to return some kind of identifier that the wallet can use to tell you if a payment was made.
121 2017-12-11 19:05:46	0|gmaxwell|BlueMatt: I don't think there is a reason to make the standard rpcs do this,  just add new ones:  "bundlesend" (works
122 2017-12-11 19:05:49	0|gmaxwell|like sendmany, but takes a maximum waittime argument) "bundleabort" (can cancel a transaction using a handle returned
123 2017-12-11 19:05:52	0|gmaxwell|by bundlesend) "bundleforce" (forces the current bundle to send now) or something... and a behavior that sends N
124 2017-12-11 19:05:55	0|gmaxwell|seconds after the last addition, or when the first timeout is hit.
125 2017-12-11 19:05:57	0|gmaxwell|unless it would really be a burden to change the rpc calls their software is making... but I think thats unavoidable
126 2017-12-11 19:06:00	0|gmaxwell|since you can't return a txid.
127 2017-12-11 19:06:03	0|gmaxwell|For a while I've wanted a standardized signed payment confirmation code, basically a signature with some well known key
128 2017-12-11 19:06:06	0|gmaxwell|that says "I promise to pay X btc to address Y", which would be a potential candidate for what gets returned, but
129 2017-12-11 19:06:09	0|gmaxwell|perhaps too much scope creep.
130 2017-12-11 19:06:33	0|gmaxwell|One thing perhaps to keep in mind is that the names of the RPCs should be short and easy because probably we'd like to make the bundle based method the default and standard method.
131 2017-12-11 19:06:54	0|BlueMatt|yes, thats probably scope creep
132 2017-12-11 19:07:11	0|BlueMatt|but, generally, I think these could be added quite simply to large benefit of some users
133 2017-12-11 19:07:55	0|gmaxwell|One reason some large users have given me for not using their own aggregation (parties easily big enough do implement their own) was that they want txids to give to users that they can immediately look up on block explorers.
134 2017-12-11 19:08:06	0|jonasschnelli|wumpus: https://github.com/bitcoin/bitcoin/pull/11845
135 2017-12-11 19:08:18	0|BlueMatt|worth reaching out to people who use bitcoin core's wallet in reasonable volume to ask what they'd want from such an interface
136 2017-12-11 19:08:20	0|jonasschnelli|The key links to btcplt.org (Bitcoin Platinum)
137 2017-12-11 19:08:31	0|BlueMatt|gmaxwell: yea, that really sucks, dunno how to get away from it except for rbf, sadly
138 2017-12-11 19:08:43	0|gmaxwell|BlueMatt: with the signed code I just suggested.
139 2017-12-11 19:08:48	0|BlueMatt|gmaxwell: an independantly-really-useful project which someone should do is go test what the ux is on wallets when you receive rbf txn
140 2017-12-11 19:08:48	0|jonasschnelli|Not sure if we want a key leading to the Bitcoin Platinum project in our repository,... could be missued for advertising?
141 2017-12-11 19:08:56	0|BlueMatt|gmaxwell: yes, but block explorers wont support that for...20 years
142 2017-12-11 19:09:17	0|gmaxwell|BlueMatt: meh, bc.i had sorta support for bech32 addresses when segwit activated.
143 2017-12-11 19:09:40	0|gmaxwell|some kind of signmessage thing wouldn't be a big deal to support, doesn't require a blockchain to back it.
144 2017-12-11 19:09:41	0|BlueMatt|gmaxwell: I'm super skeptical, but would love to be proven wrong....
145 2017-12-11 19:09:51	0|BlueMatt|true, could signmessage magic
146 2017-12-11 19:09:56	0|gmaxwell|I mean, any of us could also put up little dumb js pages for that.
147 2017-12-11 19:10:30	0|Provoostenator|jonasschnelli: would it make sense to ask for plain text keys instead of binary ones, so this sort of thing is easier to spot? (regardless of whether this domain matters)
148 2017-12-11 19:10:33	0|gmaxwell|It would just be a reciept that a person could save and use to prove to others when their counterparty doesn't make good on a promise to pay.
149 2017-12-11 19:10:48	0|BlueMatt|(obviiously getting wallets to have reasonable ux when receiving rbf txn would be independantly incredibly helpful - how many wallets spend unconfirmed/unconfirmable/conflicting txn if you receive a rbf-bumped tx?)
150 2017-12-11 19:10:54	0|jonasschnelli|Provoostenator: no... I don't think so...
151 2017-12-11 19:11:04	0|jonasschnelli|Provoostenator: there is always an email (or pretty much always) attached...
152 2017-12-11 19:11:28	0|BlueMatt|gmaxwell: true....I suppose if we put up a page for it that may also be sufficient, I guess people dont care *what* block explorer shows it, as long as they can link to one that does
153 2017-12-11 19:11:29	0|gmaxwell|BlueMatt: yes and we should keep RBF in mind when doing the batch interface, the batch interface should be specified so that it's okay for it to RBF anything you put through it.
154 2017-12-11 19:11:31	0|Provoostenator|Nvm, you can't see the email in a .asc file either; just need to import it to see.
155 2017-12-11 19:11:54	0|BlueMatt|yes
156 2017-12-11 19:12:22	0|gmaxwell|BlueMatt: batch interface's spec should be "will get a payment made of the specified amounts to the specified addresses accomplished eventually"
157 2017-12-11 19:12:23	0|BlueMatt|one thing we should do is reach out to "industry" folks regarding potential apis here (batching/whether they'd be happy with a signmessage-equivalent?)
158 2017-12-11 19:12:46	0|gmaxwell|well I think they've never thought of these things, so we'd have to propose them.
159 2017-12-11 19:13:28	0|BlueMatt|yes, thats my point :p
160 2017-12-11 19:16:50	0|gmaxwell|oh, rpc I missed: bundletxid   takes a bundle handle and tells you the txid it eventually issued.. maybe also if it was confirmed and in what block.
161 2017-12-11 19:18:03	0|BlueMatt|well bundletx verbose=X
162 2017-12-11 19:18:32	0|gmaxwell|rpcs that return all txn like listtransactions kinda stink.
163 2017-12-11 19:18:57	0|BlueMatt|i mean get the tx for the bundle in raw (or hex, or txid) form
164 2017-12-11 19:19:12	0|gmaxwell|ah.
165 2017-12-11 19:19:38	0|sipa|is there a need to support multiple bundles simultaneously?
166 2017-12-11 19:19:56	0|BlueMatt|little reason not to, but probably not?
167 2017-12-11 19:20:32	0|sipa|my thinking was that there'd just be a single set of output/amount pairs that are in flight
168 2017-12-11 19:20:51	0|sipa|and any time you update it, a new transaction is created
169 2017-12-11 19:21:04	0|sipa|which is guaranteed to conflict with earlier transactions
170 2017-12-11 19:21:16	0|BlueMatt|you mean and not announce them?
171 2017-12-11 19:21:22	0|gmaxwell|the guarenteed to conflict will result in suboptimal coin selection.
172 2017-12-11 19:21:26	0|BlueMatt|rbf would have to be optional given receiving rbf txn right now sucks
173 2017-12-11 19:21:40	0|sipa|gmaxwell: sure
174 2017-12-11 19:21:48	0|gmaxwell|BlueMatt: I described above creating the tx at RPC not announce time.
175 2017-12-11 19:21:57	0|adiabat|related to pre-signing a bunch of txs with increasing fee rates, what if you have incremental locktimes on them?
176 2017-12-11 19:22:06	0|gmaxwell|sipa: why bother with a guarentee to conflict, if you give the user no access to the txn itself until announce time?
177 2017-12-11 19:22:10	0|BlueMatt|i see no reason to not wait, except for wallet encryption, but I'd prefer to decrypt-at-send-time than at-add-output time, no?
178 2017-12-11 19:22:19	0|adiabat|would it then be possible to have nodes relay the txs even if they're not-yet-minable?
179 2017-12-11 19:22:43	0|sipa|gmaxwell: well it would need to conflict at least with broadcasted transactions
180 2017-12-11 19:22:48	0|gmaxwell|adiabat: setting locktimes on precreated replacements is the obvious thing to do, suggested every time it has come up.
181 2017-12-11 19:23:08	0|adiabat|gmaxwell: ok what's the catch...?
182 2017-12-11 19:23:20	0|gmaxwell|adiabat: relaying a non-mingable transaction is an immediate and nasty DOS vector... what value do you see in that?
183 2017-12-11 19:23:26	0|BlueMatt|some people dont want to do rbf cause the client-side wallets may handle it like garbage
184 2017-12-11 19:23:30	0|sipa|gmaxwell: in my earlier descriptions of this idea there was no separation between creation of the transaction and broadcastng
185 2017-12-11 19:23:50	0|gmaxwell|adiabat: there is no catch, if bitcoin core ever does replacement fully I assume it'll presign with locktimes.
186 2017-12-11 19:24:07	0|sipa|but it does make sense - you may want to perform multiple updates frequently, but only occasionally issue a new transaction
187 2017-12-11 19:24:13	0|adiabat|gmaxwell: value is that wallets can fire-and-forget; DoS is the issue but feels like it could be managed
188 2017-12-11 19:24:28	0|Provoostenator|BlueMatt: I suspect that if enough wallets start actually using RBF, other wallets will stop handling them like garbage. It's often a matter of educating UX folks and developers.
189 2017-12-11 19:24:44	0|BlueMatt|Provoostenator: agreed, but also a chicken-and-egg issue there
190 2017-12-11 19:25:03	0|gmaxwell|adiabat: best of luck with that.
191 2017-12-11 19:25:21	0|BlueMatt|sipa: wait, how do you propose it working if you create a new tx every time you add an output and broadcast immediately and *dont* use rbf?
192 2017-12-11 19:25:24	0|adiabat|gmaxwell: heh :)  Yeah it's hard to not get banned
193 2017-12-11 19:25:35	0|BlueMatt|(hell, even with rbf you have lots of annoying corner-cases)
194 2017-12-11 19:25:40	0|sipa|BlueMatt: of course it would RBF
195 2017-12-11 19:25:49	0|BlueMatt|sipa: the whole point was to make rbf optional..........
196 2017-12-11 19:26:01	0|sipa|maybe we're talking about something unrelated then :)
197 2017-12-11 19:26:04	0|BlueMatt|see discussion above...
198 2017-12-11 19:26:22	0|BlueMatt|a tx bundle api would have to have rbf be optional
199 2017-12-11 19:26:28	0|sipa|meh
200 2017-12-11 19:26:34	0|gmaxwell|sipa: the point of this discussion was to enable parties to sendmany.
201 2017-12-11 19:26:37	0|BlueMatt|if you have rbf on you can get instant-sends that just get replaced, but no one (right now) would use it if its only rbf
202 2017-12-11 19:26:56	0|gmaxwell|Right now too many people use txid as an effective unique key for a payment.. you utterly break stuff by rbfing.
203 2017-12-11 19:27:00	0|BlueMatt|sipa: feel free to go help user-level wallets fix their rbf-receive ux
204 2017-12-11 19:27:13	0|sipa|fair
205 2017-12-11 19:27:46	0|BlueMatt|rbf appears to work pretty sell *sending* to services, but a service sending rbf to a user-side wallet....bad ux
206 2017-12-11 19:27:48	0|sipa|i guess i was thinking about a longer term thing for when RBFing is not an issue anymore, and people have stopped relying on txids for unconfirmed transactions
207 2017-12-11 19:28:03	0|BlueMatt|no, I'm talking about building an api now...not something no one will use
208 2017-12-11 19:28:12	0|sipa|okay, ignore e
209 2017-12-11 19:28:23	0|adiabat|gmaxwell: apologies if off-topic or already discussed- what if policy was accept future locktimed tx but only if it's a fee bump of existing mempool tx?
210 2017-12-11 19:28:51	0|BlueMatt|adiabat: doesnt ln have like a model where folks run servers which auto-broadcast in the future? just piggy back on them
211 2017-12-11 19:28:57	0|BlueMatt|no need to relay it in bitcoin p2p net?
212 2017-12-11 19:29:12	0|adiabat|yup, asking because I'm working on similar stuff
213 2017-12-11 19:29:30	0|adiabat|Hmm... OK so maybe code LN stuff to accept not-yet-OK RBF txs instead?
214 2017-12-11 19:29:56	0|sipa|accepting things into your mempool which can't confirm soon undermines its DoS protection
215 2017-12-11 19:30:10	0|gmaxwell|adiabat: that gives an attacker zero-cost n-fold inflation node node bandwidth/cpu/memory... (make the initial one enough to confirm right away, make N bumps)
216 2017-12-11 19:30:22	0|BlueMatt|yea, I mean I'd strongly suggest if you're gonna run a network of servers/users providing services to montior and announce txn later to add an option to broadcast *anything* later
217 2017-12-11 19:30:22	0|sipa|as we rely on assuming that everything in the mempool will eventually be either confirmed or replaced with something paying a higher fee
218 2017-12-11 19:30:29	0|BlueMatt|then its a generic service
219 2017-12-11 19:30:32	0|adiabat|right, for small N might be doable if nodes opt-in
220 2017-12-11 19:30:35	0|Provoostenator|BlueMatt: good point to distinguish between "merchant" services and consumer wallets when it comes to RBF. Although I think it's very useful for sending money between people who reasonable trust eachother; "let me know if you need me to bump this"
221 2017-12-11 19:30:49	0|gmaxwell|adiabat: I think it's not reasonable to have every node in the general p2p network handling this,  why not just have special transaction queue nodes that will handle this?
222 2017-12-11 19:31:14	0|BlueMatt|Provoostenator: well my concern is ux for average users...if I'm sending to someone I know understands bitcoin, fine, no issue, if its some guy who's receiving a withdraw from an atm/their exchange, they may be very confused
223 2017-12-11 19:31:23	0|adiabat|gmaxwell: I agree; I'm mainly thinking about the logistics of different nodes / codebases
224 2017-12-11 19:31:52	0|gmaxwell|there is no need for 100,000 nodes to queue up txn that will likely never confirm.... just having a couple handle it would be sufficient.
225 2017-12-11 19:32:04	0|adiabat|easy enough to have a website which says "give your future-dated RBF txs" and has a captcha or something
226 2017-12-11 19:32:46	0|BlueMatt|or add it to ln nodes? dont they have some ability to do similar things?
227 2017-12-11 19:33:01	0|BlueMatt|might as well let them do it for any txn with payment of 5 satoshis over ln or so?
228 2017-12-11 19:33:11	0|adiabat|right now LN nodes don't have actual tx storage for other nodes
229 2017-12-11 19:33:21	0|adiabat|but it's something that could be added
230 2017-12-11 19:33:46	0|adiabat|I have been looking at bumping fees for funding channels and it's a little tricky due to multisig / multiple parties
231 2017-12-11 19:35:25	0|Provoostenator|BlueMatt: what's the implication of that for #11605? In particular, wouldn't that make the case for not making RBF a default in RPC, because we don't want every ATM out there to start using this just yet?
232 2017-12-11 19:35:28	0|gribble|https://github.com/bitcoin/bitcoin/issues/11605 | [Wallet] Enable RBF by default in QT by Sjors · Pull Request #11605 · bitcoin/bitcoin · GitHub
233 2017-12-11 19:35:35	0|Provoostenator|(every ATM that uses the Core wallet)
234 2017-12-11 19:35:58	0|gmaxwell|Provoostenator: hm? there is no problem signaling RBF if you don't make use of it.
235 2017-12-11 19:36:04	0|gmaxwell|The problems arise when you make use of it.
236 2017-12-11 19:36:07	0|BlueMatt|Provoostenator: I mean that would be my thought, which is what I put in that pr anyway, but worth asking morcos and jnewbery since they objected?
237 2017-12-11 19:36:15	0|BlueMatt|yea, ok, that too, if you dont use it it doesnt matter
238 2017-12-11 19:36:18	0|gmaxwell|The issue for the batching thing is that if it used RBF it would immeidately make use of it.
239 2017-12-11 19:36:19	0|Provoostenator|Ok, that's a good point. Wallets indeed suck even more at that.
240 2017-12-11 19:36:40	0|Provoostenator|They complain it's a double spend, might even mess up the balance.
241 2017-12-11 19:36:59	0|gmaxwell|though on reflection even if your batching thing can RBF, it shouldn't do so eagerly, since it'll pay high fees since the bumps have to increase fees.
242 2017-12-11 19:37:29	0|BlueMatt|yes, exactly, batching rbf isnt quite supported by the current restrictions on rbf...maybe be worth exploring reducing those restrictions if people have a desire for it
243 2017-12-11 19:37:32	0|gmaxwell|but still, flagging rbf is pretty much harmless, I believe electrum does this by default already without incident...
244 2017-12-11 19:38:05	0|gmaxwell|BlueMatt: I dunno, if anything current RBF restrictions are too lax because mempool minfee is unrealistically low.
245 2017-12-11 19:39:07	0|BlueMatt|yea, well possibly minfee needs to be higher with the incremental/relay fee lower for rbf? dunno, worth exploring
246 2017-12-11 19:40:26	0|Provoostenator|Do we have an estimate of how often fee increases are used in the wild currently? I find it useless in both GreenWallet and QT, because it doesn't let you pick your own amount, and the cheapest option is usually much too expensive.
247 2017-12-11 19:41:01	0|Provoostenator|Like I make a tx with a €0.50 fee and it says the minimum for a fee bump is €25.
248 2017-12-11 19:41:23	0|BlueMatt|that....doesnt sound right
249 2017-12-11 19:41:47	0|BlueMatt|oh, yea, greenaddress' feebump is really annoying
250 2017-12-11 19:41:50	0|gmaxwell|for greenaddress IIRC it only currently supports one bump, so it only offers it at whatever the shortest fee estimate is.
251 2017-12-11 19:41:51	0|Provoostenator|I had to use some AngularJS javascript console voodoo to make GreenWallet behave. And with Core I already have a TODO to improve this.
252 2017-12-11 19:42:06	0|BlueMatt|gmaxwell: no, it offers several, but they're all relatively short
253 2017-12-11 19:43:01	0|Provoostenator|https://twitter.com/Provoost/status/925245638379483137
254 2017-12-11 19:43:41	0|gmaxwell|Provoostenator: the bumpfee in bitcoin core however lets you set whatever target you want AFAIR.
255 2017-12-11 19:44:10	0|Provoostenator|gmaxwell: correct, so my TODO is about allow the UI to do the same. Probably by reusing the send screen, hiding all elements except the fee selection.
256 2017-12-11 19:44:32	0|Provoostenator|(and enforcing the correct minimum, etc)
257 2017-12-11 19:44:39	0|gmaxwell|you might want to also do something to handle the minim..right
258 2017-12-11 19:44:40	0|adiabat|bitcoin-qt bump fee only gives you one option though; cli lets you set whatever you want
259 2017-12-11 19:44:58	0|gmaxwell|I'd forgotten we had anything in the GUI yet.
260 2017-12-11 19:45:16	0|adiabat|you can right click on txs and there's an "increase fee" option
261 2017-12-11 19:45:16	0|Provoostenator|I'm trying to Make QT Great Again :-)
262 2017-12-11 19:45:21	0|gmaxwell|it's still relatively useless due to not being able to change the input set.
263 2017-12-11 19:45:24	0|adiabat|brings up a modal with OK / cancel
264 2017-12-11 19:47:10	0|Provoostenator|Yes, that's the other contraint I suppose. I guess the max fee is constrained by the amount of change for the original tx?
265 2017-12-11 19:48:14	0|Provoostenator|I'm not going to mess with coin selection, but for RBF, it might make sense to try and overshoot by the worst case fee, if there is an input available.
266 2017-12-11 19:50:47	0|gmaxwell|uhg. no... the correct thing to do is to just drop the same-inputs restriction.
267 2017-12-11 19:51:16	0|gmaxwell|it was just done that way to make it faster to implement, but it's a bad restriction.
268 2017-12-11 19:51:20	0|Provoostenator|That does sound cleaner. Is that restriction part of the BIP?
269 2017-12-11 19:51:25	0|gmaxwell|absolutely not
270 2017-12-11 19:52:01	0|Provoostenator|Ok, so the first step there would be to change bumpfee RPC to let go of same-input?
271 2017-12-11 19:52:52	0|Provoostenator|But somehow track what you've used, because I assuem there has to be overlap in inputs.
272 2017-12-11 19:52:59	0|Provoostenator|(between all versions)
273 2017-12-11 19:53:00	0|gmaxwell|Probably easiest to let it add additional inputs, this requires plumbing through mandatory inputs to the coin selection logic.
274 2017-12-11 19:53:41	0|gmaxwell|technically they merely needs to be an overlap. But it's simpler to superset and I think hardly worse.
275 2017-12-11 19:53:51	0|gmaxwell|Supersetting is better for privacy.
276 2017-12-11 19:56:44	0|Provoostenator|And the wallet keeps all previous versions around and knows which ones they are? (doesn't matter in the superset case)
277 2017-12-11 19:57:41	0|gmaxwell|Thats why the superset case is easier to implement.
278 2017-12-11 19:57:48	0|Provoostenator|Supersetting in combination with my idea above of overshooting the initial selection?
279 2017-12-11 19:58:25	0|Provoostenator|(though that can always be done later)
280 2017-12-11 19:59:14	0|gmaxwell|there is no reason to overshoot the initial.
281 2017-12-11 19:59:57	0|gmaxwell|we should be trying to avoid producing dusty change (e.g. change in value comparible to fees)
282 2017-12-11 20:00:55	0|Provoostenator|My rational was to make bumping cheaper in the super set scenario, because you don't need to add an extra input. But I see your point about creating dust.
283 2017-12-11 20:02:04	0|gmaxwell|well you'll pay the fees for that extra input eventually, so it's not that bad to add it.
284 2017-12-11 20:02:24	0|gmaxwell|the cost of the extra input is just the difference in the feerate between now and when you might use it later.
285 2017-12-11 20:11:14	0|luke-jr|gmaxwell: but you need to cover the cost of the data/weight for the first tx as well?
286 2017-12-11 20:11:32	0|luke-jr|not sure it matters much in practice I guess
287 2017-12-11 20:17:10	0|Provoostenator|Probably not when fees are at a level where you actually need RBF.
288 2017-12-11 20:17:54	0|Provoostenator|At what point would you expect most node operators to increase the minimum relay fee?
289 2017-12-11 20:23:01	0|gmaxwell|Provoostenator: we don't expect anyone to increase the minimum relay fee, we expect it to increase automatically.
290 2017-12-11 20:23:28	0|gmaxwell|unfortunately it's not, seemingly because the mempool is too big.
291 2017-12-11 20:25:56	0|sipa|Provoostenator: do you mean the minimum relay fee (the fee needed to get into the mempool at all) or the discard rate (the fee increment needed for replacing) ?
292 2017-12-11 20:26:26	0|sipa|the first is controlled by the mempool limiting; the second is just a configurable constant
293 2017-12-11 20:26:37	0|sipa|(luke-jr was talking about the second)
294 2017-12-11 20:40:47	0|morcos|gmaxwell: it got quite high before the weekend, i think 40 sat/B
295 2017-12-11 20:42:02	0|morcos|is there any reason that resendwallettransactions needs to be a hidden RPC only used for testing?
296 2017-12-11 20:42:23	0|morcos|doesn't it seem kind of useful to be able to fully create and locally accept transactions, but not broadcast them until ready
297 2017-12-11 20:42:59	0|morcos|is it just a privacy concern?
298 2017-12-11 20:43:44	0|morcos|this is partly in response to the ongoing discussion in #10247 right now
299 2017-12-11 20:43:46	0|gribble|https://github.com/bitcoin/bitcoin/issues/10247 | cost too many fees? · Issue #10247 · bitcoin/bitcoin · GitHub
300 2017-12-11 20:43:55	0|gmaxwell|you mean turn off wallet broadcast and trigger broadcasting yourself?
301 2017-12-11 20:44:26	0|morcos|yeah exactly
302 2017-12-11 20:44:31	0|gmaxwell|we probably need to add a flag in the wallet to track if unconfirmed txn has been seen in the mempool, and show it in the GUI,  to avoid users footgunning by never broadcasting.
303 2017-12-11 20:44:49	0|gmaxwell|but I think it's fine, personally I always run with broadcasting off.
304 2017-12-11 20:45:20	0|instagibbs|do you just sendraw when ready?
305 2017-12-11 20:45:41	0|morcos|ah, i suppose sendraw accomplish what i wanted to suggest pretty well
306 2017-12-11 20:47:46	0|phantomcircuit|personally i disable internet when i want to do that...
307 2017-12-11 21:50:52	0|jb55|morcos: I'm about to remove the InMempool() check from AbandonTransaction on my local node, is there any good reason why that's there?
308 2017-12-11 21:52:39	0|sipa|jb55: if your own node has it in its mempool, it's very likely other nodes do too, in which case the effect won't accomplish much
309 2017-12-11 21:53:01	0|sipa|you could try to double-spend the transaction, but it may not get relayed by other nodes, for example
310 2017-12-11 21:53:10	0|jb55|I've just had a tx that's been around for a month and it looks like my node keeps rebroadcasting it?
311 2017-12-11 21:56:03	0|jtimon|MarcoFalke: what needs to be done for https://github.com/bitcoin/bitcoin/pull/8994/commits/52f6f43968595a769b109b9b6987ab03275c4a9d#r153922809 ?
312 2017-12-11 21:56:33	0|jtimon|I kind of missed that whole discussion
313 2017-12-11 22:02:47	0|jb55|sipa: wouldn't it stay in the mempool if it keeps rebroadcasting it? here's my logs https://jb55.com/s/42dd917b1b1b4b05.txt
314 2017-12-11 22:03:56	0|jb55|I guess I'll just double spend it
315 2017-12-11 22:10:21	0|jb55|would be nice if there was some way to tell my node to stop broadcasting it, I though that's what abandon would do but I can't abandon because it keeps getting rebroadcasted and stays in my local mempool! Unless I'm confused about something.
316 2017-12-11 22:16:36	0|sipa|jb55: ah, yes agree wth that
317 2017-12-11 22:19:21	0|sipa|not quite abandoning, but at least stoo broadcasting
318 2017-12-11 23:06:04	0|gmaxwell|I agree that stop broadcasting would be reasonable, however I also don't think it'll be very useful:  the recieving side will also rebroadcast, and so will random nodes on the network
319 2017-12-11 23:06:50	0|gmaxwell|probably when we add a "I've seen this in a mempool before" flag on wtx we should add a "I should keep trying to rebroadcast"  and have abort set that to false.
320 2017-12-11 23:23:47	0|tomdickharry|https://bitcointalk.org/index.php?topic=2569202.0
321 2017-12-11 23:23:56	0|tomdickharry|https://bitcointalk.org/index.php?topic=2569202.0
322 2017-12-11 23:38:35	0|jb55|gmaxwell: well the case I was referring to was specifically ResendWalletTransactions, which only applys to transactions in your own node. It didn't stop rebroadcasting (for a month) until I passed in walletbroadcast=0 which seems a bit overkill
323 2017-12-11 23:44:22	0|gmaxwell|jb55: I know, my point was that even if _you_ stop, the reciever will keep going, as will random people on the network who rebroadcast other people's transactions for unclear reasons.
324 2017-12-11 23:44:46	0|gmaxwell|I think it's reasonable to have a way to stop, but at the same time don't expect it to be very useful.