--- Log opened Fri Mar 29 00:00:11 2013 00:01 < jgarzik> I might just do a wholly separate service, a "UDP beacon" 00:02 < jgarzik> Clients send a simple message, subscribing to block header (block+tx list?) broadcasts over UDP. Subscription lasts X seconds, after which, it must be renewed with another UDP request to the beacon server. 00:02 < jgarzik> Each block triggers a broadcast. 00:04 < jgarzik> Semi-related: tunneling SCTP over UDP: http://tools.ietf.org/id/draft-ietf-sigtran-sctptunnel-00.txt 00:05 < petertodd> jgarzik: ACK on UDP beacon 00:06 < BlueMatt> jgarzik: sounds like what I would think of udp as 00:18 * jgarzik retweets a bitcoin block header ;p 00:19 < petertodd> THAT'S HOW YOU DEFEAT TYRANNY!!!!! 00:35 < petertodd> jgarzik: re: uint256 for hashes in bitcoinlib, were you just trying to follow the C++ implementation? 00:35 < jgarzik> petertodd: specific code example / source file line#? 00:37 < petertodd> COutPoint is an example, where self.hash is deserialized to an integer and back again 00:39 < jgarzik> petertodd: It is helpful for the few cases where it matters as more than just a binary blob 00:39 < BlueMatt> how mature is libcoinc? 00:39 < jgarzik> petertodd: though TBPH, that was inherited from the original ArtForz mini-node 00:39 < BlueMatt> s/c?/?/ 00:40 < petertodd> jgarzik: Yeah, I was going to change that back to plain bytes instances. Bitcoin has a ton of hashes involved and you're doing a lot of copying there. 00:40 < petertodd> jgarzik: Makes it easier to build up transaction too in a natural way. 00:40 < jgarzik> BlueMatt: my libccoin? Unit tested, not much outside of that. What it does, should be solid (famous last words). You are more likely to find some missing pieces here and there. 00:42 < jgarzik> petertodd: oh yeah, it makes it a lot easier to print ;p 00:42 < petertodd> jgarzik: For instance with my code you can now do: CScript([OP_DUP, OP_HASH160, pubkeyhash, OP_EQUALVERIFY, OP_CHECKSIG]) and everything works as expected. You need to convert the hash back to bytes if it's an integer. 00:42 < jgarzik> petertodd: slower, but more pythonic 00:43 < petertodd> jgarzik: I think we've hit an edge case where "pythonic" can mean two different things. :P 00:44 < jgarzik> petertodd: pythonic == elegant python source, regardless of how slow under the hood 00:44 * jgarzik runs 00:45 < petertodd> jgarzik: Heh, well building up a transation the way you can now is IMO a lot more elegant than the previous CScript() thing. 00:45 < BlueMatt> what? is that not an accepted definition? 00:46 < petertodd> BlueMatt: What constitutes 'elegant' isn't clear-cut. 00:47 < jgarzik> petertodd: If you want to change everywhere to byte buffers, how would we test the change to see if anything breaks? 00:47 < jgarzik> :) 00:48 < jgarzik> would need print and comparison helpers (or perhaps just a convert-to-python-long helper) 00:48 < petertodd> jgarzik: Gee, I dunno, it'd be good if we had some unittests... :P 00:48 < petertodd> jgarzik: I did up h2b() and b2h() 00:48 < petertodd> jgarzik: You already have bytes to python integer. 00:58 < jgarzik> petertodd: BTW, seen this? https://github.com/samrushing/caesure 00:58 < jgarzik> petertodd: looks like he's doing some Cython work 00:59 < petertodd> jgarzik: crazy, the re-implementations never stop 00:59 < jgarzik> petertodd: that's actually pretty old 01:00 < jgarzik> petertodd: python-bitcoinlib's key.py came from there via a third party 01:00 < jgarzik> (see header) 01:00 < jgarzik> petertodd: I'm about to add base58 support, and was thinking of stealing it from there 01:00 < petertodd> jgarzik: huh, interesting 01:00 < jgarzik> petertodd: do you know of a better base58 source? 01:01 < jgarzik> https://github.com/samrushing/caesure/blob/master/caesure/proto.pyx#L53 01:01 < petertodd> jgarzik: hmm... no license specified 01:01 < petertodd> oh, wait, no I'm blind 01:01 < gmaxwell> jgarzik: that SCTP draft is dead, this one is very much alive: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps and is already shipped in beta state to many millions of systems (in Chrome and Firefox). 01:01 < petertodd> jgarzik: Probably as good as any. 01:02 < jgarzik> gmaxwell: neat 01:02 < jgarzik> petertodd: groovy 01:03 < gmaxwell> the nice thing about using that draft: (1) you can copy webrtc code for all of it (including nat traversal), (2) you get censorship resistance because you look like webrtc. ... downside: still connection oriented. 01:07 < petertodd> # having trouble understanding if there is a difference between: CHECKMULTISIG and P2SH. <- not a good sign 01:08 < gmaxwell> Which CTO in charge of technology for a hundred million dollar bitcoin business did that come from? 01:09 < petertodd> gmaxwell: lol, nah it's from yet another bitcoin reimplementation: https://github.com/samrushing/caesure 01:09 < petertodd> (more scary I know) 01:11 < petertodd> "I'm attempting to make this a full node, with tx verification etc...." "Script engine is mostly done. Needs some work on failing constraints like stack size, sig count, etc." 01:12 < petertodd> Oh, and it comes with a "drop-in replacement" for openssl... 01:21 < jgarzik> petertodd: ok, pushed 01:23 < petertodd> jgarzik: cool, lemme add some tests 01:30 < gmaxwell> sipa: oh, supposidly openssl's ECDSA signing adds the message to the randompool before generating the nonce. 01:36 < petertodd> jgarzik: prelims pushed; I'm off for the weekend 06:39 < warren> What's the number of tx's changed that causes a pre-0.8 reorg to fail again? 07:53 < sipa> warren: over 4800 affected txids in a single reorg is risky 07:57 < warren> sipa: the litecoin users finally noticed the reorg risk due to gavin's posting, and I'm thinking about the likelihood of an actual reorg attack succeeding within the next 3 months it will take coblee to upgrade the client as he doesn't think it is urgent. 08:01 < warren> sipa: their typical blocks have *at most* a few dozen tx's, and their standard fees are extremely high, so it would be expensive to artificially jack up the number of tx's in a number of successive blocks. Then a reorg attack would need amazing luck to generate a valid attack block fast enough after the previous block containing just the right number of tx's. The part I'm not sure of is the exact circumstances where an attack block would f 08:01 < warren> ail differently for some nodes in a reorg. 08:02 < warren> sipa: (I'm assuming the one-block attack from a hostile miner, as I suspect that's the easiest/cheapest attack to do. I could be wrong.) 12:13 < realazthat> hey fellas 12:13 < realazthat> any ideas for a bitcoin-based project? 12:14 < sipa> write a python script that implements blockexplorer-like website, by using bitcoind RPCs 12:14 < realazthat> heh I just wrote a python blockchain parser 12:15 < realazthat> is the API powerful enough to do that? 12:15 < sipa> not for address-based lookups 12:15 < sipa> but for pretty much everything, yes 12:15 < sipa> if you enable txindex 12:15 < realazthat> doesn't blockexplorer use a patch or somesuch 12:15 < sipa> blockexplorer was written when bitcoind was version 0.3.17 or so 12:16 < realazthat> ok 12:16 < realazthat> this sounds like a doable project 12:16 < realazthat> how useful would it be? 12:17 < sipa> i think a lot of people currently depend on blockexplorer-like sites for trivial queries that their own bitcoind could do 12:17 < sipa> but using the RPC interface isn't particularly user-friendly 12:18 < realazthat> so this would be a locally run site 12:18 < realazthat> ? 12:19 < sipa> yeah 12:19 < sipa> i'd very much like to see something like that in bitcoin's contrib/ directory 12:19 < realazthat> any ideas for a python website framework lib or somesuch to use 12:20 < realazthat> or to make it on raw sockets 12:20 < sipa> i don't know enough python for that, but for example p2pool has a very nice built-in stats page 12:20 < sipa> no idea how it's implemented though 12:20 < realazthat> ok, I'll do some research 12:21 < sipa> thanks! 13:01 < realazthat> ok so I think I wanna use something simplistic 13:01 < realazthat> not a whole framework 13:02 < realazthat> something like http://code.activestate.com/recipes/577047-bible-verse-quiz-servletpy/ 13:03 < realazthat> I'll get started 13:04 < sipa> realazthat: awesome1 13:04 < sipa> realazthat: awesome! 13:04 < sipa> poke me if you need help 13:05 < realazthat> it will take some time, I need to get a bitcoind up and running 13:59 < realazthat> sipa: should I be using python-bitcoinrpc 14:02 < sipa> realazthat: i don't care :) 14:50 < HM> sipa: is "txindex" accepted in bitcoin.conf as well? 14:50 < HM> or anyone 14:50 < HM> txindex=1 14:55 < sipa> yes 14:56 < HM> i'm starting a fresh daemon, i don't want to download twice or rebuild 14:56 < HM> so just -daemon -txindex=1 14:56 < HM> or txindex=1 in .conf 14:56 < sipa> indeed 14:56 < sipa> or -txindex 14:57 < HM> cheers 15:04 < realazthat> oh cool I'll put it there 15:05 < realazthat> does bitcoind respond to rpc calls if its still downloading the chain? 15:07 < HM> seems to real 15:10 < realazthat> kk 15:13 < sipa> realazthat: there is no difference between downloading the chain and not 15:13 < sipa> as you're always trying to catch up 15:14 < realazthat> yeah i figured that; was just running into an error 15:14 < realazthat> turns out it was a 401 unauthorized 15:14 < sipa> some calls are disabled when the client is sure it's nit done yet 15:14 < realazthat> the rpc lib didn't print anything though, it just errored 15:17 < realazthat> ok rpc is working 15:20 < HM> realazthat: you working on a web frontend? 15:20 < realazthat> yeah 15:21 < realazthat> block-explorer-like 15:21 < realazthat> but focused on locally run 15:29 < HM> that's not a bad idea generally 17:24 < realazthat> sipa: ok, gonna be afk for ~24 hrs --- Log closed Sat Mar 30 00:00:12 2013