1 2014-04-23 01:13:01 <arowser> arowser tinage
  2 2014-04-23 01:13:15 <arowser> arowser tiange
  3 2014-04-23 01:14:15 <arowser> arowser tiange
  4 2014-04-23 01:14:40 <fsx_> hey everyone
  5 2014-04-23 01:15:04 <fsx_> im looking forward to a possibility to load 20 wallets at the same time into bitcoind
  6 2014-04-23 01:15:14 <fsx_> any idea how i could archive this change?
  7 2014-04-23 01:15:26 <fsx_> or is there something like this done already?
  8 2014-04-23 01:26:11 <gmaxwell> fsx_: what are you actually trying to accomplish?
  9 2014-04-23 01:27:25 <fsx_> i want to get multiple wallets maintainable via rpc, without having to run bitcoind multiple times and spend diskspace and bandwidth multiple times
 10 2014-04-23 01:28:06 <gmaxwell> Where does the 20 come from? why not 200?
 11 2014-04-23 01:28:24 <fsx_> it was just an example, nothing specific
 12 2014-04-23 01:28:41 <gmaxwell> Codeshark had a set of multiwallet patches from a while back that he dropped working on. I'd like to see that work completed.
 13 2014-04-23 01:28:55 <Luke-Jr> +1
 14 2014-04-23 01:29:09 <fsx_> maybe there is a way in doing so
 15 2014-04-23 01:29:24 <fsx_> im a c++ developer but havent done anything with bitcoind yet
 16 2014-04-23 01:29:38 <fsx_> so maybe now i have a reason to do so :)
 17 2014-04-23 01:31:53 <warren> his patch allowed simultaneous use?
 18 2014-04-23 01:32:17 <fsx_> this multiwallet would help to archieve something like an bitcoin bank, even if i dont plan to do such things
 19 2014-04-23 01:34:38 <Luke-Jr> fsx_: a bitcoin bank shouldn't have multiple wallets
 20 2014-04-23 01:34:49 <Luke-Jr> not in that form anyhow
 21 2014-04-23 01:35:03 <fsx_> why not?
 22 2014-04-23 01:35:50 <Luke-Jr> because it's unnecessary and bad for security
 23 2014-04-23 01:36:11 <fsx_> not sure why this is bad for security
 24 2014-04-23 01:36:28 <fsx_> if the master wallet is stolen, the whole bank is bankrupt
 25 2014-04-23 01:36:36 <fsx_> nice security
 26 2014-04-23 01:36:37 <fsx_> :D
 27 2014-04-23 01:37:00 <Luke-Jr> …
 28 2014-04-23 01:37:18 <fsx_> the only bad thing about that is, that you cant see all transactions of the bank at once
 29 2014-04-23 01:37:19 <Luke-Jr> because you're *more likely* to have *all* the wallets stolen
 30 2014-04-23 01:37:59 <fsx_> but a bank has normally multiple people working with the money
 31 2014-04-23 01:38:16 <fsx_> and you dont want to give all of them access about all the money the bank owns
 32 2014-04-23 01:39:07 <Luke-Jr> best security practices for bitcoin mean that no one person has access to the money
 33 2014-04-23 01:39:46 <arowser> Hi, the issue "Build errors with GCC 4.7" https://github.com/bitcoin/bitcoin/issues/1116 have been fixed before 2011, but I still got that in master branch, My build env: ubuntu 12.04 gcc 4.7.3 boost 1.48
 34 2014-04-23 01:39:52 <fsx_> then i could give a f... about banks and avoid them..
 35 2014-04-23 01:40:37 <fsx_> whatever
 36 2014-04-23 01:40:50 <fsx_> thats not part of my question and doesnt need to be discussed
 37 2014-04-23 01:41:15 <fsx_> thanks for the answers and i guess i have to implement the multiwallet feature myself
 38 2014-04-23 01:42:42 <fsx_> good night everyone
 39 2014-04-23 02:21:28 <holmesvh> ii
 40 2014-04-23 05:12:25 <warren> gmaxwell: no, I left master running overnight, but the server went down today with hardware failure.  I'm hoping you, sipa or wumpus downloaded the tarball before it went down.
 41 2014-04-23 05:38:43 <arowser> There are some empty lines like https://github.com/bitcoin/bitcoin/blob/master/src/script.h#L244, https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp#L419, and more. Its seems unnecessary, if we should remove it?
 42 2014-04-23 05:53:34 <wumpus> arowser: don't bother; you'd help the project a lot more by focusing on fixing one of the zillion actual issues on github
 43 2014-04-23 06:22:46 <robonerd> hitler in argentina?
 44 2014-04-23 06:24:24 <wumpus> robonerd: not here please
 45 2014-04-23 06:36:38 <nell> has anyone here used armory?
 46 2014-04-23 06:36:45 <nell> it's buggy D:
 47 2014-04-23 06:37:04 <nell> when it comes to storing it on an offline liveusb
 48 2014-04-23 06:37:14 <nell> doesn't like ubuntu 12.04
 49 2014-04-23 06:37:18 <nell> 14.04*
 50 2014-04-23 06:43:40 <_andares> hi, is there any way to restrict the output that an input can be sent to?
 51 2014-04-23 06:48:42 <Emcy> what
 52 2014-04-23 06:50:46 <_andares> is there a way that the script of an input can determine how it will be spent; e.g. require that tx script match a certain pattern?
 53 2014-04-23 06:51:12 <gmaxwell> _andares: No. Not in Bitcoin today.
 54 2014-04-23 06:51:32 <gmaxwell> (That kind of functionality results in 'covenants' so its actually potentially a little ecosystem-risky)
 55 2014-04-23 06:51:41 <_andares> what is a covenant?
 56 2014-04-23 06:51:50 <gmaxwell> https://bitcointalk.org/index.php?topic=278122.0
 57 2014-04-23 06:52:39 <_andares> neat, thanks
 58 2014-04-23 07:31:45 <wumpus> <arowser> Hi, the issue "Build errors with GCC 4.7" https://github.com/bitcoin/bitcoin/issues/1116 have been fixed before 2011, but I still got that in master branch, My build env: ubuntu 12.04 gcc 4.7.3 boost 1.48  <- caused by a boost incompatiblity, I've seen it reported more times
 59 2014-04-23 08:21:24 <soquel> When I try "backupwallet" API call on my testnet bitcoind I get cryptic: error: {"code":-4,"message":"Error: Wallet backup failed!"}  How do I debug this?
 60 2014-04-23 08:25:31 <sipa> try passing a fully qualified backup file name
 61 2014-04-23 09:16:34 <warren> gmaxwell: hmm, a new master build from last night allowed it to recover testnet on the main chain
 62 2014-04-23 09:16:56 <warren> the build from early April completely failed
 63 2014-04-23 10:53:31 <warren> petertodd: "This is easily fixed too by voting to reallocate funds from any block without proper identification on hand."  eh?  So all miners need permission to receive a subsidy?
 64 2014-04-23 11:13:55 <lalala> hi! what third party merchant service do you use if you want to develop for mobile?
 65 2014-04-23 11:33:19 <petertodd> warren: remember that I was actually planning on writing up something very similar to Mike's post 22 days ago...
 66 2014-04-23 12:17:28 <chichov> what is the "Nulldata" transaction type used for?
 67 2014-04-23 12:18:25 <sipa> link?
 68 2014-04-23 12:18:40 <petertodd> chichov: oh, you mean op-return?
 69 2014-04-23 12:18:49 <chichov> petertodd: yep, that one
 70 2014-04-23 12:19:25 <petertodd> chichov: that's to do one of two things: spend all inputs to fees, or publish some data in a transaction
 71 2014-04-23 12:19:31 <sipa> op_return is an opcode that can be used in a transaction output to make it always fail
 72 2014-04-23 12:19:57 <petertodd> chichov: right, and since it is guaranteed to always fail, it can never be spent, and thus doesn't need to be added to the UTXO set - it can be pruned immediately
 73 2014-04-23 12:19:57 <sipa> that way, it doesn't end up in the utxo set (as it can be marked "spent" immediately, nobody can spend it anyway afterwards)
 74 2014-04-23 12:20:26 <chichov> was the utxo set the database of unspent transactions?
 75 2014-04-23 12:20:31 <petertodd> chichov: yup
 76 2014-04-23 12:20:50 <sipa> well, the utxo set is just the set of all unspent transaction outputs
 77 2014-04-23 12:20:59 <sipa> the reference client keeps this indeed in a database
 78 2014-04-23 12:21:21 <sipa> (soory for nitpick on abstract concept vs implementation)
 79 2014-04-23 12:21:37 <chichov> that's fine, I like to be precise
 80 2014-04-23 12:22:13 <chichov> I'm still struggling with the motivation
 81 2014-04-23 12:22:22 <sipa> for OP_RETURN?
 82 2014-04-23 12:22:38 <chichov> why would someone want to create a transaction spending all his money on fees?
 83 2014-04-23 12:22:57 <petertodd> chichov: to get rid of dust is one example
 84 2014-04-23 12:23:45 <chichov> I also see a template of OP_RETURN OP_SMALLDATA
 85 2014-04-23 12:24:04 <sipa> people seem to have an unsatiable need for putting data in the blockchain, and tend to do so via ways that result in it ending up in the UTXO set too (which is way more performance critical, and not limited in growth like the blockchain is)... op_return is like giving drug addicts a clean needle, so it causes just a bit less damage
 86 2014-04-23 12:24:08 <petertodd> chichov: right, the second form is if you want to publish data
 87 2014-04-23 12:24:17 <petertodd> chichov: which gets into a very complex topic...
 88 2014-04-23 12:24:52 <chichov> petertodd: that's a topic I'm extensively working on right now, so I'm open to anything you know
 89 2014-04-23 12:26:13 <sipa> chichov: what are you trying to do?
 90 2014-04-23 12:26:44 <chichov> sipa: to understand how data can be published in the bitcoin join without making it too messy
 91 2014-04-23 12:27:06 <petertodd> chichov: I'm a little biased for obvious reasons, but I recommend people trying to understand that stuff read this first: http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg03307.html
 92 2014-04-23 12:27:09 <sipa> imho, all data publishing in the blockchain is abuse, but that's a controversial opinion
 93 2014-04-23 12:27:11 <chichov> bitcoin chain* bleh
 94 2014-04-23 12:27:41 <sipa> chichov: what do you need it for?
 95 2014-04-23 12:28:05 <sipa> (for many cases where people want it, there are better alternatives)
 96 2014-04-23 12:29:12 <chichov> sipa: I'm working on a theoretical idea of using the blockchain for anti-censorship messaging
 97 2014-04-23 12:30:40 <chichov> I understand that this is a rather controversial topic to many bitcoin purists
 98 2014-04-23 12:30:44 <hearn> chichov: spending all money to fees has utility in various proof of sacrifice protocols, and other exotica
 99 2014-04-23 12:31:06 <hearn> chichov: people have tried it before. i think they are likely to be disappointed in the long run, especially once chain pruning starts
