1 2015-03-08 00:24:10 <ajweiss> because ibm sells message router/filter/blablas that work with xml natively
  2 2015-03-08 00:26:29 <sipa> do they support jsonx?
  3 2015-03-08 00:27:45 <ajweiss> i would certainly hope so
  4 2015-03-08 00:32:19 <sipa> we need a standard for encoding asn.1 in JSONx
  5 2015-03-08 00:32:26 <sipa> full circle
  6 2015-03-08 00:37:14 <ajweiss> 
ACTION wonders if any of the big CAs are actually lame enough to have a bunch of overpriced ibm mq infrastructure

  7 2015-03-08 00:39:32 <ajweiss> oh sweet, it already exists, XER hahahahaha
  8 2015-03-08 00:50:34 <fanquake> ;;blocks
  9 2015-03-08 00:50:35 <gribble> 346633
 10 2015-03-08 14:50:01 <SeXploit> dude at MIT trying to get on Gavin hahahaha
 11 2015-03-08 14:51:15 <sipa> ?
 12 2015-03-08 14:55:36 <SeXploit> https://www.youtube.com/watch?v=96ULlHhia_Q
 13 2015-03-08 15:19:03 <skilesare> Anyone going to Texas Bitcoin Conference at the end of March?
 14 2015-03-08 15:19:30 <skilesare> I'm looking to meet up with some folks to talk bitcoin.
 15 2015-03-08 18:20:15 <Muis> Bitcoin used to have a feature to send directly to an IP
 16 2015-03-08 18:20:32 <Muis> And that was removed because of MITM attacks
 17 2015-03-08 18:21:15 <sipa> indeed
 18 2015-03-08 18:21:23 <sipa> thiugh we have the payment protocol now
 19 2015-03-08 18:21:27 <Muis> Could it be usefull if the channel is secure? Or is it already obsolete?
 20 2015-03-08 18:21:45 <sipa> totally obsolete
 21 2015-03-08 18:21:53 <Muis> Because pay to .onion adress is safer than pay to ip maybe?
 22 2015-03-08 18:22:09 <sipa> look at the payment protocol (bip70-72) for a modern replacement
 23 2015-03-08 18:24:09 <Muis> But that requires a merchant who has a server and a customer
 24 2015-03-08 18:24:38 <Muis> Im looking for more p2p transfer like pay to ip was
 25 2015-03-08 18:25:19 <sipa> pay to ip also required the recipient being online
 26 2015-03-08 18:25:35 <Muis> Thats no problem for my usecase
 27 2015-03-08 18:26:07 <sipa> then running a payment protocol server should not be a problem either
 28 2015-03-08 18:27:19 <Muis> yes it is because instead of just running a bitcoin daemon, every user will also need to run a seperate daemon just to handle payment request
 29 2015-03-08 18:27:40 <sipa> users already don't run bitcoin daemons
 30 2015-03-08 18:27:51 <Muis> With all NAT and firewall issues associated
 31 2015-03-08 18:27:51 <sipa> and the payment protocol is being integrated in more wallets
 32 2015-03-08 18:28:13 <sipa> there are some proposed changes to improve usability for end users
 33 2015-03-08 18:29:07 <Muis> But is it possible to enable pay to ip for experimenting,or is it totally strippped from the code by now?
 34 2015-03-08 18:29:18 <sipa> totally stripped
 35 2015-03-08 18:29:26 <sipa> and the payment protocol is superior in many ways
 36 2015-03-08 18:29:44 <sipa> like support for refunds, memo messages, authentication
 37 2015-03-08 18:30:05 <Muis> Yes for shops its perfect
 38 2015-03-08 18:30:09 <sipa> i'm not sure you understand
 39 2015-03-08 18:30:20 <sipa> the payment protocol is effectively pay to ip
 40 2015-03-08 18:30:26 <Muis> But for p2p payments its awful
 41 2015-03-08 18:30:40 <sipa> except over http instead raw bitcoin p2p
 42 2015-03-08 18:30:49 <sipa> it is exactly as awful as pay to ip was
 43 2015-03-08 18:31:01 <sipa> this is an orthogonal problem
 44 2015-03-08 18:31:11 <sipa> the fact that it uses a different protocol didn't change this
 45 2015-03-08 18:31:13 <Muis> Yes, but I already have a connection to that peer in my case
 46 2015-03-08 18:31:47 <Muis> So setting up a http connection is unnecessary complex
 47 2015-03-08 18:32:20 <sipa> and running a node with a wallet in it is a bad idea for other reasons
 48 2015-03-08 18:32:27 <sipa> yet it's required for pay to ip
 49 2015-03-08 18:33:02 <sipa> if setting up an http connection is the reason for not using a vastly superior protocol, i think you have other problems :)
 50 2015-03-08 18:33:04 <Muis> But i will look more into the BIP, maybe i can adapt to use raw tcp
 51 2015-03-08 18:33:50 <Luke-Jr> hm, I think by having the relay fee policy different from the mining policies, we've created a situation where people can get txs stuck worse than before: no longer can they double spend them with a higher fee because they're in mempools :/
 52 2015-03-08 18:35:26 <petertodd> Luke-Jr: +1
 53 2015-03-08 18:51:39 <kanzure> is there any mempool pruning that happens?
 54 2015-03-08 18:51:45 <kanzure> perhaps some sort of exponential falloff?
 55 2015-03-08 18:51:51 <sipa> nope
 56 2015-03-08 18:51:57 <kanzure> or a half-life, rather. that's the better name.
 57 2015-03-08 18:52:02 <sipa> been talked about for ages, though
 58 2015-03-08 18:52:05 <kanzure> as good?
 59 2015-03-08 18:52:40 <sipa> yes, but no agreement about how to do it :)
 60 2015-03-08 19:16:40 <jcorgan> since it is not a consensus issue, what has stopped people from trying out different strategies?
 61 2015-03-08 19:17:10 <sipa> there have been forks in the past with different policies
 62 2015-03-08 19:17:20 <sipa> particularly for reducing the required fees
 63 2015-03-08 19:17:28 <sipa> but those never had much uptake
 64 2015-03-08 19:18:02 <jcorgan> sorry, i was referring to mempool TX discarding, not minimum relay fee
 65 2015-03-08 19:18:12 <sipa> heh
 66 2015-03-08 19:18:20 <sipa> someone just has to implement something
 67 2015-03-08 19:18:27 <sipa> nothing will happen before that time :)
 68 2015-03-08 19:18:41 <jcorgan> Simple Matter Of Programming :)
 69 2015-03-08 19:18:41 <sipa> jeff's poolman was neber completed
 70 2015-03-08 19:41:22 <b_lumenkraft> did i get that right? if there is a TX in mempool which never makes it to the blockchain it will never get rejected in a way?
 71 2015-03-08 19:44:32 <sipa> yes
 72 2015-03-08 19:44:41 <sipa> but note that the mempool is a per-node thing
 73 2015-03-08 19:45:21 <b_lumenkraft> ok i see. thank’s sipa :)
 74 2015-03-08 19:48:33 <jcorgan> b_lumenkraft: eventually enough of the network "forgets" an unconfirmed TX through reboots/restarts, etc., to allow retransmitting a new TX respending the original UTXOs, but that can take a few days
 75 2015-03-08 19:51:08 <b_lumenkraft> i heard this before so i wondered. thank’s for making this clear jcorgan!
 76 2015-03-08 19:54:21 <davec> I imagine the reason there isn't much traction with trying out different strategies is they effectively don't currently work because many of the transactions generally won't relay through the network.
 77 2015-03-08 19:55:38 <davec> For example, you could experiment with a replace-by-fee branch, but it's almost a foregone conclusion that your replaced transactions won't be mined since they typically won't be relayed and generally will be rejected by the majority of the mempools of most miners as a double spend.
 78 2015-03-08 19:56:21 <sipa> the replace-by-fee patch by petertodd preferably connects to other nodes running that patch, afaik
 79 2015-03-08 19:57:06 <sipa> so the odds of it reaching a miner running the same code aren't that small, i think
 80 2015-03-08 19:57:33 <sipa> assuming there are miners running it
 81 2015-03-08 19:58:13 <davec> right.  if enough people and mining hash power are running the modified version
 82 2015-03-08 19:59:16 <phantomcircuit> davec, it's easy enough to setup a high bandwidth relay network that miners will preferentially connect to
 83 2015-03-08 19:59:20 <phantomcircuit> but it does cost money
 84 2015-03-08 19:59:54 <sipa> there is also no specific reason why you'd need the p2p network to get transactions to miners
 85 2015-03-08 20:00:24 <phantomcircuit> sipa, sure there is, they're free
 86 2015-03-08 20:00:25 <phantomcircuit> :P
 87 2015-03-08 20:00:30 <sipa> it's one of the current functions of the network, but it's easily moved elsewhere
 88 2015-03-08 20:27:29 <phantomcircuit> running git master
 89 2015-03-08 20:27:32 <phantomcircuit> 00000000d87bf0b07ee39367a2de20803eb97011d236ee435874c393a5433b69 {u'message': u"Can't read block from disk", u'code': -32603}
 90 2015-03-08 20:27:41 <phantomcircuit> im thinking that's not good
 91 2015-03-08 20:29:10 <midnightmagic> Muis: You're interested in just using the raw bitcoin port/protocol to achieve a payment protocol-like result? So the fact it's a payment protocol isn't what is causing you problems, but instead just the fact there's another port? Or are you building something custom and the payment protocol spec is complex enough that duplicating it is a pain in the butt?
 92 2015-03-08 20:29:35 <Muis> the latter
 93 2015-03-08 20:30:05 <Muis> but I think i will look into < 0.8 code to see how the old style was implemented
 94 2015-03-08 20:31:31 <Muis> i want to do micro-payments using CHECKLOCKTIMEVERIFY, so chance is big that I need to enroll some custom scheme anyawy
 95 2015-03-08 20:31:42 <phantomcircuit> wumpus, 2015-03-08 20:25:57 ERROR: ReadBlockFromDisk: Deserialize or I/O error - ReadCompactSize(): size too large at CBlockDiskPos(nFile=0, nPos=3192018)
 96 2015-03-08 20:31:48 <phantomcircuit> gmaxwell, ^
 97 2015-03-08 20:31:54 <phantomcircuit> so there might be something broken here
 98 2015-03-08 20:41:52 <wumpus> phantomcircuit: have you seen https://github.com/bitcoin/bitcoin/issues/5850?
 99 2015-03-08 20:45:12 <wumpus> you could use the same tools if you want to investigate further
