< phantomcircuit>
morcos, i no longer think there's a bug in there, but that there is something about the changes which made something else more obvious
< phantomcircuit>
possibly not hitting disk there made memory failures worse or something
< GitHub71>
bitcoin/master df6e8e1 Jonas Schnelli: [Qt] rename "amount" to "requested amount" in receive coins table
< GitHub71>
bitcoin/master ae2db67 Jonas Schnelli: Merge #7383: [Qt] rename "amount" to "requested amount" in receive coins table...
< GitHub34>
[bitcoin] jonasschnelli closed pull request #7383: [Qt] rename "amount" to "requested amount" in receive coins table (master...2016/01/qt_req_amount) https://github.com/bitcoin/bitcoin/pull/7383
< wumpus>
cfields, something w/ travis is strange on the 0.10 branch, https://travis-ci.org/bitcoin/bitcoin/jobs/103586898 . fukuchi.org is failing (download for qrencode) but it's not using the fallback - there isn't even an error for bitcoincore.org/dev.bitcoincore.org
< GitHub174>
[bitcoin] laanwj opened pull request #7386: Add option `-permitrbf` to set transaction replacement policy (master...2016_01_disable_opt_in_rbf) https://github.com/bitcoin/bitcoin/pull/7386
< BlueMatt>
wangchun: regarding opt-in rbf and 0conf....be careful, you've been sold a pack of lies. EVERY company which I'm aware of which currently accepts 0conf has stated publicly that opt-in rbf does not impact them
< BlueMatt>
wangchun: many wallet creators have been asking for it because it makes paying fees much, much easier
< BlueMatt>
wangchun: the ONLY people who are complaining about opt-in rbf are on reddit
< instagibbs>
BlueMatt, I've been quoting that thread, it'd be a good idea to get more on the record to explictly rebut the FUD
< BlueMatt>
instagibbs: lol, eric vorhees, in a long post talking about why availability of 0conf is a good idea, a guy who is explicitly incredibly pissed off at core for various reasons, said this: "The current Bitcoin implementation, in my opinion, offered a very elegant balance between instant settlement and security. Zero-conf was always an option for merchants or individuals – it came with risk, but it was in many cases manageable, and bri
< BlueMatt>
lliant companies like BlockCypher rose up to make it even more manageable. For those who didn't want any risk, they could decide to wait for one or several confirmations. Neither group infringed on the other – SatoshiDICE was able to take on the risk of zero-conf while other firms decided to wait for blocks. Mutual harmony was enjoyed. "
< haakonn>
oops, sorry, my message was meant for a different channel ...
< warren>
wangchun: another example, Bread Wallet's Aaron Voisine thinks opt-in RBF is great.
< jonasschnelli>
phantomcircuit: re RBF: I think if there are merchants (example third world) that accept 0-confs over a standard wallet (Android Wallet). These guys would suffer a higher chance to get double spended
< phantomcircuit>
jonasschnelli, anybody using BIP70 payment protocol is already at extreme risk accepting unconfirmed transactions
< phantomcircuit>
because the transaction is relayed directly to the merchant, timing attacks are trivial
< phantomcircuit>
(and very effective)
< BlueMatt>
jonasschnelli: such people are already trivially attackable using petertodd's rbf tools
< phantomcircuit>
oh AND spv clients have a hard time guessing what fees are required to be included in the next block
< BlueMatt>
jonasschnelli: more importantly, those wallets can be easily upgraded to fix that issue
< jonasschnelli>
BlueMatt : totally agree with this. It just makes double spending more easy...
< BlueMatt>
jonasschnelli: my point is it /doesnt/ make double-spending easier
< jonasschnelli>
But maybe RBF is then a sign for them to "move on" and use better tools (then just a wallet as merchant)
< BlueMatt>
it does make double-spending easier against people like blockcypher, but they know this and have already adapted
< phantomcircuit>
jonasschnelli, the situation is such that unconfirmed transactions cannot be safely accepted by anybody unless they have the ability to reverse their side of the transaction after the fact
< phantomcircuit>
jonasschnelli, which actually describes most online merchants
< BlueMatt>
jonasschnelli: and some wallets already are being fixed - they're displaying opt-in rbf as 'pending' instead of 'unconfirmed'
< BlueMatt>
its a much clearer indication
< BlueMatt>
long before the network is even using opt-in rbf wallets can be ready
< jonasschnelli>
Wallets maybe also want to show a "icon" "warning" in case a RBF transaction is amount the 0-conf incommint wtxs
< BlueMatt>
yes, I know at least breadwallet is doing something like that
< BlueMatt>
I dont remeber the actual wording
< BlueMatt>
something like pending or whatever
< phantomcircuit>
BlueMatt, they probably should have already been doing that since the signaling is to set nSequence < MAX_INT
< phantomcircuit>
which has always signaled the transaction was available to be replaced
< gmaxwell>
jonasschnelli: wow, accepting 0conf in android wallet is very unsafe... it can't even tell if the inputs ever existed to begin with. Send android wallet an unconfiremd 21 million btc payment, and it happily shows it as unconfirmed.
< BlueMatt>
gmaxwell: actually it can...bitcoinj traces back all unconfirmed transactions to things in the chain
< BlueMatt>
and validates they are all non-locktime'd, etc
< sdaftuar>
phantomcircuit: if locktime is in the past, then nSequence < MAX_INT seems safe
< gmaxwell>
BlueMatt: Android wallet doesn't. I've tested this myself.
< BlueMatt>
gmaxwell: huh? It used to....wtf
< BlueMatt>
sdaftuar: but, this means bitcoinj already has logic to hide non-final txn: it should be re-used for opt-in rbf :)
< phantomcircuit>
sdaftuar, historically nSequence could be used to replace a transaction regardless of locktime
< phantomcircuit>
(unless im misremembering wildly)
< sdaftuar>
BlueMatt: i was actually looking at breadwallet's code :)
< gmaxwell>
(it checks locktime, and hides non-final tx, but will happily show transactions with never-existed inputs)
< sdaftuar>
BlueMatt: the problem SPV wallets have is needing to download unconfirmed ancestors i think?
< BlueMatt>
gmaxwell: ahhh...someone should fix that
< sdaftuar>
voisine opened an issue some time ago that is related to that, i think
< BlueMatt>
sdaftuar: they've always needed to do that
< BlueMatt>
sdaftuar: you can otherwise give them a) an invalid transaction, b) a transaction that is locked for 100 years because of a dependent
< BlueMatt>
hence bitcoinj's behavior
< BlueMatt>
though apparently that part is incomplete
< sdaftuar>
BlueMatt: agreed that its necessary, not sure everyone has implemented though
< sdaftuar>
voisine specifically requested a feature to make that easier
< BlueMatt>
indeed, but we arent changing anything wrt that
< sdaftuar>
#7237
< BlueMatt>
we could have a p2p command that does that automatically (ie gives you all deps and merkle paths for them, buttttt)
< BlueMatt>
ahh, heh, ok
< sdaftuar>
i think the patch to that would be pretty small?
< BlueMatt>
yea, it needs to also give merkle paths to the ones in the blocks
< BlueMatt>
sadly, this is probably a bad dos vector, I'd think
< BlueMatt>
maybe even worse than the bloom filtering code itself :(
< BlueMatt>
though not likely
< sdaftuar>
BlueMatt: i haven't given any thought to that aspect. just highlighting the issue so we can decide if it's worth doing, toward the goal of helping wallets do things the best way possible.
< BlueMatt>
sdaftuar: yea, I wouldnt have a huge issue with doing it for clients that both request it and bitcoind instances that have bloom filtering enabled
< BlueMatt>
its probably not hugely worse than the existing dos vectors, sooooo
< BlueMatt>
still, we need reasonable communication like "is bitcoin core eating your hdd? are you seeing a lot of outbound traffic and no inbound? are your bitcoin core ping times a few seconds? disable bloom filtering"
< BlueMatt>
oh, and fix the "mempool" command, but....whatever
< sdaftuar>
BlueMatt: ok, i might take a look at doing it. is there any significant downside to just changing the existing behavior? i coulnd't find any BIP referencing the reseponse to the mempool command given a bloom filter
< sdaftuar>
BlueMatt: and seems like SPV wallets have to check each response anyway...
< BlueMatt>
sdaftuar: i mean if you want to make it easy, there should just be a command like "prove to me this transaction isnt bogus"
< BlueMatt>
which gives you the dep chain and spv proofs that the leaves are included
< sdaftuar>
oh new p2p command
< BlueMatt>
thats how /I/ would do it
< BlueMatt>
but...meh, as you wish :)
< sdaftuar>
maybe that's cleaner, but seems like more work :)
< BlueMatt>
a bit more, but not much, I'd think
< BlueMatt>
and it clearly tells spv client implementors what to do
< sdaftuar>
fair point
< BlueMatt>
others will likely not like this idea since they want to deprecate the bloom filtering stuff entirely
< BlueMatt>
though adding a new command that is like "this is a dos risk, but people who want to serve spv clients should give them this info"
< sdaftuar>
that might also make it easy/easier to rate limit, i'd think
< BlueMatt>
ideally we could make it an rpc and spv wallet implements would connect to their central server and get that info from them, but...whatever
< BlueMatt>
sdaftuar: quite possible, indeed
< BlueMatt>
but, more importantly, if we pull out the bloom filtering shit and replace it with something sane that serves a similar purpose, we dont have to touch this rpc :)
< BlueMatt>
ehh, msg
< gmaxwell>
getting dependency chains is incompatible with pruning-- or even without running with a huge high overhead index, in any case.
< BlueMatt>
gmaxwell: you dont actually need -txindex right now, though
< BlueMatt>
gmaxwell: its a huge dos risk either way :)
< BlueMatt>
gmaxwell: (we know when a utxo was created, so we can load that block, you just cant prune)
< instagibbs>
Sorry if this is pure C++ q: I'm adding a .h/.cpp file pair for additional rpc stuff, and I can't get the linker to link and external library I'm calling inside that file(undefined references to libevent functions). I figure I'm missing something super obvious but don't really understand largish automake files.
< instagibbs>
I figure I need to link -levent somewhere in addition to bitcoind/bitcoin-cli in the Makefile.am, but noob so.