1 2015-05-30 01:53:07 <Luke-Jr> lol, even with reddit spamming transactions, my transaction with a minimum fee gets in the very next block :P
  2 2015-05-30 02:01:39 <kryo_> i assume reddit is doing their spamming manually
  3 2015-05-30 02:33:05 <Luke-Jr> hm, we should probably fix the min fee defaults before too many miners update
  4 2015-05-30 03:50:43 <justanotheruser> Seriously, the entire "fee market" is going to be a complete trial-and-error mess for end users -- especially when compounded by the never-ending delays and other payment nightmares caused by full blocks.
  5 2015-05-30 03:50:52 <justanotheruser> oops... didn't mean to paste that
  6 2015-05-30 03:51:03 <justanotheruser> (also not my words)
  7 2015-05-30 03:53:34 <gmaxwell> things like RBF (safemode) would largely address that; but chicken and egg.  We had a lot of development of things like RBF and CFPF in 2013 when blocks were at the soft limits; but without real pressure there is little interest.
  8 2015-05-30 03:54:30 <justanotheruser> once again, not my words :P
  9 2015-05-30 05:10:35 <GAit> even with RBS safemode there's still wait-error mess for end users that don't have more inputs to spend and can't adjust change
 10 2015-05-30 05:37:21 <gmaxwell> GAit: At one point there was a suggestion of being able to flag outputs as RBS-able on an output by output basis, which would actually let you adjust change down.
 11 2015-05-30 05:37:54 <gmaxwell> But I think that got dropped from recent discussions because there is no 'tidy' place to encode that in ordinary transactions.
 12 2015-05-30 05:38:41 <gmaxwell> perhaps a safe-mode RBF would still be sufficiently safe if any diminishment of an output moved output to fee?
 13 2015-05-30 05:44:25 <GAit> gmaxwell: seem reasonable, what are its weaknesses? that I could decide to punish someone I just paid and send all/most of its output to fee
 14 2015-05-30 05:45:18 <GAit> maybe you should be able to reduce only to the output you can prove control of, a bit like child pays for parent minus the new transaction
 15 2015-05-30 06:02:39 <GAit> flagging doesn't seem tidy from a user experience prospective either. I can't imagine wallet showing to users that they received an RBF enabled transaction or a normal one. I don't see the point of safe RBF, doesn't solve the problem for people that spent the only input they had and still doesn't seem to work if you have to update the fee twice and don't have another spare input and last, I think it doesn't make too much sense because i
 16 2015-05-30 06:12:44 <gmaxwell> GAit: I think it could be okay. e.g. a wallet could supress displaying any non-RFB safe 0 conf outputs.
 17 2015-05-30 06:18:38 <GAit> but RBF-safe transactions would be displayed and meanwhile they could get dropped from mempool and double spent anyway, is that too far fetched?
 18 2015-05-30 06:20:27 <gmaxwell> thats one of the arguments against safe-mode RBF generally; that it furthers misunderstanding about the safty of zero-conf transactions.
 19 2015-05-30 06:21:12 <gmaxwell> (I dealt with a large merchant not so long ago who thought they were getting RBFed in the network. even though no notable miners have it deployed, just because they hadn't internalized the notion that mempools are inherently inconsistent)
 20 2015-05-30 06:28:44 <GAit> gmaxwell: yes, the fact that miner are free to use a RBF branch regardless of what default policy bitcoin core uses and the fact that mempool could get full should be enough for everyone in the space, especially merchants, exchanges and payment processors to handle these cases and understand zero-conf safety risks. Hence I do not see a point in safe-mode RBF. It's interesting to discuss but makes core and wallet code much more complicat
 21 2015-05-30 06:32:37 <gmaxwell> GAit: Safe-mode RBF is a political compromise over full RBF; the latter of which cause full on anaphylactic shock for those who think zero-conf is "mostly safe", which mostly enables an application of RBF that virtually everyone could agree with.
 22 2015-05-30 06:33:28 <gmaxwell> (even on my part, I do regard the kinda sorta safty of zero conf as a feature that its sad to degrade; but perhaps I'm being foolish: I also know that overconfidence in zero-conf has aided a fair amount of loss)
 23 2015-05-30 06:34:13 <GAit> maybe default should be AS-IS with easy flag for miners to pick full RBF or safe-RBF as they wish
 24 2015-05-30 06:34:14 <Luke-Jr> gmaxwell: I wonder if things would have been better if Bitcoin had explicitly supported reversable transactions using lock time
 25 2015-05-30 06:34:30 <midnightmagic> I don't think anyone cares much about that, not really. People can be pretty mercenary about whose fault it is if someone loses money as a result of some kind of RBF mechanism.
 26 2015-05-30 06:34:45 <Luke-Jr> GAit: yes, we've been gradually getting to split off policy code from the rest
 27 2015-05-30 06:35:31 <midnightmagic> I mean who blames anyone but mybitcoin for example.
 28 2015-05-30 06:36:14 <gmaxwell> GAit: well the argument against that is if any substantial amount of hashpower is running RBF then the most safe thing is for everyone to run it... because consistency makes things generally safer, and also because if everyone runs it people can use the 'scortched earth' (and the threat that someone might scortched earth, even if most dont) is a discouragement.
 29 2015-05-30 06:36:16 <GAit> gmaxwell: all i am saying is that even if bitcoin core goes safe-RBF, political compromise or not, everyone will need to handle both RBF and safe-RBF
 30 2015-05-30 06:37:08 <GAit> gmaxwell: but given RBF is not part of consensus the only limit at the moment is that you have to compile yourself some branch
 31 2015-05-30 06:37:57 <GAit> all it takes is someone to provide nice deterministic builds and some devs supporting it and more miners could already start using it
 32 2015-05-30 06:38:45 <Luke-Jr> gmaxwell: it's not developers' place to be forcing policy decisions on people, regardless of benefits/costs
 33 2015-05-30 06:40:11 <gmaxwell> Luke-Jr: not sure how you translate that into forcing.
 34 2015-05-30 06:40:33 <gmaxwell> We're also not required to spend our time developing or supporting features we think are ill advised.
 35 2015-05-30 06:40:35 <Luke-Jr> gmaxwell: argument against making it practical to run RBF?
 36 2015-05-30 06:40:51 <Luke-Jr> sure, but some of us think it's a good idea
 37 2015-05-30 06:41:02 <gmaxwell> People are free to apply patches. (and I suppose I'd be in support of general refactoring that made it easier to maintain patches)
 38 2015-05-30 06:41:37 <GAit> so having three options, as is, RBF and safe-RBF would never be considered for merge?
 39 2015-05-30 06:41:41 <GAit> too risky?
 40 2015-05-30 06:41:53 <GAit> run time options
 41 2015-05-30 06:42:16 <GAit> even compile time option is better than what we got today actually
 42 2015-05-30 06:42:19 <gmaxwell> policy fragmentation generally decreases the utility of the network. I'd prefer to not lead fragmentation.
 43 2015-05-30 06:42:35 <gmaxwell> If things are already fragmented by peoples will, thats another matter.
 44 2015-05-30 06:42:40 <GAit> i thought the whole point of what is not part of consensus is that it can be fragmented
 45 2015-05-30 06:43:32 <wumpus> yes, it *can* be
 46 2015-05-30 06:43:52 <GAit> and i understood that diversity is good too
 47 2015-05-30 06:43:53 <gmaxwell> It's not black and white, for example, if the network has a mix of A and B then only their intersection will propagate well, and anything else is more vulnerable to surprise double spend races than you might otherwise expect.   So yes, it _can_ be fragmented, but the fragmentation has costs.
 48 2015-05-30 06:43:58 <wumpus> that doesn't bind anyone to do anything
 49 2015-05-30 06:44:22 <GAit> diversity -> decentralization
 50 2015-05-30 06:44:23 <felipelalli> gmaxwell: agreed.
 51 2015-05-30 06:44:39 <Luke-Jr> perhaps the ideal is to load a .so for policy, and have each policy be a separate codebase/repo
 52 2015-05-30 06:44:58 <gmaxwell> like most things in engineering its a mixed bag.  Policy diversity has advantages (less control over policy) and disadvantages (propagation is harder to predict).
 53 2015-05-30 06:45:00 <wumpus> lots of practical issues with that
 54 2015-05-30 06:45:36 <wumpus> Luke-Jr: a more realistic proposal would be to have it out-of-process
 55 2015-05-30 06:45:44 <gmaxwell> and inconsistent policy has other negative effects, e.g. if policy is too hard to predict it encourages people to connect to every reachable node just in the hopes of not being silently partitioned from the same policy they have.
 56 2015-05-30 06:46:47 <gmaxwell> when policy differes over 'weird' or 'rare' things already, I think thats mostly beneficial. When it treads into common every day behaviors the costs are more painful.
 57 2015-05-30 06:47:22 <wumpus> eg make it possible to run a separate bitcoinpolicyd that communicates with bitcoind and makes those decisions. Not that I'm advocating that, just that loading dynamic libraries is not feasible. Another option would be to integrate a python/lua interpreter for this kind of stuff *ducks*
 58 2015-05-30 06:47:26 <Luke-Jr> wumpus: maybe.
 59 2015-05-30 06:47:37 <gmaxwell> If policy were more codifyable, peers could tell you their policy, or even the intersection of ther policy with the most permissive of their own peers other than you.
 60 2015-05-30 06:47:46 <GAit> because nodes or wallets that want RBF or even safe-RBF behaviour would have to connect to more nodes to get the transactions to propagate
 61 2015-05-30 06:47:46 <wumpus> but I think gmaxwell's position is, in general, pretty convicing
 62 2015-05-30 06:48:06 <Luke-Jr> loading dynamic libraries is much easier than a separate process :p
 63 2015-05-30 06:48:28 <wumpus> Luke-Jr: not if your frigging executables are statically linked
 64 2015-05-30 06:48:35 <GAit> so it would be better to have RBF behaviour everywhere than just few (miner?) nodes?
 65 2015-05-30 06:48:38 <Luke-Jr> wumpus: well, they never should be <.<
 66 2015-05-30 06:48:48 <gmaxwell> GAit: or even want to hear about if it RBF nodes have replaced a transaction they think will go through.
 67 2015-05-30 06:49:02 <GAit> right
 68 2015-05-30 06:49:41 <gmaxwell> yes, there is an argument that RBF is strictly superior as a realy policy even when you oppose it for mining.
 69 2015-05-30 06:50:04 <Luke-Jr> gmaxwell: well, if *nobody* mines RBF, it's not.
 70 2015-05-30 06:50:11 <Luke-Jr> then it just becomes a DoS vector
 71 2015-05-30 06:51:00 <gmaxwell> Luke-Jr: it is, because it makes it more likely that you'll know about a race in the network;  and wrt DOS the basic RBF requires you to increment the fee by the relay fee amount. So it doesn't allow a sigifnicant traffic amplification over what you could do anyways.
 72 2015-05-30 06:51:27 <gmaxwell> of course it loses its visiblity advantage due to that too.. someone trying to race will just avoid triggering RBF.
 73 2015-05-30 06:51:49 <gmaxwell> and without the fee increment rule its a trivial four-lines-of-python-takes-out-the-network vulnerability.
 74 2015-05-30 06:52:13 <Luke-Jr> gmaxwell: start with 10 BTC, minimum fee; that will get mined because miners saw it first.
 75 2015-05-30 06:52:33 <gmaxwell> Luke-Jr: oh .. fair point.
 76 2015-05-30 06:52:34 <Luke-Jr> now you can increment the fee by the relay amount until you read 10 BTC, without needing to worry
 77 2015-05-30 06:52:44 <Luke-Jr> s/read/reach/
 78 2015-05-30 06:53:11 <gmaxwell> I wasn't thinking clearly, I agree. If _no one_ RBFs at all, it's again a trivial DOS.
 79 2015-05-30 06:53:24 <gmaxwell> though, perhaps a bit fragle, someone would start RBFing!
 80 2015-05-30 06:53:57 <wumpus> Luke-Jr: also .so plugins are a segfault proven factory, at least with an external backend process it's more robust, and possible to define a clean communication protocol, which other applications could use too
 81 2015-05-30 06:54:08 <wumpus> proven segfault factory*
 82 2015-05-30 06:54:54 <gmaxwell> I've suggested an external process before.. e.g. to enable captcha instead of fee.
 83 2015-05-30 06:55:15 <gmaxwell> though ... doubt that will happen ever; three years ago it was a cute idea, but we're past that state.
 84 2015-05-30 06:55:39 <Luke-Jr> wumpus: yes, we'll need shared libraries to get there still
 85 2015-05-30 06:56:20 <gmaxwell> Luke-Jr: you mean for bitcoin core itself?
 86 2015-05-30 06:56:41 <wumpus> Luke-Jr: I'm not against shared libraries!
 87 2015-05-30 06:56:45 <Luke-Jr> gmaxwell: it's not reasonable to duplicate the transaction parsing code between Core and an external policy process
 88 2015-05-30 06:56:54 <wumpus> Luke-Jr: just against dynamic loading of third party code
 89 2015-05-30 06:57:04 <wumpus> e.g. plugins
 90 2015-05-30 06:57:08 <Luke-Jr> even if we accept the overhead of serialise+deserialise constantly
 91 2015-05-30 06:57:26 <gmaxwell> Luke-Jr: I agree that the subprocess should be linking bitcoin core.
 92 2015-05-30 06:58:14 <Luke-Jr> wumpus: in practice, I'm not sure it's significantly different from a separate process though
 93 2015-05-30 06:58:25 <wumpus> gmaxwell: for the utility functions etc it could link some library from bitcoin core, sure
 94 2015-05-30 06:58:26 <Luke-Jr> if the policy code is malicious, it will just ptrace bitcoind
 95 2015-05-30 06:58:40 <gmaxwell> Luke-Jr: it couldn't on my system
 96 2015-05-30 06:58:49 <wumpus> Luke-Jr: if it runs at the same user (and you don't have this fancy ptrace protection enabled)
 97 2015-05-30 06:59:08 <gmaxwell> standard linux desktops (not just hardened gentoo) have ptrace protection now, in fact.
 98 2015-05-30 06:59:12 <wumpus> (which Ubuntu enabld by default, so I have to disable it every time when I want to attach to debug...)
 99 2015-05-30 06:59:25 <Luke-Jr> interesting
100 2015-05-30 07:00:11 <Luke-Jr> ok, didn't know that
101 2015-05-30 07:00:13 <gmaxwell> part of the reason that I want to process sep the wallet in the long term is to use selinux to make it so that the wallet is the only thing on the system that can access the wallet. :) and the wallet can only talk to the full node and nothing else. etc.
102 2015-05-30 07:00:41 <wumpus> it's a useful protection, but also annoying, i wish there was a way to selectively disable the protection for say, a gdb process, so that it doesn't have to be disabled globally
103 2015-05-30 07:00:47 <gmaxwell> plus malicious is a wide description. I can much more easily add a subtle bug that creates a backdoor, than I can get people to run something that randomly ptraces stuff. :)
104 2015-05-30 07:01:28 <Luke-Jr> having it an external process makes Python policies easier too
105 2015-05-30 07:01:45 <gmaxwell> wumpus: there is, at least with selinux controlling it (not sure how it works in ubuntu) you can just make a single gdb binary that bypasses it. (and/or set it up just so you can newroll, authenticate, and run whatever debuggers you want)
106 2015-05-30 07:01:52 <Luke-Jr> (for example! not that I recommend Python :P)
107 2015-05-30 07:01:54 <wumpus> (without running gdb as root, which is kind of risky, wouldn't be the first explitable issue in dedug information processing, or gdb's scripting)
108 2015-05-30 07:02:54 <wumpus> gmaxwell: cool, didn't know that
109 2015-05-30 07:07:56 <Luke-Jr> fwiw, the fee-less tx I sent during /r/Bitcoin's spamfest took ~6 hours to get mined.
110 2015-05-30 07:09:06 <midnightmagic> my fee'd tx took just a few blocks, i think
111 2015-05-30 07:10:43 <Luke-Jr> my fee'd one was in the very next block
112 2015-05-30 07:12:02 <midnightmagic> pointless tantrum is pointless
113 2015-05-30 07:12:38 <Luke-Jr> well, it reaffirms my view that we're nowhere near "full block" troubles at least.
114 2015-05-30 07:13:23 <gmaxwell> we already went through 'full blocks' in 2013. Not sure why people are doing this stuff without analyizing the expirence from before.
115 2015-05-30 07:13:56 <Luke-Jr> gmaxwell: it's reddit :p
116 2015-05-30 07:14:33 <gmaxwell> if people want to test full blocks they should go convince the couple miners producing >750 k ones to drop to 500; which would actually leave things with standing pressure; I think.
117 2015-05-30 07:15:25 <gmaxwell> but its sort of pointless to 'test' without getting wallets fixed. since we know what will happen if there really is standing pressure: people on some wallets will be irritated until they get fixed.
118 2015-05-30 07:15:49 <Luke-Jr> gmaxwell: yeah, one comment to me was basically "my wallet won't let me pay a reasonable fee"
119 2015-05-30 07:15:55 <gmaxwell> otoh, one could honestly say creating pressure to get those wallets to fix themselves.
120 2015-05-30 07:16:50 <gmaxwell> Luke-Jr: yea, right now ~all wallet vendors (bitcoin core included) are somewhat guilty of outsourcing the cost of good fee handling onto the users.
121 2015-05-30 07:17:32 <gmaxwell> e.g. having a situation where users constantly pay higher fees than they should, or too low and suffering when they don't go through; without clean and smart handling, etc.
122 2015-05-30 07:17:43 <gmaxwell> but it's hard to prioritize doing better when its not necessary right now.
123 2015-05-30 07:19:24 <Luke-Jr> gmaxwell: no, I mean apparently Breadwallet and mycelium literally do not let users choose their fee at all
124 2015-05-30 07:19:35 <Luke-Jr> they will use a too low fee and you cannot at any point tell them to pay more
125 2015-05-30 07:20:03 <gmaxwell> ugh, not that "let the user choose" is actually an answer either (of course it should allow it, but if the user has to you've already failed)
126 2015-05-30 07:21:26 <Luke-Jr> I was tempted today to try to teach Core to allow respend attempts, but then I remembered .. wallet code :P
127 2015-05-30 07:21:49 <gmaxwell> it's not so bad!
128 2015-05-30 07:22:25 <gmaxwell> Wallet _testing_ otoh...
129 2015-05-30 07:22:30 <Luke-Jr> maybe not, but it's certainly more time than the few hours I was considering spending on it
130 2015-05-30 07:24:55 <justanotheruser> has reddit yet concluded that if you spam the network, your low/no fee transactions aren't confirmed next block and the sky is falling?
131 2015-05-30 07:28:53 <justanotheruser> oops wrong channel
132 2015-05-30 07:39:28 <btcdrak> luke-jr: you could have a kind of basic "policy scripting language" where you can define policies in a configuration file loaded by bitcoind. Then you could take out all the relay policy code from bitcoin core entirely.
133 2015-05-30 07:39:54 <Luke-Jr> btcdrak: maybe. I don't think we know all the possible policies yet, though.
134 2015-05-30 08:05:48 <wumpus> gmaxwell: "sudo setcap cap_sys_ptrace=eip /usr/bin/gdb" should be enough to let e.g. gdb bypass the ptrace restriction (note: haven't tested yet)
135 2015-05-30 08:11:47 <Luke-Jr> wumpus: fork&exec gdb :D
136 2015-05-30 08:31:35 <wangchun> What is bitcoin xt? does it 100% compatible with bitcoin core?
137 2015-05-30 08:38:36 <Luke-Jr> wangchun: at the moment.
138 2015-05-30 08:38:55 <wangchun> Luke-Jr: I see. Just checked the source code.
139 2015-05-30 08:39:40 <wangchun> Is Gavin planning to increase max block size on XT first, before the deployment on Bitcoin Core?
140 2015-05-30 08:40:20 <justanotheruser> wangchun: he probably couldn't manage to increase the block size in Bitcoin Core at all
141 2015-05-30 08:41:32 <wangchun> If blocks becoming full, why not increase default max block size first? Most pools just leave default value as is.
142 2015-05-30 08:49:31 <Luke-Jr> wangchun: it's not a default.
143 2015-05-30 08:49:35 <Luke-Jr> wangchun: it's a consensus rule.
144 2015-05-30 08:49:47 <Luke-Jr> wangchun: if XT doesn't enforce 1 MB, then it has a critical consensus bug
145 2015-05-30 09:02:02 <wangchun> Luke-Jr: No, I mean most pool now at 750KB
146 2015-05-30 09:02:17 <wangchun> static const unsigned int DEFAULT_BLOCK_MAX_SIZE = 750000;
147 2015-05-30 09:02:20 <Luke-Jr> wangchun: would be nice if it was 500 kB
148 2015-05-30 09:56:48 <LeMiner> You are advocating against satoshi dice/dust/fee paying transactions but enforcing a minimum block size that'd fill up some blocks with hot air is not a problem? heh
149 2015-05-30 09:56:54 <LeMiner> @luke
150 2015-05-30 12:03:15 <maaku> Feedback is requested on a first draft of the BIP describing relative lock-time via sequence numbers : https://gist.github.com/maaku/be15629fe64618b14f5a
151 2015-05-30 15:08:13 <Happzz> i dont expect anyone to change world orders because of this, but i decided to stop running bitcoin-core with its 40gb database. i find it ridiculously large and not needed.
152 2015-05-30 15:09:29 <Happzz> i dont see any reason to keep ALL of the history. there can be a concensus about the last N blocks, this can be in the thousands and keep a reasonable database size.
153 2015-05-30 15:59:12 <wumpus> Happzz: this is really #bitcoin barter and not -dev but anyway: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes.md#block-file-pruning   master and 0.11 (to be released soon) will support pruning
154 2015-05-30 16:46:50 <kanzure> "because if a miner is stupid enough to not arrange to be directly or almost-directly connected to most of the other miners (preferably via Matt Corallo's fast relay network) then they deserve to go out of business."
155 2015-05-30 16:46:57 <kanzure> hmm i wonder if exclusion could happen there
156 2015-05-30 17:03:03 <XiaronFlux> is this the offical bitcoin dev channel or are there others?
157 2015-05-30 17:24:08 <dgenr8> of what possible value would it be to advertise the relay policy you would like people to think you follow?
158 2015-05-30 17:25:13 <harding> dgenr8: so like-minded relayers/miners could connect to you?
159 2015-05-30 17:25:30 <dgenr8> you mean could connect to who you claim to be?
160 2015-05-30 17:26:15 <harding> dgenr8: I guess.  Is this a random hypothetical or part of an on-going conversation?
161 2015-05-30 17:26:55 <harding> Oh, I see in scrollback.
162 2015-05-30 17:29:51 <dgenr8> otoh, if node software declared "must-relay" transaction set, pairs of nodes could test for compliance and ban non-compliant nodes
163 2015-05-30 17:35:31 <dgenr8> "must-relay" transactions would gain reliability from this
164 2015-05-30 17:35:49 <dgenr8> bbl
165 2015-05-30 19:28:57 <Luke-Jr> cfields: ugh, src/bitcoin-config.h keeps getting recreated when I build old versions. would be nice to once and for all add code to delete it :P
166 2015-05-30 19:41:12 <jonasschnelli> Luke-Jr: you probably wan't to rebase #6201. Your last commit below you change commit is from dec. 2014!
167 2015-05-30 19:41:39 <Luke-Jr> jonasschnelli: I just intentionally rebased it there.
168 2015-05-30 19:41:46 <Luke-Jr> jonasschnelli: it merges cleanly to master and 0.10 now
169 2015-05-30 19:41:56 <jonasschnelli> ah. Okay.
170 2015-05-30 19:42:47 <Luke-Jr> (not implying it needs to or should be backported)
171 2015-05-30 20:37:10 <hulkhogan_> sdaftuar: just wondering for myself, have you made much progress porting the comparisontool tests to python? I saw more complaining in recent days on GH about it bugging out, so i'm guessing it still needs to be looked at
172 2015-05-30 20:40:16 <hulkhogan_> i was considering reopening 6119 if i end up making progress on debugging, i just havent gone through to see how serious this batch of issues were, yet