100 2015-03-08 22:41:17 <gmaxwell> kanzure: maybe it would be useful to make a list of reasons people are giving to not run bitcoind yourself and make sure that those which can be addressed are.
101 2015-03-08 22:41:19 <kanzure> gmaxwell: i think that swithcing to deterministic hardened bip32 keypool things would be a very useful strategy to argue that (in addition to all of the normal and sane reasons that everyone should use bitcoind) moving to a third party api is harmful, and additionally unnecessary.
102 2015-03-08 22:41:31 <kanzure> hoever, i suspect that brisque is right and they will just claim "it's infrastructure that we don't want to have to run" or something... or "walletnotify is too hard to configure", i dunno. there are always going to be lazy people.
103 2015-03-08 22:41:42 <gmaxwell> kanzure: some of them can't be addressed. like ^ except via education.
104 2015-03-08 22:41:59 <kanzure> do you think that there has not been enough education about that?
105 2015-03-08 22:42:05 <gmaxwell> Clearly not.
106 2015-03-08 22:42:55 <gmaxwell> actually you see the education yourself, from hearing from you several people (authorities in the eyes of the organizers) at the mit expo were telling people not to run it. Was there anyone saying that those people were wrong?
107 2015-03-08 22:43:08 <kanzure> nobody was saying those people were wrong
108 2015-03-08 22:43:19 <gmaxwell> WRT walletnotify, thats something that could be improved, e.g. RPC accessible ways to register callbacks.
109 2015-03-08 22:43:20 <kanzure> i was going to ask petertodd to make very loud complaints about it, but i forgot to ping him in time :(
110 2015-03-08 22:43:40 <kanzure> ooh rpc registerable walletnotify hooks. that is a neat idea.
111 2015-03-08 22:43:53 <gmaxwell> kanzure: right, so clearly thats an education fail, because there are plenty of people who are only reciving information from the channels that include only the hosted service echo chamber.
112 2015-03-08 22:44:16 <kanzure> so in this specific format- like at the conference- what would have been the thing we expected to happened?
113 2015-03-08 22:44:19 <kanzure> like who's job is it to call this out
114 2015-03-08 22:45:05 <gmaxwell> I don't know, one of the reasons that I am not a great fan of conferences is that they do not provide a socially acceptable mechenism for correction; except going all socractic with questions, ... which has limitations.
115 2015-03-08 22:45:08 <andytoshi> kanzure: ideally there'd be a lot of people who frequent this channel, bitcointalk, etc, and have a "weak wizard" understanding of bitcoin
116 2015-03-08 22:45:20 <andytoshi> and there'd be enough of them that there'd always be a couple somewhere
117 2015-03-08 22:45:45 <gmaxwell> It's no one's job to call it out, and specifically "calling it out" has considerable costs. Though there are approaches which don't require overt calling out.
118 2015-03-08 22:46:38 <kanzure> true, "calling it out" might be too strong of a phrase here. instead there could be some people talking about the disastrous implications and why it's broken, i suppose.
119 2015-03-08 22:47:27 <gmaxwell> It's interesting to me that multiple times in meetups and conferences I've seen members of the audience interrupt speakers to "correct" them with the (misleading IMO) point that BC.i webwallets don't allow the server access to the private keys (when the speaker says something generalically negative about bank-like websites). So I think this evidence that widespread understanding is sufficient to make
120 2015-03-08 22:47:33 <gmaxwell>  corrections happen.
121 2015-03-08 22:47:47 <gmaxwell> (I use that particular example just because I remember it because it's so horrifying. :) )
122 2015-03-08 22:49:15 <kanzure> gmaxwell: so on another note, i have been wondering about "deprecation strategies" or something.. like let's say you are one of these third parties providing this sort of api service... and you are a genuinely thoughtful and careful human being that wants to do good things and not totally screw everything up. perhaps we should be squawking about how they can transition to a sort of SPV infrastructure? what other option might there be
123 2015-03-08 22:50:40 <gmaxwell> We can squak that but I am doubtful that its useful. If people wanted to use SPV-security they'd already use it, it's not likely it's merely theoretical, there are two major implementations (bitcoinj+bitcoind and electrum).
124 2015-03-08 22:51:20 <gmaxwell> also, I think in the contexts we've been discussing I don't think even SPV is a reasonable answer.
125 2015-03-08 22:51:46 <gmaxwell> Bitcoin cannot survive if major commercial players cannot be bothered to run their own full verifing nodes.
126 2015-03-08 22:52:39 <gmaxwell> But whatever, let us not obess over the things we possibly cannot solve when there are so many things to do that we can solve and we know how to solve.
127 2015-03-08 22:53:23 <kanzure> yeah yeah, i guess i'm ust kicking up dirt in public to make sure people are aware that "don't use bitcoind" is a broken answer
128 2015-03-08 22:54:52 <kanzure> hmm maybe i'll go do that rpc webhook patch
129 2015-03-08 22:55:34 <kanzure> it will be a little annoying to have to implement each of add/remove/list
130 2015-03-08 22:56:03 <kanzure> was your recommendation for command calls, or specifically a sort of webhook?
131 2015-03-08 22:56:20 <kanzure> seems like webhooks would be safer than allowing anything like arbitrary shell access
132 2015-03-08 22:58:19 <gmaxwell> I have basically always disliked walletnotify (its a fork attack vector), I'm not the ideal person to ask for ideas on what people would like. One thing to do would be to look at some of these service offerings that have callbacks and do something similar.  We might want to include a small http client thats used for making callbacks as a seperate process so it can be strongly sandboxed.
133 2015-03-08 22:58:49 <kanzure> i disabled walletnotify the other day on some infrastructure of mine for those very reasons. (i walletnotify-bombed myself.)