Transcript for #bitcoin-dev 2014/08/17

00:24 BlueMatt ayansh: sorry, I'm (slowly) recovery from catastrophic fs failure...but yea, it should be 8336
00:34 agorist000 petertodd, are you available? I have a question about python-bitcoinlib.
01:00 gmaxwell Anyone know what Mike's plan for lighthouse and getutxo is? I feel like the network was pressured for a overly hasty rollout of bloom filters on the basis of wanting it for bitcoinj, and I'm concern the same will happen for 0.10 and getutxo.
01:35 jgarzik gmaxwell, the getutxo PR thread seemed to cover that. He was going to sample multiple nodes exporting getutxos.
01:37 jgarzik gmaxwell, I am definitely not ACK'ing that PR, as it exports the info untrusted (even if block height/etc. included).
01:37 jgarzik but reluctant to NAK
01:37 gmaxwell jgarzik: I mean right now there are no nodes exporting getutxos. I don't want to deal with an emergency "0.10 must be released now!" and "everyone must upgrade now!"
01:37 jgarzik getutxos is easy to use insecurely
01:37 jgarzik and difficult to use securely
01:38 gmaxwell yea, I'm on the fence between non-ack and nak. For two reasons, one is additional untrusted data, the other is that btcd said they are disinclined to implement. If we're also looking at an upgrade firedrill then that pushes me towards NAK.
01:38 jgarzik gmaxwell, I haven't seen anything RE upgrade firedrill
01:39 gmaxwell well thats why I was trying to ask. This could be avoided by the initial version of litehouse having a configurable server list.
01:39 jgarzik so I don't have that worry
01:39 jgarzik gmaxwell, NODE_UTXOS means you don't have to worry about that?
01:39 jgarzik it gets advertised
01:40 gmaxwell I know it does, but if only a few nodes on the network have it you may not learn about any of them.
01:40 gmaxwell and we'll get pressured to deploy 0.10 prematurely and the network will be pressured to widely deploy it prematurely, and we'll end up with yet another remote crasher bug as a result.
01:41 jgarzik I think anybody rolling out new NODE_xxx services has to deal with that
01:41 jgarzik nah, I haven't seen any pressure like that
01:42 jgarzik My worries are more about (a) untrusted data; even with "mempool" the users are full nodes expected to verify the data, (b) implementing services in bitcoind that ought to be in other layers (we are duplicating Insight), (c) easy to use securely, requires complexity to use securely,
01:42 jgarzik and notably (d) this P2P command was implemented long before services to use it
01:43 jgarzik thus somewhat speculative
01:43 gmaxwell jgarzik: we absolutely did suffer it with 0.8, not just the pressure to release but things like:
01:43 jgarzik gmaxwell, I was referring to getutxos specifically.
01:45 jgarzik Honestly, the only reason why I don't NAK is because I think it is a bit of a special case. We already index utxos, and will for the forseeable future. The main danger in exporting that via P2P is IMO lazy "just check one node for an answer" implementations.
01:46 gmaxwell yes, its narrow enough that I think its safe wrt tying out hands wrt pruning or data structures, plus the service bit can go away.
01:47 gmaxwell It's wrong with respect to the security model. And btcd doesn't want to implement either.
01:47 gmaxwell But it's also very narrow and that means a lot. I also know what mike originally wanted and he did accomidate the design substantially.
01:47 gmaxwell (he wanted an arbritary free transaction lookup)
01:51 moa "Actually running old versions can cause problems even if you don't think you need any of the new features. Old versions just generally cause problems for the network. It's best to stay up to date if you can." Mike Hearn, March 03 2013
01:52 moa On 12 March 2013, a Bitcoin miner running version 0.8.0 of the Bitcoin software created a large block that was incompatible with earlier versions of the Bitcoin software because of its size.
01:52 moa ... due to leveldb implementation
01:52 BlueMatt ehhh, whether that made sense depends entirely on context
01:53 BlueMatt and, iirc, the bloom stuff was before 0.8, so this is irrelevant to the discussion
01:53 moa ok
01:54 jgarzik BlueMatt, adding a feature + pushing to upgrade is relevant
01:54 jgarzik but also to be expected
01:54 BlueMatt yes, but I dont think that quote was relevant
01:54 jgarzik people are cheerleaders for their features
01:54 BlueMatt but, yea, sure I get the issue here
01:56 jgarzik At some point it's a philosophical question (though, again, getutxos is a special case as mentioned). Do we implement extra indices and services in bitcoind? NODE_QUERY_ADDRESS is ok, if optional? NODE_TRADE_STOCKS?
01:57 jgarzik I prefer the "bitcoin == IP, in a HTTP/TCP/IP analogy" model, which pushes services up. Others disagree.
01:58 jgarzik What is mainnet: relaying transactions and blocks, or a bootstrap into myriad bitcoin-related services?
01:58 BlueMatt I prefer none of this be tied to bitcoind
01:58 BlueMatt etc
01:58 jgarzik original Satoshi design was much broader
01:58 BlueMatt true, but...oh well
01:59 jgarzik included ebay-ish stuff, pubsub, trading, ...
01:59 BlueMatt yes, but bitcoin today is a bit different from the (early) satoshi days ;)
02:00 BlueMatt and I think keeping bitcoin core/the p2p network as minimal as possible is better
02:03 moa yes minimal is good
02:05 moa where are the TCP HTTP inventors for btc is the question?
02:05 BlueMatt ?????????
02:07 gmaxwell BlueMatt: the reason I brought up the bloom filter stuff was because mike applied a lot of pressure to ship 0.8 and when it was out he applied a lot of pressure for people to deploy it. (and separately, he pressured mining pools to increase their block sizes). I don't want a replay of that with getutxo. Fortunately we're doing a lot better with the service bit for it, so at least it can be disabled.
02:07 BlueMatt it was 0.8? for some reason I thought 0.7
02:07 BlueMatt ohh, no that was just the protocol version
02:10 petertodd agorist000: best to email me
02:12 TheRelic is it possible using a command in bitcoind to give a address coins in a -testnet ?
02:12 ayansh hi #bitcoin-dev, i am using RelayNodeClient.jar, * 8336 connection refused, it worked fine earlier. service is down?
02:13 BlueMatt probably, I'll look later
02:13 TheRelic or is there a way to find out how many confirmations a block has?
02:15 dsnrk blocks don't have confirmations really, they have a depth.
02:15 BlueMatt ayansh: fixed, though I'll look a bit later into the cause
02:16 ayansh BlueMatt:Thanks, it's working now.
02:19 TheRelic right now, for a miner it requires 120 confirmations to get paid out, how do i change this in the src?
02:19 dsnrk altcoin development is off topic.
02:19 dsnrk if you can't find a simple variable, please don't try to make a currency.
02:20 gmaxwell TheRelic: the fact that newly generated coins can't be spent immediately is a requirement of the bitcoin protocol it cannot be changed.
02:20 TheRelic gmaxwell i'm working on a clone,
02:20 TheRelic i need to change the block confirmations for block generators to get paid out for testing purposes
02:20 BlueMatt in which case, see dsnrk's reply
02:20 gmaxwell TheRelic: please read
02:21 agorist000 petertodd, thanks, and where might I find your email address?
02:21 gmaxwell TheRelic: creating a cryptosystem (which a cryptocurrency is one) is a serious responsibility... you're asking the most basic possible parameter question.
02:42 ayansh BlueMatt: I think issue is reproducible, connection is refused after telnet * 8336. i was sending standard error and standard output to /dev/null to avoid disk io.. couldn't corelate both.
02:45 ahmed_ anyone here know why bitcoind could keep crashing/
02:52 eberline I need some help purchasing a coin and mining it. I am willing to pay bitcoin for this service. Someone message me please
02:54 jgarzik eberline, way way off topic for this channel
02:57 phantomcircuit gmaxwell, supreme NACK for utxo polling
03:12 gmaxwell oh my. did this actually emit the txouts themselves before?