100 2014-04-23 12:31:35 <petertodd> chichov: that's a very good application actually, regardless of what purists think
101 2014-04-23 12:31:58 <chichov> petertodd: yea, it's the topic for my thesis
102 2014-04-23 12:32:15 <petertodd> chichov: basically when you think about it, bitcoin provides a way to spend money to provably publish a transaction to a well-defined audience - the hashing power who mine
103 2014-04-23 12:32:26 <chichov> petertodd: the idea is that there is strong censorship in many countries, e.g. china, where bitcoin is still allowed
104 2014-04-23 12:32:59 <petertodd> chichov: yup, and I think part of what makes people so uncomfortable about the fact that you can use the blockchain for publication is that it'll likely lead to censorship of bitcoin on that basis
105 2014-04-23 12:33:20 <chichov> petertodd: binding a message to bitcoin would force a government to work against bitcoin aswell
106 2014-04-23 12:33:34 <petertodd> chichov: indeed - it's an "all the eggs in one basket" scenario
107 2014-04-23 12:33:38 <petertodd> but this belongs in #bitcoin-wizards
108 2014-04-23 12:34:06 <chichov> alright, lets not diverge too far then
109 2014-04-23 12:34:22 <chichov> could you elaborate on chain pruning?
110 2014-04-23 12:34:40 <chichov> I haven't had the opportunity to read about it yet, do you have any resources by any chance?
111 2014-04-23 12:34:58 <petertodd> chichov: so basically the UTXO set is a subset of all possible blockchain data - modulo reorganizations you only need unspent transactions to fully verify going forward
112 2014-04-23 12:35:45 <chichov> exactly, else you'd go through the unnecessary work of constant look-ups through the complete chain
113 2014-04-23 12:36:00 <petertodd> ?
114 2014-04-23 12:36:29 <chichov> well, without a set of unspent transaction, how else would you verify a transaction?
115 2014-04-23 12:37:07 <chichov> for each transaction input you'd have to go through the blockchain and look for the transaction output in question
116 2014-04-23 12:37:38 <chichov> and it is my understanding that a simple set of unspent transaction is kept to keep it efficient
117 2014-04-23 12:37:40 <petertodd> ah, right, yeah, so right now all nodes have a UTXO data base, and *also* store all blocks, even though they don't use those blocks to actually verify new transactions
118 2014-04-23 12:38:32 <chichov> and where does pruning come into play?
119 2014-04-23 12:39:32 <petertodd> pruning is where the node throws away some or (almost) all of those blocks, which means it can't serve up prior blocks to other nodes
120 2014-04-23 12:40:06 <petertodd> problem is if you want to sync your node up in a trust free manner, you have to have all those blocks to validate the blockchain history (at least currently)
121 2014-04-23 12:41:05 <chichov> indeed, you have to compute the UTXO set bottom-up from the raw blockchain
122 2014-04-23 12:42:17 <chichov> so, in the coming future, nodes will start discarding most (or the complete?) blockchain?
123 2014-04-23 12:43:30 <petertodd> probably, but that does raise a *lot* of issues
124 2014-04-23 12:44:00 <petertodd> re: censorship what's interesting is that pruning doesn't change the usecase of using the blockchain to publish censored data - pruning can only happen after the data has been published
125 2014-04-23 12:45:16 <chichov> how will new nodes build up the UTXO set if nodes start discarding their blockchain?
126 2014-04-23 12:45:57 <petertodd> one option is they just trust someone else's copy is valid, other options are with things like UTXO/TXO commitments
127 2014-04-23 12:47:34 <chichov> do you have any resources on UTXO/TXO commitments?
128 2014-04-23 12:47:46 <chichov> I'm not aware of this construct and would like to read up on it
129 2014-04-23 12:49:03 <drizztbsd> hi, why is multibit the suggested wallet (https://bitcoin.org/en/choose-your-wallet) and not electrum?
130 2014-04-23 12:49:34 <drizztbsd> multibit has the retarted "feature" to do not allow zero-fee
131 2014-04-23 12:49:39 <petertodd> chichov: http://utxo.tumblr.com/
132 2014-04-23 12:51:01 <chichov> petertodd: one more question - I don't see OP_SMALLDATA anywhere in the Script-wiki description. Are there any other resources where I can read up on how to use it?
133 2014-04-23 12:51:39 <petertodd> chichov: here's some example tx's using it http://webbtc.com/scripts/op_return
134 2014-04-23 12:52:11 <petertodd> chichov: I can send you a quick timestamping app with it that I wrote for the python-bitcoinlib library
135 2014-04-23 12:52:41 <hearn> chichov: the idea is that if you’re stuffing data into blocks, eventually most nodes will throw it away and the ones that don’t might charge for it
136 2014-04-23 12:53:07 <chichov> petertodd: I'd gladly take a look
137 2014-04-23 12:53:11 <hearn> chichov: if you put data into the UTXO set then that doesn’t apply, but everyone is incentivised to not let you do that as it hurts bitcoin overall. if your outputs can be identified in any way, and proved to be unspendable, they might also be deleted
138 2014-04-23 12:53:19 <hearn> that’s what OP_RETURN is about. making it easy to prove that.
139 2014-04-23 12:54:22 <chichov> hearn: indeed, as sipa already said, it's a clean needle
140 2014-04-23 12:55:13 <petertodd> chichov: https://github.com/petertodd/python-bitcoinlib/blob/master/examples/timestamp-op-ret.py
141 2014-04-23 12:55:40 <petertodd> chichov: you familiar with mastercoin/counterparty, or the term "embedded consensus system"?
142 2014-04-23 12:55:48 <hearn> chichov: right. theoretically we could schedule an upgrade that deletes a bunch of ASCII art outputs and stuff from the UTXO set, as we know they can never be spent anyway. if you want to go even more extreme then outputs which are both spendable and storing data could also simply be deleted or reallocated. that’d be more controversial as it’d be effectively stealing peoples bitcoins, but if there’s a very strong consensus that sto
143 2014-04-23 12:55:49 <hearn> the UTXO set is bad for everyone, it’s imaginable
144 2014-04-23 12:56:09 <hearn> chichov: so these are the issues with storing data in bitcoin. if you want anti-censorship systems, you may wish to look at Tor insted
145 2014-04-23 12:56:34 <chichov> petertodd: I'm aware of how consensus is reached in bitcoin, but I haven't heard the term "embedded consensus system"
146 2014-04-23 12:57:13 <petertodd> chichov: right - read my "disentangling mining" paper I linked a few minutes ago
147 2014-04-23 12:57:42 <petertodd> chichov: also, note that censoring data in the blockchain is very difficult, perhaps not realisticly possible to implement
148 2014-04-23 12:58:41 <chichov> petertodd: how can I find that paper?
149 2014-04-23 12:59:13 <petertodd> http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg03307.html
150 2014-04-23 12:59:32 <chichov> hearn: that's why I'm trying to find a painless way. OP_RETURN seems promising
151 2014-04-23 12:59:54 <chichov> ah yes, this one
152 2014-04-23 13:00:32 <petertodd> chichov: on my todo list is actually to write up a general-purpose library that publishes data in the chain via all available methods with as strong censorship resistance as possible
153 2014-04-23 13:01:05 <hearn> chichov: it’s not exactly “painless”. nodes still have to store and process your transactions. it reduces the cost somewhat but it’s still not free. what problem exactly are you trying to solve? did you ever look at Freenet
154 2014-04-23 13:01:17 <hearn> bitcoin wasn’t actually designed for arbitrary file storage. things like Freenet are.
155 2014-04-23 13:01:22 <chichov> petertodd: this sounds like there is great overlap with my plans
156 2014-04-23 13:02:18 <chichov> hearn: it's not about filestorage, it's about publishing messages in countries with strong censorship
157 2014-04-23 13:02:23 <petertodd> chichov: quite likely! there's also a lot of interesting hybrid things you can do, where, for instance, you use a Freenet-like DHT in the general case, and fall back to the bitcoin blockchain for data publishing if anyone tries to censor the data
158 2014-04-23 13:02:55 <hearn> chichov: right, but a “message” can be quite long, right? or are videos not messages now :) freenet was designed to solve thi.
159 2014-04-23 13:02:57 <hearn> *this
160 2014-04-23 13:03:07 <GAit> hearn: but as long as there is no way to prevent that isn't it better to just assume someone will do it and work against it by pruning? and maybe build some WOT inside SPV?
161 2014-04-23 13:03:09 <chichov> petertodd: I believe we'll have long discussions on that very soon
162 2014-04-23 13:03:10 <hearn> chichov: bear in mind, bitcoin is very easy for countries to ban entirely. so i’m not sure it’s quite what you are looking for.
163 2014-04-23 13:03:57 <chichov> hearn: I'll keep your advice in mind and take a look at Freenode as well
164 2014-04-23 13:04:00 <petertodd> chichov: pure publishing is a particularly good use-case for that kind of hybrid system as usually delaying when things are actually succesfully published doesn't do much harm - quite different than financial applications like mastercoin
165 2014-04-23 13:04:05 <hearn> freenet :) freenode is this irc network
166 2014-04-23 13:04:24 <chichov> my bad, freenet
167 2014-04-23 13:04:25 <hearn> freenet is an old project. accessing “freesites” was very slow because of how it worked, and they couldn’t be interactive. but it tried hard to be censorship proof.
168 2014-04-23 13:04:41 <hearn> of course it got a lot of flak in the day for hosting child porn sites etc. so you have to be ready for that.
169 2014-04-23 13:04:45 <petertodd> chichov: keep in mind that non-proof-of-publication tech like Freenet is really easy to sybil attack, and what's worse, you're users will never know. The #1 thing bitcoin does is makes a jam free network where you can *detect* the fact that you are being jammed.
170 2014-04-23 13:05:03 <chichov> hearn: in principal, the messages are not supposed to be videos
171 2014-04-23 13:05:05 <petertodd> chichov: Freenet and similar tech just can't do that
172 2014-04-23 13:05:23 <GAit> petertodd: interesting.
173 2014-04-23 13:05:44 <hearn> he’s talking about things like mastercoin.
174 2014-04-23 13:06:04 <petertodd> chichov: also, re: scalability, see http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04388.html
175 2014-04-23 13:06:48 <chichov> I very much appreciate this discussion, but I have a doctor's appointment shortly and have to leave
176 2014-04-23 13:07:07 <hearn> good luck!
177 2014-04-23 13:07:07 <petertodd> chichov: np, looking forward to chatting
178 2014-04-23 13:07:24 <chichov> petertodd: I'll come back to you shortly!
179 2014-04-23 13:07:46 <chichov> and thanks to you too hearn for your input
180 2014-04-23 13:08:06 <chichov> see you soon
181 2014-04-23 13:08:24 <petertodd> GAit: amiller has a great extension to the idea that makes the PoW function prove the miners actually have some known data, and then uses forward error correcting codes to make censorship of specific parts of that data impractical
182 2014-04-23 13:08:26 <GAit> hearn: you can show child porn in any piece of data with a onetime pad :)
183 2014-04-23 13:10:01 <GAit> petertodd: I'll have to read it up
184 2014-04-23 13:11:28 <GAit> what i meant with the one time pad remark is that it could be already embedded in the blockchain, perhaps encrypted
185 2014-04-23 13:11:37 <GAit> or encoded in a weird way
186 2014-04-23 13:12:06 <petertodd> GAit: indeed, note how Mastercoin coerces it's data to look like valid pubkeys
187 2014-04-23 13:13:53 <Luke-Jr> sounds like a bad idea
188 2014-04-23 13:14:23 <petertodd> Luke-Jr: don't forget to look at things from your opponents perspective
189 2014-04-23 13:14:48 <GAit> petertodd: that's a great way to improve i agree
190 2014-04-23 13:14:48 <Luke-Jr> petertodd: I don't really care what attackers and spammers think
191 2014-04-23 13:14:55 <Luke-Jr> beyond what is necessary to stop them
192 2014-04-23 13:18:28 <petertodd> GAit: yeah, right now all MSC tx's include a dust payment to the exodus address too, making them easy to detect, but that can be easily changed in the future to something that a bloom/prefix filter matches probabalistically
193 2014-04-23 13:18:50 <petertodd> GAit: once that's done blocking it becomes a game of colatteral damage
194 2014-04-23 13:19:05 <GAit> as you'd ban normal users too
195 2014-04-23 13:20:12 <Luke-Jr> GAit: anti-censorship is not a goal of Bitcoin, and is pretty much incompatible with it on a fundamental level
196 2014-04-23 13:20:55 <petertodd> GAit: exactly. of course you can just try having a centralized/semi-centralized blacklist provider who watches the state of the mastercoin chain and gives miners transactions to blacklist, which gets really interesting with a system like coinbase reallocation/coinbase blacklists that essentially let hashing power vote on what blocks/transactions they want to blacklist
197 2014-04-23 13:21:33 <petertodd> used against transactions it's really ugly for how it incentivizes hashing power to quit small pools and join the big pools with the best-maintained blacklists
198 2014-04-23 13:24:30 <petertodd> Luke-Jr: proof-of-publication is an excellent anti-censorship tool for its ability to reliably detect whether or not censorship is happening and respond. secondly forcing an attacker to censor a whole range of applications rather than selective ones is often advantageous
199 2014-04-23 13:47:30 <Luke-Jr> petertodd: proof-of-publication is not Bitcoin
200 2014-04-23 13:58:52 <GAit> is there any advantage in using a satellite bitcoin node compared to using a couple of vpns/vps to have better network visibility ?
201 2014-04-23 13:59:39 <GAit> it's a great feat and publicity for bitcoin but not more impressive than internet over sat from a tech point of view
202 2014-04-23 14:05:09 <octocodercat> Hi, I'm trying to break down a 'version' message that I got from a local copy of bitcoin-qt as a reference, and I'm having some issues
203 2014-04-23 14:05:27 <octocodercat> "b6 10" Would be a var_int with a value of 16, correct>
204 2014-04-23 14:05:29 <octocodercat> *?
205 2014-04-23 14:07:23 <octocodercat> There are six bytes between the nonce and the var_int containing the length of the user agent that seem unaccounted for :/
206 2014-04-23 14:07:43 <octocodercat> They are b7 5a b9 7f 6e 0f 36
207 2014-04-23 14:24:36 <octocodercat> Am I completely off with where I think the var_int is?
208 2014-04-23 14:29:05 <btiefert> GAit, created a one-time pad that combines with past published data does not create a proof of publish, anyway, for the very reason you stated earlier.
209 2014-04-23 14:29:47 <GAit> i know that, tell that to the public when some stupid media, perhaps the same one that found Dorian comes out with it
210 2014-04-23 14:30:02 <btiefert> As a general rule, I try not to waste time stopping stupid.
211 2014-04-23 14:30:26 <GAit> sounds like good policy
212 2014-04-23 14:32:02 <octocodercat> b7 5a b9 7f 6e 0f 36 b6 10 Is this whole thing a var_int?
213 2014-04-23 14:32:26 <octocodercat> Either it's a var_int with the value of 16, or I am horribly confused
214 2014-04-23 14:44:46 <ThickAsThieves> i'd like to put a nose in my nose to prevent me from having to smell things i dont like
215 2014-04-23 14:45:32 <GAit> proxy nose
216 2014-04-23 14:46:45 <ThickAsThieves> I was told hearn could help me with this
217 2014-04-23 15:11:10 <michagogo> cloud|hearn: around?
218 2014-04-23 15:11:13 <hearn> hi
219 2014-04-23 15:11:20 <hearn> for a little while. need to head out for a bit soon
220 2014-04-23 15:11:36 <michagogo> cloud|> The idea of discouraging blocks that perform Finney attacks by having honest > miners refuse to build on them has been proposed. But it has a couple of > problems:
221 2014-04-23 15:11:46 <michagogo> cloud|> Miners who want to vote "no" on a block take a big risk, they could be on > the losing side of the fork and end up wasting their work.
222 2014-04-23 15:11:52 <michagogo> cloud|Arguably, that's how it should be.
223 2014-04-23 15:12:39 <hearn> why
224 2014-04-23 15:12:42 <michagogo> cloud|Something like voting to seize $,,(calc [tlast] * 25) from someone should be expensive
225 2014-04-23 15:12:44 <gribble> 12183.25
226 2014-04-23 15:12:53 <hearn> why
227 2014-04-23 15:13:06 <michagogo> cloud|...
228 2014-04-23 15:13:28 <hearn> do you think people should be charged $10k to vote in regular elections? you can’t simply assert that voting should be expensive and assume that’s obvious
229 2014-04-23 15:13:37 <michagogo> cloud|Uh?
230 2014-04-23 15:13:57 <GAit> wouldn't that proposal cause miner mafia?
231 2014-04-23 15:14:07 <michagogo> cloud|Voting to *take $10k away from someone* should be expensive
232 2014-04-23 15:14:53 <hearn> you’re simply repeating yourself. justify it.
233 2014-04-23 15:15:05 <hearn> remember our goal here - stop double spending as effectively as possible
234 2014-04-23 15:15:22 <hearn> forcing miner majorities to perform giant reorgs stops double spends, but it isn’t as effective as possible
235 2014-04-23 15:16:15 <michagogo> cloud|Yes, but giving the majority of miners the ability to arbitrarily decide to take away someone's $10k with no cost or risk to do so?
236 2014-04-23 15:16:24 <GAit> imho a double spend is less important for the greater good than the solution if it involves some corruptable mechanism to do reorgs
237 2014-04-23 15:17:06 <hearn> michagogo|cloud: again, you are just repeating yourself endlessly. justify your position. don’t just rephrase “but whaaa” over and over and call it an argument ;)
238 2014-04-23 15:18:14 <michagogo> cloud|hearn: If a couple big miners decide they don't like catholics, they can decide to start setting the "vote to seize" flag for all of Eligius's blocks
239 2014-04-23 15:18:46 <michagogo> cloud|Yes, this is something that could be done right now by rejecting it
240 2014-04-23 15:18:51 <hearn> they could also re-org them out. if they know they have a majority via some other mechanism, why not? the solution to that is to have lots of miners, not stick our head in the ground and pretend it can’t happen. remember that a successful 51% attack is “free” for the attackers
241 2014-04-23 15:19:00 <michagogo> cloud|But it's risky
242 2014-04-23 15:19:07 <hearn> if you’re worried about abusive miner cartels, work on p2pool or some other decentralisation project
243 2014-04-23 15:19:17 <michagogo> cloud|Yes, it's "free" for the attackers, iff it's successful
244 2014-04-23 15:19:32 <michagogo> cloud|As long as they don't get unlucky, they can reorg away the block
245 2014-04-23 15:19:53 <michagogo> cloud|But if they do, they've lost a lot of money
246 2014-04-23 15:20:13 <hearn> if they do what? if they do reorg their target block away they lost nothing. they get all the fees and rewards as per normal
247 2014-04-23 15:20:14 <michagogo> cloud|This would make it completely free for them no matter what
248 2014-04-23 15:20:23 <michagogo> cloud|If they do get unlucky
249 2014-04-23 15:20:32 <hearn> if they have a majority they can keep mining and eventually succeed
250 2014-04-23 15:21:06 <hearn> the more they have the faster that happens, but if they dominate the network then eventually they will overtake it barring some astonishingly unlikely run of bad luck that means their equipment all dies before they win, or something
251 2014-04-23 15:21:11 <michagogo> cloud|...while putting even more on the line with each block, in the event that they fail
252 2014-04-23 15:21:21 <hearn> the solution is the same as always - don’t have abusive miner cartels.
253 2014-04-23 15:21:24 <michagogo> cloud|If they're a narrow majority
254 2014-04-23 15:22:05 <michagogo> cloud|*maybe* if you require a supermajority
255 2014-04-23 15:22:21 <GAit> saying we should not have drug cartels (or miners) is not enough to stop them from happening. I'm afraid of the incentives and the barrier to entry for small miners.
256 2014-04-23 15:22:43 <michagogo> cloud|anyway, g2g -- my grandfather's leaving tonight and we're going out to dinner
257 2014-04-23 15:22:46 <hearn> enjoy!
258 2014-04-23 15:22:51 <michagogo> cloud|thanks
259 2014-04-23 15:22:58 <hearn> actually i have to go too
260 2014-04-23 15:36:39 <ThickAsThieves> <hearn> remember our goal here - stop double spending as effectively as possible /// a goal already pondered when designing bitcoin, no?
261 2014-04-23 15:38:15 <AndyOfiesh> I'm contructing an educational bitcoin treasure hunt, and I'm wondering if I gave you the private keys for an m-of-n P2SH/MultiSig txout how hard would it be to spend the txout with just bitcoind?
262 2014-04-23 15:38:28 <AndyOfiesh> How high can I go with m and n, before it doesn't work?
263 2014-04-23 15:38:59 <shesek> AndyOfiesh, if you're using p2sh, its up to 15 total public keys (assuming they're compressed)
264 2014-04-23 15:39:14 <shesek> and spending with bitcoind's jsonrpc api is not that hard, but requires some understanding
265 2014-04-23 15:41:46 <AndyOfiesh> I'm trying to  "require some understanding" while limiting the amount of PITA
266 2014-04-23 16:08:57 <maaku> hearn: out-of-band consensus rules. seriously?
267 2014-04-23 16:14:42 <hearn> maaku: seriously
268 2014-04-23 16:14:49 <hearn> (or not, depending on how you define “band")
269 2014-04-23 16:15:23 <maaku> if the block chain no longer defines what is valid, it's out of band
270 2014-04-23 16:16:01 <hearn> the block chain does define what is valid
271 2014-04-23 16:16:05 <hearn> where did i suggest otherwise?
272 2014-04-23 16:17:11 <maaku> hearn: when you suggested that looking at the block chain history was not sufficient to determine if the next block is valid
273 2014-04-23 16:17:19 <hearn> i did not suggest that
274 2014-04-23 16:17:39 <maaku> if the coinbase amounts are adjusted downward, that invalidates transactions which spend their full amount
275 2014-04-23 16:18:02 <maaku> have you considered this mechanism can be used to extend control to user transactions, by means of coinbase censorship
276 2014-04-23 16:19:00 <maaku> whatever this out of band mechnism is had better be damn secure and perfectly incentive compatible
277 2014-04-23 16:19:07 <petertodd> maaku: +1
278 2014-04-23 16:19:30 <petertodd> maaku: better yet, just make it a soft-forked share-chain like p2pool has, but with rules to enforce it
279 2014-04-23 16:20:54 <hearn> maaku: did you read my email? i said specifically quorum had to be reached within the maturity period (100 blocks currently)
280 2014-04-23 16:21:08 <hearn> maaku: so your criticism is incorrect. there is no chance of invalidating transactions.
281 2014-04-23 16:21:14 <petertodd> Luke-Jr: regardless of whether or not proof-of-publication was meant to be something Bitcoin would provide, the fact is that it does provide that mechanism
282 2014-04-23 16:21:48 <petertodd> hearn: obviously you use the coinbase censorship to threaten other miners into adopting your chosen blacklists
283 2014-04-23 16:22:08 <maaku> hearn: uh, no. that doesn't address the issue at all. by design you have to pay attention to and respect this out-of-band voting mechanism
284 2014-04-23 16:22:34 <hearn> the idea is the votes are in the coinbase scriptSigs, same as existing votes. perhaps i did not make that clear.
285 2014-04-23 16:22:38 <maaku> this is a forking vs policy distinction
286 2014-04-23 16:22:54 <hearn> so it’d be a network rule. whether a coinbase survives into maturity could be calculated entirely from chain data.
287 2014-04-23 16:25:15 <petertodd> which is irrelevant to the problem of how it's a network rule designed to make it much easier for a slim majority to censor a minority
288 2014-04-23 16:26:32 <hearn> you should take that argument up with satoshi
289 2014-04-23 16:27:01 <petertodd> I about bitcoin the system, not satoshi the figurehead
290 2014-04-23 16:27:08 <petertodd> *I care about
291 2014-04-23 16:27:21 <hearn> figurehead? nice
292 2014-04-23 16:27:58 <petertodd> stick to discussion about software and how it works
293 2014-04-23 16:28:16 <hearn> my point is that bitcoin has always worked that way. if you don’t like it, don’t get upset about it now.
294 2014-04-23 16:28:44 <petertodd> no, bitcoin has previously worked in the way where attempting to blacklist a block was expensive, and required a reorg, you want to change that
295 2014-04-23 16:29:06 <petertodd> it also previously worked in a way where double-spending an unconfirmed transaction was actually pretty easy, as I demonstrated
296 2014-04-23 16:41:43 <AndyOfiesh> I have been playing with 2-of-3 multisig example TwoOfThree.sh on github, how hard would it be to do the same thing but with P2SH using bitcoind?
297 2014-04-23 17:13:36 <bazil5> Why is everyone talking about dark wallet? what can it do you can't do already?
298 2014-04-23 17:13:37 <michagogo> cloud|AndyOfiesh: link to that script?
299 2014-04-23 17:14:17 <michagogo> cloud|BTW, I'm told my bitcoind segfaulted: 17:31:37 <nyuszika7h> .tell michagogo|cloud [1360663.225120] bitcoind[20405]: segfault at 4 ip 00007f462d40a9b6 sp 00007f461affc080 error 4 in bitcoind[7f462d36c000+45b000]
300 2014-04-23 17:14:37 <michagogo> cloud|Is this something to worry about?
301 2014-04-23 17:22:16 <gavinandresen_> michagogo|cloud: if it segfaulted because it ran out of memory: no.  Any other reason: yes.
302 2014-04-23 17:22:48 <michagogo> cloud|gavinandresen_: Is there an easy way to tell?
303 2014-04-23 17:23:15 <AndyOfiesh> michagogo see https://gist.github.com/gavinandresen/3966071
304 2014-04-23 17:23:25 <michagogo> cloud|Nothing in the log, if it helps -- 2014-04-23 14:30:48 connect() to 83.150.81.129:18333 failed after select(): Connection refused
305 2014-04-23 17:23:30 <michagogo> cloud|then the bunch of empty space
306 2014-04-23 17:23:38 <michagogo> cloud|And then 2014-04-23 14:57:33 Bitcoin version v0.9.0rc2-183-g513412f-dirty-beta (2014-04-05 13:26:16 +0200)
307 2014-04-23 17:23:54 <gavinandresen_> michagogo|cloud: how much memory on your bitcoind machine?
308 2014-04-23 17:24:28 <michagogo> cloud|One sec, I'll find out
309 2014-04-23 17:25:01 <gavinandresen_> michagogo|cloud: … and I should have said "run out of memory" is a 'maybe worry' -- there are fill-up-memory-DoS attacks that we worry about.
310 2014-04-23 17:25:02 <michagogo> cloud|6 GB
311 2014-04-23 17:25:26 <gavinandresen_> 6GB should be plenty.
312 2014-04-23 17:25:57 <michagogo> cloud|Might that happen if it's killed by the system for hitting a limit, or would that look like something else?
313 2014-04-23 17:26:54 <michagogo> cloud|(this is a testnet node running on a shared machine where I have a shell, with the permission of the admins)
314 2014-04-23 17:27:18 <gavinandresen_> michagogo|cloud: dunno-- you running on Linux?  Any linux experts here know if kill-a-process always writes to syslog?
315 2014-04-23 17:27:36 <michagogo> cloud|gavinandresen_: yep, debian iirc
316 2014-04-23 17:27:58 <michagogo> cloud|AndyOfiesh: erm, that gist does use p2sh
317 2014-04-23 17:28:25 <gavinandresen_> michagogo|cloud: if you can compile yourself --enable-debug and then run under gdb and get a backtrace if it crashes again that'd be helpful.
318 2014-04-23 17:29:33 <michagogo> cloud|gavinandresen_: I updated it to v0.9.1. If the crash happens again anytime soon I'll do that
319 2014-04-23 17:30:28 <michagogo> cloud|(It had been running for a long time)
320 2014-04-23 17:35:42 <michagogo> cloud|https://www.irccloud.com/pastebin/hdAAAyGV
321 2014-04-23 17:36:30 <michagogo> cloud|
ACTION afk for a bit

322 2014-04-23 17:37:00 <hearn> gavinandresen: one thing i’d like to do at some point is run bitcoind under a supervisor process (i.e. that forks at startup) which can restart the server if it crashes or goes over a memory limit
323 2014-04-23 17:37:22 <hearn> gavinandresen: right now if anyone finds a crash bug we’re hosed. if the node immediately restarts upon crashing, it converts it into a much less severe DoS
324 2014-04-23 17:38:06 <gmaxwell> hearn: but then also makes a "gives you a local code execution 0.1% of the time, crashes 99.9% of the time" much more severe.
325 2014-04-23 17:38:41 <hearn> on platforms that support it the supervisor could sandbox the child, i’d hope
326 2014-04-23 17:38:47 <hearn> though that ups the complexity a fair bit
327 2014-04-23 17:39:20 <petertodd> gmaxwell: note too how DDoS attacks can be made much more severe if affected nodes recover rather than crash and stop attacking other nodes
328 2014-04-23 17:39:33 <gmaxwell> petertodd: I'm not convinced by that.
329 2014-04-23 17:39:40 <gmaxwell> You also get things like "corrupts memory, mostly crashes, sometimes generates unrecoverable public keys" going undetected.
330 2014-04-23 17:40:05 <gmaxwell> (which is not just a theoretical problem)
331 2014-04-23 17:40:06 <petertodd> gmaxwell: wait, I think we're in agreement here :)
332 2014-04-23 17:40:49 <gmaxwell> petertodd: I think the space of transitive dos attacks that crash witless participating nodes is small enough that I wouldn't rate it as a high priority.
333 2014-04-23 17:41:53 <petertodd> gmaxwell: sure, not compared to local code exec, but it is something we've seen in the past
334 2014-04-23 17:42:52 <gmaxwell> petertodd: I'm not sure where we've seen any that relayed and then crashed. e.g. where coming back up would be bad.  (though the AT&T network wide crash in the early 90s would be an example of that kind of behavior)
335 2014-04-23 17:43:23 <hearn> i was thinking if there were 3 crashes in quick succession it’d stay down, to avoid infinite crash loops
336 2014-04-23 17:43:31 <petertodd> gmaxwell: mempool flood attacks work that way - that we don't reload mempools after crashes is especially useful there
337 2014-04-23 17:43:33 <hearn> this stuff is hardly rocket science though. all servers have to deal with this
338 2014-04-23 17:43:41 <petertodd> gmaxwell: that I've personally seen in experiments
339 2014-04-23 17:44:59 <gmaxwell> hearn: then I think its pretty easy to just keep everything down, just do your crash three times and they all stay down.
340 2014-04-23 17:45:45 <hearn> right, during startup is different to post-listening
341 2014-04-23 17:45:53 <hearn> also there can be crashes that aren’t DoS attacks
342 2014-04-23 17:49:25 <petertodd> if they're not attacks, they're probably randomly distributed enough that it doesn't matter all that much for the health of the network
343 2014-04-23 17:59:53 <lechuga_> probably a dumb question but why is SetBestChain called here only when height % 144 == 0?
344 2014-04-23 17:59:56 <lechuga_> http://pastebin.com/Ph674J1c
345 2014-04-23 18:05:35 <AndyOfiesh> michagogo I see now that it does use P2SH.  Now I'm wondering...Is it possible to not use P2SH? It seems that createmultisig always returns a P2SH address. Correct?
346 2014-04-23 18:06:22 <michagogo> cloud|AndyOfiesh: yep
347 2014-04-23 18:06:45 <michagogo> cloud|Since there's no such thing as a non-p2sh multisig address
348 2014-04-23 18:07:27 <michagogo> cloud|Afaik bitcoind doesn't do non-p2sh multisig
349 2014-04-23 18:08:03 <AndyOfiesh> Ah, yes, so using multisig without P2SH means you are sending bitcoin to the actual multisig script so that whole step would be skipped. Makes sense now.
350 2014-04-23 18:08:49 <michagogo> cloud|Though it might recognize them as part of the wallet if it has all the keys, and it might sign them in signrawtransaction, but if it does, I'm unaware.
351 2014-04-23 18:10:57 <baldur> my debug log is showing return error("Non-canonical public key: compressed nor uncompressed"), is this on my side or something from another node?
352 2014-04-23 18:13:06 <michagogo> cloud|baldur: did you do anything?
353 2014-04-23 18:13:15 <michagogo> cloud|If not, probably from another node
354 2014-04-23 18:13:49 <michagogo> cloud|That sounds like a tx IsStandard fail or something
355 2014-04-23 18:28:34 <baldur> thanks, found http://sourceforge.net/p/bitcoin/mailman/message/30725525/ which is discussing making signatures strictly DER (as an initial move away from OpenSSL?)
356 2014-04-23 18:38:25 <hearn> baldur: as a way to lock down various forms of malleability
357 2014-04-23 18:45:20 <GAit> is anyone interested in a techy pint on the 14th before the expo?
358 2014-04-23 18:45:43 <GAit> if you manage to get past the coffee shops, that is :D
359 2014-04-23 18:48:50 <hearn> i won’t be there until the 15th
360 2014-04-23 18:48:54 <hearn> but definitely interested in beers!
361 2014-04-23 18:49:45 <GAit> hearn:  we may disagree on some stuff but i'm not going to disagree on this
362 2014-04-23 18:51:40 <GAit> i have  a feeling this can't be organized before hand, it wiil just be people pouring after the expo into bars and pubs
363 2014-04-23 19:03:06 <sipa> GAit: i'll be there the 14th
364 2014-04-23 19:03:30 <GAit> sipa: dangerous :D
365 2014-04-23 19:05:19 <kenrestivo> i'm trying to create a link where people can pay via bitcoin. i'm using the BIP for bitcoin:1XXXXX url's, but the problem is what if they don't have a program installed? i'd like to as a backup link them to a website somewhere instead
366 2014-04-23 19:05:50 <kenrestivo> this is for android in particular, and i can try/catch for the case where there's no wallet app installed.
367 2014-04-23 19:06:04 <GAit> kenrestivo: as far as I know you can't even check if there's already a bitcoin: uri handler in a browser
368 2014-04-23 19:06:15 <GAit> which makes for terrible UI's
369 2014-04-23 19:06:24 <kenrestivo> right, but i'm not in a browser, i'm in an Intent
370 2014-04-23 19:06:26 <michagogo> cloud|kenrestivo: what do you expect to happen if there isn't a handler?
371 2014-04-23 19:06:46 <GAit> oh android, sorry i don't know enough to say
372 2014-04-23 19:06:58 <kenrestivo> i'd like to link them to a website, i.e. coinbase or similar, where they can open an account or otherwise transfer money via some other means (handwave here) to bitcoin
373 2014-04-23 19:08:19 <kenrestivo> so, imaginging something totally pulled-from-ass, if there were a http://someservice.com/pay/1XXXXXXXXX service, which'd helpfully give people the opporunity to create their own wallet
374 2014-04-23 19:09:20 <kenrestivo> otherwise, sadly, people will click on these bitcoin:1xxxx links, get a message that there's no app, and then they go away, and say, bleh, i don't know what to do, no way to pay, too bad
375 2014-04-23 19:10:06 <kenrestivo> apologies if what i'm asking for here is still a few years out in bitcoin's ecosystem development
376 2014-04-23 19:11:37 <kenrestivo> coinbase has something *almost* there, i.e. https://coinbase.com/api/doc/1.0/buttons/create.html
377 2014-04-23 19:13:29 <GAit> kenrestivo: is there no way in android to check if there's an installed handler for an intent? there must be. Then you can see if the list returned is zero just offer some new wallet thing and if not just allow the actual handler to be called.
378 2014-04-23 19:14:14 <GAit> kenrestivo: what about queryIntentActivities
379 2014-04-23 19:14:32 <kenrestivo> right, the "some new wallet thing" is the missing peice: i'd like to basically have an url that will start them down the road to opening their own wallet somewhere
380 2014-04-23 19:14:59 <kenrestivo> i know how to check to see if there's a handler. that part's easy (try/catch, in the crudest form).
381 2014-04-23 19:15:07 <GAit> just send them to /en/choose-your-wallet
382 2014-04-23 19:15:27 <kenrestivo> with the address already filled in, much like https://coinbase.com/checkouts/4d4b84bbad4508b64b61d372ea394dad
383 2014-04-23 19:16:19 <kenrestivo> anyways, i'm getting the impression that no such thing exists, so thanks, i'll just leave it as it is
384 2014-04-23 19:16:29 <GAit> i fear soon someone will say this is not the appropriate channel for the discussion. Anyway, perhaps you can wait until thei 'webview' is closed and then ask the user if they are ready to repeat the previous action (assuming the new wallet just installed a handler for the bitcoin uri:)
385 2014-04-23 19:19:24 <kenrestivo> i'm not in a webview, but i guess as a hack i could open one
386 2014-04-23 19:19:43 <kenrestivo> and then just use the coinbase javascript button stuff.
387 2014-04-23 19:20:07 <GAit> kenrestivo: in some ways the user will have to open the wallet. If you get a callback when they are done you may have a chance to continue your previous process which i believe is the entire reason of this exercise
388 2014-04-23 19:20:28 <kenrestivo> it's easier than that, it's just a donation, so i don't even care about the callback
389 2014-04-23 19:20:56 <kenrestivo> just trying to make it as frictionless as possible, since if it's a hassle people will just not bother
390 2014-04-23 19:21:25 <GAit> callback or stack card, again, i don't know android too well but what i meant is continue what you intended to do in first palce
391 2014-04-23 19:27:46 <hearn> kenrestivo: andreas’ app has a small integration library that handles installation of a wallet app for you
392 2014-04-23 19:27:57 <hearn> kenrestivo: it automatically checks if an intent handler is available and opens the market if not
393 2014-04-23 19:28:19 <hearn> kenrestivo: https://code.google.com/p/bitcoin-wallet/wiki/InAppPayments
394 2014-04-23 19:29:18 <GAit> hearn: interesting.
395 2014-04-23 19:29:40 <hearn> kenrestivo: ideally this sort of thing will appear in the new dev guide at some oint
396 2014-04-23 19:30:22 <kenrestivo> hearn: thanks!
397 2014-04-23 19:34:15 <kenrestivo> oh, i see, he just redirects to "market://details?id=de.schildbach.wallet" if it's not there
398 2014-04-23 19:34:25 <hearn> yeah
399 2014-04-23 19:34:42 <hearn> i dunno if the play store supports “show me every app that handles intent X”. i had a feeling it could actually but it might be poorly documented
400 2014-04-23 19:37:00 <hearn> hmmmm
401 2014-04-23 19:37:05 <hearn> you can do a search for “file:pdf"
402 2014-04-23 19:37:10 <hearn> i guess that’s a kind of intent filter
403 2014-04-23 19:39:56 <kenrestivo> supports bip70 too, if i'm reading this right. nice
404 2014-04-23 19:40:48 <kenrestivo> ok, for now i'm going with this as a first approximation then. as things evolve i can always update it later.
405 2014-04-23 19:41:17 <hearn> cool