--- Log opened Sun Oct 20 00:00:13 2013
--- Day changed Sun Oct 20 2013
00:00 < petertodd> and people don't get accused of being satoshi by large companies for doing them :P
00:00 < gmaxwell> what company accused which of us of being satoshi? :P
00:02 < petertodd> when coinbase kept on getting forked by those weird transaction a: they assumed I did it specificly to kill them and b: at one point one of them even said something that was basically along the lines of "only satoshi could have known enough to make the tx"
00:02 < petertodd> kinda funny really
00:03 < gmaxwell> petertodd: was it you that killed btcgo?
00:03 < petertodd> btcgo?
00:04 < petertodd> what's btcgo?
00:04 < gmaxwell> the conformal software btcd stuff.
00:04 < petertodd> huh, not familiar with it, I assume it's written in go right?
00:04 < gmaxwell> Killed on testnet by invalid script stuff inside an unexecuted OP_IF branch.
00:04 < petertodd> when was this?
00:04 < gmaxwell> couple weeks ago.
00:05 < petertodd> nah, I've been busy
00:05 < gmaxwell> they announced that it was "done" and within a day or two it was forked on testnet.
00:05 < petertodd> ha
00:05 < gmaxwell> I think they think I did it, as they seemed a bit irritated at me about it.
00:05 < petertodd> I did add a test case for something similar to that though in the unittests
00:05 < petertodd> and there were already unittests for specific versions of that anyway
00:06 < petertodd> ...why do I get the feeling that my branch of python-bitcoinlib probably is more conformal than btcgo...
00:07 < gmaxwell> They're putting in more effort than most alt implementors.
00:07 < gmaxwell> esp after getting bludgeoned once or twice. e.g. they pass the block pulltester.
00:07 < petertodd> I'm pretty sure the unittests would have caught that one.
00:08 < gmaxwell> They complained the unittests didn't have that case.
00:08 < gmaxwell> I asked them to open an issue, lets see if they did.
00:08 < petertodd> "0", "IF RESERVED RESERVED1 RESERVED2 ELSE 1 ENDIF", "RESERVED ok in un-executed IF"
00:08 < petertodd> for instance
00:09 < petertodd> oh, was this a un-named opcode?
00:09 < petertodd> maybe that's what they tripped up on
00:09 < gmaxwell> unfortunately they didn't take the approach I suggested with pulltester: complete your implementation, when you are really convinced that its correct only then run pulltester.
00:09 < petertodd> no, that can't be it: "0", "IF 0xba ELSE 1 ENDIF", "opcodes above NOP10 invalid if executed"
00:09 < petertodd> er, I mean: ["0", "IF 0xba ELSE 1 ENDIF", "opcodes above NOP10 invalid if executed"],
00:10 < gmaxwell> if your ass is handed to you, don't just fix one thing at a time, go back and carefully check whole areas.
00:10 < petertodd> I added tests for every single invalid opcode months ago back when I got provably unspendable standardized
00:10 < petertodd> yeah, good way to do it
00:10 < petertodd> but not what businesses want to hear...
00:10 < gmaxwell> petertodd: seems they didn't open an issue. maybe they went and found out that they'd since been added.
00:11 < gmaxwell> well, I'm unsure of what their business is.
00:11 < gmaxwell> My best guess is that they're being paid by some wealthy bitcoin entity as a hedge against ecosystem monoculture.
00:11 < gmaxwell> (but thats 90% speculation and 10% a result of discussion with them)
00:11 < maaku> gmaxwell: i talked to them for 45min over lunch at the conference, and walked away still not knowing what their business is
00:12 < petertodd> hmm... last change to the script unittests was when I documented some OP_RESERVED weirdness, aug 25th
00:12 < gmaxwell> maaku: okay you had an similar expirence to me then, I basically got the impression that I was being lied to because they didn't want to disclose it.
00:12 < maaku> but that's a better theory than anything i came up with
00:12 < gmaxwell> and from that I was speculating beyond there.
00:12 < petertodd> gmaxwell: ha, a hedge against monoculture by making something vulnerable, lovely
00:12 < phantomcircuit> gmaxwell, my guess is they're being paid by a wealthy bitcoin person who is a fool
00:12 < petertodd> gmaxwell: sounds like they're as misguided as amir is
00:13 < petertodd> gmaxwell: and gavin last I heard from him
00:13 < gmaxwell> petertodd: well, as I said, I think they're doing more effort to be compatible than most alt implementations.
00:13 < gmaxwell> not enough,  obviously. And they've replaced real compatiblity with slavish duplication of bitcoind. (well, could be worse)
00:14 < petertodd> this type of stuff is why fraud proofs are going to be great fun :(
00:14 < gmaxwell> but I'm not quite able to tell how much they understand, they're too quick to agree with me.
00:15 < petertodd> tell them some pure BS and see if they challenge you on it :P
00:15 < Luke-Jr> who is "they"? O.o
00:15 < gmaxwell> well, I don't really gain anything from knowing that they're dangerous. Since they're dangerous anyways just becuase all alt implementations have some danger.
00:15 < gmaxwell> Luke-Jr: conformal
00:16 < gmaxwell> latest fun with them is that their pure go crypto is excruciatingly slow, even compared to openssl.  "Don't worry, checkpoints!"
00:16 < petertodd> we need a market so we can short alt-implementations, maybe do a prediction market on it
00:16 < petertodd> god help us...
00:16 < gmaxwell> they're also doing some really insane stuff to work around their decision to use sqllite.
00:16 < petertodd> ha
00:17 < gmaxwell> E.g. they constantly rewrite indexes because inserts with the index are too slow.
00:17 < petertodd> sheesh
00:17 < gmaxwell> So they batch up a bunch of changes then drop the index and add them then recreate the index.
00:18 < Luke-Jr> lol
00:18 < petertodd> if the large-block crowd get their way it'll be fun watching implementations explode due to performance fuckups
00:18 < gmaxwell> I wouldn't be surprised if this implementation couldn't keep up with 1mb blocksize, in fact.
00:18 < phantomcircuit> gmaxwell, that's actually a very common thing to do with sqlite
00:18 < gmaxwell> It's slow enough that this is a concern.
00:18 < gmaxwell> phantomcircuit: I know but that doesn't make it a good idea!
00:19 < gmaxwell> right now it works because the utxo set only has a few million entries.
00:19 < phantomcircuit> sqlite indexes dont include the WAL portion until it's flushed
00:19 < maaku> sqlite? seriously? *shudder*
00:19 < phantomcircuit> yeah sqlite is not designed to be fast
00:19 < phantomcircuit> their stated goal is to replace flat files
00:19 < gmaxwell> one of their blog posts goes on extolling its virtues.
00:19 < phantomcircuit> for like config files
00:20 < Luke-Jr> ew
00:20 < Luke-Jr> who'd want a binary format for configs?
00:20 < Luke-Jr> even XML is better
00:20 < maaku> ugh
00:20 < phantomcircuit> Luke-Jr, well compared to the binary files that lots of stuff uses it's an upgrade
00:20 < gmaxwell> in any case, we need to get off our asses and fix a lot of stupid sharp corners with the reference software if we don't want things like this to be a problem for the ecosystem. ("oh no, you can't implement new feature X because implementation Y is slow as shit!")
00:20 < phantomcircuit> like firefox used to use a custom binary format for everything
00:20 < gmaxwell> (or worse, "because we depend on implementation Y and no one is maintaining it now.")
00:20 < phantomcircuit> which they replaced with sqlite3 files
00:21 < petertodd> gmaxwell: well IMO the right thing to do is just run your services behind trusted ref implementation nodes
00:21 < petertodd> gmaxwell: trust the ref implementation and do no verification at all
00:21 < phantomcircuit> gmaxwell, it would be very helpful for alt implementations if the rules were split up into network/soft/antiddos
00:22 < gmaxwell> so crap like bitcoind + wallet seperation, spv bootstrap, initial sync time, watching wallets, coin control, etc. all need to get fixed, because they're all really easy to fix in a crappy greenfield implementation.
00:22 < gmaxwell> we're fortunate that btcd copied as many of bitcoind's design flaws as it did. :P
00:23 < gmaxwell> (I mean, lucky in that if they'd made it moderately better in user facing ways but did so without commitment to network consistency, or performance, it might be bad for the network)
00:23 < maaku> sqlite actually would be better than bdb for the wallet...
00:23 < petertodd> gmaxwell: ok, so add SPV and partial UTXO modes to bitcoind, and leave it at that
00:23 < gmaxwell> maaku: yea, probably. BDB, for all its warts, actually got a lot of things right though.
00:23 < jgarzik> maaku, I'm suspicious of that claim
00:23 < petertodd> gmaxwell: make sure it continues to be useful for miners
00:23 < jgarzik> maaku, sqlite is SQL on top of a lower level BDB-like system
00:24 < jgarzik> what do you think sqlite indexes are?
00:24 < maaku> jgarzik: i mean better than locking wallets to a specific (outdated and large) bdb version
00:24 < jgarzik> Using SQL would move some intelligence out of the client and into the database layer
00:24 < maaku> and better debugging support
00:25 < phantomcircuit> sqlite3 isn't safe really
00:25 < maaku> (sqlite executable would replace pywallet)
00:25 < jgarzik> maaku, by locking to sqlite3 instead?
00:25 < jgarzik> six of one, half-dozen of the other
00:25 < phantomcircuit> maaku, i've had sqlite corrupt databases entirely on more than one occasion without any obvious reason
00:27 < petertodd> IMO the wallet should be designed such that the core of it can be a strictly append-only file
00:27 < jgarzik> petertodd, yes, that has been said many times on #bitcoin-dev
00:28 < petertodd> sure, have indexes for speed, but there should be some part of it that can literally be set to append-only in the fielsystem flags
00:28 < jgarzik> petertodd, even a rough sketch of append-only by sipa and myself was discussed
00:28 < petertodd> jgarzik: I know, that's why I'm bringing it up :P
00:29 < jgarzik> one problem is appending in block-aligned sizes
00:29 < petertodd> jgarzik: you mean re: partial writes at the device level?
00:30 < maaku> jgarzik: why does that matter, assuming you are checksumming appends?
00:34 < gmaxwell> because losing the last N appends kinda stinks. .. though with misdirected writes and eraseblock relocation screwups becoming common now with ssds... I dunno how important HDD durability models matter anymore.
00:35  * maaku smells a grad student project for someone with academic connections
00:35 < petertodd> maaku: you mean someone with industry connections to figure out what the !@#$ hardware is doing? :P
00:37 < maaku> heh
00:37 < maaku> i'm not sure industry would really know better
00:37 < maaku> not institutionally at least
00:37 < gmaxwell> my thought was if we're going to a determinstic wallet thing, we should just splat out 64 bits of the master public key with every @#$@# write to the file... so recovering any few kilobytes of it is enough to at least recover your @#$#@$ private keys.
00:38 < maaku> you'd have to find the engineer that actually debugs these bizaare failure modes
00:38 < gmaxwell> er s/master public/master private/
00:38 < gmaxwell> you assume they debug them. I assume they just replace the product. Time to market!
00:38 < maaku> gmaxwell: some customers get the special treatment
00:39 < petertodd> maaku: the nice thing is there are very few suppliers out there who actually do this stuff, so you'd only need a dozen contacts to cover it all
00:39 < maaku> i know someone who does basically the same thing for HP, debugging weird NonStop errors for clients like air traffic control and NASDAQ
00:40 < petertodd> maaku: half a dozen is probably good enough for 90% of the storage devices out there
00:40 < maaku> but most of the problems he solves are introduced by HP because HP engineers have no idea how the hardware failure modes really work...
00:40 < jgarzik> gmaxwell, maaku: it matters for both hardware and kernel reasons.  Kernel really really likes page-based I/O, and you wind up with atomicity of pages at multiple levels.  Applications crossing page boundaries or updating a single page multiple times can cause corruption.  Also, for hardware, you want sector-aligned -- usually page-aligned gets you that for free.  As gmaxwell points out, this matters less on SSD, but in some ways it is stil
00:40 < jgarzik> l very relevant to corruption prevention, just in different ways.
00:40 < maaku> left hand, meet right hand
00:40 < petertodd> well HP is a hollow shell of it's former self
00:41 < jgarzik> filesystems and block all go through page cache, even if write-through
00:41 < jgarzik> if you have PCI-express (PCIe) super-fast storage, even kernel page locking can become a relevant factor.
00:41 < petertodd> jgarzik: sucks that pages are so big, though for the average person 4KiB/transaction is not going to hurt you
00:42 < jgarzik> petertodd, indeed.  That is one the annoying bits, for us.  Our commits are likely well under 4k
00:42 < jgarzik> much less 8k
00:42 < petertodd> jgarzik: 64KiB is enough for anything right? :P
00:42 < jgarzik> ;p
00:43 < maaku> if you want to get clever, you can fill the extra space with error correction of previous writes
00:44 < petertodd> maaku: if you want to get overly clever, you would run a testnet node in parallel and also write your wallet data to the testnet blockchain
00:44 < petertodd> maaku: or maybe just a scamcoin that you don't like
00:44 < jgarzik> gmaxwell, upload the master public key to bitcoinkeyserver.net ;p
00:45 < jgarzik> gmaxwell, create a really slow, clunky mirror at bp.mit.edu
00:45 < gmaxwell> I do think supporting some kind of integrated backup system would be nice.
00:45 < gmaxwell> "we store our wallet backups encoded as fake public keys in the pgp key servers"
00:45 < jgarzik> "the cloud"
00:45 < petertodd> "the caves"
00:46 < petertodd> "the salt mines"
00:46 < maaku> jgarzik: gmaxwell: you do that, and people will start "logging into their account" on a friend's client
00:46 < petertodd> maaku: ooh, sounds useful! very 2.0!
00:46 < jgarzik> gmaxwell, heh, well, petertodd and I were discussing how SIN (an ECDSA key, after all) might look inside OpenPGP packetizing
00:46 < petertodd> maaku: can I login with my facebook account?
00:46 < jgarzik> gmaxwell, might be fun...
00:47 < gmaxwell> jgarzik: openpgp land is a little brain damaged, they'd likely just have some silly robot that sees your sin and signs for you. (see cacert's signer for an example) :(
00:47 < petertodd> gmaxwell: what's cacerts signer do exactly? sign for email identity?
00:48 < petertodd> gmaxwell: PGP runs a bot that does that
00:48 < jgarzik> gmaxwell, openpgp source code and packetization both leave a both to be desired.  but ah well, it's The Standard.
00:48 < gmaxwell> petertodd: if you have two cacert certifications of your identity their robot will sign a pgp key for you, so long as the name matches exactly.
00:49 < jgarzik> everybody forks the same 1960s era codebase.
00:49 < jgarzik> I'm pretty sure OpenPGP was originally fortran, auto-translated to C
00:49 < gmaxwell> jgarzik: yea, and it covers a LOT of usecases. sometimes I get irritated and want to rewrite it, and then I remember it does a ton of stuff I don't even completely understand.
00:49 < petertodd> gmaxwell: oh, that's not so bad, though it'd be better done with a cert sig notation
00:49 < gmaxwell> "You can write fortran in any language"
00:50 < gmaxwell> petertodd: yea, it's just a sig0 user signature from some random key.
00:50 < petertodd> jgarzik: you mean the gnupg codebase?
00:50 < gmaxwell> buggers up the WOT because most things don't know to ignore it.
00:50 < petertodd> jgarzik: there's no OpenPGP codebase
00:50 < petertodd> gmaxwell: huh? all WoT tools require you to explicitly state your trust at every step, at least what I've used
00:52 < gmaxwell> petertodd: e.g. pathfinder tools will follow hops through that stupid key.
00:52 < gmaxwell> or at least some of them will.
00:54 < petertodd> gmaxwell: right, but pathfinder tools don't do what you really want anyway, because they don't let you specify anyones keys as trusted or untrusted
00:54 < gmaxwell> I know.
00:54 < petertodd> gmaxwell: equaly, they give you all the distict paths, so just pick one that doesn't use that key
00:54 < gmaxwell> I also recently realized that my own trust database is all 2#$@#@#$@ up, as well as my signature levels are all wrong.
00:55 < petertodd> Main thing is we need off-line versions of those things that use your trust settings.
00:55 < petertodd> how so?
00:55 < gmaxwell> at some point a gpg update switched me to the mode where it doesn't ask what level of verification you did, and just issues all sigs as sig0.
00:55 < petertodd> oh, you were local-signing keys?
00:56 < petertodd> likely gnupg changed because they wanted to simplify things, although IMO that's just a failing of non-existant tools to actually use the WoT
00:56 < gmaxwell> and most of my sigs are actually sig2/sig3.
00:56 < gmaxwell> and you can't change them without redoing the sigs. So now I'm probably not going to fix it until I scrap my old 1024 bit key.
00:57 < petertodd> right, because of how gnupg doesn't let you resign a key, although you can revoke the signature, minimize/clean the key to get rid of the revoked sigs, and resign, it's just not obvious
00:57 < petertodd> *obvious how
00:57 < gmaxwell> I know, but a PITA. and it will gunk up the keyservers with more signatures.
00:58 < gmaxwell> also, why the @#$@ must all your keysigning be with your master identity key?
00:58 < petertodd> the OpenPGP standard has trust signatures which let you specify a secondary key to do signing on your behalf
00:59 < gmaxwell> petertodd: yea but it looked like it would be treated as a differnet key id.  E.g. I want a key which is signed by everyone, which delegates to a key signed only by it, which goes and signs everyone.
00:59 < gmaxwell> and everyone sees that as just the same as the master key signing everyone, unless I revoke the delegated key.
01:00 < petertodd> gmaxwell: I'd have to double-check, but I'm pretty sure that subkeys can have the cert bit set
01:00 < gmaxwell> gpg ui wouldn't let me do that at least. hm. that would be nice.
01:01 < petertodd> yeah, myself I just have hardware PGP keys, and keep my master key on one that I leave offline
01:01 < petertodd> my day-to-day subkey is in the second smartcard
01:01 < gmaxwell> you still need to interact with it to sign people. which is what I'd like to avoid.
01:02 < petertodd> well, done on a secure computer, esp if air-gapped, that's still pretty damn good
01:02 < gmaxwell> yea, but I update my master key once every couple years. I sign more often than that, so it should be seperate.
01:03 < petertodd> indeed, but as I say, I do think the standard supports what you want to do
01:03 < gmaxwell> cool. I'll have to give it a shot again, I only looked briefly.
01:04 < petertodd> anyway, without timestamping a lot of this stuff isn't as useful because sigs aren't trustworthy once keys are compromised
01:05 < phantomcircuit> jgarzik, in general relying on sector size writes being atomic doesn't seem like a great solution
01:05 < petertodd> IMO the more important thing for OpenPGP is to be able to know exactly when signatures were created, and be able to issue revokations as applying to after certain times
01:05 < gmaxwell> petertodd: have you thought about defining a signature packet that says "this key is timestamped" with blockheader stuff?
01:05 < petertodd> gmaxwell: yes, in fact last night I changed my GPG setup to use blockheader hashes as random beacons - only half the problem, but interesting how simple it was (uses signature notation data)
01:06 < petertodd> gmaxwell: I've looked at it carefully, and I think defining timestamping as a new signature algorithm is the right approach
01:06 < petertodd> OpenPGP already has a "this sig is a timestamp" bit
01:11 < gmaxwell> petertodd: though validating a bitcoin timestamp is not quite stateless... since you need to know some of the network.
01:12 < petertodd> gmaxwell: yeah, that'll be a first for OpenPGP
01:12 < gmaxwell> though I guess you can have a minimum difficulty... which is now almost 60 bits.
01:12 < gmaxwell> log2(267731249.48242110)+32 = 59.996
01:14 < petertodd> for validation of old sigs it's interesting how you could just ship a "official" set of block headers
01:14 < gmaxwell> well, it could be a --recv kind of thing to get the headers.
01:14 < gmaxwell> and show it as an untrusted signature if you don't have the headers or something.
01:16 < petertodd> yeah, though that's actually ignoring the bigger issue, which is that for user acceptance you have to have a way of timestamping that happens instantly or near instantly
01:17 < gmaxwell> not for key identification you don't.
01:18 < petertodd> gmaxwell: even for that people won't be happy - you need a scheme where you can upgrade the timestamp as more data is known
01:19 < petertodd> gmaxwell: one interesting idea is to put support for it into keyservers
01:20 < gmaxwell> I'd think the thing to do would be just for one of us to run it for the whole world.
01:20 < gmaxwell> just being able to get evidence that a key is as old as it claims to be is very useful once old is somewhat-old.
01:20 < gmaxwell> you might even intentionally delay publishing new timestamps since they're not useful when they've very new.
01:21 < petertodd> well, speaking of, a 1 second MMR timestamp chain is very useful there, so that timestamps *can* be made immediately
01:21 < petertodd> the problem is you want that chain to be a: reliable, and b: spam resistant, and c: still useful even if some big attacker wants to shut it down
01:30 < jgarzik> phantomcircuit, in general, relying on any generalization is unwise ;p
01:30 < phantomcircuit> jgarzik, heh
01:30 < jgarzik> phantomcircuit, the bottom line is always "know your hardware", but sadly many users fail that ;p
01:30 < phantomcircuit> jgarzik, fucking hdds do tons of random stupid shit
01:30 < jgarzik> know your hardware, and tune your software to match, I mean.
01:30 < phantomcircuit> hurr durr flying writes
01:31 < jgarzik> phantomcircuit, I think it's more the software on top in this era
01:31 < phantomcircuit> jgarzik, with ssds it's the firmware
01:31 < jgarzik> phantomcircuit, the latter comment, when investigated at Red Hat, turned up stupid app behavior 90% of the time
01:31 < phantomcircuit> it's not uncommon at all for an ssd to completely fuck up where things are written
01:32 < jgarzik> I was L3 on that for years
01:32 < phantomcircuit> yeah that's not surprising
01:32 < petertodd> The great thing about embedded systems development is "know your hardware" can mean reading the datasheet for your 8-bit uC's and getting a timing diagram showing under exactly what conditions EEPROM cells get corrupted. :P
01:33 < petertodd> Heck, on the wall by my desk I have one of my artworks that does exactly that with a carefully calculated set of VCC hold-up caps.
01:50 < jgarzik> petertodd, "the pool uses compressed keys, while the blockchain.info client only uses compressed keys"
01:50 < jgarzik> petertodd, should one of those be "uncompressed"?  or am I just confused?
01:50 < petertodd> doh!
01:50 < gmaxwell> the latter is uncompressed
01:50 < petertodd> yeah, client is uncompressed
01:51 < phantomcircuit> jgarzik, i get a good laugh out of bc.i
01:51 < phantomcircuit> they operate a service which allows you to purchase bitcoins and then obscure their origin
01:51 < phantomcircuit> quite literally money laundering
01:51 < phantomcircuit> herp derp
01:52 < petertodd> money laundering isn't what you think it is...
01:52 < gmaxwell> jgarzik: so the difficulty in getting people to use petertodd's dust-b-gone is starting to make me doubt my prior thought that "wallet applets" could be a viable way to introduce new wallet features.
01:52 < petertodd> the purpose of money laundering is to make money have a *legit* origin, bc.i is just making it have no origin at all
01:52 < phantomcircuit> petertodd, useful money laundering is the first
01:52 < phantomcircuit> legal money laundering is either
01:52 < gmaxwell> petertodd++  but that doesn't mean bc.i might not get into a regulatory mess.
01:53 < phantomcircuit> you'd be an idiot to launder money through bitcoin anything
01:53 < phantomcircuit> but that doesn't mean doing so isn't illegal
01:53 < petertodd> well if we keep repeating my point over and over we might change the discussion... :)
01:53 < gmaxwell> in any case, they've been warned! (and at least renamed their "mixer")
01:54 < phantomcircuit> they've had legal council refuse to represent them because their business is obviously in violation of uk law
01:54 < gmaxwell> we need someone to make a catchy music video like https://www.youtube.com/watch?v=7E0ot9iJm_k (terrible secret of space)  which just repeats over and over again "the purpose of money laundering is to make money have a *legit* origin"
01:54 < Luke-Jr> is that the legal definition?
01:55 < phantomcircuit> Luke-Jr, the legal definition is to obscure the origin
01:55 < jgarzik> gmaxwell, not sure I was party to a "wallet applet" discussion.   I did notice that some wallets like Hive are direct-integrating with gambling and exchange sites via plugins.
01:55 < phantomcircuit> however that's not very useful for actual criminals
01:55 < gmaxwell> in the US there isn't just one legal definition there are dozens (hundreds? easily if you count state laws) of laws that possibly interact with money laundering.
01:55 < phantomcircuit> none the less the definition is what it is
01:55 < jgarzik> gmaxwell, RE dust, I just think there should be background defragmentation
01:55 < phantomcircuit> gmaxwell, bc.i is a uk company
01:55 < jgarzik> gmaxwell, perhaps via coinjoin.  mix + dedust
01:56 < petertodd> gmaxwell: yeah, that's the real issue - better for something like bc.i to not be operating at all if they want to be safe, chances are even operating a wallet is legally risky
01:56 < gmaxwell> jgarzik: ah, I'd thought you'd were at least in the past I'd bought into an idea that things like background defragmentation and such could potentially be introduced with contrib/ grade side-car applications.  As a way of reducing the time to getting features in the core codebase.
01:56 < gmaxwell> jgarzik: yea, petertodd's dust-b-gone is a coinjoin dust discarder.
01:57 < gmaxwell> Luke-Jr: I'd guess that if you are pedantic about the law that in some states its probabably unlawful to accept money.. ever. just due to poorly constructed laws that interact in unexpected ways.
01:57 < phantomcircuit> petertodd, its better that they do one thing at a time
01:58 < jgarzik> gmaxwell, some pedantic interpretations of US law imply you should file forms for every cash transaction, anywhere, regardless of whether you are consumer or merchant or peer
01:58 < jgarzik> especially if you cross state or international borders
01:58 < Luke-Jr> gmaxwell: IMO trying to change the definition to workaround laws isn't a viable option
01:58 < jgarzik> nutters
01:59 < gmaxwell> Luke-Jr: I'm not suggesting it to workaround the law.
01:59 < Luke-Jr> the elegance of CoinJoin is that it isn't concealing anything; it's just discarding unnecessary information
01:59 < petertodd> jgarzik: which reminds me of idiotic people are for continuely pointing out cash as why bitcoin won't be banned; lots of jurisdictions are doing everything they can to ban cash
01:59 < gmaxwell> Luke-Jr: the reason I suggest making the definition more clear is just because the broken one used in bitcoin land (mostly inspired by half understanding tv crime drama) just doesn't make sense.
01:59 < Luke-Jr> gmaxwell: a music video to promote a definition that differs from the legal definition, would be just that IMO
01:59 < jgarzik> My on-going prediction, since 2010, has been that bitcoin will be regulated as cash is currently regulated.
01:59 < jgarzik> in US and elsewhere
02:00 < jgarzik> with all that implies
02:00 < gmaxwell> Luke-Jr: I don't think that what I'm saying is distinct from the legal definition. (I also didn't mean it seriously)
02:00 < petertodd> jgarzik: right, so it'll be illegal to have bitcoin wallets with large amounts of bitcoins in them, and gradually those amounts will decrease to the point where bitcoin is effectively banned
02:00 < Luke-Jr> petertodd: huh?
02:01 < Luke-Jr> is there some law saying I can't bury large amounts of cash in my backyard? :/
02:01 < jgarzik> petertodd, I'm waiting for the first attempted prosecution when someone flies across a US/international border without declaring the > $10,000 in bitcoins they were carrying.
02:01 < petertodd> jgarzik: meanwhile bitcoins, when discovered, will be seized routinely the same way large amounts of cash are under civil forfeitture laws
02:01 < gmaxwell> Luke-Jr: the legal definition is very complicated. the idea that anything that conceals the origin is money laundering is a toy version of the law. The idea that money laundering == giving an apparent legitimate origin to money is another toy statement of the law. The latter has the benefit of actually explaining _why_ people launder money at least...
02:01 < petertodd> Luke-Jr: in some european countries yes
02:01 < gmaxwell> Because just doing the first, in the US at least, actually does you very little good.
02:01 < petertodd> Luke-Jr: for instance IIRC italy has banned all cash transactions for any reason over 1000 euros
02:01 < phantomcircuit> gmaxwell, the problem is that the definition you use is based largely on how strict law enforcement wants to be
02:01 < petertodd> jgarzik: bingo
02:02 < gmaxwell> jgarzik: so I might attempt a declaration of bitcoins when returning from vancuver at the beginning of november. I don't have anything scheduled for the week after that... it would be interesting to see what happens.
02:03 < Luke-Jr> petertodd: that's a cash *transaction*
02:03 < jgarzik> in terms of US "climate", it is noteworthy that government types are also concerned about consumer privacy.
02:03 < jgarzik> A handful of Large Businesses (Fortune 1000) have also expressed concern about business transaction privacy.
02:03 < petertodd> gmaxwell: lol, I like how you're giving a week for that...
02:03 < jgarzik> it is easy to look over a shoulder at starbucks, if you can spot a payment address, and chain-stalk that person
02:03 < petertodd> Luke-Jr: yes, and meanwhile large amounts of cash get routinely seized in the US on suspicion of being involved with drugs, and it's damn near impossible to get it back.
02:03 < gmaxwell> in particular I could arrange it so that bitcoins  I have with me are likely to increase in value while I'm at IETF and cross the threshold.
02:04 < petertodd> Luke-Jr: other countries have direct capital controls on cash
02:04 < gmaxwell> jgarzik: or the minimum wage drone at starbucks hired a week ago is doing the chainstalking.
02:04 < Luke-Jr> gmaxwell: how are the bitcoins "with you"? :p
02:04 < petertodd> jgarzik: one of the ironies is that Bitcoin could be simultaneously considered as being too private, and prone to "money laundering", and too public, and thus banned for privacy reasons
02:04 < gmaxwell> Luke-Jr: that would be part of what the excercise is for exploring. What does customs think that definition is?
02:05 < jgarzik> One argument I do think could be made:  the coins are "in the cloud".  Control of the coins (keys) are what the owner holds.  Not sure if that could be legally useful, but it seems like it might be.
02:05 < jgarzik> petertodd, indeed
02:06 < phantomcircuit> <gmaxwell> in particular I could arrange it so that bitcoins  I have with me are likely to increase in value while I'm at IETF and cross the threshold.
02:06 < jgarzik> petertodd, depends on which prosecutor is writing their next Shakespearean piece
02:06 < phantomcircuit> gmaxwell, the us border patrol will arrest you if you fail to declare the changed amount
02:06 < petertodd> jgarzik: that was brought up before actually with stored value cards, and IIRC whether or not the transaction "actually" happened on some server somewhere wasn't considered to be as important as simple pragmatic problems of verifying them at borders
02:06 < phantomcircuit> they have done it before for someone entering with CAD
02:07 < gmaxwell> obviously I wouldn't bring a bunch of coin unless I was planning on playing the declariation game.
02:07 < petertodd> phantomcircuit: well, keep in mind that having amounts just over the limit violates laws in other ways
02:07 < gmaxwell> oh well, thats perhaps a problem then. I guess I need to consult an attorney first. bleh.
02:08 < phantomcircuit> petertodd, if you have funds which are your own and you declare it then it's entirely on the discretion of the border patrol agent
02:08 < petertodd> phantomcircuit: there's a great example of a small grocery store in a poor area that had their bank accounts seized because they were making frequent deposits just under $10k, which was considered to be illegal structuring, but their insurance company mandates that no more than $10k of cash be held...
02:08 < phantomcircuit> although given that if they confiscate it that indirectly goes towards paying their salary
02:08 < phantomcircuit> im not thinking you have good odds
02:09 < petertodd> phantomcircuit: yeah, proceeds from civil forfeitture should always be destroyed and returned to society in the form of deflation to keep the incentives right
02:10 < gmaxwell> or at least sent to a maximally far away place. E.g. added to social security of the nation's general fund.
02:11 < gmaxwell> (arguably the US would be silly to return it as deflation: people all over the world use USD, keeping the benefit of our forfeitures nationally local isn't too much to ask)
02:11 < petertodd> gmaxwell: ok, use it to fund legal aid :P
02:11 < gmaxwell> ohh hey, thats a neat idea.
02:11 < gmaxwell> give it to the public defenders.
02:12 < petertodd> yup
02:13 < petertodd> kinda the same thinking as to why I think if your ever charged with something, and the prosecution can't get a conviction, even on only some of the charges, you should always get compensation - use it to pay for legal aid
02:14 < petertodd> what's really nice about that is it helps avoid the prosecution piling up charges as a threat
02:14 < petertodd> problem is courts are relatively corrupt because judges, prosecution, and law enforcement all know each other - just human nature
02:15 < gmaxwell> well also corrupt because most people who are charged are actually guily... encourages a kind if laxity.
02:15 < petertodd> yup
02:16 < petertodd> places like japan with 99.7% conviction rates are scary...
02:16 < jgarzik> scary... but it's a headline, too
02:16 < petertodd> it also encourages other abuses "so what if we beat the suspect a bit? he's guilty anyway"
02:16 < jgarzik> some cases just aren't brought unless they are highly likely to be won
02:16 < jgarzik> well s/some//
02:17 < petertodd> jgarzik: yes, but that doesn't change the dynamics of the system re: laxity
02:17 < petertodd> and for that matter public opinion
02:17 < jgarzik> I'd be willing to bet the general public knows that some innocents go to jail
02:19 < petertodd> meh, general public don't give me much faith re: skepticism
02:21 < petertodd> I mean, heck, in highschool one friend of mine accused the other of raping her... and reality is I'll never know what happened. But so many people who I say this too just don't understand how it's possible to not be sure. ("But your supporting rape culture!" "The bitch was lying of course!")
02:22  * jgarzik kicks xchat
02:37  * jgarzik looks at the clock, and decides it is far too late.  *sniff*   Ah, yearn for the days when I would code until 5-6am, and get up at noon.
08:20 < adam3us> musing about double spend protection - to what extent other models are possible vs some unavoidable / most efficient pattern t the existing logic
08:21 < adam3us> so eg double spends are not broadcast, so 0-confs are not secure until wait for the conf
08:21 < adam3us> an alternative discussed by a few people , double spends are broadcast (even broadcast at high priority), then you get a negative notification so if you wait a while
08:22 < adam3us> eg 20 sec maybe you get some indication
08:22 < adam3us> i was wondering if the reason it is how it is because its sort of attractive to have a positive indicator, even though it can be retracted later (a different spend ends up in the confirmation)
08:23 < adam3us> vs a negative indicator (waiting for absence of conflicting spends)
08:23 < adam3us> though i think the net result is the same
15:48 < HM2> I wonder if a taxi driver will give me a discount for paying in bitcoin
15:48 < HM2> costs almost as much for a taxi at an unreasonable hour to my local airport as it does for an extra night in a hotel to avoid it
16:07 < jgarzik> heh
18:54 < Luke-Jr> petertodd: markdown sucks, as does having to use pull requests for every minor BIP change :P
18:55 < Luke-Jr> BIPs actually began as a git repo, but that died quickly.. :p
18:58 < sipa> yeah, the wiki used to be just a dump of the repository
18:59 < sipa> but it didn't take long before people just used the wiki pages without pullreqing the changes
19:02 < petertodd> sounds to me like a lack of proper change tracking!
19:02 < petertodd> sheesh
19:02 < sipa> it's just too inconvenient
19:02 < petertodd> could always use git-submodules, lol
19:03 < petertodd> sipa: that's what my co-workers say about revision control... :/
19:03 < petertodd> oh well, the people have spoken :(
19:03 < sipa> welk the repository still exists
19:03 < petertodd> oh yeah?
19:03 < gmaxwell> It would probably be okay for 'finished' BIPs.
19:03 < sipa> we could bring it up ti date
19:04 < sipa> genjix/bips iirc
19:04 < petertodd> gmaxwell: that's my point really: BIPs should become finished at some point with further changes tracked - we don't want there to be any incentive or ability to sneak in changes, especially if they may have security issues
19:17 < sipa> agree there
19:19 < petertodd> well, maybe I'll take my bloom bip and do up a bip repo with subtrees or somesuch for sake of argument
19:19 < petertodd> work through how it could be done in a more user-friendly way
19:21 < petertodd> probably something where only a disaster will change people's minds - at work every time they try to build a backup of a piece of equipment it seems opinions about revision control soften...
19:23 < sipa> clearly we just need a wiki whose storage backend uses git :)
19:24 < petertodd> you realize one exists right?
19:24 < sipa> i didn,t know, but my guess would have been yes :)
19:24 < petertodd> I've actually used it for an art project, and it worked really well for us
19:25 < petertodd> the artists (well author) got a nice GUI to play with, and yet we still got really solid revision logging, versioning and backups.
19:25 < petertodd> s/author/authors/
19:27 < petertodd> https://github.com/gollum/gollum
19:27 < petertodd> I think that's what we used, was a while ago
19:27 < petertodd> the actual git repo of course is totally generic and doesnt say what software was used to make it!
19:35 < sipa> petertodd: i still don't get what your concern is with the canonical pushes pullreq?
19:36 < sipa> is there a case where we create things that this pullreq would reject?
20:30  * jgarzik volunteers petertodd  for some work and runs
20:31 < jgarzik> git repo is clearly superior.  Should be easy enough to get a bot that copies to read-only wiki pages.
20:32 < jgarzik> Getting committed to the git repo should be a Big Deal, and presumes that rounds of discussion have proceeded
20:33 < jgarzik> I would probably publish a BIP queue too, for trail balloons, works in progress, kinda like IETF draft
20:33 < jgarzik> much much lower barrier to entry
20:34 < gmaxwell> Having a queue would be a great idea. I will make that happen.  (Queue can just be a wiki page, I think)
20:44 < jgarzik> gmaxwell, the points about source code control stand, IMO
20:44 < jgarzik> gmaxwell, I would prefer hash-sealed BIPs
20:45 < jgarzik> gmaxwell, it's a bit lame that we don't, being bitcoin and all
20:47 < jgarzik> A robot that pushes git repo changes to wiki should be straightforward
20:47 < gmaxwell> jgarzik: oh absolutely, I agree. I don't think that source control is worth forcing on people for BIPs which are early in life. It absolutely should be used when they're "done".
20:48 < gmaxwell> but we're not even (yet) using signing in GIT... so "being bitcoin and all" isn't itself that compelling yet. :P
20:48 < jgarzik> gmaxwell, how about "email jgarzik the latest draft, and he will stick it in the git repo for you"?
20:48 < gmaxwell> (well, okay, signed tags)
20:49 < gmaxwell> It's not me you need to satisify. I'm happy with source control.
20:49 < jgarzik> gmaxwell, as a process proposal, to make the barrier of entry low, and address the "SCM not worth forcing..." complaint.
20:50 < sipa> i git-sign all github merges i do now :)
20:51 < jgarzik> e.g. Policy proposal:  Anybody can create a BIP.  As long as it is remotely related to bitcoin and has formatting similar to other BIPs, accept into bips.git/draft.  Once general consensus is reached, promote to bips.git/.  Robot auto-copies all changes, converting markdown to wikitext if people like markdown as source.
20:52 < jgarzik> I'll volunteer at BIPS editor, but I think whole dev team should have commit access to bips.git
20:52 < jgarzik> *as
20:52 < sipa> i'm sure people will complain that the developers of just one clientr shouldn't have privileged access
20:53 < jgarzik> model loosely after IETF draft -> IETF RFC process, albeit with less time and bureaucracy ;p  Some BIPs come together in days, some in months or years.
20:53 < sipa> note that extra process does scare people away
20:54 < jgarzik> sipa, thus the proposed "just email your draft to XXX, and the rest will happen"
20:54 < jgarzik> for the git-scared
20:54 < jgarzik> Linux kernel always had a process for people who did not want to touch git at all (sometimes it was necessary for legal reasons).  You can always just email a patch against a tarball.
20:56 < gmaxwell> I do think we should have clear seperation from "crap random person produced" and something that has had some public support.
20:56 < jgarzik> commit access can be anybody trusted, even outside dev team.  mainly must fulfill rule "BIPS editor + backups in case he goes crazy or gets hit by a bus"
20:57 < gmaxwell> E.g. no BIP number for things that are just submitted.
20:57 < jgarzik> indeed
20:57 < gavinandresen> jgarzik gmaxwell sipa: I'm thinking of cleaning up pull requests by closing anything with a merge conflict more than X months old.  I'm wasting time constantly re-reading old requests....
20:57 < jgarzik> gavinandresen, my standard is "rebased has been requested, and not responded to after X months"
20:57 < jgarzik> *rebase
20:58 < jgarzik> gavinandresen, kinder gentler to request a rebase first
20:58 < gmaxwell> gavinandresen: fine with me. To avoid bruised feelings you can say that it can be reopened with a new patch if someone would like to continue it.
20:58 < gavinandresen> I'll definitely say "reopen after rebase"
20:59 < gmaxwell> gavinandresen: note that random people can't actually reopen themselves (IIRC only people with commit access can)
20:59  * gmaxwell hops onto an airplane
20:59 < gavinandresen> gmaxwell: ok, I'll definely say "open a new request after rebase"
21:00 < gavinandresen> (they can link to discussion in old request, if it is relevant)
21:00 < gavinandresen> Wading through long discussions in old pull requests is a time-sink, too
21:00  * jgarzik wonders if github supports close-with-boilerplate
21:00 < gavinandresen> What do we like for X months?  Two?
21:00 < jgarzik> 2-3
21:01 < jgarzik> *poof* hops on the baby bedtime bus.
21:01 < gavinandresen> good deal, prepare for a flurry of closes....
21:02  * sipa prepares by closing his eyes
21:02 < sipa> zZzZ
21:04 < Luke-Jr> I seem to have a PR rebase/fix period of about 3 months with my current workload :<
21:04 < Luke-Jr> too bad github doesn't make it possible for the author to reopen things
21:25 < petertodd> sipa: if we ever made a standard transaction type with scriptSig's with single byte pushes, then yes, the current ref implementation would reject it
21:26 < petertodd> sipa: point is if you do scriptSig << single-byte in the C++ code, it gets added with a PUSHDATA always
21:28 < petertodd> sipa: "< sipa> i git-sign all github merges i do now :)" <- careful, I *will* call you out on that if you ever don't :P
--- Log closed Mon Oct 21 00:00:28 2013