00:00:07realazthat:at least now I can possibly make a flow chart of how to do it right
00:00:14realazthat:I wonder if that would be helpful
00:09:39realazthat:imma work on that then
00:13:44c0rw1n:that should probably be linked directly from https://bitcoin.org/en/development if I may
00:14:28optimator_:can i assume a correct implementation of the protocol would allow for spending zero-conf change address TxIns?
00:14:58optimator_:optimator_ is now known as optimator
00:15:40c0rw1n:sry, that's way above my level
00:16:14sipa:optimator: that has nothing to do with the protocol (the protocol doesn't know about "change" or "address")
00:25:53optimator:so is it correct to say that spending zero-conf change transactions is a reference client implementation separate from the protocol?
00:26:20sipa:i don't understand what you're asking
00:26:22c0rw1n:ia, ia, cthulhu ftaghn
00:26:28c0rw1n:(ok i stop)
00:26:32sipa:whether you allow that or not is a wallet implementation/policy thing
00:26:40sipa:with benefits and risks
00:27:11c0rw1n:ah ok finally parsed it
00:27:46optimator:sipa: i think that is what I was asking, so it's the wallet implementation, like spending coinbase transactions after 120 confs rather than 100, kinda?
00:28:05sipa:yes, that's also a wallet policy
00:28:12sipa:(in 0.9 it's reduced to 101, btw)
00:28:28sipa:it can't be reduced below 100 though, as that _is_ a protocol rule
00:28:37optimator:way the extra 1? just curious
00:29:02sipa:no time to explain... short story: extra protection in some weird edge cases
00:44:46Xarian:Xarian is now known as Xarikins
02:51:46austinhill1:austinhill1 has left #bitcoin-wizards
03:56:47crispy1:crispy1 has left #bitcoin-wizards
03:57:37crispy1:crispy1 has left #bitcoin-wizards
03:58:09crispy1:crispy1 has left #bitcoin-wizards
04:00:15Luke-Jr:sipa: ping
04:00:23Luke-Jr:Is this a bugfix? a42eef6 verify vchPubKey matches calculated public key unless fSkipCheck is set
04:04:34phantomcircuit:Luke-Jr, no
04:04:43phantomcircuit:Luke-Jr, https://github.com/bitcoin/bitcoin/pull/2950
05:32:40nOgAnOo:nOgAnOo is now known as nogandoo
05:37:57nogandoo:nogandoo is now known as nOgAnOo
11:21:41gavinandresen_:gavinandresen_ is now known as gavinandresen
15:51:51jarpiain:jarpiain is now known as Guest52815
15:57:42qwertyoruiop_:qwertyoruiop_ is now known as qwertyoruiop
16:09:57TD:good evening
16:10:13TD:so has anyone established what exactly is going on with the network? is this a sybil attack of bogus nodes that are spamming/mutating simultaneously?
16:16:50K1773R:TD: whats happing currently?
16:17:59TD:there's the 25% tx mutation rate, and also the "enjoy sochi" spam
16:31:08andytoshi:'enjoy sochi' has been around for a long time afaik, who knows what that is. we are assuming the mutation is a collection of nodes mutating every single tx that they happen across, but afaik nobody has really looked into it..
16:31:48TD:enjoy sochi is new to me. if it's been around for a while then there's been a step-up in volume lately, i think
16:32:13TD:i wonder if the mutation is malicious or the result of a stupid implementation that doesn't roundtrip transactions correctly
16:35:10wumpus:well as it started just after the malleability became well known (due to mtgox), I don't think it is accidental
16:36:45wumpus:but yeah, AFAIK no one really looked into which nodes are doing this, also because it's so easy to pull off and it's more urgent to make wallets robust against it
16:47:59OneFixt_:OneFixt_ is now known as OneFixt
20:58:56zooko:zooko is now known as zooko-standup
21:05:35phantomcircuit:sipa, how difficult would it be to add a flag to ignore unconfirmed transactions entirely?
21:09:50zooko-standup:zooko-standup is now known as zookowatercooler
21:12:40wumpus:phantomcircuit: a one-liner: https://github.com/bitcoin/bitcoin/pull/3657
21:45:22phantomcircuit:wumpus, that is similar to what i was saying, but not exactly the same
21:45:34phantomcircuit:with the the unconfirmed mutated transaction is still stored in wallet.dat
21:45:40phantomcircuit:which is the longer term issue here
21:49:47gmaxwell:storing it is not bad, we absolutely should still store it.
21:49:55gmaxwell:we should never delete records.
21:50:51phantomcircuit:gmaxwell, sure... except if i can connect directly to your node its a trivial DoS condition to flood you with IsMine or even IsFromMe mutated txs
21:51:01gmaxwell:phantomcircuit: no its not.
21:51:15phantomcircuit:gmaxwell, what i dont get is how someone is managing to even get these relayed, they should largely be blocked as a double spend
21:51:18gmaxwell:we won't accept them unless they show up in a block because we already have the first one.
21:51:28gmaxwell:because the mutant makes it into a block.
21:51:48phantomcircuit:gmaxwell, ah so the wallet code already rejects them as a double spend?
21:51:50gmaxwell:speaking of that... /me goes to ping elu to see if he's applied the filtering yet.
21:52:12gmaxwell:phantomcircuit: the basic node code does. (either as a doublespend from the original in the mempool or in the blockchain)
21:52:54phantomcircuit:so it's only an issue when the mutant gets into the block instead of the original tx
21:53:00phantomcircuit:i guess that makes sense in a way
21:53:22phantomcircuit:except the getbalance logic is all fubar from IsConfirmed being weird
21:53:31phantomcircuit:and also just from the accounts stuff in general being weird
21:53:35gmaxwell:right, this was why I was attempting to get major pools to deploy the code blocking these things.
21:54:00gmaxwell:no. fucking a he still has not. "doing it now"
21:54:00phantomcircuit:gmaxwell, which code?
21:54:13gmaxwell:the canonical push patch.
21:54:37phantomcircuit:gmaxwell, im out of the loop on all of this at the moment sitting in a dc surrounded by mining hardware
21:54:48phantomcircuit:which reminds me... /me goes to get ear protection
22:06:31phantomcircuit:gmaxwell, heh the getbalance logic is something that was on my list of things to fix... you know eventually maybe
22:08:18phantomcircuit:gmaxwell, also is it just me or are the usernames of the commiters on that issue all uuid's except you?
22:08:54sipa:gmaxwell: elu?
22:11:43Guest52815:Guest52815 is now known as jarpiain
22:14:30zookowatercooler:zookowatercooler is now known as zooko
22:35:08phantomcircuit:sipa, would it help to completely remove the silly behavior in IsConfirmed?
22:35:43phantomcircuit:gmaxwell, also apparently bitcoinqt will use 0 confirm transactions as inputs but only after it's tried everything else
22:36:39jgarzik:phantomcircuit, yes. However note the user experience: have 1000 BTC. send 1 BTC. balance drops to zero...
22:36:51jgarzik:(if unconfirmed are disabled for spends)
22:37:13phantomcircuit:jgarzik, i dont believe the second half of the IsConfirmed code ever works currently actually
22:37:42phantomcircuit:iirc vtxPrev is always populated with empty CTransaction (CWalletTx?) objects
22:38:01phantomcircuit:except in the case where you're spending and receiving
22:38:09phantomcircuit:but yeah i guess that's very common with change
22:38:32phantomcircuit:(hadn't thought about change)
22:39:24sipa:phantomcircuit: here is my suggestion that i've been making in a few mails already, but maybe not publically
22:39:41sipa:phantomcircuit: consider wallet transactions active when they are either confirmed, or in the mempool
22:40:00sipa:get rid of vtxPrev and vfSpent
22:40:13sipa:keep a multimap of all inputs spent by wallet transactions
22:40:36sipa:and consider a coin as spendable if it is created by an active transaction, and not spent by an active one
22:41:05sipa:as the mempool guarantees perfect consistency with the blockchain and itself, this means no two conflicting transactions can ever be counted at the same time
22:47:31nOgAnOo:nOgAnOo is now known as me
22:48:01me:me is now known as Guest66919
22:48:36Guest66919:Guest66919 is now known as nOgAnOo
22:53:10phantomcircuit:sipa, i like that
22:53:19phantomcircuit:it's clean and wouldn't result in crazy displays to the user