1 2015-07-13 00:43:11 <harding> sfultong: all of the release signing keys are listed and linked here: https://bitcoin.org/en/download
  2 2015-07-13 00:45:33 <sfultong> harding: huh? The file signatures are available at https://bitcoin.org/bin/bitcoin-core-0.11.0/SHA256SUMS.asc, but not the developer keys or the release signing key
  3 2015-07-13 00:46:00 <harding> sfultong: see the page I just linked to, search for "Bitcoin Core Release Signing Keys"
  4 2015-07-13 00:46:29 <sfultong> ah, sorry
  5 2015-07-13 00:47:01 <harding> The rest of the core devs keys (for email) can be found here: https://bitcoin.org/en/development
  6 2015-07-13 00:47:43 <sfultong> thanks
  7 2015-07-13 00:47:49 <harding> np
  8 2015-07-13 00:49:35 <sfultong> I'm also having trouble verifying http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009045.html
  9 2015-07-13 00:51:50 <harding> sfultong: he sent three messages; two of them had broken signatures (utf-8 conversion problems).  The third message is validly signed.
 10 2015-07-13 00:52:16 <sfultong> ah, cool. Is that message publicly posted somewhere?
 11 2015-07-13 00:52:35 <harding> Oh.  That message.  That signature checked out for me.
 12 2015-07-13 00:53:07 <harding> (At least via actual email.)
 13 2015-07-13 00:53:30 <sfultong> hmmm... I assume the problem is on my end
 14 2015-07-13 00:53:33 <sfultong> line-endings?
 15 2015-07-13 00:54:25 <harding> sfultong: here, try the text from here: https://github.com/bitcoin-dot-org/bitcoin.org/pull/924
 16 2015-07-13 00:54:32 <harding> I just checked it again, and it works.
 17 2015-07-13 00:54:58 <phantomcircuit> gmaxwell, actually with the addrKnown being a trolling bloomfilter, I'm not sure we need to be clearing the set at all
 18 2015-07-13 01:02:17 <sfultong> harding: excellent, thanks. That works for me as well
 19 2015-07-13 01:02:36 <phantomcircuit> rolling*
 20 2015-07-13 01:02:37 <phantomcircuit> har
 21 2015-07-13 01:03:24 <harding> sfultong: great!  Thanks for checking to make sure everything was correct!
 22 2015-07-13 01:08:01 <sfultong> harding: just doing my due diligence as an unofficial package maintainer for nixos
 23 2015-07-13 01:35:08 <phantomcircuit> sipa, for the trickle logic stuff
 24 2015-07-13 01:37:33 <phantomcircuit> it seems like something more sophisticated than merely fixing the trickling is necessary
 25 2015-07-13 01:44:30 <phantomcircuit> CAddrMan::GetAddr should probably take a seed as input and sort the addresses it knows about using the seed before responding such that a single peer flooding getaddr requests will simply get back the same results
 26 2015-07-13 02:19:17 <sipa> phantomcircuit: yeah, that's an independent problem we need to fix
 27 2015-07-13 02:34:02 <leakypat> petertodd: you around?
 28 2015-07-13 02:34:26 <petertodd> leakypat: yup
 29 2015-07-13 02:34:58 <leakypat> Just thinking through the implications on spending unconfirmed change etc. In the wallet
 30 2015-07-13 02:35:07 <leakypat> With full RBF
 31 2015-07-13 02:35:19 <petertodd> leakypat: oh, as in, the sender might double-spend you
 32 2015-07-13 02:35:20 <petertodd> ?
 33 2015-07-13 02:35:45 <leakypat> If transaction a returns change b to me and I spend change b to person c
 34 2015-07-13 02:35:55 <petertodd> leakypat: right
 35 2015-07-13 02:35:56 <leakypat> Then I RBF transaction a
 36 2015-07-13 02:36:05 <leakypat> I need to work down the chain
 37 2015-07-13 02:36:08 <sipa> yup
 38 2015-07-13 02:36:12 <leakypat> And RBF all dependencies
 39 2015-07-13 02:36:16 <petertodd> leakypat: ah, but see, with full-rbf, ratehr than making two txs, you'd replace tx1 with tx1b spending funds to b and c
 40 2015-07-13 02:36:20 <petertodd> *rather
 41 2015-07-13 02:36:29 <sipa> you need to look at what you're removing, and what you're adding
 42 2015-07-13 02:36:33 <petertodd> leakypat: equally, if you started with two txs, do that :)
 43 2015-07-13 02:36:56 <sipa> and what you're adding needs to pay for everything (and improve the situation in terms of feerate for those accepting it)
 44 2015-07-13 02:37:31 <leakypat> if I run out of change outs it perhaps won't
 45 2015-07-13 02:37:40 <petertodd> leakypat: run out? what do you mean?
 46 2015-07-13 02:37:46 <leakypat> Ie if I need to add another input somewhere down the chain
 47 2015-07-13 02:37:58 <petertodd> leakypat: ah, because your change output is exhausted?
 48 2015-07-13 02:37:58 <sipa> so?
 49 2015-07-13 02:38:01 <leakypat> Yeah
 50 2015-07-13 02:38:18 <sipa> there's no problem with adding another input
 51 2015-07-13 02:38:20 <squidicuz> ...I liked the icons in pre 0.11 better, was more colorful ._.
 52 2015-07-13 02:38:29 <petertodd> leakypat: you're still (very likely) in a situation where replacing tx1a with tx1b with another input and output is more efficient
 53 2015-07-13 02:39:19 <leakypat> Also the case where if someone receives an output from me and their wallet allows them to spend unconfirmed and I RBF
 54 2015-07-13 02:39:33 <petertodd> leakypat: this will be particularly true if the p2p protocol is changed to support tx deltas - as in create tx1b from tx1a and some (small) delta
 55 2015-07-13 02:40:03 <petertodd> leakypat: yeah, as always, don't trust incoming txs until they're confirmed - most wallets work that way and don't let you respend unconfirmed incoming payments
 56 2015-07-13 02:40:24 <petertodd> leakypat: that said, bumping fees via cpfp in that case is fine
 57 2015-07-13 02:40:45 <leakypat> Hmm, mine allows spending unconfirmed and so does breadwallet
 58 2015-07-13 02:40:50 <leakypat> Not sure about mycelium
 59 2015-07-13 02:40:58 <petertodd> leakypat: mycelium doesn't IIRC
 60 2015-07-13 02:41:07 <petertodd> leakypat: do recognise that doing that just isn't all that safe...
 61 2015-07-13 02:41:11 <leakypat> (I got tons of complaints for not doing so)
 62 2015-07-13 02:41:18 <petertodd> leakypat: not surprised :(
 63 2015-07-13 02:41:47 <petertodd> leakypat: we need an addition to the payment protocol or something that lets receivers say "we're really counting on this tx; double-spend it and we'll consider it fraud"
 64 2015-07-13 02:41:52 <leakypat> I was musing the nVersion thing
 65 2015-07-13 02:41:55 <leakypat> Exactly
 66 2015-07-13 02:42:07 <leakypat> I was thinking qr codes would have a parameter
 67 2015-07-13 02:42:17 <petertodd> leakypat: oh, for marking full-rbf txs?
 68 2015-07-13 02:42:42 <leakypat> Yep, so a merchant that requires confirmations flags the qr code as rbfable
 69 2015-07-13 02:42:57 <leakypat> A merchant that allows unconfirmed flags it as non rbfable
 70 2015-07-13 02:43:10 <leakypat> Or whichever way round the default is
 71 2015-07-13 02:43:37 <petertodd> leakypat: I think using nVersion for this sends a bad message; nSequence is a much better option
 72 2015-07-13 02:43:47 <leakypat> Sorry that's what I meant
 73 2015-07-13 02:44:29 <leakypat> From the users pout of view of a merchant accepts non conf, I don't care how long it takes to confirm
 74 2015-07-13 02:44:38 <leakypat> That's the merchants problem, I can still spend my change
 75 2015-07-13 02:44:46 <petertodd> leakypat: cool - I'm going to change that pull-req to make full-rbf a command line flag, (default off) and then have a separate one that does the nSequence behavior
 76 2015-07-13 02:45:03 <leakypat> But if I am buying flowers online for my mums birthday tomorrow and they require confs and it's stuck
 77 2015-07-13 02:45:08 <petertodd> leakypat: yup
 78 2015-07-13 02:45:12 <leakypat> I need to RBF and the merchant would want  me too also
 79 2015-07-13 02:45:36 <petertodd> leakypat: looks good
 80 2015-07-13 02:45:43 <leakypat> Ok
 81 2015-07-13 02:46:14 <leakypat> I think some kind of bip for a qr code parameter would be good
 82 2015-07-13 02:46:25 <leakypat> To allow wallets and payment processors to standardize
 83 2015-07-13 02:46:32 <petertodd> leakypat: yeah, that'd be appropriate w/ a scorched earth implementation IMO
 84 2015-07-13 02:47:25 <leakypat> There needs to be a way to abstract this from the users somewhat
 85 2015-07-13 02:48:19 <petertodd> leakypat: indeed - though do recognise that you can only go so far with abstraction here - bitcoin will fundementally be not as easy as paypal for many things
 86 2015-07-13 02:48:28 <leakypat> From the wallet maybe they will wonder: hmm, why can't I increase the fee on this transaction ? Ie they just bought a beer with an unconfirmed accepting merchant
 87 2015-07-13 02:48:36 <petertodd> leakypat: abstractions that cause people to lose money in favor of them getting confused are problematic...
 88 2015-07-13 02:48:51 <petertodd> leakypat: yup, full-rbf is much nicer there
 89 2015-07-13 02:48:54 <leakypat> But when they buy flowers online they will see the increase fee option
 90 2015-07-13 02:49:09 <Luke-Jr> petertodd: use the low bit -.-
 91 2015-07-13 02:49:12 <Luke-Jr> of amount
 92 2015-07-13 02:49:13 <leakypat> Yeah, for me FSS is not really feasible for ux
 93 2015-07-13 02:49:15 <petertodd> Luke-Jr: bad for privacy
 94 2015-07-13 02:49:20 <Luke-Jr> petertodd: … how?
 95 2015-07-13 02:49:26 <leakypat> Full RBF all the way
 96 2015-07-13 02:49:35 <petertodd> Luke-Jr: people will implement it in ways that make the change addr obvious
 97 2015-07-13 02:49:51 <Luke-Jr> petertodd: well, yeah. that's kinda the goal.
 98 2015-07-13 02:49:54 <petertodd> leakypat: agreed! might make sense for you to implement full-rbf by default; with size-limited mempools it's still useful
 99 2015-07-13 02:50:11 <Luke-Jr> petertodd: using sequence tags the entire tx, which makes it not practical to really use ever
100 2015-07-13 02:50:11 <petertodd> Luke-Jr: well, I'm not implementing anything with that kind of privacy issue, complete non-starter to me
101 2015-07-13 02:50:32 <Luke-Jr> (you can't use it ever because merchants won't take it)
102 2015-07-13 02:51:09 <petertodd> Luke-Jr: look, this is a temporary measure, given I fully expect full-rbf to become adopted by a % of hashing power sufficient to make it effective
103 2015-07-13 02:51:21 <petertodd> Luke-Jr: I am *not* designing systems with big privacy issues, end of story
104 2015-07-13 02:52:45 <gmaxwell> petertodd: there are all sorts of transaction set subsetting idenfiers now.. and they seem to be going up instead of down. Heck, taking a hardline position on this would have you reject multisig... stealth addresses.. nlocktime... and so on.
105 2015-07-13 02:53:02 <petertodd> gmaxwell: sure, but I'm not adding to that set
106 2015-07-13 02:53:18 <sipa> gmaxwell: still a difference between being able to identify software and being able to gratuitously identify change
107 2015-07-13 02:53:34 <petertodd> sipa: +1
108 2015-07-13 02:53:42 <gmaxwell> oh sorry, missed the context.
109 2015-07-13 02:53:53 <petertodd> np
110 2015-07-13 02:53:59 <gmaxwell> I misunderstood that.  I thought it was a question of marking whole transactions FSS or not.
111 2015-07-13 02:54:13 <petertodd> gmaxwell: yup, and even that I expect will be a temporary thing
112 2015-07-13 02:54:34 <gmaxwell> Whole transactions seem reasonable to me. I agree that change shouldn't be marked.
113 2015-07-13 02:54:53 <phantomcircuit> hmm actually
114 2015-07-13 02:55:16 <phantomcircuit> the current behavior is to relay a received addr to a deterministic set of peers upon receiving the addr
115 2015-07-13 02:55:31 <phantomcircuit> that's almost certainly not really what we want to do
116 2015-07-13 02:55:37 <phantomcircuit> but changing it could partition the network
117 2015-07-13 02:55:38 <phantomcircuit> :|
118 2015-07-13 02:57:29 <petertodd> phantomcircuit: received addr as in the gossiping of ip addrs?
119 2015-07-13 02:57:35 <sipa> phantomcircuit: deterministically random based on day and address
120 2015-07-13 02:57:55 <sipa> every addr goes to different peers
121 2015-07-13 02:58:08 <sipa> just the same address always goes to the same peers, during a 24-hour window
122 2015-07-13 02:59:37 <phantomcircuit> petertodd, yeah
123 2015-07-13 02:59:48 <phantomcircuit> sipa, yup i get it
124 2015-07-13 02:59:59 <sipa> how is that bad?
125 2015-07-13 03:02:35 <phantomcircuit> sipa, gossiping this was doesn't seem ideal since someone can pretty easily get us to gossip a bunch of nonsensical peers
126 2015-07-13 03:02:46 <phantomcircuit> or am i missing a filter for that?
127 2015-07-13 03:46:57 <leakypat> petertodd: just reread the conversation before; the merging transaction thing is v interesting , I hadn't thought of that, a wallet could function by merging new tx with existing unconfirmed tx
128 2015-07-13 03:57:08 <leakypat> That would work very nicely as it would be the balance of your wallet that would get confirmed rather than a bunch of transactions
129 2015-07-13 03:57:41 <leakypat> And any fee bumping would just be done the entire unconfirmed balance
130 2015-07-13 03:57:59 <leakypat> (Within reason, of course there are limit to the tx size etc)
131 2015-07-13 04:46:50 <leakypat> (*by balance I mean balance of outgoing tx)
132 2015-07-13 05:52:50 <dgenr8> what's the point in marking transactions replaceable or not? an attacker can do whatever they want.
133 2015-07-13 05:53:01 <dgenr8> leakypat: you could have merchant specify a minimum fee/kb that he wants to see if he's to deliver the goods quickly.
134 2015-07-13 05:59:56 <devrandom> I'm curious about a possible race condition with inv/getdata
135 2015-07-13 06:00:37 <devrandom> what happens if we get an tx inv, and before we manage to getdata, a block comes in that includes the tx and also spends it
136 2015-07-13 06:00:43 <devrandom> won't the tx be pruned?
137 2015-07-13 06:05:48 <Luke-Jr> dgenr8: the point is so merchants can detect it
138 2015-07-13 06:06:15 <dgenr8> and rely on it somehow?
139 2015-07-13 06:06:43 <Luke-Jr> dgenr8: no, of course not - unconfirmed transactions are inherently unreliable.
140 2015-07-13 06:07:34 <dgenr8> so what good is it
141 2015-07-13 06:10:32 <Luke-Jr> political compromise
142 2015-07-13 06:29:00 <leakypat> dgenr8: it is a way for the merchant to say, I don't trust you, but I trust the miners not to mine any replacement for this transaction because it has a flag on it - so I will accept unconfirmed tx from you as payment
143 2015-07-13 06:30:51 <Luke-Jr> leakypat: which is dumb when you can't use that flag because it breaks fee bumping :P
144 2015-07-13 06:58:20 <devrandom> ignore my question above, I see in main.cpp that the full tx is sent with the block if it wasn't previously sent, even for SPV clients
145 2015-07-13 07:10:01 <wumpus> cfields: is this the right way to add autoconf.sh to the dist archive? https://github.com/bitcoin/bitcoin/pull/6418
146 2015-07-13 07:18:48 <devrandom> hmmm... still seems to be a race condition for SPV clients and inv/getdata/block:
147 2015-07-13 07:19:15 <devrandom> * inv is sent to SPV client (setInventoryKnown is marked)
148 2015-07-13 07:19:44 <devrandom> * block comes in, tx is removed from mempool, SPV client is provided with filtered block which has the tx hash
149 2015-07-13 07:20:12 <devrandom> * tx is not sent after block, because setInventoryKnown is marked
150 2015-07-13 07:20:25 <devrandom> * getdata returns nothing because tx is not in mempool
151 2015-07-13 07:37:52 <Luke-Jr> devrandom: getdata doesn't use the mempool IIRC
152 2015-07-13 07:38:42 <Luke-Jr> it uses mapRelay, which doesn't get cleared AFAIK
153 2015-07-13 07:42:00 <devrandom> Luke-Jr: oh, I see, it first tries mapRelay, then mempool
154 2015-07-13 07:42:12 <Luke-Jr> right
155 2015-07-13 07:45:18 <devrandom> looks like mapRelay has a 15 minute expiration
156 2015-07-13 07:47:48 <devrandom> that should work in sane situations
157 2015-07-13 07:54:26 <devrandom> If an SPV client is on a really bad connection and doesn't manage to get the tx within 15 minutes, then it would need to connect to a new peer and re-start downloading from the block in question.
158 2015-07-13 08:03:43 <jonasschnelli> wumpus: i'm having a look at https://github.com/bitcoin/bitcoin/issues/6426
159 2015-07-13 08:34:10 <wumpus> jonasschnelli: wonder if upgrading the qt version helps
160 2015-07-13 08:34:29 <jonasschnelli> wumpus: yes. Im testing now the qt bump PR (over gitian)
161 2015-07-13 08:34:47 <jonasschnelli> wumpus: I think it's a upstream qt5 issue.
162 2015-07-13 08:35:02 <wumpus> otherwise I think the only way to solve it would be to use custom dbus code to talk to the newfangled notification system, instead of QTrayIcon...
163 2015-07-13 08:35:44 <jonasschnelli> yeah. Which would defeat the idea of cross platform.
164 2015-07-13 08:35:48 <wumpus> I think I have a husk of that around somewhere in my old branches, but I hoped to never need such monstrous measures
165 2015-07-13 08:35:51 <jonasschnelli> 0.11.0 does static build against Qt5.2?
166 2015-07-13 08:36:32 <wumpus> yes 5.2.1
167 2015-07-13 08:37:08 <wumpus> cross-platform GUI is dead anyway. e.g. for osx we already have custom code for noticiation and such.
168 2015-07-13 08:38:02 <wumpus> well it would work with distro-specific packages
169 2015-07-13 08:38:33 <wumpus> which would link to the distro's, but the one-binary idea is dead
170 2015-07-13 08:38:34 <jonasschnelli> hah. Indeed. But still much better than nativ implementation on each platform. I really found out the quality of bitcoin-core's QT GUI is really good with the fact, that we are using just a bunch of platform dependent code lines.
171 2015-07-13 08:39:03 <wumpus> the distro's *qt5*
172 2015-07-13 08:39:12 <wumpus> jonasschnelli: agreed, it's better than doing everything per-platform
173 2015-07-13 08:39:23 <wumpus> that would be completely unrealistic
174 2015-07-13 08:39:48 <wumpus> and the dumbest issue is that qt is supposed to be native-ish on Linux. On Windows, MacOSX it's working fine :p
175 2015-07-13 08:43:04 <wumpus> but bumping qt at least can't hurt.
176 2015-07-13 08:44:34 <wumpus> not surprised to see this on Ubuntu with its specifc Unity tray/noficiation system, but also on Fedora?
177 2015-07-13 08:46:02 <jonasschnelli> wumpus: Hmm.. couldn't reproduce on fedora 21... just couldn't found a way to display the notification area / try area.
178 2015-07-13 08:47:52 <wumpus> jonasschnelli: does this help to show them? https://stackoverflow.com/questions/17460705/the-missing-system-tray-icons-on-fedora-19-desktop-edition
179 2015-07-13 08:48:36 <jonasschnelli> wumpus: was also stumpled over this. Didn't help. <window>-m doesnt show anything. Moving the mouse to the right bottom corner either.
180 2015-07-13 08:48:46 <wumpus> okey
181 2015-07-13 08:53:46 <wumpus> if this means we have to end up with different notification/tray driver APIs *per distro*, I'd rather disable the tray support in the bitcoin.org binary and leave it to distro-specific packages
182 2015-07-13 08:55:30 <jonasschnelli> wumpus: as far as i know most tray systems have been deprecated.
183 2015-07-13 08:55:53 <wumpus> right.
184 2015-07-13 09:11:06 <jonasschnelli> wumpus: just double-checked what happen if i build 0.10.2 with Qt5.2.x... same issue with the tray.
185 2015-07-13 09:17:38 <wumpus> yes, it's a static qt issue
186 2015-07-13 09:18:33 <wumpus> cfields and I have known about it for quite a long time - but we've not been able to find a solution. All distros either patch qt or provide custom plugins, none we can use from statically linked sw.
187 2015-07-13 09:19:22 <wumpus> the hope was that a newer qt would integrate it
188 2015-07-13 09:23:22 <Luke-Jr> what was the problem with share-linking Qt again? the OpenSSL mix?
189 2015-07-13 09:23:53 <wumpus> libstdc++ incompatibilities, qt API incompatiblities
190 2015-07-13 09:24:01 <Luke-Jr> ah
191 2015-07-13 09:24:02 <wumpus> and the openssl mix was fun too
192 2015-07-13 09:25:38 <wumpus> compatibility is the sole reason for existence of the single-binary approach on bitcoin.org, so we must prioritize compatibility over small UI issues
193 2015-07-13 09:25:39 <Luke-Jr> Qt is overdue for a network abstraction layer >.>
194 2015-07-13 09:27:17 <Luke-Jr> maybe most of the UI complaints will go away when BlueMatt updates the PPA
195 2015-07-13 09:27:28 <wumpus> yes. The PPA shouldn't suffer from this.
196 2015-07-13 09:28:12 <BlueMatt> yea, willdo tomorrow
197 2015-07-13 09:29:34 <wumpus> great!
198 2015-07-13 12:21:35 <flyingkiwi> Hi there, I'm running core v0.11.99.0-44fa82d and facing some problems I've never had before. When running bitcoin-qt I can't use bitcoin-cli anymore - its mostly resturning "JSON double out of range". When running bitcoind everything works fine. Any idea?
199 2015-07-13 12:22:40 <mist_> Hiya fellas, am i on the wrong version?   "version": 119900,
200 2015-07-13 12:22:59 <mist_> bitcoin@maquiberry:~/bitcoin$ git status
201 2015-07-13 12:22:59 <mist_> On branch master
202 2015-07-13 12:31:25 <sipa> flyingkiwi: that seems strange, qt and bitcoin use the exact same code here
203 2015-07-13 12:31:36 <sipa> mist_: no
204 2015-07-13 12:31:48 <sipa> flyingkiwi: what exact value are you sending?
205 2015-07-13 12:32:25 <petertodd> sipa: spent a bunch of time reviewing your limitpool pull-req; looks pretty good modulo various nits
206 2015-07-13 12:33:59 <petertodd> sipa: I was thinking though, you could probably replace the entire mempool with a "transaction package" scheme, where you have CTxPackage's that contain one or more transactions in them; if a child tx depends on a parent tx in a package, and the total fees/kb would be higher if the child and parent(s) were merged into a new package, do that
207 2015-07-13 12:34:22 <flyingkiwi> sipa, I captured the traffic with ngrep: http://pastebin.com/raw.php?i=PMSGvUG5
208 2015-07-13 12:35:13 <petertodd> sipa: then just keep a sorted index of packages and build blocks from highest fee/kb package to lowest. Keep packages under some limit, say 150KB, to prevent "holes" from ill-fitting packages while building blocks.
209 2015-07-13 12:36:02 <flyingkiwi> sipa, also happens with many other commands... like "getinfo" and "getrawmempool 1" (though "getrawmempool" is working)
210 2015-07-13 12:36:27 <petertodd> sipa: computing fee/kb for packages when a new child comes in is an issue, but I think a simple depth*breadth limit sufficies - not unlike Luke-Jr's -limitunconfdepth pull-req
211 2015-07-13 12:37:14 <petertodd> sipa: finally, on each new block, (lazily) rebuild packages when parent txs have been confirmed, changing the fee/KB of the whole
212 2015-07-13 12:38:15 <mist_> sipa: then why am i getting a warning about it being a prerelease version?
213 2015-07-13 12:38:31 <mist_> "errors": "This is a pre-release test build - use at your own risk - do not use for mining or merchant applications"
214 2015-07-13 12:39:51 <petertodd> sipa: for mempool size limiting, the package thing guarantees that throwing away the smallest fee/kb package is always possible, because if a child tx makes the fee/kb rate higher than the parent, it would have been included in the tx package the parent was in already
215 2015-07-13 12:43:14 <sipa> mist_: master is not a release
216 2015-07-13 12:43:28 <sipa> mist_: but a moving and often unstable development branch
217 2015-07-13 12:43:41 <sipa> petertodd: yup, i like that
218 2015-07-13 12:44:13 <petertodd> sipa: good :) I'd suggest your pull-req get merged all the same, but I'll see if I can find some time to do the package thing
219 2015-07-13 12:45:28 <sipa> flyingkiwi: that looks strange
220 2015-07-13 12:45:41 <sipa> flyingkiwi: that shouldn't happen
221 2015-07-13 12:45:45 <sipa> can you file an issue?
222 2015-07-13 12:46:26 <sipa> petertodd: how is conputing fee/byte for packages an issue? remember total fee and total size for packages
223 2015-07-13 12:50:01 <petertodd> sipa: cases where a tx set spends multiple outputs of a single tx can lead to overcounting basically - easiest to just traverse the tx graph back to confirmed txouts for each new tx, which without a depth*breadth limit would lead to O(<something bad>) performance
224 2015-07-13 12:50:18 <petertodd> sipa: huge nests of unconfirmed txs are pathological anyway
225 2015-07-13 12:51:06 <sipa> petertodd: hmm? a package would have a set of txids i suppose, to avoid double ibcluding the same tx
226 2015-07-13 12:53:18 <petertodd> sipa: right, but consider the case where you have parent tx0, spent by tx1a and tx1b, both with lower fee/KB than tx0, and finally tx2 spending tx1a and tx1b - naively just adding tx1a/b sum fees/size together overcounts
227 2015-07-13 12:53:34 <mist_> 14:38 < mist_> sipa: then why am i getting a warning about it being a prerelease version?
228 2015-07-13 12:53:37 <mist_> 14:38 < mist_>   "errors": "This is a pre-release test build - use at your own risk - do not use for mining or merchant applications"
229 2015-07-13 12:54:02 <afk11> mist: it's not an official tagged release like 10
230 2015-07-13 12:54:09 <afk11> therefore isn't supported in an official sense
231 2015-07-13 12:54:15 <afk11> 0.10 *
232 2015-07-13 12:56:21 <mist_> Hmpf.... This gives me a headache... /r/bitcoin says i should run it but its making my monitoring script sad
233 2015-07-13 13:27:23 <afk11> who elects onion seeds?
234 2015-07-13 13:27:50 <jgarzik> the continental bitcoin congress
235 2015-07-13 13:27:58 <afk11> jgarzik: ;)
236 2015-07-13 13:28:07 <afk11> load balancing is being researched by the tor project at the moment - seems we could have a similar setup to dns seeds
237 2015-07-13 13:28:36 <afk11> effectively, you give out a .onion which is running a load balancer. it distributes across the hidden services you have set up
238 2015-07-13 13:29:24 <afk11> we could probably set up a load balancer that has keys kept by the current dns seed peeps?
239 2015-07-13 13:34:38 <afk11> for reference: https://github.com/DonnchaC/onionbalance
240 2015-07-13 13:48:12 <sipa> petertodd: yup, i would expect that in the package approach you either combine the child with both parents into a single package, or don't combine them at all
241 2015-07-13 13:52:44 <ssa3512> why is discus fish mining such empty blocks, even 5+ minutes after the previous
242 2015-07-13 15:09:22 <Lightsword> so…seeing a lot of this on my stratum server [2015-07-13 08:35:54.567] HTTP socket read+write took 6.331s in json_rpc_call ( "getblock...)
243 2015-07-13 15:12:37 <Luke-Jr> Lightsword: #bitcoin for user questions
244 2015-07-13 15:13:20 <Lightsword> Luke-Jr, well its not the stratum server its bitcoind being slow
245 2015-07-13 15:13:47 <Lightsword> Luke-Jr from the transactions spam
246 2015-07-13 15:14:02 <Luke-Jr> sure, but it's not development ;)  - actually #bitcoin-mining may be better (and doesn't have conversation ongoing)
247 2015-07-13 16:14:02 <kefkius> In python, multiple different projects use "\x18Bitcoin Signed Message:\n" as the magic bytes in message signing/verifying. Why is the byte "\x18" used?
248 2015-07-13 16:15:45 <wumpus> size of the string
249 2015-07-13 16:17:25 <kefkius> >_< thanks wumpus, it's obvious now
250 2015-07-13 18:12:51 <gavinandresen> Am I imagining things, or does running CXXFLAGS='-DDEBUG_LOCKORDER' ./configure   not work to define DEBUG_LOCKORDER any more?
251 2015-07-13 18:14:10 <sipa> use ./configure CXXFLAGS='-DDEBUG_LOCKORDER'
252 2015-07-13 18:14:35 <gavinandresen> sipa: mmm... that doesn't seem to work for me, either, but maybe I'm doing something stupid... lemme try again
253 2015-07-13 18:15:52 <gavinandresen> sipa: aha, ./configure --enable-debug is the culprit.
254 2015-07-13 18:16:10 <gavinandresen> ... that seems to override CXXFLAGS...
255 2015-07-13 18:52:14 <morcos> sipa: another though re: #6421.   When adding a new transaction, we're currently requiring feerate(newtx) > feerate(package being removed) and fee(newtx) > fee(package being removed) (putting aside for the moment that there might be a but in that as implemented)
256 2015-07-13 18:52:35 <sipa> indeed
257 2015-07-13 18:52:36 <morcos> s/but/bug)
258 2015-07-13 18:52:59 <morcos> i think we should also require that feerate(of all parents of new tx + new tx) > feerate(package being removed)
259 2015-07-13 18:53:13 <morcos> otherwise you might end up removing things that are actually more likely to be mined
260 2015-07-13 18:53:28 <morcos> or was that what you were thinking is a next step?
261 2015-07-13 18:56:41 <sipa> not sure i see why
262 2015-07-13 18:58:34 <morcos> imagine you already have a chain of low fee tx's in the mempool.  adding a medium fee child, might still make the whole chain too low average feerate to be mined.   but that medium fee child, may have just booted a smaller chain with less total fee but higher fee rate than the new tx's full ancestor chain.
263 2015-07-13 18:59:09 <morcos> the booted chain would actually be mined first, i think both by CPFP miners and regular miners
264 2015-07-13 18:59:47 <morcos> i'm beginning to think that it might be a mistake to try to push this out there without trying to do the full package approach from the beginnig
265 2015-07-13 19:01:22 <sipa> i may make sense to run a bunch of nodes with various mempool size limits
266 2015-07-13 19:01:41 <sipa> and see what % of new blocks was in their mempools already
267 2015-07-13 19:04:44 <jgarzik> I continue to be skeptical of CPFP having in-the-field practical value, versus replace-by-fee
268 2015-07-13 19:05:10 <jgarzik> if it's not getting confirmed, part of the issue may be parent distribution
269 2015-07-13 19:05:24 <morcos> jgarzik: even if it doesn't have practical value to users, its the economically sensible thing for miners to do
270 2015-07-13 19:05:43 <morcos> so makes sense to design the code to anticipate that and make it efficient
271 2015-07-13 19:05:59 <sipa> and even if it's not used by users, implementing the mempool as a cpfp-precombined package set results in better RBF decisions, iirc
272 2015-07-13 19:06:27 <sipa> iirc i often use iirc when i mean afaict
273 2015-07-13 19:06:55 <jgarzik> iiuc
274 2015-07-13 19:07:10 <sipa> ha!
275 2015-07-13 19:07:17 <helo> would it be so bad if miners set up CPFP interfaces, and users connect to those directly when necessary, and ignore the chicken-egg problem on the network?
276 2015-07-13 19:07:39 <morcos> sipa: my other concern is even increasing to 20 tries as per your latest commit, still seems a bit risky that somehow 20 chains with a low fee transaction in them will get sorted near the bottom, and artificially make the cost to get in the mempool very high
277 2015-07-13 19:08:01 <morcos> this could actually prevent any transactions from getting in the mempool unless they pay a very high fee
278 2015-07-13 19:08:08 <morcos> until a block is mined
279 2015-07-13 19:09:19 <sipa> if we assume a fixed usage/txsize ratio, a much stronger heurstic is even possible
280 2015-07-13 19:09:21 <jgarzik> morcos, that will sort itself out in the long term - that produces ideal behavior.  CPFP is a backup.  You don't want the _normal_ behavior to be tuned to support transactions for which the fee will come later, in a 2nd tx
281 2015-07-13 19:09:25 <morcos> i was thinking randomly trying 20 out of a much bigger potential pool..  but i'm not even sure thats good enough...   if somehow you end up with a lot of chains in the mempool..  it seems bad that you're preventing small high fee rate transactions
282 2015-07-13 19:09:40 <jgarzik> That's just tuning the entire system for a case for which CPFP is essentially a workaround.
283 2015-07-13 19:09:58 <morcos> sipa: what do you mena?
284 2015-07-13 19:10:00 <morcos> mean
285 2015-07-13 19:10:15 <sipa> jgarzik: i beginnen to see CPFP more as an implementation mechanism for mempool strategies than as an interface
286 2015-07-13 19:10:26 <jgarzik> Fundamentally you cannot predict that low-fee TX_a will be followed by a TX_b.  CPFP is a patch trying to fix a mistake, not a primary path.
287 2015-07-13 19:10:30 <helo> i.e. since miner profitability is what calls for CPFP, leave it to them to implement it?
288 2015-07-13 19:10:38 <morcos> them is us!
289 2015-07-13 19:11:10 <morcos> at least i think it makes a lot of sense for bitcoin core to continue building the best prototypical mining software
290 2015-07-13 19:11:19 <jgarzik> packages == you're optimizing a lot for the not-common case
291 2015-07-13 19:11:20 <helo> mostly... hopefully CPFP is not a large portion of miner revenue
292 2015-07-13 19:11:46 <sipa> jgarzik: without downside for the common case
293 2015-07-13 19:12:14 <morcos> what did you mean on fixed usage/txsize ratio though?
294 2015-07-13 19:12:31 <sipa> morcos: well there are at every point a number of bytes of usage to remove still
295 2015-07-13 19:12:43 <sipa> morcos: and we know what the minimum feerate is of what we're removing
296 2015-07-13 19:12:47 <jgarzik> sipa, the most obvious downside leapt out at me -- delaying a mempool cap implementation getting merged while we wait for the implementation to be even more perfect, even more complex
297 2015-07-13 19:13:00 <sipa> jgarzik: i think mempool cap is more urgent
298 2015-07-13 19:13:24 <jgarzik> sipa, I do too
299 2015-07-13 19:13:29 <sipa> jgarzik: and if the concerns about tx chains conflicting with it are too large, we should have code that limits large chains in the mempool period
300 2015-07-13 19:14:19 <sipa> morcos: thus we know how much fee at least will have to be removed still at every point, which can be a fast bail-out mechanism for deciding whether to include a top-level tx in the to-be-removed set
301 2015-07-13 19:14:48 <sipa> unfortunately, txsize != usage
302 2015-07-13 19:14:57 <jgarzik> sipa, if you have the time-based janitor and/or floating relay fee (low/high water), the only time the cap should ever evict transactions is during bursts, rather than a continuously full state
303 2015-07-13 19:15:57 <jgarzik> and precise eviction becomes less important (because you can never be fully precise, as you can never precisely guess collective miner policy)
304 2015-07-13 19:16:07 <sipa> right
305 2015-07-13 19:16:26 <sipa> but as long as the mempool is significantly larger than the next few blocks, i'm not sure it matters
306 2015-07-13 19:16:38 <sipa> you effectively create a separate effective relay fee and effective mining fee
307 2015-07-13 19:16:43 <sipa> which can diverge somewhat
308 2015-07-13 19:16:47 <sipa> but not much
309 2015-07-13 19:16:56 <jgarzik> sipa, nod that's natural
310 2015-07-13 19:17:24 <morcos> i'd feel a lot better about limiting the mempool if we had the floating relay fee first, so the limit was only a fall back
311 2015-07-13 19:17:48 <sipa> i'm running 6421 with -checkmempool now
312 2015-07-13 19:17:55 <morcos> i'm worried that what we're currently discussing makes it too likely that someone can find a way to fill up the mempool and block new transactions from being relayed unless they are very expensive
313 2015-07-13 19:18:12 <morcos> sipa: ha i told you not to do that!  better press your turbo button
314 2015-07-13 19:18:20 <sipa> morcos: lol
315 2015-07-13 19:18:21 <sipa> it works
316 2015-07-13 19:18:23 <jgarzik> heh
317 2015-07-13 19:18:37 <sipa> limiting to 16 MB now
318 2015-07-13 19:19:01 <jgarzik> sipa, what -debug options do you find most useful for mempool hacking like this?
319 2015-07-13 19:19:12 <jgarzik> mempool+net?
320 2015-07-13 19:19:14 <sipa> debug=mempool :)
321 2015-07-13 19:19:23 <morcos> you don't always use -debug ?
322 2015-07-13 19:19:25 <sipa> i've moved the orphan tx handling to a different debug class
323 2015-07-13 19:19:34 <sipa> because they're spamming my log
324 2015-07-13 19:19:40 <jgarzik> debug=all spams my logs too much
325 2015-07-13 19:20:25 <jgarzik> debug can be invoked multiple times.  You can debug mempool & net, and not others.
326 2015-07-13 19:21:45 <sipa> morcos: if we would limit the size of 'packages' (the number of tx that depend on a given tx, recursively), would that remove your worry about blocking mempool liquidity?
327 2015-07-13 19:22:46 <sdaftuar> i think the size and the number
328 2015-07-13 19:23:23 <morcos> it would certainly alleviate a lot of the concern, but i still think even in the absence of attack its going to be likely that in the event the mempool gets full, the price to get in is goign to end up being a lot more than it seems like it should be.
329 2015-07-13 19:25:23 <morcos> i think if you combined that with broadening the potential evictee list to more than 20, maybe that would be enough
330 2015-07-13 19:26:41 <morcos> also did you agree with my initial question, which is actually somewhat separate
331 2015-07-13 19:27:13 <jgarzik> a cap should be coupled with another solution (floating fee and/or janitor), since cap-based mempool eviction is IMO a last resort and other methods should be preferred normally
332 2015-07-13 19:27:46 <morcos> jgarzik: i agree both of those solutions are important.
333 2015-07-13 19:28:59 <sipa> what about just relayfee = configured_relayfee * (cap-lowwater)/(usage-lowwater)
334 2015-07-13 19:29:06 <morcos> and i think they should go in at the same time.  the janitor requires a bit of thinking to make sure it doesn't suffer from free relay issues, but i think fundamentally if you have a way of sending transactions that are accepted into mempools but unlikely to be mined we're in trouble, and kicking them eventually can't be worse than holding on to them forever
335 2015-07-13 19:29:19 <sipa> effectively making the fee go up to infinity as you get close to the cap
336 2015-07-13 19:30:12 <morcos> uh is that the right formula?
337 2015-07-13 19:30:17 <sipa> and whenever a tx does not satify the fee for the increased size, try to use the limit logic to remove something instead
338 2015-07-13 19:30:52 <sipa> it's the wrong formula
339 2015-07-13 19:31:27 <jgarzik> the relay fee ideally needs to float towards "what will be accepted in the short term"
340 2015-07-13 19:31:58 <sipa> yes, i agree
341 2015-07-13 19:32:02 <sipa> drop my suggestion
342 2015-07-13 19:32:23 <sipa> it would make the relay fee go way above the actual fee levels in the mempool
343 2015-07-13 19:34:36 <jgarzik> low water < high water < cap
344 2015-07-13 19:34:53 <jgarzik> start draining at high water.  start force evicting at cap (but we hope it doesn't come to that).
345 2015-07-13 19:35:16 <morcos> draining = janitor?
346 2015-07-13 19:35:34 <sipa> how do you make effective draining decisions without knowing what it will be replaced with?
347 2015-07-13 19:35:35 <jgarzik> morcos, #6402.  draining = increase relay fee above default minimum.
348 2015-07-13 19:35:39 <sipa> ah
349 2015-07-13 19:35:45 <morcos> thats an odd name
350 2015-07-13 19:35:57 <jgarzik> draining the pool
351 2015-07-13 19:36:01 <jgarzik> lowering the water level
352 2015-07-13 19:36:02 <sipa> but increasing the relay fee will not drain the pool
353 2015-07-13 19:36:03 <sdaftuar> turning down the spigot?
354 2015-07-13 19:36:11 <sipa> only new blocks do that
355 2015-07-13 19:36:28 <jgarzik> sipa, in the long term it does, when combined with new blocks
356 2015-07-13 19:36:55 <sipa> so what does low water do?
357 2015-07-13 19:37:00 <morcos> yeah.. i mean that seems reasonable to me...
358 2015-07-13 19:37:09 <sipa> ah, below low water you reduce the fee?
359 2015-07-13 19:37:11 <jgarzik> sipa, relay fee goes back to default
360 2015-07-13 19:37:16 <jgarzik> below low water
361 2015-07-13 19:37:35 <jgarzik> since the pool is near-empty
362 2015-07-13 19:40:55 <sipa> morcos: do you see any way to use the fee estimation code to set the relay fee?
363 2015-07-13 19:41:20 <morcos> we were just talking about that, but i think basing it on mempool size makes more sense
364 2015-07-13 19:41:45 <sipa> i'm not sure
365 2015-07-13 19:42:14 <morcos> hmm...  well i'm worried about their being some unforeseen feedback loop.
366 2015-07-13 19:42:27 <sipa> assume there is some steady state of transactions on the network, somewhat below the block creation rate, with relatively little variation in fee rate
367 2015-07-13 19:42:49 <sipa> there have been a few long blocks, and the mempool starts to rise above normal levels
368 2015-07-13 19:43:01 <sipa> high water kicks in, and the relay fee is doubled
369 2015-07-13 19:43:13 <sipa> now not a single tx can get through anymore
370 2015-07-13 19:43:21 <sipa> because none are willing to pay that much
371 2015-07-13 19:43:26 <morcos> hmm
372 2015-07-13 19:43:43 <sipa> so the result is that effectively, the network relay drops to zero until the pool is cleared out
373 2015-07-13 19:43:45 <jgarzik> using #6402 metric doubling seems extremely unlikely
374 2015-07-13 19:43:49 <sipa> that is a very extremely effect
375 2015-07-13 19:43:56 <jgarzik> sipa, "flapping"
376 2015-07-13 19:43:58 <morcos> well i assume the fee estimation is going to have to floor at the relay
377 2015-07-13 19:44:21 <sipa> jgarzik: right, using some percentile of what is actually in the pool makes sense
378 2015-07-13 19:44:46 <jgarzik> #6402 uses the bottom-of-the-top-half
379 2015-07-13 19:45:01 <morcos> actually, now that i'm thinking about it though
380 2015-07-13 19:45:13 <morcos> maybe using estimatefee 25 or 50 or whatever
381 2015-07-13 19:45:27 <jgarzik> estimatefee 144
382 2015-07-13 19:45:31 <sipa> jgarzik: so, the median?
383 2015-07-13 19:45:37 <morcos> ha ha
384 2015-07-13 19:45:40 <phantomcircuit> could do a strict ordering by feerate for the mempool and relay filtering with a rolling bloom filter per peer with the outputs being spent
385 2015-07-13 19:45:59 <jgarzik> sipa, yep
386 2015-07-13 19:46:03 <phantomcircuit> since it would be per peer the fp rate wouldn't matter
387 2015-07-13 19:46:17 <morcos> jgarzik: what was your response to ashleyholman's concern about once over 50% of the mempool is low fee
388 2015-07-13 19:46:23 <morcos> then the relay rate never gets raised
389 2015-07-13 19:46:28 <jgarzik> sipa, thus plenty of room to still get into mempool / cap still necessary
390 2015-07-13 19:47:13 <jgarzik> morcos, the relay rate is not raised until high water is reached - because logically if high water is not reached, miners are happy draining the pool as is
391 2015-07-13 19:47:21 <morcos> i need to think about it a bit, but you want the feedback to be fast enough that the relay fee goes up before you hit the cap
392 2015-07-13 19:47:29 <morcos> yes  i understand, but even after they hit high water
393 2015-07-13 19:47:33 <sipa> morcos: i don't think so
394 2015-07-13 19:47:37 <morcos> median fee could still equal old relay rate
395 2015-07-13 19:47:59 <sdaftuar> you need to find the smallest relay fee that actually reduces the mempool size
396 2015-07-13 19:48:02 <sipa> i think the relay fee should be something that reflects long-term average for _minimal_ cost to get a transaction in the blockchain
397 2015-07-13 19:48:27 <morcos> hmm...
398 2015-07-13 19:48:29 <sipa> not something that should change in the short term to deal with emergency
399 2015-07-13 19:48:34 <sipa> because it can't
400 2015-07-13 19:48:45 <morcos> so the opposite of petertodd's doubling as the mempool grows idea
401 2015-07-13 19:48:53 <jgarzik> morcos, sure, median fee could still equal old relay rate.   if mempool size stays above high water, relay fee keeps getting increased.
402 2015-07-13 19:49:01 <jgarzik> quick bursts are handled by the -backup method-, the cap
403 2015-07-13 19:49:02 <sipa> highe relay fee only has an effect in so far that there are still blocks being produced that drain transactions
404 2015-07-13 19:49:09 <phantomcircuit> which means you need a new way to filter out repeating transactions
405 2015-07-13 19:49:21 <phantomcircuit> like say a bloom filter per peer keyed on the transactions inputs
406 2015-07-13 19:49:23 <sipa> i think hitting the cap isn't a problem, as it does not preclude a functional network
407 2015-07-13 19:49:33 <sipa> only one that may make slightly suboptimal decisions
408 2015-07-13 19:49:43 <jgarzik> morcos, if the median is the default minimum, you still have functionining network and incentives
409 2015-07-13 19:50:37 <sipa> morcos: i could be something that uses such a formula, based on a long-term average of mempool size
410 2015-07-13 19:50:45 <sipa> morcos: which should converge to a stable value
411 2015-07-13 19:51:35 <sipa> i'm still uneasy with something not actually using effective fees in the pool
412 2015-07-13 19:52:01 <morcos> ok...   i get the idea... so now i have a different reason to answer yes
413 2015-07-13 19:52:47 <morcos> the fee estimation code can kind of work backwards , i use this now to determine when things are unlikely to be confirmed in x number of blocks.  this virtually always gives the minimum feerate as the answer for 10 blocks.
414 2015-07-13 19:54:01 <morcos> but if you asked this question, then only if on the long term average < some % (can be anything) of the tx's with that feerate or lower were getting confirmed in that number of blocks would you get an answer bigger than the minimum
415 2015-07-13 19:54:37 <morcos> sorry that barely parses in english i know, but i think its what we want.
416 2015-07-13 19:55:23 <morcos> if you have some fee rate where < 20% of transactions with that fee rate or lower are confirmed within 144 blocks, then maybe that should be the minimum feerate
417 2015-07-13 19:55:32 <morcos> for instance
418 2015-07-13 19:55:54 <morcos> that information is already available
419 2015-07-13 19:56:41 <phantomcircuit> seems like we're kind of going in a circle
420 2015-07-13 19:57:10 <phantomcircuit> can we all agree that mempool inclusion should be disconnected from relaying decision?
421 2015-07-13 19:57:49 <sipa> i haven't given it too much thought
422 2015-07-13 19:59:24 <phantomcircuit> sipa, the decisions around mempool inclusion stop having network issues if they're disconnected
423 2015-07-13 19:59:49 <phantomcircuit> we would run all of the mempool acceptance tests, except for the final check to see if the transaction would overflow
424 2015-07-13 19:59:51 <jgarzik> phantomcircuit, I don't see how they can be disconnected as they are unavoidably linked economically
425 2015-07-13 20:00:09 <phantomcircuit> jgarzik, they're not though
426 2015-07-13 20:00:10 <jgarzik> phantomcircuit, we should not be relaying shite on the network that will never confirm
427 2015-07-13 20:00:19 <stonecoldpat> sipa: if the memory pool is capped, do you think this will increase the bandwidth requirements for a node? (e.g. if my tx is dropped from the memory pool, i'll need to rebroadcast it)
428 2015-07-13 20:00:44 <phantomcircuit> jgarzik, and maybe i have a server with 64GB of ram that can hold virtually infinite transactions in it's mempool
429 2015-07-13 20:00:56 <sipa> stonecoldpat: if it's dropped from the mempool, you won't be able to quickly rebroadcast it (to the same nodes)
430 2015-07-13 20:01:12 <morcos> sipa: wait, why not?
431 2015-07-13 20:01:38 <sipa> because if it is dropped, it meens the mempools now have a better feerate than your transaction
432 2015-07-13 20:01:57 <sipa> if you just rebroadcast it, it won't beat it
433 2015-07-13 20:01:59 <phantomcircuit> jgarzik, the link between mempool and relaying is really just some nice code reuse; the rules on what we consider to be spam are currently the same for both
434 2015-07-13 20:02:08 <stonecoldpat> sipa: if the fee was increased, you could re-broadcast it then?
435 2015-07-13 20:02:09 <jgarzik> phantomcircuit, so?  you are always free to do that.
436 2015-07-13 20:02:19 <phantomcircuit> however if the total mempool size is limited... that should be reconsidered
437 2015-07-13 20:02:42 <morcos> ah yes, it won't get relayed....    sor
438 2015-07-13 20:02:44 <morcos> ry
439 2015-07-13 20:02:44 <phantomcircuit> jgarzik, nobody else will send me transactions after their mempool is full
440 2015-07-13 20:02:51 <sipa> stonecoldpat: that's not a rebroadcast, but RBF
441 2015-07-13 20:05:30 <stonecoldpat> sipa: RBF worries me as well, e.g. I can create a 100kb transaction, broadcast it to the network with the full fee and then, raise the fee by a small amount ($0.01) and rebroadcast it.
442 2015-07-13 20:05:43 <sipa> stonecoldpat: won't work
443 2015-07-13 20:05:56 <sipa> the fee delta needs to pay for the relay of the new transaction
444 2015-07-13 20:06:48 <stonecoldpat> ah okay, so that fee delta an additional fee ontop of the previously paid one? so old_fee + fee delta = new fee?
445 2015-07-13 20:07:16 <sipa> yes
446 2015-07-13 20:07:25 <sipa> precisely to avoid the issue you're mentioning
447 2015-07-13 20:07:30 <sipa> something needs to pay for relay
448 2015-07-13 20:07:51 <sipa> and whenever you kick something out of the pool, it is assumed it won't pay anymore
449 2015-07-13 20:08:36 <sipa> so you make the new thing pay for the old of both the old and the new
450 2015-07-13 22:45:46 <dgenr8> some scary "packages" float by on the network http://i.imgur.com/ZTKAuqz.png
451 2015-07-13 22:49:50 <ST3R> ??
452 2015-07-13 22:52:23 <dgenr8> set of related mempool transactions (being referred to as a package here)
453 2015-07-13 22:54:07 <ST3R> got it! thanks!