--- Log opened Sun Mar 31 00:00:13 2013
00:08 < realazthat> sipa: are the block indices used by the API zero-based?
00:08 < realazthat> such that getblockcount() returns top index +1
00:10 < BlueMatt> isnt this more appropriate for #bitcoin-dev or #bitcoin ?
00:10 < sipa> yeah
00:10 < realazthat> er sorry
01:39 < realazthat> sipa: nvm I think I see a size field
06:38 < realazthat> sipa: ping
06:38 < realazthat> dunno what hours you keep haha
06:39 < realazthat> its 0630 here
06:39 < sipa> don't ask
06:40 < realazthat> lol same
06:40 < realazthat> ok I think I have something to show
06:40 < realazthat> shall I just put the code on github
06:40 < realazthat> and you can check it out yourself
14:53 < jgarzik> Random bitcoin wizards question:
14:54 < jgarzik> Is there any way to have a single bitcoin address, which may receive bitcoins, that is then _guaranteed_ to be divided up and distributed to a pre-specified list of bitcoin addresses?
14:55 < jgarzik> ie. the simple example is "donate to developer group"
14:55 < jgarzik> Clearly you can pay to a single P2SH hash...
14:56 < jgarzik> But what would a redeem script look like... that _split_ the funds?
14:56 < jgarzik> "Any-of-N may redeem" is easy, because the redeemer gets 100% of the funds.
14:56 < jgarzik> But it seems outside the scope/ability of bitcoin to split to the funds
14:56 < gmaxwell> Only e.g. by having a trusted (e.g. TPM) oracle that controls the private key.  Alternatively, you could make it a multisig of those people and then they have to agree on the split.
14:57 < jgarzik> Yeah, the best solution I could think of was a bot
14:57 < gmaxwell> But yea, script can't control output values.
14:57 < jgarzik> but not within plain ole bitcoin
14:57 < jgarzik> I need to research US state laws
14:58 < gmaxwell> if we had another address type we could specify an address that encoded N addresses to sendmany to, I suppose.
14:58 < jgarzik> I bet I could find a US state where an escrow bot would be legal
14:58 < jgarzik> nod, something like that
14:58 < gmaxwell> well, as I said, the bot could just be a TPM oracle— it might not even know what bitcoin is.
14:59 < sipa> how about a payment request for such a sendmany?
14:59 < gmaxwell> If the bot is something like: trusted computing enviroment, you send it a script, it generates per-script private keys based on the hash of the script.. then it runs the script.  you could send it a script that teaches it how to sign transactions but only if they have the right outputs.
15:00 < gmaxwell> The operator of this thing wouldn't even know it was being used for 'escrow payments'. It's just generic infrastructure.
15:02 < gmaxwell> speaking of that, we got a 10 BTC donation to developers a while back that we should do something with.
15:02 < gmaxwell> (sent to a p2sh of our public keys)
15:24 < jrmithdobbs> dude
15:25 < jrmithdobbs> i think test-driven-development (besides making me want to kill people) actually *PROVES* (like, possibly mathmatically, with a bit of fiddling) that SSL/TLS is broken by design
15:25 < jrmithdobbs> think about this for a second
15:25 < jrmithdobbs> so, I'm trying to add proper cert validation to some code acting as a tls client
15:25 < jrmithdobbs> let's assume i can get the code correct, i move on to writing the test cases for it
15:26 < jrmithdobbs> let's even assume we get past that part
15:26 < jrmithdobbs> now the test suite needs to act as a tls server in order to use the certs in the test cases
15:26 < jrmithdobbs> which means the code now needs functionality completely irrelevent to it's actual purpose
15:26 < jrmithdobbs> which means you have a new set of functionality to test
15:27 < jrmithdobbs> problem: a valid tls server implementation requires valid x509 validation
15:27 < jrmithdobbs> so we can't test the tls server code without solving the original problem the tls server code is meant to solve
15:27  * jrmithdobbs MIND BLOWN
15:27 < jgarzik> hmmm
15:27  * jgarzik scrolls back, after putting down wife and 2 kids for naps
15:28 < jrmithdobbs> if it can't be proven to "broken by design" it can at least be proven that there is no such thing as a tls *client* only servers acting as clients
15:28 < jrmithdobbs> (which to me really, is the same level of brokeness due to complexity in this context, really ;p
15:28 < jrmithdobbs> )
15:29 < HM> jrmithdobbs: i just give up
15:29 < HM> throw stunnel up in front of your server, firewall things properly
15:32 < jrmithdobbs> that doesn't fix the fact that this shit isn't validating certs properly on outbound connections and the fix to make it so wont get merged without test cases ;p
15:32 < HM> what 'shit' is this?
15:33 < jrmithdobbs> (all of the above came from a real scenario, not imagined PKI/x509 whining, jfyi https://github.com/gitlabhq/gitlabhq/issues/3445 )
15:33 < HM> yeah
15:34 < jrmithdobbs> this shit is unimplementable in a deterministic fashion =/
15:34 < jrmithdobbs> what a clusterfuck
15:35 < jrmithdobbs> can't even blame ruby (let alone rails, this is the non-rails part of the app, though the rails part uses https for git cloning without verifying too! ugh!)
15:35 < jrmithdobbs> this is a problem with the standards not the language =/
15:35 < HM> how can CN verification be off?
15:35 < jrmithdobbs> because it was never on
15:36 < HM> actually stunnel does this as well
15:36 < jrmithdobbs> openssl doesn't do that for you, it just verifies the chain
15:36 < HM> " Specifically for level 2 every non-revoked certificate is accepted regardless of its Common Name"
15:36 < HM> default is level 0
15:36 < HM> stunnel is a proxy frontend for OpenSSL basically
15:36 < jrmithdobbs> binding it to an identity (the fqdn in the case of https) is outside the scope of openssl's implementation
15:36 < jrmithdobbs> believe it or not
15:36 < HM> wouldn't surprise me if those levels were part of the openssl api
15:36 < jrmithdobbs> people don't seem to realize this
15:37 < jrmithdobbs> so nothing but browsers validates properly, basically
15:37 < HM> hmmm
15:37 < jrmithdobbs> gmaxwell linked a paper that backs up that statement a while back
15:37 < HM> what about SNI?
15:37 < HM> that moves the requested hostname up to the SSL/TLS protocol level
15:37 < jrmithdobbs> doesn't matter if you don't check the identity after performing the sni operation
15:38 < jrmithdobbs> sni solves a different problem
15:38 < HM> sure
15:38 < jrmithdobbs> the problem is nothing verifies the identity, not in requesting the right identity (though that is a problem too, and i'm not sure how well sni addresses it because i've not looked at it much because nothing supports it)
15:38 < amiller> gmaxwell, tpm and split key are so *boring* i wish you would toss along "or another blockchain" as another kind of delegation
15:39 < jrmithdobbs> amiller: imagine the tpm is controlled by an agent, not so boring now, eh?
15:39 < jrmithdobbs> ;p
15:39 < amiller> that's just a tpm
15:39 < amiller> agent is a non-word there
15:39 < HM> i think SNI would solve it
15:39 < jrmithdobbs> HM: it doesn't.
15:40 < jrmithdobbs> HM: sni doesn't have anything to do with the fqdn -> subject/subjectAltName binding/verification step
15:40 < HM> for http?
15:40 < HM> i don't know what gitlabhq is
15:40 < jrmithdobbs> HM: it's a method for requesting the identity you intended, if you don't verify it afterwards sni doesn't force you to verify it afterwards any more than plain https
15:40 < amiller> the options are a) use a magic tpm remote attestation device, b) use an M-of-N split of designated trust identities, or c) an anonymous public competitive process like bitcoin
15:40 < jgarzik> amiller: boring but useful, in the stated use case (spend to address -> trustworthy, automated split of spent funds to N independently controlled addresses)
15:41 < jrmithdobbs> HM: think github / gitolite / gitorious
15:41 < HM> perhaps you're right
15:41 < jrmithdobbs> sni is kind of stupid too
15:42 < jrmithdobbs> because http just needs a real starttls command ;p
15:42 < amiller> jgarzik, fair enough, in order of usefulness i'd say the order goes (most useful) an anonymous public competition, (second most useful) m-of-n trusted designees, (last most useful) tpms
15:42 < jrmithdobbs> sni already requires argeement on protocol level changes, if you're conceeding that just add starttls to http damn it
15:43 < HM> jrmithdobbs: https://www.ietf.org/rfc/rfc2817.txt this isn't good?
15:43  * amiller reads up and finally sees jgarzik's original question though
15:43 < amiller> that would be really easy to encode with more powerful scripts and wouldn't require any of the three *fancy* solutions...
15:44 < jrmithdobbs> i should write a paper about this experience
15:44 < jrmithdobbs> and title it "An indictment of x509, tls, and the security community at large."
15:44 < jrmithdobbs> ;p
15:44 < amiller> so any bitcoin value sent to this address is automatically split three ways
15:45 < amiller> that's cool
15:46 < jgarzik> amiller: ?
15:46 < jrmithdobbs> HM: you mean the 13 year old document that has no chance of ever being implemented? no there's nothing wrong with it per se, it's just never getting implemented ;p
15:47 < HM> i thought Googles SPDY was going to require TLS by default
15:47 < HM> the HTTP 2.0 scene seems to have gone quiet though
15:47 < amiller> jgarzik, that application is really cool, i haven't seen anyone talk about it before, and it's a great example of something that shouldn't require 'fancy' trust splitting techniques and would be a good justification for slightly more powerful scripts that can constrain txouts in subsequent txes
15:49 < jrmithdobbs> HM: but actually, yes, in glancing over it i can come up with a few problems with that too =/
15:49 < jrmithdobbs> HM: implementing that requires concession of http proxies, big ones
15:50 < HM> Websockets upgrade is also broken in the face of shitty proxies
15:50 < jrmithdobbs> HM: it basically MUST be possible to CONNECT through an http proxy to port 80 and 443, for starters, which if you're somewhere trying to use said http proxy for egress filtering in a non-evil-mitm way it makes things difficult without conceeding to evil and mitm'ing the traffic
15:51 < gmaxwell> amiller: I don't even know how you're really usefully express those limits... and they wouldn't be compact at all... kinda sucks to have to carry around a bunch of data in the distributed consensus for a one time operation.
15:51 < jrmithdobbs> (assuming you have access to the client, which in these scenarious you usually do)
15:51 < gmaxwell> (obviously I know how it can be expressed at all— not not compactly)
15:51 < jrmithdobbs> HM: also i see about 10 different ways implementations could shoot themselves in the foot with that (it's too complex)
15:52 < amiller> gmaxwell, the limits for jgarzik's split-three-ways txouts?
15:52 < HM> This is why I don't like implementing SSL/TLS
15:52 < jrmithdobbs> HM: but then, so are the range/etc operators introduced in http/1.1 that are related to that connection upgrading stuff (outside of that tls extension) is guilty of the same, so in this case it's an http and tls problem for once at least ;p
15:53 < jrmithdobbs> http or without tls is a security nightmare to implement correctly, adding tls in any way makes it that much more convoluted =/
15:53 < amiller> i don't know why i never thought of it before but it might be exactly the simple killer app i've been hoping for...
15:53 < gmaxwell> amiller: Yes, well he didn't say /three/ ways...
15:53 < jgarzik> amiller: arbitrary split, not 3-way
15:53 < HM> jrmithdobbs: let's leave http now :P
15:54 < amiller> the basic thing that this would need to work is a way for a txout to validate txouts in subsequent txes
15:54 < jgarzik> amiller: Example: lead dev gets 50% of funds, remaining devs split remainder of funds.
15:54 < gmaxwell> amiller: hm? I thought you'd talked before about constraining following txouts? but it becomes messy fast. e.g. what happens when you want to spend two coins in the following txout with conflicting constraints?
15:54 < amiller> the representation would be like a remaining balance for each of the parties, rather than one total btc amount
15:54 < jgarzik> a "fund broadcast" almost
15:55 < amiller> so each 'change' tx would have to put back the correct amounts for the other parties
15:55 < amiller> oh or the simplest thing
15:56 < amiller> maybe make it so anyone can spend it
15:56 < amiller> but... the only 'valid' way to spend it is to split it into however many txouts
16:03 < amiller> so yeah i have talked before about constraining following txouts but i've never had any example where that was necessary or the easiest way to implement, but this is a good candidate
16:04 < amiller> the simplest way to implement fwd validation i think is to have new opcodes like OP_PUSH_TXOUTS that load the txouts from the transaction-currently-undergoing-validation into the validation stack
16:05 < amiller> and OP_PUSH_TXIN i guess too
20:57 < jgarzik> fork success!  bitcoind starts up and shuts down a new process, complete with pipe RPC.  Of course, just a skeleton that does nothing useful at all.  But it forks!
20:57 < jgarzik> RPC (IPC?) has one command at the moment, BCE_SHUTDOWN_REQ
21:26 < gmaxwell> lol
21:28 < HM> jgarzik: you're working on a new RPC implementation?
22:12 < jgarzik> HM: no, adding fork() separation between the network code and "everything else" (RPC/wallet)
22:12 < warren> nice!
22:13 < HM> jgarzik: eh? but won't the 2 forks need to communicate via their own RPC mechanism?
22:13 < jgarzik> HM: well, ok, I guess you can call that a new RPC implementation.  But it's not a public RPC interface, but a private, inter-process communication interface.
22:14 < HM> right
22:14 < HM> you could make use of network namespaces as well
22:14 < HM> put the main process in to its own network namespace so it can't talk to the outside world
22:14 < HM> interesting little project anyway, cool beans
22:15 < jgarzik> the "everything else" process (wallet/GUI/JSON-RPC) is the master process, and the "blockchain engine" is a sub-process of that main process.
22:15 < HM> right
22:15 < jgarzik> blockchain engine manages the P2P network code, and the blockchain dataset
22:15 < jgarzik> BCE might be chroot-able, as well as enabling things like network namespaces
22:18 < sipa> discussion idea: peer rotation; this is something gmaxwell and I have been discussion a long time ago, and the idea is this: instead of always maintaining 8 outbound connections, after timeout N, start attempting creating a 9th connection anyway, and when it works, disconnect one of the existing one. This should make the network much more dynamic and less deterministic, and more quickly crawl through existing peers. For selecting the peer to...
22:18 < sipa> disconnect, the idea is to aim for an "exponential distribution of connection times", so have some connections that live very shortly, and some that live for very long. Some simulations have shown that giving each outbound peer a chance proportional to its connection_time^(-0.8) would approximately achieve that nicely, ideally combined with some health metrics per-peer as modified to prevent disconnecting the peer that relays most blocks...
22:18 < sipa> first, for example
22:19 < HM> sounds sensible
22:20 < HM> jgarzik: i think the RPC mechanism needs overhauling. process separation would potentially make way for an RPC v2. I've already been toying with a proxy for Apache Thrift that layers over the existing HTTP JSON RPC
22:21 < sipa> the problem is that RPC does interaction with multiple fundamentally different components
22:21 < sipa> it does interaction with the blockchain, the network, and the wallet
22:21 < sipa> while ideally, each of those would have a single interface that can be used for both interaction with humans and with other components
22:22 < HM> well, Thrift just got service multiplexing committed to git
22:22 < HM> and it supports about a dozen languages
22:23 < HM> the drag for a lot of these marshalling formats though is that  bitcoin inherently deals with a lot of custom binary data
22:23 < jgarzik> sipa: indeed
22:24 < jgarzik> sipa: a big part of my task here is "drilling holes" -- creating internal IPC calls from RPC server into the blockchain process, and back again
22:24 < jgarzik> sipa: e.g. getconnectioncount, for a simple example
--- Log closed Mon Apr 01 00:00:15 2013