--- Log opened Wed Nov 20 00:00:39 2013
10:06 < adam3us> hmm HD wallets, armory use of the concept, does the chaincode of an offline wallet get copied to the watch only online wallet?
10:07 < adam3us> ie if someone has a copy of the root key, is that enough to recovery the wallet and access funds if they also got all the info out of the online wallet?
10:18 < sipa> do you mean BIP32, or armory's deterministic wallets?
10:18 < sipa> or did armory already adopt BIP32?
10:30 < adam3us> hmm i am not sure - i thought because alan had commented on bip 32 and been involved with it that was the same thing
10:33 < sipa> they both use a 'chaincode'
10:46 < adam3us> i am wondering if the online wallet is a sub-wallet or shares the same chain code
13:07 < cfields> anyone happen to be around and running windows?
13:49 < BlueMatt> hah
13:49 < BlueMatt> windows?
13:52 < cfields> heh, exactly. hacking on win32, but i have to trust wine to verify. in this case i really can't
14:01 < BlueMatt> this is what kvm is for
14:18 < phantomcircuit> BlueMatt, yeah but who has a retail license to install with anymore?
14:18 < phantomcircuit> i still use windows xp since its the only thing i have a disk for...
14:19 < BlueMatt> university licenses :)
15:20 < warren> I'm trying to figure out a quick hack (for modeling purposes only) that removes all UTXO that is 1-satoshi in value after reindexing to X height.
16:10 < BlueMatt> warren: try using the new drop-unspendable code and replace the unspendable check with 1-satoshi?
16:10 < BlueMatt> (and then short-circuit the return falses for now-invalid txn?)
16:11 < warren> BlueMatt: tried that, that only works during reindex, it works until I hit a block where someone spent a 1-satoshi (which is extremely rare in litecoin)
16:12 < warren> BlueMatt: I could find the small number of spent 1-satoshi txo and whitelist them to allow reindex to succeed.
16:12 < warren> this isn't meant to be committed, just testing stuff
16:12 < BlueMatt> or just consider all unknown-txin to be 1-satoshi and all spends of them correct
16:13 < warren> hah
16:13 < BlueMatt> if its just for analysis, why not
16:13 < warren> where's the code for that part?
16:13 < BlueMatt> in ConnectInputs?
16:13 < warren> looking
17:07 < warren> BlueMatt: back from lunch.  it appears I need to construct a fake CTxOut
17:08 < warren> oh, screw it, just consider everything valid
17:09 < michagogo|cloud> 04:41:28 <warren> I'm not sure why people downvoted the bounty thread.
17:09 < michagogo|cloud> Unless the total score is negative, there may be no downvotes -- reddit adds random equal numbers of upvotes and downvotes to avoid gaming the system
17:18 < michagogo|cloud> 23:41:42 <cfields> Luke-Jr: unfortunately, the cleanest approach to the next step is to begin modding the hfs+ kernel module. And at that point, I don't think it's really worth it
17:18 < michagogo|cloud> Am I wrong, or would that break gitian builds with LXC? (IIRC, some trouble we were having had to do with a kernel module Wine tried to install or something like that?)
17:18 < cfields> michagogo|cloud: nm that, i got it working
17:18 < michagogo|cloud> Oh, awesome
17:19 < michagogo|cloud> (I'm still at Wednesday morning, midnight UTC+2 in the backlog)
17:24 < michagogo|cloud> 00:31:41 <cfields> as an osx user (i hate admitting that), any download that's not a dmg gets on my nerves
17:24 < michagogo|cloud> 00:31:48 <cfields> unless it's a .pkg for good reason
17:24 < michagogo|cloud> I'm not a Mac user, but I've been told (somewhere, don't remember exactly -- I think it was in the context of bitcoin, so maybe #bitcoin-build?) that among Mac users, any non-.dmg software downloads are treated with extreme (or at least much) suspicion
17:24 < cfields> michagogo|cloud: keep reading ;)
17:25 < cfields> deterministic dmg's are working
17:25 < michagogo|cloud> cfields: Yeah, I saw that :-)
17:26 < cfields> but yea, i agree with the above. If it's not a dmg, it's usually a pkg because it requires root (like an sdk). If it's neither, it usually goes in the trash
17:26 < cfields> for me, anyway
17:26 < adam3us> sipa: about bip32 vs armory alan says its not a sub-wallet the same chain code is in the online watching (read only) wallet
17:26 < adam3us> sipa: so its not hierarchical, just using public derivation
17:26 < michagogo|cloud> cfields: Actually, I've seen even pkgs be distributed as dmgs
17:27 < michagogo|cloud> (I have used Macs some, just not a full-time user)
17:30 < cfields> michagogo|cloud: yea, that's reasonable too
17:31 < michagogo|cloud> cfields: So you managed to get bare-bones deterministic DMG working?
17:31 < michagogo|cloud> (bare-bones, meaning without all the fancy dmg features, AIUI?)
17:31 < cfields> yep, passes basic sanity checks anyway
17:32 < michagogo|cloud> That's great :-)
17:32 < michagogo|cloud> Nice work.
17:32 < cfields> thanks. but hold that until there's some proof ;)
17:33 < warren> hmm, what part is signed to distribute in Apple's app store for mac os x?
17:33 < warren> or would it be rejected like they rejected bitcoin apps from the iphone?
17:34 < cfields> the dmg is signed, i believe
17:34 < cfields> any signatue would break determinism ofc
17:34 < cfields> rather.. provable determinism
17:34 < warren> gavinandresen: ever considered submitting Bitcoin to the MacOS X app store?
17:36 < warren> cfields: for developers and power users determinism is great, the only way to prove safety
17:36 < michagogo|cloud> cfields: MAS uses dmg?
17:36 < warren> cfields: but or end users who mess up downloads ... MITM ... DNS redirection ... an app store might be safer.
17:39 < cfields> might be possible to add a comment, not sure. if so, the comment could contain the original checksum
17:45 < michagogo|cloud> warren: Looks like the process is running https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/codesign.1.html#//apple_ref/doc/man/1/codesign
17:45 < michagogo|cloud> and then https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/productbuild.1.html#//apple_ref/doc/man/1/productbuild
17:45 < michagogo|cloud> (https://developer.apple.com/library/mac/releasenotes/General/SubmittingToMacAppStore/)
17:47 < michagogo|cloud> okay, it's 12:47 am
17:47 < michagogo|cloud> goodnight.
17:47 < warren> michagogo|cloud: you must be on the opposite side of the planet from me
17:47 < michagogo|cloud> UTC+2
17:47 < michagogo|cloud> (Israel)
17:48 < michagogo|cloud> warren: Hawaii, right?
17:48 < cfields> great, i think my macbook hdd is about to take a dump
17:48 < warren> yes, UTC-10
17:53 < gavinandresen> warren: RE: app store: maybe when we're 1.0. And have a user-friendly "you are out of date; upgrade now?".  And start in SPV mode. And have a reasonable customer support system.
17:54 < gavinandresen> warren: I think it makes more sense for a company to comercialize Bitcoin-Qt, and give professional support, etc etc etc.
17:54 < warren> bitcointroll isn't a reasonable customer support system? =)
17:54 < warren> joking
17:54 < warren> gavinandresen: to do that wouldn't they need to pay for qt?
17:55 < petertodd> warren: red hat model
17:55 < phantomcircuit> it's not that expensive...
17:55 < gavinandresen> yes, red hat model.
17:56 < petertodd> warren: though in the case of bitcoin, I think there's a lot of stuff about theft that we're not considering... it may be the case that the only model that works for anything over a small businesses re: liability is actually bitbanks - you gotta trust someone, might as well trust someone whose business is trust.
17:56 < petertodd> warren: I sure wouldn't want to be distributing binaries as a business for instance with a support contract without some long discussions with the lawyers first.
17:57 < gmaxwell> warren: where is the bounty link?
17:58 < phantomcircuit> petertodd, "not fit for purpose, any purpose"
17:58 < warren> https://bitcointalk.org/index.php?topic=337294.0
17:58 < petertodd> phantomcircuit: "We're the premier company in the Executive Desk Toys that happen to also be turnkey Bitcoin nodes business!"
17:58 < warren> I suppose we can't get away with a perpetual beta when Bitcoin hits $1 trillion.
17:58 < warren> That is unless a loaf of bread is $10k at that time, then maybe.
17:59 < phantomcircuit> warren, it's a beta until there are no known issues
17:59 < gmaxwell> "Novelty nodes"
17:59 < phantomcircuit> shrug
18:00 < phantomcircuit> im gonna order a bunch of flash drives with the blockchain + bitcoin-qt loaded on them
18:00 < warren> someone donated 0.5 BTC
18:00 < petertodd> warren: tl;dr: people are going to lose shitloads of money, over and over again. and maybe Thompson's "Reflections on Trusting Trust" will be common knowledge.
18:00 < phantomcircuit> and include a nice little script to start with -loadblocks
18:00 < warren> petertodd: the massive centralized thefts seem to happen a lot
18:01 < petertodd> warren: indeed, and more to the point, it's impossible to know how many are insiders.
18:01 < warren> Don't worry, Coin Validation to the rescue.
18:01 < warren> forgot the smiley on that
18:01 < phantomcircuit> warren, the issue is people keep trusting people nobody really knows
18:01 < petertodd> warren: but we're also starting to see thefts due to hacked software - anything that auto-updates is scary.
18:01 < phantomcircuit> people suck at trust
18:02 < warren> You mean TradeFortress isn't trustworthy?
18:02 < phantomcircuit> aahahh
18:02 < phantomcircuit> oh god
18:03 < warren> both him and Ukto came into #bitcoin-dev screaming for help with wallet issues
18:03 < gmaxwell> warren: you mean people didn't know he wasn't trustworthy?
18:03 < phantomcircuit> gmaxwell, amazingly that message was apparently not received by everybody
18:03 < petertodd> warren: My views on those things is I'm likely to lose whatever I have in them eventually, but I also like the privacy. So I've lost money on instawallet, inputs.io, and will eventually lose $100 or so on EasyWallet.
18:03 < warren> it's a little sad that we can't recommend that people can't use bitcoind's wallet for a service provider
18:03 < phantomcircuit> largely because he basically bribed a bunch of people to write positive fluff stories
18:04 < warren> my english is failing,I need more sleep.
18:04 < phantomcircuit> warren, well if there is a 0.8.6 release with my wallet hashing code then it will be totally
18:04 < phantomcircuit> you just need to have enough ram for all of the transactions in the wallet
18:05 < warren> phantomcircuit: was that merged into master yet?
18:05 < phantomcircuit> i have a testnet wallet with like 90k transactions that's only 400 MB on disk
18:05 < phantomcircuit> probably less in memory
18:05 < petertodd> warren: ha, yeah, that satoshi didn't use type1 deterministic wallets should convince anyone he was a shitty programmer.
18:05 < phantomcircuit> warren, yeah it was
18:05 < warren> phantomcircuit: we have at least two DoS patches that could be a 0.8.6
18:05 < phantomcircuit> warren, hmm?
18:05 < phantomcircuit> ones that haven't been merged yet?
18:05 < warren> phantomcircuit: yes
18:05 < phantomcircuit> warren, you have a pr?
18:06 < warren> phantomcircuit: which PR's were the wallet performance commits?
18:06 < warren> phantomcircuit: you really want me to tell the public which are DoS fixes?
18:06 < phantomcircuit> i guess not
18:06 < phantomcircuit> lol
18:08 < phantomcircuit> https://github.com/bitcoin/bitcoin/pull/2950
18:08 < warren> that the only one?
18:08 < warren> I thought there were like four
18:08 < gavinandresen> I'm dragging my feet on 0.8.6 because I keep hoping somebody figures out the leveldb corruption issue….  Time to give up on that, I think.
18:09 < warren> gavinandresen: my 0.8.5++ branch is super well tested
18:09 < gavinandresen> warren: famous last words!
18:09 < warren> gavinandresen: the leveldb bounty was only posted recently, let's wait a bit longer?
18:10 < petertodd> gavinandresen: release 0.8.6 with macos disabled, followed by 0.8.7 with it enabled once leveldb is fixed - good statement re: maintenance doesn't happen by magic
18:11 < gavinandresen> petertodd: good idea.
18:11 < phantomcircuit> warren, there are other ones that haven't been merged
18:11 < gavinandresen> warren: link to your 0.8.5++ branch?
18:11 < phantomcircuit> i fixed the fractal complexity IsConfirmed function
18:12 < warren> gavinandresen: https://bitcointalk.org/index.php?topic=320695.0
18:12 < warren> gavinandresen: not suggesting shipping all of this crap of course
18:12 < warren> phantomcircuit: should I add your wallet thing to OMG?
18:13 < gavinandresen> mmm, definitely not. 0.8.6 will be critical-bug-fix-only
18:13 < warren> gavinandresen: OMG is whatever I think is good enough for non-mining nodes
18:14 < warren> gavinandresen: some of the patches here are appropriate for 0.8.6
18:14 < gavinandresen> warren: email me a list
18:15 < warren> gavinandresen: tonight
18:16 < warren> gavinandresen: seriously going to skip mac in a release?
18:17 < petertodd> warren: there's important fixes that would go in 0.8.6, why hold them back for a small minority?
18:17 < warren> are they a small minority?
18:18 < warren> and are the fixes important?
18:18 < petertodd> warren: last I checked on one of my nodes the supermajority of nodes had ip addresses that were definitely VPS services
18:18 < warren> petertodd: all at digitalocean? =)
18:18 < sipa> note that there aren't even bitcoind releases for OSX
18:18 < petertodd> warren: lol, nah, this was before that
18:19 < gavinandresen> warren: sure, when the bug is fixed we can release a mac version then. I don't like shipping known-seriously-buggy software.
18:19 < phantomcircuit> gavinandresen, well currently all the osx releases are known to be buggy
18:19 < gavinandresen> I don't like taking things away from people even more....
18:19 < nOgAnOo> hi phantom <3
18:19 < phantomcircuit> would it not be better to fix some things even if that cant be fixed yet?
18:19 < nOgAnOo> I love you.
18:19 < warren> gavinandresen: while I tested these patches against 0.8, my 0.8 is really a hybrid of 0.9, so I make no guarantees about these backports being correct against plain 0.8.5
18:20 < phantomcircuit> nOgAnOo, lol ok
18:20 < phantomcircuit> nOgAnOo, ohh hello
18:20 < phantomcircuit> i know who you areeee
18:20 < sipa> ehm
18:20 < sipa> get a room
18:20 < petertodd> warren: why not point osx users to your OMG branch then?
18:20 < sipa> s/room/channel/
18:20 < nOgAnOo> I remember your handle.. but I'm stoned.
18:21 < petertodd> "Wizards don't use drugs."
18:21 < phantomcircuit> lol
18:21 < nOgAnOo> *laffter*
18:21 < nOgAnOo> I hauled 5 truckloads of compost today
18:21 < nOgAnOo> shoveled by hand
18:21 < petertodd>  /ignore nOgAnOo
18:22 < warren> gavinandresen: the elephant in the room here: many of us really think NODE_BLOOM should be added as a safety fallback.  If we're doing 0.8.6 for the purpose of protecting the network with <those other DoS mitigations> I strongly suggest we include NODE_BLOOM too.  Having it disabled by default but available as an option would allow the world to recover quickly without a software update.
18:22 < warren> petertodd: OMG branch isn't fixed for mac either
18:22 < petertodd> warren: you really had to bring that up?
18:22 < warren> petertodd: is it productive to continue to not talk about it?
18:23 < petertodd> warren: IMO we've pushed the cost of the attack just high enough that it's a bit hard to exploit, which gives us breathing room; NODE_BLOOM in that context is not critical.
18:23 < warren> gavinandresen: given inertia of defaults we're not under the risk of people turning it off en masse.
18:23 < petertodd> warren: IE, it's a "policy" decision, and calling it a solution to DoS attacks isn't the way to talk about it.
18:24 < warren> petertodd: sure it isn't a solution
18:24 < petertodd> warren: hence, leave it out of 0.8.6 and let people continue to think about it on their own terms
18:24 < warren> petertodd: neither is anything else we have
18:24 < petertodd> warren: yes, but we're at the point where a bored hacker can't cause us damage we can't recover from.
18:25 < warren> bored hacker was the risk we're concerned about?
18:25 < gavinandresen> warren: "many of us" ?  be specific, please.
18:25 < petertodd> warren: not exactly a strong guarantee, but it takes pressure off and lets all kinds of solutions be worked on.
18:25 < warren> gavinandresen: perhaps you didn't notice that nearly everyone is in favor of it?
18:26 < petertodd> warren: bitcoin-qt development happens by rough consensus, nearly everyone with strongly opposed minority isn't rough consensus
18:26 < gavinandresen> warren: I was under the impression that sipa/jgarzik/gmaxwell did not feel strongly about it.  And I'm listening to Mike Hearn very carefully, because bitcoinj is ACTUALLY USING THE FEATURE
18:27 < gavinandresen> It seems extremely likely that match-only bloom filters will be the default way of propagating nodes in the 0.9 release, too.
18:27 < gavinandresen> (to help address the orphan cost / high transaction fee problem)
18:27 < warren> sipa jgarzik gmaxwell were actually in favor.
18:27 < gavinandresen> ^propagating nodes^propagating blocks
18:27 < sipa> i'm in favor of NODE_BLOOM yes, but i don't think it's urgent
18:27 < petertodd> sipa: +1
18:28 < warren> OK, it isn't urgent enough for 0.8, I agree.
18:28 < sipa> also, match-only bloom filtering has no DoS risk, it can always be available
18:28 < petertodd> sipa: yeah, match-only bloom filtering has nothing to do with the real intent of NODE_BLOOM
18:28 < sipa> it's just a side effect of nicely fitting in the same protocol
18:29 < gavinandresen> I'm already hearing the "why am I getting merkleblock messages when I don't have NODE_BLOOM set" complaints…..
18:29 < warren> gavinandresen: part of the problem with bitcoinj is its scary absolute reliance on using only the DNS seeds, not asking nodes for peer addresses and not remembering any.  It also has no facility to query peers for service bits and deciding not to use that peer.  We're looking at fixing that.
18:29 < petertodd> sipa: yup, and as match-only becomes more developed my NODE_BLOOM bip should be updated to figure out how to differentiate them
18:29 < warren> gavinandresen: how is that true?  there aren't any NODE_BLOOM nodes yet.
18:30 < sipa> warren: he's prognosticating
18:30 < gavinandresen> warren: if we implement NODE_BLOOM but make an exception for match-all, then that is a wart that future developers will wonder/complain/obsess-over ....
18:31 < petertodd> gavinandresen: yes, which means letting the discussion sit for a bit while that's hashed out is perfectly reasonable.
18:31 < warren> gavinandresen: let's have the full policy discussion for 0.9, no rush for now.  We have problems with other implementations of full nodes and future pruned nodes that can't service bloom.
18:31 < warren> gavinandresen: sorry for pushing for 0.8, it's not ready, I agree.
18:31 < gavinandresen> good, we all agree
18:32 < sipa> warren: you mean 0.10 and 0.9 i think
18:32 < sipa> 0.8 has been out for half a year or more
18:33 < petertodd> warren: the question isn't "can't service bloom", it's "don't want too/it would be best if they used their resources in a different way"
18:33 < petertodd> warren: sure, some can't, but that's not the interesting part
18:37 < cfields> which ubuntu version did we end up upgrading gitian to for win32 builds?
18:37 < warren> cfields: 12.04
18:38 < cfields> blah
18:38 < warren> cfields: let's have a fourth VM! =)
18:38 < warren> cfields: you found that any distro clang is good enough?
18:39 < cfields> warren: i just had the fun of ripping out my nightlies and confirming that raring's default clang works
18:39 < warren> trouble there is it isn't LTS
18:39 < petertodd> gavinandresen: re: high fees, if you can get 0.1s latency, and 500KB/s bandwidth between hashing power, 0.1mBTC/KB fees are profitable with 1MB blocks - if you care about the issue, tell BTC Guild, GHash.IO, Eligius and BitMinter/Slush to run some nodes doing private peering and do 1MB blocks and you're done.
18:39 < cfields> without a big hassle, i can't test anything lower. so for my POC, i'm going with raring
18:40 < cfields> if it turns out that it works with earlier versions, that's a bonus
18:40 < petertodd> gavinandresen: if they don't listen, well, that says a lot about pool incentives...
18:40 < warren> cfields: want me to create a 12.04 VM for you to login and test?
18:41 < cfields> warren: nah, nothing's automated. so it's not an easy test, i'd have to recreate my entire env.
18:41 < cfields> i'll script something up as agnostic as possible
18:41 < gavinandresen> petertodd: I'm trying to get out of the business of "Everybody Do What Gavin Says"
18:42 < warren> cfields: if we can figure out how to use new-linux to compile old-glibc compatible binaries, we can have the same VM for all gitian.
18:42 < petertodd> gavinandresen: ok, I'll do
18:42 < petertodd> *do it
18:42 < gavinandresen> petertodd: excellent
18:42  * gavinandresen rubs his hands together like Mr. Burns
18:43  * petertodd rubs his hands together like the board that Mr. Burns is accountable too
18:43 < cfields> warren: aiming for a single abi isn't reasonable to me. someone else can attempt if they'd like, but i won't be spending my time on that
18:43 < warren> petertodd: was that ever featured in an episode?  I don't recall.
18:43 < petertodd> warren: it got left out for dramatic purposes
18:44 < petertodd> warren: quite serious I'm really interested to see how pools react to this stuff - it can be taken as a solid sign of centralization after all
18:45 < petertodd> warren: what I'm also interested in, is trying to figure out if this latency/bandwidth stuff - the limits of the "jam free broadcast medium" model - is inherent to the design of Bitcoin and by extension other possible consensus systems.
18:47 < petertodd> warren: e.g. suppose you had a system where multiple blocks could have the non-conflicting parts of them re-merged - how does that change the profitability vs. hashing power effect? can you get a system where the dE/dQ isn't positive, maybe zero or even negative? I dunno.
18:47 < sipa> petertodd: you know about amiller's blockdag idea?
18:47 < petertodd> sipa: that's exactly what I'm talking about
18:48 < petertodd> sipa: could be especially important for p2pool for instance - and it's easiest to implement there
18:48 < sipa> not really, if you say "non-conflicting parts"
18:48 < petertodd> ?
18:50 < amiller> i never got very far on it
18:50 < amiller> it's along the lines of stuff you've talked about anyway petertodd
18:50 < petertodd> amiller: ah, I was going to ask if you had published it
18:51 < amiller> i have rambled about it once or twice in forum posts and bitcoin-dev
18:51 < sipa> petertodd: blocks would refer to a single "valid predecessor" node, but also to 0 or more other blocks of which only the PoW is merged, not the transactions
18:51 < petertodd> sipa: right, and in this case, if merging the PoW also rewards those who did that work in some way, then you may be able to make profitability not so heavily dependent on hashing power and latency/bandwidth
19:15 < amiller> no one's going to like it, but i'm vaguely headed towards a notion of incentive-compatibility in a world of context-dependent values of things
19:15 < amiller> basically the path to that is to realize that miner fees may be in the form of color coins
19:15 < amiller> and you can't prevent miners from being motivated by overlay values
19:40 < gavinandresen> amiller: If "nobody" likes it, then it should be easy to prevent. Just have miners "discourage" blocks that they don't like.  We haven't done any of that yet, but the more I think about it the more I think that is the way miners will solve collective-action problems
19:41 < amiller> i mean no one's going to like it just because it challenges the notion of "one true currency" that makes things simpler
19:41 < gavinandresen> amiller: ah, ok.
20:13 < Luke-Jr> gavinandresen: that only works if it's something non-debatable with unanimous consensus against it
20:14 < Luke-Jr> to discourage blocks that are mining legitimately, even if everyone dislikes something, is nothing short of a conspiracy to 51% really
20:14 < gavinandresen> Luke-Jr: doesn't have to be unanimous
20:15 < gavinandresen> if miners are using a variety of policies for how to break block-chain-race ties, then that is perfectly OK
20:15 < Luke-Jr> oh, sure
20:15 < Luke-Jr> I thought you meant deliberately forking
20:16 < gavinandresen> if miners don't know exactly how ties are being broken, all the better.
20:16 < gavinandresen> No, when I say "discourage" i mean  relay all orphans, and if there is a tie, use some policy to decide which fork to follow
20:17 < Luke-Jr> makes sense then
20:18 < petertodd> There's also the argument that relaying all orphans levels the playing field between those with and without a lot of nodes, although I'm not 100% convinced - relaying orphans done badly uses up bandwidth that could be used for something else.
20:18 < petertodd> Relaying orphans would be damn convenient though to get good stats...
20:19 < warren> petertodd: just peer with all nodes to get good stats...
20:19 < gmaxwell> I don't think thats obvious at all. Relaying orphans is against your self interest in some cases, e.g. if it helps nodes end up on a different chain than the one your node prefers.
20:20 < petertodd> warren: and if knowing about orphans is ever profitable we've just incentived an attack
20:20 < gmaxwell> For example, non-relaying of orphans means that a inconsistent hardforking glitch is more likely to pick the least common denominator chain instead of leaving some nodes hardforked.
20:21 < Luke-Jr> let the receiver choose whether he wants it ;)
20:21 < petertodd> gmaxwell: IIRC I mentioned something very similar to that in my discussion about the 30% propagation incentives
20:21 < Luke-Jr> btw, I assume "orphans" here is being used to mean stale blocks..
20:21 < petertodd> gmaxwell: and yeah, a inconsistent hardforking glitch is a consideration
20:22 < petertodd> Luke-Jr: correct, and you'd only sanely do that if its palce in the chain was very recent
20:23 < gavinandresen> right, I mean relay-all-blocks-at-current-best-block-height-that-I-think-are-valid
20:23 < gavinandresen> Having nodes only relay blocks that they are mining on top if might, indeed, be the best policy
20:24 < gavinandresen> ^on top of^
20:24 < petertodd> gavinandresen: which is the current policy...
20:25 < Luke-Jr> petertodd: if so, only recently?
20:25 < Luke-Jr> IIRC there was a fingerprinting bug that allowed you to fetch old stale blocks
20:25 < gavinandresen> Right, but we could change the "what should I do if I get another block at current best height" policy different-- could be switch to it, and relay it....
20:25 < petertodd> Luke-Jr: if you relay non-recent, at some point it makes some types of DoS attacks possible
20:25 < Luke-Jr> petertodd: no, I mean until recently, we *did* relay old stale blocks
20:26 < gavinandresen> we wouldn't relay them, but we would serve them up
20:26 < petertodd> Luke-Jr: not relay, we'd give the data for them if asked
20:27 < petertodd> gavinandresen: note that from a technical point of view checking that the second one is actually valid kinda sucks - easier to ignore the txin validity and just relay
20:27 < Luke-Jr> hmm, I need to rebuild #bitcoin-watch's bitcoind branch
20:27 < Luke-Jr> it keeps crashing
20:28 < Luke-Jr> I wonder if it would make sense as a block-preference policy, to use "has all the same outputs as the current bestblock, but fewer transactions"------ selfanswer: no, since coinjoin changes txid
20:28 < Luke-Jr> too bad txids/outputs aren't referred to by hash of scriptPubKey
20:28 < petertodd> Luke-Jr: rational miner policy in some cases is to prefer blocks with the fewest transactions
20:29 < petertodd> Luke-Jr: or, to be exact, smallest fees
20:29 < gavinandresen> petertodd: meta-rational policy is to prefer larger blocks
20:29 < Luke-Jr> rational policy IMO is to prefer the first one you saw :p
20:29 < petertodd> gavinandresen: meta-rational policy to hold hands and sing songs about world peace
20:29 < Luke-Jr> because it means whoever broadcast it might have better peering than the later-seen one
20:30 < gavinandresen> … and if you discourage blocks that are "too small" then you can FORCE minority assholes to do the right thing
20:30 < Luke-Jr> and you don't want to get in a stale-block-war with him
20:30 < gavinandresen> (well, incentivize....)
20:30 < Luke-Jr> gavinandresen: the smaller blocks are probably better than the bigger ones!
20:30 < petertodd> gavinandresen: there's already that incentive because you don't want 100% propagation
20:30 < gavinandresen> Luke-Jr: better how?
20:30 < petertodd> Luke-Jr: heh, the small blocks are less spam of course :P
20:30 < Luke-Jr> gavinandresen: likely to have better spam filters, and not full of spam
20:31 < petertodd> Luke-Jr: given we somehow are meta-rational about resource use...
20:31 < petertodd> *don't want 100% propagation in the cases where wanting small blocks apply
20:31 < gavinandresen> Luke-Jr: okey dokey.  That's why I say "too small" -- that can be a miner policy preference, too small versus too big…. "this one is Just Right."
20:31 < Luke-Jr> gavinandresen: also, if you ever prefer larger blocks, you incentivize the miner to make spam if there isn't any left
20:31 < petertodd> Luke-Jr: indeed
20:31 < gavinandresen> sigh.  okay, fine, "includes the right number of transactions that are/were in the mempool"
20:32 < Luke-Jr> gavinandresen: then you punish miners with superior spam filters than whatever-the-relay-nodes-run
20:32 < Luke-Jr> and/or incentivise spam-filling miners to broadcast the spam
20:32 < gavinandresen> who is "you" ?  This would be general-consensus-of-the-network
20:32 < petertodd> There's also the strategy that if you know another block has been created, only mine much smaller blocks until you verify it - but that's only really applicable if mining has forced verification...
20:33 < Luke-Jr> gavinandresen: if it's hardcoded in mainline code, there is no consensus-of-the-network, just core developer fiat
20:33 < gavinandresen> I would give miners the knobs to decide whatever policy they liked, and have them figure it out based on their best judgement.
20:33 < petertodd> gavinandresen: why does the network matter? pools can and should connect to each other directly in most models
20:33 < Luke-Jr> I like knobs.
20:34 < petertodd> In which case, if we're going to talk about rational strategy for non-mining nodes, we're back to "do good for our clients", and they'd like to know if an orphan exists that might suddenly unconfirm a transaction they thought was confirmed...
20:34 < Luke-Jr> ^ best reason yet to relay stale blocks imo
20:35 < Luke-Jr> in fact, I think it outweighs all the costs
20:35 < gavinandresen> petertodd: sure, pools will directly connect to each other. I assume pools will listen to their users about what their block creation policy should be, and if the policy is way out of whack for what the users want (e.g. their users cannot transfer their payouts to Mt.Gox because transaction fees are too high) then they will lose hash power.....
20:35 < petertodd> Luke-Jr: there's strong incentives to do it too once merchants get sophisticated software
20:35 < Luke-Jr> *maybe* it even makes sense to relay *invalid* blocks that meet the POW requirement, for that reason
20:35 < petertodd> gavinandresen: users of pools != users of bitcoin
20:36 < petertodd> Luke-Jr: yeah, and technically relaying regardless of validity is way easier to implement
20:36 < gmaxwell> who the heck knows anything anymore, see ghash.io/cex.io 0_o
20:36 < Luke-Jr> petertodd: point is, users of pools have the influence here
20:36 < gavinandresen> petertodd: really?  There are still pools that payout using PayPal instead of bitcoin?
20:36 < Luke-Jr> gavinandresen: yes
20:36 < petertodd> Luke-Jr: yes, but how? that's a hard question
20:36 < Luke-Jr> I think Eclipse does still
20:36 < petertodd> gavinandresen: huh? that's what I said
20:38 < gmaxwell> relaying invalid blocks is just irrational though, not only does it use your resources, it helps the network achieve a difference consenus from you. At best it's probably not usually harmful. If it were limited to valid that would be less concerning to me, but it's still helping the network achieve a different state than your current node, but at least one your node would find acceptable.
20:38 < petertodd> gmaxwell: look at it from a merchants perspective: relaying invalid blocks tells them something useful: an invalid block was created.
20:39 < petertodd> gmaxwell: That could mean "I should trigger safeguards because something went wrong."
20:39 < Luke-Jr> gmaxwell: but it might help you spend your money easier
20:39 < Luke-Jr> since merchants will know if someone is trying to build a different consensus of almost any sort
20:39 < gmaxwell> petertodd: Other people doing it helps them in that case, but it's not personally rational.
20:40 < Luke-Jr> they can then afford to accept 1 block deep confirmation
20:40 < gavinandresen> Relaying invalid blocks seems like angels-dancing-on-the-head-of-a-pin … there should be approximately zero invalid blocks created
20:40 < gmaxwell> (except in the good for everyone sense, perhaps, but relaying invalid blocks is also not good for everyone, I dunno if on the balance it's helpful— just relaying compeating headers is just as good for knowing bad things are happening, I think)
20:40 < Luke-Jr> gmaxwell: if you're the only one selfishly relaying blocks, it won't matter
20:40 < petertodd> gmaxwell: In the spherical cow model you would relay anything at all and have infinite bandwidth - relaying the fact that someone threw away $12,500 due to a bug is worth knowing.
20:41 < Luke-Jr> gavinandresen: but if there are, we want people to know about it
20:41 < gavinandresen> meh. Throwing away $12K will be a self-correcting problem
20:41 < gavinandresen> (and QUICKLY self-correcting)
20:41 < petertodd> gavinandresen: eventually, in the meantime it means you probably don't want to accept zeroconf at the very least
20:41 < Luke-Jr> gavinandresen: it might not be thrown away in some case
20:41 < gmaxwell> gavinandresen: except when they are. E.g. if not for the fact that two directly connected pools with >>50% hashpower were running 0.8 the <0.8/0.8 fork would have self-cured due to nodes not relaying it.
20:42 < gavinandresen> hmm?  relaying double-spent transactions is a good idea.
20:42 < petertodd> Besides, implementing relaying based on valid PoW and nothing else is way easier to implement and still DoS resistent.
20:42 < gavinandresen> that's completely separate from invalid blocks
20:42 < gmaxwell> and instead we got a rather large reorg out of that.
20:42 < Luke-Jr> gavinandresen: so pull the transactions out of the blocks?
20:42 < Luke-Jr> at least the blocks have a proof-of-work - hard to DoS with that
20:43 < Luke-Jr> mere transaction double-spend notification is riskier IMO
20:43 < petertodd> gmaxwell: pools connecting directly to each other is just going to become more, not less, of a thing in the future
20:43 < Luke-Jr> (although possibly still necessary)
20:43 < petertodd> Luke-Jr: yeah, relaying headers is even easier to defend
20:43 < gavinandresen> Luke-Jr: sure, if they're valid and haven't already been relayed, you could pull them out of the block.  There's going to be a very strong incentive not to put non-relayed transactions in your block, though
20:43 < Luke-Jr> petertodd: if both blocks have your transaction, you care a bit less ;)
20:43 < gavinandresen> (because it'll increase your orphan cost by quite a bit)
20:43 < gmaxwell> petertodd: none of this changes that fact that relaying a block you don't personally like is not something that helps you.
20:43 < petertodd> Luke-Jr: exactly!
20:44 < gmaxwell> at best you can say it's probably inconsequential.
20:44 < petertodd> gmaxwell: yes, but if you are running a node *on behalf of merchants* the incentives are different!
20:45 < gmaxwell> I'm sure if we're thinking at all we're spending 1000x more thought than any bitcoin merchants are likely to put into anything in the near term.
20:45 < gmaxwell> oh well.
20:45 < petertodd> Yeah well, if we're going to eventually design better systems, understanding the incentives of the one we have right now is very valuable.
20:46  * gmaxwell goes off and continues to sulk that he found _yet another_ very high profile bitcoin service provider that was trivially exploitable.
20:46 < petertodd> gmaxwell: that we're all still whitehats says a lot about our incentives :P
20:47 < Luke-Jr> gmaxwell: to be fair, BitPay did hire jgarzik; that counts :P
20:47 < gmaxwell> petertodd: what good are awesome exploits if you can never brag about them?
20:47 < petertodd> Luke-Jr: heh, cavirtex tried to hire me
20:47 < petertodd> gmaxwell: what good is bragging rights if you don't have hired strippers and the hot tub?
20:48  * petertodd brb, snorting coke
20:48 < gmaxwell> hah
20:48 < Luke-Jr> gmaxwell: next time maybe you should say "if I demonstrate how I can steal 50 BTC from Coinbase, can I keep it?" ;)
20:48 < Luke-Jr> s/Coinbase/whatever service/
20:48 < Luke-Jr> s/50 BTC/something reasonable at the time/
20:48 < petertodd> Luke-Jr: heh, that's why I demonstrated that zeroconf attack on bc.i rather than just told piuk it was possible :P
20:49 < petertodd> Luke-Jr: figured I had a 50:50 chance he'd let me keep it
20:49 < Luke-Jr> <.<
20:49 < gmaxwell> I don't even want the 50 BTC, I want the bitcoin economy to not be super fragile.
20:49 < Luke-Jr> petertodd: if you don't ask in advance, there's a question of legality
20:50 < petertodd> Luke-Jr: meh, I didn't know if it could be done, which puts you in a catch-22 between responsible disclosure and actually doing the attacks
20:50 < Luke-Jr> petertodd: that's why you ask :P
20:50 < Luke-Jr> once you have permission to try, then go for it :D
20:50 < sipa> "Hi, I think there's a bug in your systems. If I can exploit it tovgain no more than X btc, can I keep it?"
20:50  * Luke-Jr glares at Litecoin for not giving permission
20:50 < petertodd> Luke-Jr: that's my point, by asking I would have been irresponsibly disclosing the attack!
20:51 < Luke-Jr> petertodd: ?
20:51 < petertodd> sipa: yes, which I probably should have done, but I figured $50 wasn't a big deal
20:51 < petertodd> Luke-Jr: the nLockTime zerocoin attack was embarassingly obvious once you got at all clued in on it
20:51 < gmaxwell> At least with bc.i I've had bad expirences with them ignoring reports, and then claiming that an attack wasn't ever possible after I do finally get their attention. Mostly I just try to not load their pages, lest I find _yet another_ exploitable vulnerablity and have to deal with the stress of convincing them to fix it.  Fortunately most other services I've reported to are more responsive.
20:52 < gmaxwell> TD seemed to be saying bc.i is still mostly a one man operation, so I guess that explains part of it.
20:52 < petertodd> Luke-Jr: I basically went through every service I could think of and did the attack - only bc.i was really vulnerable to it.
20:52 < Luke-Jr> "Hi, I offer penetration testing services. You owe me nothing if I don't find anything, but if I do, I keep up to x BTC of what I acquire using the discovered exploit, and deliver to you documentation on how I did it. If this offer interests you, please sign and email this permissions contract."
20:53 < petertodd> Luke-Jr: meh, for now you can be pragmatic - give it another year or two and my advise would be don't
20:53 < Luke-Jr> ?
20:53 < Luke-Jr> with permission, hard to see how it can go sour
20:54 < Luke-Jr> of course, in a year or so hopefully there won't be anything so obvious I could actually get anywhere XD
20:54 < petertodd> Luke-Jr: as bitcoin gets bigger and the companies have more to lose permission is both more important, but also, doing stuff out in the open is legally risky
20:54 < gmaxwell> Luke-Jr: one limitation with that is that some attacks require collateral crime... a real attacker isn't constrained to not defraud other people, but you are.
20:54 < petertodd> Luke-Jr: even really whitehat-acting people ahve been rail-roaded in the real world
20:54 < gmaxwell> e.g. those people trying to compromise mining pools by social engineering datacenter operators.
20:54 < Luke-Jr> petertodd: with permission?
20:55 < petertodd> Luke-Jr: yes, define "permission" - companies have later claimed whitehats didn't have permission for instance
20:57 < Luke-Jr> petertodd: signed document
20:58 < petertodd> Luke-Jr: "That employee never had authority to sign that document/you and him were conspiring." (e.g. if an attack somehow goes worse than expected, say takes down a whole site accidentally)
20:58 < Luke-Jr> hrm
21:01 < petertodd> Legality is hard. Speaking of, it's going to be fascinating to see the first time someone threatens to prosecute a miner for mining a zeroconf double-spend...
21:02 < petertodd> ...or assisting in one, as you do with Elgigius by not following the same mempool rules re: satoshidice as everyone else. Or as you do every time you upgrade...
21:02 < gmaxwell> how can you even establish which one was the right one?
21:02 < gmaxwell> e.g. the doublespender could have just given you the other one first.
21:02 < petertodd> gmaxwell: Sworn testimony in court obviously.
21:03 < petertodd> This isn't a technical question.
21:03 < gmaxwell> I suppose. The doublespender has no assets and cooperates?
21:04 < petertodd> No, e.g. a *dice site: the site would swear that according to their logs GHash.IO allowed a double-spend to be mined on multiple occasions, or Eligius *through negligence* allowed it to happen.
21:04 < petertodd> "Accepted practice in Bitcoin is to not mine double-spends and to peer well enough that they don't happen."
21:04 < Luke-Jr> petertodd: good thing everyone here is able to be an expert witness against such nonsense
21:05 < Luke-Jr> petertodd: Eligius didn't neglect anything
21:05 < petertodd> Just for the record, for a sufficient amount of money I'll be a expert witness on the opposite side...
21:05 < Luke-Jr> petertodd: you'll lie under oath?
21:05 < petertodd> (might as well say that given that is the reality...)
21:05 < petertodd> It's not a lie, it's... a different interpretation of the facts.
21:05 < Luke-Jr> that statement would be a lie.
21:06 < Luke-Jr> every double spend ever, has been mined
21:06 < petertodd> Luke-Jr: what do you mean by that?
21:06 < Luke-Jr> petertodd: exactly what I said
21:06 < petertodd> Well I've personally used that exact mempool trick to demonstrate that zeroconf isn't safe, so I'm not sure what you mean there.
21:06 < Luke-Jr> for any given conflicting transaction pair, one of them has appeared in a block eventually
21:07 < Emcy> anyone surprised how many people sont appear to like the eligius address reuse patch thing
21:07 < Luke-Jr> Emcy: I'm surprised
21:07 < Luke-Jr> partly my fault though
21:07 < Luke-Jr> the original plan was to make a set of multiple competing patches
21:07 < petertodd> Right, but I'm saying you could convince a court that because "accepted practice" was to not allow double-spends in mempools, failing to do that is negligence, or perhaps conspiracy if an attacker keeps doing that and Eligius doesn't change their policy.
21:07 < Luke-Jr> but it was taking up too much time
21:08 < Emcy> ar they just ignrant/misinformed or do they not want anything to rock the price boat
21:08 < Luke-Jr> petertodd: either of the transactions is equally valid
21:08 < Luke-Jr> and accepted practice is that nodes are free to choose which transactions they relay or mine
21:08 < Luke-Jr> and often DO discriminate
21:09 < petertodd> Luke-Jr: no, one was broadcast first. By the *accepted practices* the first was the valid one. Eligius allowed a double-spend to enter its mempool even 5 minutes later!
21:09 < petertodd> Luke-Jr: No it's not. Look at how angry people were at GHash.IO.
21:09 < Luke-Jr> petertodd: miners have a duty to filter spam. even if Eligius were the only one to be fulfilling this role (we're not), it is the *other* miners who are neglegent
21:10 < Luke-Jr> petertodd: they were mad at GHash.IO for actually PERFORMING the double-spend
21:10 < Luke-Jr> not for merely mining it
21:10 < Luke-Jr> also, that thread was surprisingly not-very-angry
21:10 < petertodd> Luke-Jr: "Duty to filter spam? What duty? Accepted practice by all by one rogue pool is to follow the Official Bitcoin-QT Implementation."
21:11 < Luke-Jr> petertodd: that's not true
21:11 < petertodd> Luke-Jr: Truth is established in a court of law in a process that may have results you do not like.
21:11 < Luke-Jr> petertodd: no, truth cares not what any court says
21:12 < petertodd> Luke-Jr: ok, whether or not the government has a judgement for damages and/or an arrest warrent for your name has nothing to do with your definition of truth
21:12 < Luke-Jr> petertodd: whether you have committed perjury does
21:13 < Luke-Jr> "Accepted practice by all but one percent of businesses is to use USD cash"
21:13 < Luke-Jr> ^ about as good as your argument
21:13 < petertodd> Hey, we can sit here all day if you want to be a engineer and ignore the complexity of the legal system.
21:14 < petertodd> Reality is, my line of argument is one that a court may very well accept, resulting in real world and undesirable consequences.
21:15 < Luke-Jr> not after I demonstrate how you're lying :P
21:15 < petertodd> if you truly believe a court would be guaranteed to think I was lying I suggest you spend some more time with your lawyer
21:18 < Luke-Jr> I don't believe a court would hear a case from a criminal enterprise plaintiff
21:18 < petertodd> what? satoshidice?
21:19 < Luke-Jr> yes
21:19 < petertodd> ok, go to a jurisdiction where gambling is legal and or replace that example with another business
21:20 < Luke-Jr> I don't see a court accepting the basis that I am forced to do business with <other business>
21:20 < petertodd> Or heck, lets say I write an Android app called "Rip off zeroconf merchants!" that automates the process, and give Eligius 10% of the stolen funds in terms of fees.
21:20 < Luke-Jr> even outside of bitcoin, I have the right to choose who I do and don't do business with
21:20 < petertodd> This has nothing to do with who you choose business with - no-one is making you mine those transactions.
21:21 < petertodd> We're just forcing you to follow standard good practice and accept them into your mempool so double-spends can be detected and not mined.
21:21 < gmaxwell> well be careful to distinguish civil liability and criminal.
21:21 < gmaxwell> I think making a criminal claim out of anything in this space would be very hard.
21:21 < gmaxwell> It's too easy to deny intent.
21:21 < Luke-Jr> petertodd: accepting them into my mempool is forcing me to provide a service to them
21:21 < petertodd> gmaxwell: indeed, and civil is majority, which is a much lower bar...
21:21 < gmaxwell> (except in cases like ghash.io where they were directly and obviously profiting from it)
21:22 < petertodd> gmaxwell: I brought up the app example because it could be used in court to infer conspiracy to commit a crime.
21:22 < Luke-Jr> petertodd: why should I be forced to provide conflict detection services for <your business>?
21:22 < gmaxwell> In a civil claim, its almost sufficient to just show someone was harmed and that you were on the critical path.
21:22 < petertodd> Luke-Jr: what gmaxwell said...
21:22 < petertodd> Luke-Jr: you are being forced to take the minimal accepted prudent action
21:23 < gmaxwell> It's uncertian what the standards people would be held to in the future.
21:23 < petertodd> gmaxwell: +1 - Reality is this is all uncertain.
21:23 < Luke-Jr> petertodd: especially in the case of a spammer, who is abusing these exact resources
21:23 < gmaxwell> Basically as petertodd says. Doing something unusual that is responsible for someone else losing money, which you could or should have foreseen, may leave you with civil liablity.
21:23 < gmaxwell> _may_
21:23 < gmaxwell> In the case of these gambling services its totally moot.
21:24 < Luke-Jr> gmaxwell: even if they know they can lose money?
21:24 < petertodd> gmaxwell: yup, which is why defacto-zeroconf scares me a lot - the other half of it is "something unusual" might just mean you didn't invest as much money in network bandwidth
21:24 < gmaxwell> Their services are very likely unlawful in any jurisdicition that you care about being exposed to, and so they don't get to enjoy relief from the courts.
21:24 < gmaxwell> Luke-Jr: sure, and in defense someone being accused of a civil claim here would point to the fact that everyone knows zeroconf is unsafe.
21:25 < petertodd> Luke-Jr: "Every knows zeroconf is unsafe? Why we have the Lead Developer of Bitcoin on record saying it's safe for low-value transactions and that no pool would mine double-spends to preserve the value of their Bitcoins."
21:25 < gmaxwell> Luke-Jr: most of the US uses https://en.wikipedia.org/wiki/Comparative_negligence in deciding these things...
21:26 < gmaxwell> It's possible to get a decision that "yea, they should have known it was unsafe, so you're only 5% at fault"
21:26 < petertodd> Yup, and 5% of tens of thousands might still bankrupt you.
21:27 < gmaxwell> more importantly, you really just want to not be in a position where someone can bring a claim to court.... just defending is very expensive.
21:27 < petertodd> nor do you want to be in a position where some regulator is actually working behind the scenes to make the case happen
21:28 < Luke-Jr> all sounds like more reason to remove any sense of "defaults" from bitcoind
21:28 < gmaxwell> well, the right case happening wouldn't be so bad.
21:28 < petertodd> Luke-Jr: that I agree with mostly
21:29 < phantomcircuit> gmaxwell, boy is it
21:29  * petertodd brb, starting a fake ringtone company to set precedent
21:30 < gmaxwell> you really want the precident setting defrauded site to be that girls gone wild guy
21:31 < petertodd> ha, ok, "pay by the minute barely legal live BDSM porn"
21:31 < Emcy> cant you just ensire tor mining is a thing for the foreseeable and preclude all this nonsense
21:32 < petertodd> Emcy: "As a major pool, you should put a stop to this nonsense by discouraging blocks with double-spends." <- I've seen this as a suggest way too many times
21:32  * warren is anyone else creeped out by that guy?
21:33 < petertodd> warren: which guy?
21:34 < Emcy> whats wrong with discouraging double spends
21:34 < petertodd> Emcy: by that I mean if you see a block with a double-spend in it, you delibrately orphan it
21:34 < petertodd> Emcy: is very dangerous for consensus
21:34 < Luke-Jr> nOgAnOo: yes; no
21:35 < Emcy> i didint know you could get a double spend into the same block
21:35 < petertodd> Emcy: block would double-spend a tx in the mempool in this case
21:35 < Emcy> that seems bund
21:50 < gmaxwell> Does anyone offer abortions for bitcoin?  Now there would be your double feature test case.
21:50 < gmaxwell> catholic abets a double spend fraud of a payment for an abortion. 0_o
21:54 < Luke-Jr> gmaxwell: you didn't think that through ;)
21:54 < Luke-Jr> I'm not about to aide someone seeking a murder for hire
21:57 < warren> Luke-Jr: now sure how you'd code that into eligius ...
21:58 < gmaxwell> Luke-Jr: no thats exactly the point.
21:58 < gmaxwell> Luke-Jr: someone accepts payments for abortions. You, as expected, block the transactions if you can.
21:58 < gmaxwell> They get ripped off via a double spend as a result.
21:59 < warren> gavinandresen: sent
21:59 < gmaxwell> Now they sue you claiming that you're culpable for the theft. You defend saying that it would be unconscionable to demand that you knowingly aid their enterprise.
22:00 < Luke-Jr> hmm, in that case I'd have to figure out a way to blacklist the coin ;)
22:01 < gmaxwell> I didn't mean it seriously in any case, its a thought expirement about miner culpability. (and what a perrilous route it is)
22:02 < gavinandresen> petertodd: zero-confirmation transactions can be made  "safe-enough" for in-person low-value transactions where there is some trust that the person standing in front of you isn't colluding with a miner to double-spend.
22:03 < gavinandresen> trust/safety are not booleans
22:04 < warren> does the android wallet tell you about double spends?
22:05 < gmaxwell> petertodd: does android wallet still hide (some?) confirmed nlocktime payments?
22:05 < Luke-Jr> it doesn't even get normal spends right, so I doubt it
22:06 < Luke-Jr> btw, anyone here know an accountant into bitcoin?
22:06 < gmaxwell> TD[away]: Were you ever able to get android wallet to compile?
22:11 < BlueMatt> gmaxwell: huh? the android wallet is easy to compile
22:11 < BlueMatt> or are you talking about a branch?
22:14 < gmaxwell> derp right it was multibit that had the issue, now AW.
22:16 < warren> nOgAnOo: You are not being helpful here.
22:37 < jrmithdobbs> Is there a testnet chain big enough for io subsystem fuzzing?
22:38 < jrmithdobbs> I want 100k or so blocks I can throw at n bitcoind instances in parallel for parsing/indexing
22:39 < warren> testnet3 has over 100k blocks
22:39 < warren> not very big though
22:40 < jrmithdobbs> Guess I can jus use the real chain.
22:41 < jrmithdobbs> Actually. Tesnet3 may be ideal
22:41 < jrmithdobbs> Less CPU choking on smaller blocks and more io thrashing
22:43 < jrmithdobbs> Someone have it in a < .8 && <= bdb 4.8 format somewhere?
22:45 < Luke-Jr> uh?
22:45 < Luke-Jr> blockchains don't use db formats
22:47 < jrmithdobbs> The Indra
22:47 < jrmithdobbs> Index
22:48 < jrmithdobbs> Guess could just reindex it, forget how non-intensive test net processing is. ;p
--- Log closed Thu Nov 21 00:00:50 2013