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