1 2014-06-20 01:30:19 <G_Qu> Good evening everyone.
  2 2014-06-20 03:04:02 <amincd> As the blockchain gets bigger, more and more people will opt for a thin client, but some Bitcoin users need bitcoind commands for their automated services. Is the full client the only way to use these commands, or is there an SPV client out, or being developed, with similar functionality?
  3 2014-06-20 03:06:22 <mr_burdell> amincd: sx and electrum can both do most of the functionality
  4 2014-06-20 03:06:34 <mr_burdell> not sure if sx does full spv verification
  5 2014-06-20 03:07:22 <amincd> mr_burdell: thanks. Does electrum use spv? From what I understand, it's not as decentralized as Multibit
  6 2014-06-20 03:07:58 <justanotheruser> amincd: it uses SPV but gets block headers from a set of authorities
  7 2014-06-20 03:08:46 <mr_burdell> well, it needs the servers to get UTXO/address balances
  8 2014-06-20 03:08:53 <mr_burdell> without scanning the blockchain like multibit
  9 2014-06-20 03:09:16 <mr_burdell> but it does full spv verification of the data
 10 2014-06-20 03:10:29 <amincd> I thought multibit requested that data from full nodes, who then scan the blockchain
 11 2014-06-20 05:25:55 <dabura667> Re: BIP32 vulnerability where M/ + m/m(x) can be joined to create m/... Would someone who held m/m(1)/m(x) be able to collude with someone who held M/ to calculate m/ ? or could they only calculate m/m(1) (by person with M/ calculating M/M(1)/ then colluding) ?
 12 2014-06-20 05:28:32 <jcorgan> not sure i parsed that correctly, but pretty the the answer is the last one
 13 2014-06-20 05:28:37 <jcorgan> pretty sure
 14 2014-06-20 09:06:54 <sipa> cfields: you can safely call init twice (though not simultaneously). for now, not going to worry too much about multiple in-process users i think; when it's actually production ready with a stable api that can still be done
 15 2014-06-20 09:10:55 <shesek> Does anyone know if bc.i's wallet allows sending to p2sh addresses yet?
 16 2014-06-20 09:37:15 <GAit> I think there's something missing from the bip draft about instant confirmation via BIP70 protobuf ext.
 17 2014-06-20 09:40:13 <GAit> there may be instances in which you rather receive an instant confirmation or nothing, i.e. waiting is not an option - how do you prevent people with BIP70 support but without the extention to pay without breaking bip70 completely? I was thinking of using 0 amount but that has already a special meaning
 18 2014-06-20 09:40:16 <GAit> "If the sum of outputs.amount is zero, the customer will be asked how much to pay"
 19 2014-06-20 10:30:43 <skinnkavaj> https://blog.ethereum.org/2014/06/19/mining/
 20 2014-06-20 11:26:03 <hearn> wumpus: what exactly do you want to see in such a pull request?
 21 2014-06-20 11:26:54 <wumpus> hearn: so it's either this or full UTXO commitments?
 22 2014-06-20 11:27:55 <hearn> there is a spectrum of trust. there's the raw utxo data. there's the raw data that's authenticated retroactively when the spending tx confirms, which is what I explained for the SPV fee estimation algorithm. then there's UTXO commitments, where you are assuming miners don't collaborate against you vs remote nodes.
 23 2014-06-20 11:28:12 <hearn> then there's "pick a trusted third party and assume they're honest" which is of course, not decentralised.
 24 2014-06-20 11:29:03 <wumpus> I'm still wrapping my head over why this P2P message would be so especially bad for security, i mean we have calls like 'mempool' that could just as well lie... as you document that the call queries that node's utxo set (not "some global trusted information"), it's not inherently insecure, only if you expect too much from it
 25 2014-06-20 11:29:32 <wumpus> you could, for example, use it on an internal network with a node or set of nodes that you trust
 26 2014-06-20 11:29:34 <wumpus> that's up to the caller
 27 2014-06-20 11:29:56 <hearn> yes, it's indeed the same
 28 2014-06-20 11:30:26 <hearn> and actually i pointed both those things out in the original writeup .... also since last week i'm kind of burned out on the assumption that hashpower majority is the gold standard for security
 29 2014-06-20 11:30:41 <hearn> it's clearly not. i sort of joked about people demanding authentication by ghash.io, but we're not actually far from that
 30 2014-06-20 11:30:58 <wumpus> there is no expectation that nodes can't lie in the information that they provide, sure, in this case there is no cryptographical way to verify it, but there may be other application-specific ways
 31 2014-06-20 11:31:04 <hearn> having a mix of IP addresses *and* a good mix of miners would be the best. but we work with what we've got.
 32 2014-06-20 11:31:29 <wumpus> right
 33 2014-06-20 11:31:30 <hearn> yeah. so the SPV fee algorithm, for example, works just fine with the current getutxo patch and is also authenticated
 34 2014-06-20 11:31:50 <hearn> rather, it'd be authenticated if we do tx v3 with value in the signature hash, which beyond requiring a chain fork, is not a very hard change to code up
 35 2014-06-20 11:32:22 <wumpus> yup, so it depends on the specific application that you would use the getutxos call for
 36 2014-06-20 11:33:44 <hearn> right
 37 2014-06-20 11:33:58 <GAit> hearn: if you got a minute I'd like to bounce some ideas re instant ext
 38 2014-06-20 11:34:15 <hearn> i guess so. actually let me go get a cup of tea first
 39 2014-06-20 11:34:27 <GAit> sure - ta
 40 2014-06-20 11:34:31 <wumpus> I think it's really childish that people started with 'this is insecure!!!' outcries immediately, even though the network is not affected at the least, we could merge this without risk to existing clients.. is it our task to be network nannies, avoiding anything that could be used insecurely?
 41 2014-06-20 11:36:15 <wumpus> I can understand that way of thought in the user interface, if you have to interact with (sometimes clueless) users, but on a network protocol... I'm not sure
 42 2014-06-20 11:36:43 <hearn> well that seems like a fundamental design principle that could be resolved either way. my inclination is basic safeties like the JSON-RPC excessive fee check are good, but indeed the purpose of an API is not to deny you any feature that might be misused by someone else. computers would look pretty different if that was how they worked ...
 43 2014-06-20 11:36:46 <GAit> wumpus: there's too much outcry but there's also space for improvements no? I'm not thinking we should wait for perfection as that's the enemy of good but at least fix the things we know can be improved now rather than later
 44 2014-06-20 11:37:56 <wumpus> hearn: well if it is the case we have to start restricting the protocol immediately, make sure people do no dangerous or illegal things :)
 45 2014-06-20 11:38:34 <wumpus> but in turn that makes *us* responsible for people's safety and security
 46 2014-06-20 11:38:46 <wumpus> kind of wrong in a distributed system
 47 2014-06-20 11:39:23 <hearn> indeed. i'm not a big fan of that implication :) i guess it's a rerun of the apple vs android debates. apple won't let you run any program they feel doesn't align with their goals or that might potentially be problematic in any way.
 48 2014-06-20 11:39:29 <sipa> i do like the distinction that the p2p protocol should be there to support trustless operation up to the extent possible - anything else is services offered by a node you trust rather than network operation
 49 2014-06-20 11:39:36 <GAit> wumpus: it's a trade off between consensus in bitcoin core or a fork
 50 2014-06-20 11:39:37 <wumpus> I really don't know how to handle this - I encourage forks of bitcoind for experimentation that add things to the protocol
 51 2014-06-20 11:39:46 <hearn> android has signposts pointing in the right direction and tries its best to help be secure, but you can still ultimately install what you want, if you choose to
 52 2014-06-20 11:40:08 <wumpus> hearn: but the thing is, apple and android are owned
 53 2014-06-20 11:40:18 <sipa> it would be useful if we had documentation about each of the network messages, and in which ways you need to trust the peer or in which ways they can lie
 54 2014-06-20 11:40:36 <sipa> as indeed, there is already a large variety of those
 55 2014-06-20 11:40:43 <GAit> sipa: indeed very useful
 56 2014-06-20 11:40:48 <wumpus> sipa: yes
 57 2014-06-20 11:41:02 <hearn> sipa: there are obviously practical benefits to having something provided by the p2p network even if it's not authenticated. for instance, the fact that SPV clients can query the mempool directly is of tremendous help
 58 2014-06-20 11:41:03 <wumpus> sipa: but hearn describes that in his pull request
 59 2014-06-20 11:41:18 <wumpus> I suppose that would go into the BIP as well
 60 2014-06-20 11:41:24 <hearn> the alternative is, i'd basically have to pay for some server to do that myself. then not only would we not have decentralised wallets, but i'd need to find a way to raise the money to afford that, or pay for it out of my savings.
 61 2014-06-20 11:41:37 <hearn> and then we'd have to charge people to use SPV wallets because now the cost isn't being shared across the community any more
 62 2014-06-20 11:41:38 <sipa> i still believe we should not encourage trusting behaviour on the global p2p network
 63 2014-06-20 11:41:42 <hearn> and then how do you do that, with open source wallets?
 64 2014-06-20 11:42:09 <GAit> donations or provide a service and charge for it?
 65 2014-06-20 11:42:23 <wumpus> sipa: but making something possible is not the same as encouraging
 66 2014-06-20 11:42:33 <sipa> maybe
 67 2014-06-20 11:42:54 <sipa> but hiding it behind a private extension feels much cleaner
 68 2014-06-20 11:43:04 <hearn> donations don't work. blockchain uses advertising and just hopes nobody forks them or people don't block the ads. but you know what, the model where a large community works out pretty well so far
 69 2014-06-20 11:43:18 <hearn> sorry, where a large community donates together
 70 2014-06-20 11:43:47 <wumpus> sipa: I'd agree on that for expensive queries, you'd want to allow those for whitelisted (or whiteported) nodes only
 71 2014-06-20 11:43:50 <hearn> sipa: did you get a chance to review my spv fee estimation proposal? it uses getutxo as-is today
 72 2014-06-20 11:44:00 <hearn> sipa: in a way that's authenticated
 73 2014-06-20 11:44:07 <sipa> hearn: not enough to comment on it
 74 2014-06-20 11:44:44 <wumpus> sipa: but here it's the other way around, you want to protect the other node against getting possible lied information from you?
 75 2014-06-20 11:45:06 <wumpus> sipa: I don't see how authentication would fit in here, unless it would be the other way around (clients verifies server)
 76 2014-06-20 11:45:18 <wumpus> in that case, you can already decide as client who you query
 77 2014-06-20 11:45:26 <sipa> wumpus: right, in a way
 78 2014-06-20 11:45:30 <wumpus> although MiTM is possible
 79 2014-06-20 11:45:55 <sipa> but it's also a service that we commit to provide on the network, making it harder to change implementation
 80 2014-06-20 11:46:08 <wumpus> avoiding that would involve adding a  MAC check to the bitcoin P2P packets going both ways, or signatiures...
 81 2014-06-20 11:46:16 <hearn> mapping outpoint to output is pretty fundamental.
 82 2014-06-20 11:46:30 <hearn> a bitcoin that doesn't do that is sufficiently star-trek we can jump that hurdle when we come to it
 83 2014-06-20 11:46:31 <sipa> imho it just does not belong in what the network should provide, and i prefer being conservative there
 84 2014-06-20 11:46:40 <wumpus> sipa: well it's behind a service bit -- a node can decide not to offer it
 85 2014-06-20 11:47:05 <hearn> sipa: here's a question to ponder - what level of trustlessness would you require to be a part of the p2p protocol? does bloom filtering fit?
 86 2014-06-20 11:47:09 <sipa> that's better, but doesn't really prevent the ecosysyem from growing to rely ob it
 87 2014-06-20 11:47:10 <hearn> sipa: what about addr relay?
 88 2014-06-20 11:47:20 <sipa> hearn: "to the extent possible"
 89 2014-06-20 11:47:35 <wumpus> no, it doesn't, but it does allow getting rid of it if it really turns out to be a problem
 90 2014-06-20 11:47:42 <petertodd> sipa: incentivising network-level sybil attacks is a concern - there seems to be some evidence that someone is sybil attacking either dice sites directly, or miners, to do zeroconf doublespends for instance
 91 2014-06-20 11:47:56 <hearn> then surely getutxo qualifies - better is not possible with today's infrastructure or protocol. perhaps future protocol changes would allow better
 92 2014-06-20 11:48:08 <wumpus> hearn: right
 93 2014-06-20 11:48:12 <petertodd> wumpus: fwiw don't forget my point that if getutxos had privacy features, it'd discourage targetted attacks and maybe be safer
 94 2014-06-20 11:49:09 <hearn> for assurance contracts, the outputs being queried will appear together on the block chain in a single transaction when the contract completes anyway, so the privacy upgrade from having noisy queries here would be extremely small and short lived.
 95 2014-06-20 11:49:32 <wumpus> petertodd: sure, *if* someone would implement it with UTXO commitments, that would obviously be better
 96 2014-06-20 11:49:48 <sipa> i'd put it the other way
 97 2014-06-20 11:49:50 <petertodd> the privacy is for the moment when you query your peer for data
 98 2014-06-20 11:50:21 <sipa> if we agree that utxo querying is a sufficentlynuseful network features, that should incentivize work on getting authenticayed utxo commitments
 99 2014-06-20 11:50:38 <sipa> not just provide it in a way that ptovides no safety whatsoever
100 2014-06-20 11:50:45 <hearn> i think mark is already incentivised, seeing as he started work on it some time ago already
101 2014-06-20 11:51:00 <sipa> yes, and i would love to see that work move forward
102 2014-06-20 11:52:38 <hearn> by the way, i disagree that there's "no safety whatsoever". you're assuming a binary outcome: if something involves miners, it's secure, and if it doesn't, it isn't. i don't see it like that.
103 2014-06-20 11:53:42 <hearn> but anyway, the path you want is I think quite problematic. it sends a powerful message to people - don't try adding stuff to the protocol, because if someone comes up with any idea for making it better, no matter how expensive or even if it would take years, then your proposal will be rejected. that's not how any successful project makes progress.
104 2014-06-20 11:53:49 <hearn> it simply ensures nobody will even take the first step
105 2014-06-20 11:54:36 <wumpus> right, nothing is ever perfect at first try
106 2014-06-20 11:54:55 <hearn> e.g. someone comes along and says, hey we could make this better with a zkSNARK, so your current approach is not acceptable. and they say, but I don't understand the PCP theorem. guess i should give up.
107 2014-06-20 11:55:17 <petertodd> I simply can't agree with that. lots of changes have been made to bitcoin core changing policy, p2p network and otherwise with very little debate, e.g. my own patch to stop CHECKMULTISIG malleability
108 2014-06-20 11:55:25 <wumpus> what if Mark does all the work on UTXO commitments, would we merge that? or would it still not be safe enough?
109 2014-06-20 11:55:45 <sipa> there is a distinction between impmementation and theory here
110 2014-06-20 11:55:45 <wumpus> what if there is an even safer and more secure way
111 2014-06-20 11:55:47 <petertodd> wumpus: there would be debate over how it implies keeping a ever-growing UTXO set
112 2014-06-20 11:56:22 <sipa> wumpus: utxo commitmemts bring spv security to utxo queries
113 2014-06-20 11:56:23 <hearn> wumpus: i have not examined it closely enough to have much of an opinion. the idea seems sound but maaku told me he expected petertodd to oppose it, surprise, look what just happened.
114 2014-06-20 11:56:37 <hearn> wumpus: i think a lot of it would depend on the actual efficiency of the implementation, etc
115 2014-06-20 11:56:49 <hearn> + it means a fork and waiting for everyone to upgrade, etc
116 2014-06-20 11:56:58 <hearn> so hard to know what people would think, ahead of time
117 2014-06-20 11:57:03 <wumpus> hearn: right, it would be a difficult sell as well
118 2014-06-20 11:57:04 <sipa> if it works as intended (no bugs, ...), the security properties are perfectly clear
119 2014-06-20 11:57:19 <sipa> and so are the benefits under those security assumptions
120 2014-06-20 11:57:48 <sipa> (bypassing full history check if you accept spv security up to some point in history, authenticated utxo queries, ...)
121 2014-06-20 11:58:09 <hearn> current SPV wallets don't have much use for UTXO commitments, as far as I can tell. though there may be use cases I haven't thought of. obviously for making getutxo answers more checkable that's useful, but most wallets don't need it
122 2014-06-20 11:58:45 <sipa> i think being able to bypass checking the entirely of history alone is sufficient reason for it; but that isy personal opinion
123 2014-06-20 11:58:46 <wumpus> but still you have to take those security properties into account when you design a solution on top of that, even though they are much stronger than hearn's current solution
124 2014-06-20 11:59:01 <petertodd> hearn: SPV would make more use of per-block TXO indexes I suspect to authenticate blockchain data queries
125 2014-06-20 11:59:32 <sipa> there are many ways in which bitcoin can work in the future
126 2014-06-20 11:59:45 <sipa> and it will depend both on demand as availability of technology
127 2014-06-20 12:00:41 <sipa> but abandoning even spv security just seems a step too far to me
128 2014-06-20 12:01:03 <hearn> what's being abandoned? you can't abandon something that doesn't currently exist.
129 2014-06-20 12:01:12 <sipa> as a principle
130 2014-06-20 12:01:40 <sipa> but you know my opinion, i won't agree about it anymore
131 2014-06-20 12:01:51 <petertodd> sipa: well, one ugly thing with UTXO commitments is that adding it is a soft-fork, but removing/modifying it is likely not going to be a soft-fork.
132 2014-06-20 12:02:11 <hearn> there was never any such principle! as wumpus pointed out, the protocol is full of things that have no authentication at all, just because they were useful or needed. the entire addr relay system is one example. bitcoin could operate like Tor but satoshi's code tries to avoid that, even though it's a big pile of heuristics and hacks
133 2014-06-20 12:02:13 <petertodd> sipa: makes getting a reasonable design right a good deal more important
134 2014-06-20 12:03:13 <hearn> generally things get better over time, but for example, bloom filtering weakened the security properties of SPV nodes in order to win us more performance and scalability. the first versions of bitcoinj downloaded full blocks and verified the entire merkle tree, then scanned.
135 2014-06-20 12:03:34 <petertodd> Bitcoin has very different properties than Tor and doesn't need to operate like it - the #1 difference being that the blockheaders provide strong detectability that you are being jammed, making authenticated addr relay much less important.
136 2014-06-20 12:03:38 <hearn> bloom moved filtering to the remote peer and allowed them to start lying through omission - a strictly weaker security model. but it had to be done, otherwise nobody would be using SPV wallets today at all
137 2014-06-20 12:03:52 <wumpus> but as sipa said it's indeed important to document what call/algorithm provides what level of security
138 2014-06-20 12:04:18 <hearn> documentation is certainly not an issue, now we have a developer guide things can be added there, and of course discussions in the defining BIP are useful too
139 2014-06-20 12:07:18 <petertodd> people could have very easily been using SPV wallets with the electrum model of a trusted server for chain data backed up by multiple sources for block header information. (e.g. the unauthenticated p2p network) equally due to the nature of blockchain data, you're probably well off to back up electrum-style data queries with unauthenticated and (hopefully!) randomly chosen p2p peer queries
140 2014-06-20 12:08:14 <petertodd> note how the security is additive - again fundementally because your knowledge of the blockchain can only improve and conflicts are easily resolved by the best known chain mechanism
141 2014-06-20 12:15:56 <hearn> luckily it has not been necessary. and that's important; bitcoin's purpose is to be decentralised. every time you say ....... well, what we've got seems to work, but better introduce a trusted third party again just in case, that undermines the purpose of the project. if it turns out based on practical experience that there's really no alternative, well, ok then we accept some degree of failure. but pre-emptively assuming it, would be wrong
142 2014-06-20 12:16:29 <hearn> at any rate, security/cost tradeoffs are subtle and people often come down at slightly different points on the spectrum. the purpose of competition is to let us explore these tradeoffs.
143 2014-06-20 12:17:35 <hearn> anyway, GAit sorry you wanted to talk about your bip
144 2014-06-20 12:17:56 <petertodd> as I said before, if this is going to be one of "competition" you can compete by releasing an experimental fork of Bitcoin Core and asking people to volunteer to run it. we can see if it offers features that people are sufficiently interested in and it saves us a lot of controversy
145 2014-06-20 12:18:53 <hearn> no, the best way is for Core to support this feature that costs nothing, and to let people use it if they want to. there is no need for a fork. it's not a dangerous feature.
146 2014-06-20 12:19:22 <hearn> ultimately the insecurity that may or may not result falls on the users of the message, not the nodes
147 2014-06-20 12:19:28 <GAit> Yeah, it has been brought to my attention that some people may want instant or nothing. I was wondering how to handle that. At first I thought I could use a zero amount but that has already a meaning in BIP70
148 2014-06-20 12:19:30 <GAit> "If the sum of outputs.amount is zero, the customer will be asked how much to pay"
149 2014-06-20 12:19:38 <hearn> GAit: how do you mean instant or nothing?
150 2014-06-20 12:19:39 <petertodd> it is dangerous to the ecosystem and incentivizes network attacks, but anyway, enough discussion
151 2014-06-20 12:20:04 <hearn> GAit: you mean, they won't accept a payment unless it was signed by a TTP?
152 2014-06-20 12:20:11 <GAit> hearn: that the want to use bip70 + extention but only accept instant confirmation, so avoid having standard bip70 manage to actually pay.
153 2014-06-20 12:20:16 <GAit> hearn: yeah.
154 2014-06-20 12:20:45 <hearn> er, that's not the bitcoin protocol anymore :) in that case i'd suggest defining a new protocol scheme and mime type so if your wallet doesn't support that, the clickable link doesn't work anymore
155 2014-06-20 12:20:55 <GAit> having zero outputs was suggested
156 2014-06-20 12:20:58 <GAit> yeah
157 2014-06-20 12:20:58 <hearn> effectively fork the protocol
158 2014-06-20 12:21:34 <GAit> even if forked I'd still like it to be simple to do if you already accept BIP70
159 2014-06-20 12:22:14 <hearn> sure, the message format itself can be the same. you would just need a new name and triggering mechanism. so the merchant wouldn't advertise that they accept bitcoin anymore, they'd say they accept payment via providers X Y and Z
160 2014-06-20 12:22:25 <hearn> and you could just have links for those providers directly, perhaps
161 2014-06-20 12:22:39 <GAit> like Bitcoin accepted via BitPay?
162 2014-06-20 12:23:35 <hearn> I think it's different. If I see a shop saying that they accept Bitcoin, it's irrelevant to me if they're using bitpay or not. the coins in my pocket will still work
163 2014-06-20 12:23:50 <hearn> if I see a shop saying they accept Bitcoin, and then they actually require that I use some TTP, then the coins in my pocket will not work
164 2014-06-20 12:24:06 <GAit> anyway I agree it should be explicitly incompatible in that case, too bad. Maybe it should just work with incentives, i.e. have an extra field with value interpreted as discount as you suggested
165 2014-06-20 12:24:18 <GAit> it is different, wrong example.
166 2014-06-20 12:24:56 <hearn> the discount field means the system is somewhat adaptable, at least. if losses from fraud on the regular bitcoin network go down, the discount can go down too.
167 2014-06-20 12:24:59 <hearn> and vice-versa
168 2014-06-20 12:25:22 <GAit> yep
169 2014-06-20 12:25:31 <GAit> but i am not yet convinced by multi signatures
170 2014-06-20 12:25:39 <hearn> by the way, one thing to consider is that if the recipient accepts the TTP's signature, the miners fee is useless at that point. the tx may as well be free.
171 2014-06-20 12:26:04 <hearn> so the wallet does indeed need to know that their TTP will be accepted when it crafts the transaction
172 2014-06-20 12:27:37 <GAit> true but remeber that in our case we have to get the tx confirmed before the nlocktime expires, so we'll work on increasing fees to increase incentive as necessary
173 2014-06-20 12:29:20 <GAit> we don't allow instant for outputs we know the user can double spend without a buffer of 1 day (144 blocks) but we may have to adjust this number
174 2014-06-20 12:29:56 <hearn> presumably that means whether i get an instant approval or not depends on basically random stuff (from the users POV), like what order and when I received payments in
175 2014-06-20 12:30:31 <GAit> no, it's all explicit
176 2014-06-20 12:30:34 <GAit> by default no instant
177 2014-06-20 12:30:41 <GAit> by default no double spend prevention
178 2014-06-20 12:31:15 <GAit> so for instance you can't do an instant unless your inputs have at least 6 confs and this number too is going to be adjusted depending on amount
179 2014-06-20 12:31:39 <hearn> from the users perspective, this will seem basically random
180 2014-06-20 12:31:59 <GAit> they get told that they have to wait if we find no inputs that satisfy instant
181 2014-06-20 12:32:16 <GAit> same with 0 conf, they can't spend it until it has 1 conf like bitcoin core
182 2014-06-20 12:32:53 <GAit> nothing is fixed in stone, i think the system will evolve and adapt to how the bitcoin world evolves
183 2014-06-20 12:56:22 <JackH> what is the prefered linux build to run bitcoin on command line from? Ubuntu right?
184 2014-06-20 13:10:23 <epscy> preferred by whom?
185 2014-06-20 13:12:34 <JackH> the greater mass
186 2014-06-20 13:12:51 <JackH> I opted in for ubuntu 13.10
187 2014-06-20 13:12:55 <JackH> should do fine it seems
188 2014-06-20 13:16:27 <Guest43267> logistical problem: I have a multisig transaction that I have to safestore until I'm ready to sign and broadcast.  Is there any facility in Bitcoin-Qt that would facilitate this?  For example, could I stick it the mempool then retrieve and sign later?
189 2014-06-20 13:17:48 <shesek> Guest43267, no. just store it somewhere externally
190 2014-06-20 13:21:05 <Guest43267> release note: `sendrawtransaction`: report the reject code and reason, and make it possible to re-send transactions that are already in the mempool
191 2014-06-20 13:21:21 <Guest43267> how long does it remain in mempool after reject is received?
192 2014-06-20 13:26:15 <petertodd> GAit: the thing with the miners fee is a good argument for signing these instant tx's with SIGHASH_ANYONECANPAY btw
193 2014-06-20 13:29:03 <wumpus> Guest43267: it doesn't go into the mempool if rejected
194 2014-06-20 13:30:01 <GAit> petertodd: true but wouldn't that be an issue with the change and the nlocktime tx?
195 2014-06-20 13:30:04 <petertodd> GAit: oh, and funny too: you're supporting replace-by-fee scorched-earth if you guys ever doublespend :P
196 2014-06-20 13:30:20 <petertodd> GAit: why/
197 2014-06-20 13:30:56 <GAit> need to think about it a bit
198 2014-06-20 13:32:41 <hearn_> what stops scorched earth policy just turning into every miner being bitundo
199 2014-06-20 13:32:42 <petertodd> so, the edge case with SIGHASH_ANYONECANPAY is if you make two payments in a row to the same set of outputs. basically any miner can take both sets of signatures, combine them, and get a very high-fee transaction. ensuring change addrs are unique removes the concern.
200 2014-06-20 13:33:18 <GAit> petertodd: we already do that
201 2014-06-20 13:33:30 <GAit> i.e. change addr unique
202 2014-06-20 13:33:50 <petertodd> GAit: i know - basically the concern is just edge cases, for instance "app crashes", users restarts, and the same change addr is picked because it's the next unused one
203 2014-06-20 13:35:19 <petertodd> oh, and what's interesting about that is since nLockTime is signed, if it's, say, set to the current time you've reduced that edge case to a very, very, small probability with no special effort. (though doing that raises some ugly issues re: miner incentives)
204 2014-06-20 13:35:33 <GAit> that is unlikely with multisig given we keep track of indexes and we don't use gaps
205 2014-06-20 13:35:46 <petertodd> (well, i guess you could leave nSequence = max_int)
206 2014-06-20 13:36:05 <petertodd> GAit: no, that actually makes it more likely! basically you'll get the exact same transaction twice
207 2014-06-20 13:36:57 <GAit> we don't reuse addresses if the app crashes, so i don't get it sorry
208 2014-06-20 13:37:39 <petertodd> GAit: well, i guess my point is what's the mechanism that stops that? chances are you can conveive of some highly unlikely specific crash point where that would happen
209 2014-06-20 13:38:12 <GAit> i  can think of users giving the same address out twice
210 2014-06-20 13:38:24 <petertodd> GAit: then you're probably fine
211 2014-06-20 13:38:53 <GAit> but just because i can't think of any doesn't mean i'm right
212 2014-06-20 13:39:02 <petertodd> yup!
213 2014-06-20 13:51:58 <petertodd> curious, bc.i seems to index addresses in their database by the thing being hashed: https://blockchain.info/address/3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy
214 2014-06-20 13:52:32 <petertodd> see how all the transactions for 1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E appear on the same page? it's all Hash160('')
215 2014-06-20 14:15:06 <dsnrk> petertodd: ha, good find!
216 2014-06-20 14:16:37 <GAit> petertodd: oh, that's not going to confuse users </s>
217 2014-06-20 14:56:34 <t7> !vote GAit for using sircasm tag
218 2014-06-20 14:56:35 <gribble> Error: "vote" is not a valid command.
219 2014-06-20 14:57:22 <GAit> is that good or bad?
220 2014-06-20 15:00:23 <t7> i meant voteban
221 2014-06-20 15:00:43 <GAit> sounds bad
222 2014-06-20 15:00:51 <t7> shame on you
223 2014-06-20 15:01:09 <GAit> i'll stop doing it, didn't realize it was that bad at first!
224 2014-06-20 15:01:29 <michagogo> JackH: well, 13.10 EOLs next month
225 2014-06-20 15:01:36 <t7> I take it you are american
226 2014-06-20 15:01:45 <michagogo> JackH: consider upgrading to 14.04
227 2014-06-20 15:02:02 <GAit> t7 i am not american - i am a bitcoiner from EU :)
228 2014-06-20 15:04:58 <JackH> yeah, 14.04 would be better you think?
229 2014-06-20 15:07:52 <ubuntuDoubts> hi
230 2014-06-20 15:08:27 <michagogo> JackH: the only Ubuntus you should be using are 12.04 or 14.04
231 2014-06-20 15:08:38 <michagogo> (Well, as of next month)
232 2014-06-20 15:08:40 <ubuntuDoubts> does i need ever to get a git repository to compile something?
233 2014-06-20 15:08:42 <JackH> ok, I am good then
234 2014-06-20 15:08:52 <JackH> thx :)
235 2014-06-20 15:08:57 <ubuntuDoubts> Or i can create a folder clone a repository and change some files
236 2014-06-20 15:08:59 <ubuntuDoubts> and compile?
237 2014-06-20 15:09:09 <Belxjander> ubuntuDoubts: any "repository" is a storage mechanism with version tracking for source code
238 2014-06-20 15:09:20 <ubuntuDoubts> Cause im getting a fatal -error . it is cause i dont create a git and commit changes?
239 2014-06-20 15:09:28 <Belxjander> ubuntuDoubts: just check it out...make changes and build away
240 2014-06-20 15:09:37 <ubuntuDoubts> May I pm you?
241 2014-06-20 15:22:12 <andytoshi> hi guys, when i send getdata to my node to get the first 500 blocks, the node sends them back to me, but my rust code only receives the first one followed by a message without a proper network header
242 2014-06-20 15:22:34 <andytoshi> i have a pretty boring "receive data, check magic, decode message, repeat" loop, is there something simple i might be missing?
243 2014-06-20 15:22:49 <petertodd> GAit, dsnrk: if i had more spare time, i'd bruteforce a collission to make a pubkey that also happens to be a valid redeemScript, which would make both addresses valid and spendable!
244 2014-06-20 15:34:27 <dsnrk> petertodd: what would the result script look like?
245 2014-06-20 15:44:53 <andytoshi> sorry, ignore me, i forgot a loop and was only listening for a single block
246 2014-06-20 16:04:22 <petertodd> dsnrk: so, a valid pubkey has to start with 02, 03, or 04, which as a script encode 2 byte, 3 byte, or 4 byte pushdata's. easiest would be to just encode that pushdata, and then the rest of the scriptPubKey as another pushdata, which is a spendable scriptPubKey. that's just a few bytes to brute force, so pulling that off is feasible
247 2014-06-20 16:06:35 <dsnrk> petertodd: yep, I follow. that's doable.
248 2014-06-20 16:17:57 <jcorgan> ;;seen haltingstate
249 2014-06-20 16:17:58 <gribble> haltingstate was last seen in #bitcoin-dev 5 weeks, 2 days, 3 hours, 16 minutes, and 16 seconds ago: <HaltingState> if i can communicate with them, obviously, i can just take their pubkey and send message like that and they can only read it if they know my private key or they know the private key for the pubkey and that proves to me that they have the private key; but if i took the (1 more message)
250 2014-06-20 16:18:08 <HaltingState> ?
251 2014-06-20 16:18:23 <jcorgan> heh
252 2014-06-20 16:18:44 <jcorgan> just looking at your internal libsecp256k1 code, it is a few commits behind the sipa's repository
253 2014-06-20 16:18:53 <HaltingState> ya
254 2014-06-20 16:19:04 <HaltingState> i dont think he fixed any bugs so it should be fine
255 2014-06-20 16:19:35 <HaltingState> jcorgan, did you see this https://medium.com/@RKHilbertSpace/elminating-mining-pool-concentration-in-bitcoin-196d02bf2d81
256 2014-06-20 16:19:37 <jcorgan> yeah, the diff is pretty small, but just wondering if cgo could be coereced to link against an .so instead of having to compile
257 2014-06-20 16:20:08 <jcorgan> i haven't, will read
258 2014-06-20 16:22:58 <jcorgan> bbiab, but want to follow up on the external vs. internal lib with cgo
259 2014-06-20 17:31:17 <jcorgan> HaltingState: read through that briefly.  no technical comments, but i'm suspicious of proposals that reduce everyone to solo mining.  But that's not really a topic for -dev, but for -wizards.
260 2014-06-20 17:34:23 <jcorgan> otoh, i'm still interested to know that if i already have libsecp256k1 installed as a shared library, is there a way to have your go wrapper link to it instead of statically linking to the internal libs in the tree?
261 2014-06-20 17:37:01 <graingert> jcorgan: I think the static linking is used on purpose here for cryptographically validated binary builds
262 2014-06-20 17:37:34 <graingert> jcorgan: so everyone in the DEV team can simultaneously build bitcoin-qt and have the same binary every time
263 2014-06-20 17:49:05 <jcorgan> i understand your point but i'm referring to the work that haltingstate did to wrap sipa's libsecp256k1 C++ library to be used as a module in a golang program
264 2014-06-20 17:49:14 <jcorgan> not to the bitcoin binary stuff
265 2014-06-20 17:49:56 <tresdf> hi folks when I try to run daemon via tor its kinda rejected - maybe tor ip was misused before?
266 2014-06-20 17:50:19 <dsnrk> tresdf: that shouldn't be a problem.
267 2014-06-20 17:50:59 <dsnrk> some nodes *might* have banned tor exit nodes, but I doubt all 8000 listening IPv4 peers have banned all Tor exits. HS don't ban other peers at all.
268 2014-06-20 17:52:17 <tresdf> true
269 2014-06-20 17:52:32 <tresdf> maybe I have to recheck tor settings
270 2014-06-20 17:54:00 <gmaxwell> it takes a while to get connected the first time via tor.
271 2014-06-20 18:03:02 <tresdf> gmaxwell: u are genius
272 2014-06-20 18:03:10 <tresdf> its connecting now
273 2014-06-20 18:30:23 <ronkrt> i am looking for someone who would like to help engineer a x11 encoded sha-256 encoded scrypt encoded algor
274 2014-06-20 18:30:47 <maaku> ronkrt: OT
275 2014-06-20 18:31:23 <ronkrt> OT?
276 2014-06-20 18:31:52 <ronkrt> I'm working on a crypto cur that will come out with some big improvements to the current system, will also come out with a 1 to 1 local cur garuntee,
277 2014-06-20 18:32:04 <ronkrt> decentrilize the value of the coin and its even more decentrilized then bitcoin
278 2014-06-20 18:33:24 <ronkrt> and it wont be any of this 0.00000000000btc stuff, stright 0.00
279 2014-06-20 18:34:32 <gmaxwell> ronkrt: I'm glad you're enthusastic, but alternative systems are offtopic for this channel— especially speculative ones. This channel is for production discussion related to bitcoin network and reference software.
280 2014-06-20 18:46:20 <t7> ronkrt: where can i fund your kickstarter?
281 2014-06-20 18:52:30 <cfields> gmaxwell: i've never seen the performance argument for unsigned loop counters. I'm familiar with the usual pitfalls, but that one's new to me
282 2014-06-20 18:52:41 <cfields> gmaxwell: you've seen it make a real-world difference?
283 2014-06-20 18:55:53 <tm4> unsigned loop counters in what language?
284 2014-06-20 18:59:07 <gmaxwell> cfields: oh absolutely, it breaks the autovectorior in gcc / clang fairly often.
285 2014-06-20 18:59:49 <gmaxwell> e.g. in cases where the analysis would show the the loop either runs 16 times or forever.
286 2014-06-20 19:00:44 <tm4> sounds like the analyzer is broken...
287 2014-06-20 19:02:09 <tm4> at the assembly level, there isn't much difference between a loop using an signed vs unsigned loop counter on the architectures I can think of offhand.
288 2014-06-20 19:02:50 <cfields> gmaxwell: i see, i'm reading that bug right now
289 2014-06-20 19:03:18 <gmaxwell> tm4: there is a big difference at the C level— signed counters may not overflow.
290 2014-06-20 19:03:27 <cfields> gmaxwell: good to know. seems lots of cases that i would've assumed to be easily vectoriezed... haven't been
291 2014-06-20 19:03:45 <cfields> -e
292 2014-06-20 19:03:48 <gmaxwell> yea, you can -ftree-vectorize-verbose=n in gcc and get reports.
293 2014-06-20 19:04:30 <gmaxwell> I suspect for a lot of what we do it doesn't matter much— in my DSP work it matters a lot, and it may matter in the crypto inner loops. If the only argument were the optimization one I wouldn't worry about it as a general matter.
294 2014-06-20 19:04:31 <tm4> counters may overflow, but C doesn't care afaik.
295 2014-06-20 19:05:21 <tm4> There's only one architecture I can think of that has instructions which trigger on overflow - MIPS has special signed instructions (ADDS, SUBS) that generate an exception on overflow, but nobody uses them.
296 2014-06-20 19:05:22 <gmaxwell> tm4: overflow in signed types in C/C++ is undefined. If your software has a signed overflow your software is wrong and frequently will be miscompiled. The compiler is allowed to optimize assuming it never happens.
297 2014-06-20 19:05:55 <gmaxwell> and so, for example, if value analysis observes some branch can only be taken if a signed value has previously overflowed— the code is dead and will be removed.
298 2014-06-20 19:06:00 <cfields> gmaxwell: sure.
299 2014-06-20 19:06:40 <gmaxwell> likewise, if values can only alias if there is a signed overflow, it will assume they don't and will emit code which is incorrect if the values alias, etc.
300 2014-06-20 19:06:47 <tm4> how would you detect a signed value has previously overflowed?
301 2014-06-20 19:07:32 <tm4> "values aliasing" sounds wrong. are you sure you don't mean "pointers aliasing" ?
302 2014-06-20 19:07:35 <gmaxwell> You don't detect it, you never emit the code in the first place because static analysis proved that the condition could happens only if there were an overflow (which is by definition 'never' going to happen)
303 2014-06-20 19:08:04 <gmaxwell> tm4: I'm being casual with language, 'storage alaising' would be more pedantic.
304 2014-06-20 19:08:17 <tm4> you mean pointers aliasing, really. ok.
305 2014-06-20 19:10:27 <tm4> The only language I can think of which seriously cares about values overflowing is Ada. It does trigger an exception on overflow iirc.
306 2014-06-20 19:10:41 <tm4> erm, integers overflowing
307 2014-06-20 19:11:54 <gmaxwell> You're incorrect.
308 2014-06-20 19:12:05 <gmaxwell> Go compile http://0bin.net/paste/CULfwymjCzNLTQox#AS/klVQguateWxknRArqpfUyclqIHZS2Vw99VVl0q90= with any remotely modern optimizing compiler.
309 2014-06-20 19:12:17 <gmaxwell> You'll see the entire last branch is not emitted at all.
310 2014-06-20 19:12:34 <gmaxwell> (along with the string and call to printf)
311 2014-06-20 19:13:28 <GAit> well maybe wait tomorrow
312 2014-06-20 19:14:38 <tm4> what I meant by "seriously cares" is that it's treated as an error condition, as in trappable.
313 2014-06-20 19:16:13 <tm4> The example you gave is interesting. if the printf code is never emitted, it kinda looks like a compiler bug.
314 2014-06-20 19:17:33 <gmaxwell> It's not. The overflow of signed types is defined to never happen in C. If your code can overflow a signed type at runtime your code is broken.
315 2014-06-20 19:18:10 <andytoshi> tm4: you should say that in ##c :)
316 2014-06-20 19:19:27 <tm4> at gcc -O I see the string in the assembly output
317 2014-06-20 19:19:49 <tm4> at -O2 I don't see it.
318 2014-06-20 19:20:09 <gmaxwell> (It's not implementation defined, it's undefined. The compiler is allowed by the language spec to insert an overflow check that calls system("rm -rf /") ... though usually they do not. ... if the compiler can prove that an overflow always happens in your main() even down at the bottom its valid for it to compile main to an empty stub though usually they don't.)
319 2014-06-20 19:21:02 <tm4> so which RTL pass is removing the code?
320 2014-06-20 19:21:59 <gmaxwell> No clue, the knoweldge that signed won't overflow shows up in a bunch of places.
321 2014-06-20 19:22:12 <tm4> it looks like it's removed before the RTL generation, so maybe a tree pass.
322 2014-06-20 19:22:15 <gmaxwell> Last time I did anything with gcc internals except report bugs was a decade ago.
323 2014-06-20 19:22:23 <tm4> I'm more familiar with RTL than GIMPLE
324 2014-06-20 19:23:19 <tm4> I haven't worked on gcc in about a year.
325 2014-06-20 19:25:15 <tm4> I see it in test.c.064t.mergephi2 but not in test.c.065t.vrp1.
326 2014-06-20 19:25:28 <tm4> so it looks like it's optimized by the GIMPLE value range prop pass.
327 2014-06-20 19:26:00 <tm4> This is with Ubuntu gcc 4.8.1
328 2014-06-20 19:26:39 <gmaxwell> well as I said, anything should do it. being able to bound the range of signed values is pretty helpful from an optimization perspective.
329 2014-06-20 19:27:23 <tm4> this code bothers me, though. it assumes negative numbers will not become positive when values are added to it.
330 2014-06-20 19:27:35 <tm4> will look at it later...bbl
331 2014-06-20 19:29:18 <gmaxwell> It's correct. Change the example I gave to use an unsigned type (e.g. with a check on 0) and you'll see that it correctly concludes that it can wrap.
332 2014-06-20 19:56:48 <dgenr8> was there an issue or PR contemplating mempool persistence?  Thought I saw it but can't seem to find it...
333 2014-06-20 19:58:57 <mr_burdell> dgenr8: what about it? i have transactions up to a week or more old in my mempools
334 2014-06-20 20:03:44 <dgenr8> sometimes it would be nice not to forget them on restart
335 2014-06-20 20:04:03 <dsnrk> don't we do that already?
336 2014-06-20 20:04:40 <dsnrk> I thought mempool persistence was part of the floating fee stuff
337 2014-06-20 20:05:23 <mr_burdell> oh, I see
338 2014-06-20 20:05:30 <dgenr8> if so, where are they stored?
339 2014-06-20 20:05:35 <dgenr8> mempool txes
340 2014-06-20 20:05:36 <mr_burdell> no, mine drops tx after restart
341 2014-06-20 20:06:06 <dsnrk> could have sworn there was a mempool.dat file at some point
342 2014-06-20 20:06:18 <dgenr8> i guess it was just a passing conversation I'm remembering
343 2014-06-20 20:06:34 <mr_burdell> http://mempool.info is mine... so you can see there are tx as old as 4 days, which is when I last restarted that node
344 2014-06-20 20:06:37 <dsnrk> no it was certainly a thing in the client, maybe a PR I was testing?
345 2014-06-20 20:07:46 <mr_burdell> and it's running up to date 0.9.2
346 2014-06-20 20:08:19 <mr_burdell> maybe a config option for it?
347 2014-06-20 20:10:55 <dgenr8> mr_burdell: welcome to my bookmarks ;)
348 2014-06-20 20:11:38 <lechuga_> dont think anything persists mempool
349 2014-06-20 20:12:57 <mr_burdell> also, is there a way to increase mempool capacity?
350 2014-06-20 20:13:05 <mr_burdell> or is there a limit on that?
351 2014-06-20 20:14:25 <lechuga_> no limit afaik
352 2014-06-20 20:14:32 <sipa> mr_burdell: it's unlimited
353 2014-06-20 20:14:39 <lechuga_> theres a limit on how many orphan txs we'll hang onto
354 2014-06-20 20:14:49 <mr_burdell> I thought it might be controlled by "maxblocksize", but I guess that's only if you're actually mining?
355 2014-06-20 20:14:59 <sipa> mr_burdell: indeed
356 2014-06-20 20:15:10 <sipa> likely the mempool will be limited in size in the future
357 2014-06-20 20:15:13 <mr_burdell> orphan? as in tx with unconfirmed inputs?
358 2014-06-20 20:15:20 <mr_burdell> or if you don't even have the input?
359 2014-06-20 20:15:22 <lechuga_> unknown inputs
360 2014-06-20 20:16:16 <mr_burdell> hmmm... what does it do with unknown inputs? does it accept the tx?
361 2014-06-20 20:16:26 <dsnrk> rejects.
362 2014-06-20 20:16:31 <lechuga_> puts them in a bound holing area to see if the parents show up
363 2014-06-20 20:16:36 <lechuga_> holding*
364 2014-06-20 20:16:47 <mr_burdell> ok.. i need to check my scripts if it's doing anything with those
365 2014-06-20 20:17:05 <dgenr8> mr_burdell: your removed page says it includes txes where a conflict was mined, but I don't see any...
366 2014-06-20 20:17:30 <mr_burdell> the conflict would be in the blockchain
367 2014-06-20 20:17:33 <jcorgan> sipa, is there a more intelligent way of discarding orphan txes other than "oldest arrival"
368 2014-06-20 20:18:17 <mr_burdell> https://blockchain.info/tx-index/58829008 and http://mempool.info/tx/c98b4c7d72b7bda927588e7314290962b245030731ddae3ef67f728ecfafd9fc
369 2014-06-20 20:18:21 <mr_burdell> those conflict
370 2014-06-20 20:19:34 <dgenr8> mr_burdell: oh, i was looking for a special Tag value.. that one says LowFee.  So the ones with Tag=blank were conflicts?
371 2014-06-20 20:19:38 <mr_burdell> so the one in the removed page doesn't exist on blockchain because they didn't keep it
372 2014-06-20 20:20:10 <mr_burdell> dgenr8: the tag doesn't have to do with if it was removed
373 2014-06-20 20:20:26 <mr_burdell> that's just so you can easily see if there's anything special/weird about that transaction
374 2014-06-20 20:20:52 <dgenr8> mr_burdell: ok.  how far back do you have the removed txes?
375 2014-06-20 20:21:02 <mr_burdell> if you scroll down on the front page, you can see that most of the tx that have been there for a while have low fees, no fees, or something else for a reason why they aren't being mined
376 2014-06-20 20:21:18 <mr_burdell> about 2 weeks
377 2014-06-20 20:21:31 <mr_burdell> and the tags aren't updated as well if you go back too far
378 2014-06-20 20:21:52 <mr_burdell> and tx fees are wrong before monday or so
379 2014-06-20 20:24:03 <mr_burdell> if you need the json for the transactions you can do http://mempool.info/rawtx/<hash> (plus my extra data like tag, fee, couchdb key)
380 2014-06-20 20:28:47 <lechuga_> jcorgan: it's not an LRU, it's random eviction
381 2014-06-20 20:33:28 <lechuga_> seems like LRU would be better
382 2014-06-20 20:33:57 <ubuntuDoubts> Good night.
383 2014-06-20 20:34:08 <jcorgan> just based on time, LRU would evict the one least likely to get unorphaned
384 2014-06-20 20:34:12 <ubuntuDoubts> there is anybody here able to explain me how do I create my genesis block ?
385 2014-06-20 20:34:41 <ubuntuDoubts> Im trying to create my own coin.. nothing for crypto world, but just for my self- knowledge.. anyone able to help me ?
386 2014-06-20 20:35:00 <lechuga_> ur looking for #scamcoin-dev
387 2014-06-20 20:35:23 <ubuntuDoubts> No im not.
388 2014-06-20 20:36:24 <lechuga_> why don't you learn the protocol before creating a coin
389 2014-06-20 20:36:50 <ubuntuDoubts> hum
390 2014-06-20 20:36:54 <sipa> or programming
391 2014-06-20 20:36:55 <ubuntuDoubts> may I pm u lechuga?
392 2014-06-20 20:37:01 <ubuntuDoubts> sipa im php
393 2014-06-20 20:37:03 <ubuntuDoubts> php prog
394 2014-06-20 20:37:12 <sipa> learn real programming
395 2014-06-20 20:37:15 <lechuga_> lol
396 2014-06-20 20:37:15 <ubuntuDoubts> Im trying to learn more abiut crypto / some c++
397 2014-06-20 20:37:35 <ubuntuDoubts> ok to all of you know waht you know today you doesnt ask same question i do?
398 2014-06-20 20:37:43 <ubuntuDoubts> You born with knowledge already?
399 2014-06-20 20:37:56 <ubuntuDoubts> Im just trying to know more and understand by me.. by trying
400 2014-06-20 20:38:02 <sipa> by all means do
401 2014-06-20 20:38:06 <sipa> but it will take time
402 2014-06-20 20:38:13 <sipa> and just asking questions won't help
403 2014-06-20 20:38:15 <ubuntuDoubts> As you have noticed im here since sunday trying to get my objective done..
404 2014-06-20 20:38:22 <ubuntuDoubts> I know, but sipa
405 2014-06-20 20:38:30 <ubuntuDoubts> last tuesday i was asking how to compile.
406 2014-06-20 20:38:38 <kazcw> ubuntuDoubts: you're not going to learn by getting people to walk you through holding your hand the whole way
407 2014-06-20 20:38:41 <ubuntuDoubts> Atm im asking other thing, compile i already know how to
408 2014-06-20 20:38:45 <ubuntuDoubts> and already made sucessuful.
409 2014-06-20 20:38:47 <sipa> please, not here
410 2014-06-20 20:38:58 <ubuntuDoubts> sipa ok, i respect.
411 2014-06-20 20:39:16 <ubuntuDoubts> Could you tell me then where i will get some help ? or some people who like to share?
412 2014-06-20 20:39:21 <sipa> if you have spent a few months programming in c++, and you understand how bitcoin works, and still have some questions about details, you'll be very welcome
413 2014-06-20 20:39:29 <sipa> yes, read books
414 2014-06-20 20:39:31 <sipa> exercise
415 2014-06-20 20:39:38 <sipa> program examples
416 2014-06-20 20:39:49 <GAitM> Play with gdb ;)
417 2014-06-20 20:40:24 <gwillen> ubuntuDoubts: this is not an appropriate place to learn programming. Please go somewhere else. Do not PM people from this channel.
418 2014-06-20 20:41:36 <ubuntuDoubts> sipa about reading, i try.. but there isn't good guides, or explanations about this matter.
419 2014-06-20 20:41:53 <ubuntuDoubts> Thats why you watch me here sometimes.
420 2014-06-20 20:41:59 <ubuntuDoubts> Ok i will respect everyone ..
421 2014-06-20 20:42:03 <lechuga_> http://www.stroustrup.com/C++.html
422 2014-06-20 20:42:03 <ubuntuDoubts> have a good night all.
423 2014-06-20 20:42:08 <gwillen> Good night.
424 2014-06-20 20:42:09 <lechuga_> start there
425 2014-06-20 20:45:49 <equex> haha the stroustrup treatment
426 2014-06-20 20:46:19 <lechuga_> *shrug* i was being genuine
427 2014-06-20 20:46:34 <equex> here's a mouintain, heres a trout. take down the mountain.
428 2014-06-20 20:47:10 <equex> i agree though :D
429 2014-06-20 20:52:03 <GAit> bouncing some ideas re: instant, i would like to handle two main cases with bitcoin instant: instant accepted and instant required. The former can be the extention I proposed and perhaps as Mike said it can be in form of another set of outputs with different values, i.e. a discount. I think this sounds reasonable, at least as an option. For the latter I was considering a different BIP70 like protocol with different mime and incompatibl
430 2014-06-20 20:54:09 <mr_burdell> GAit: like bitcoin:address?amount=0.1&r=https://asdf&i=https://someotherlink
431 2014-06-20 20:54:36 <mr_burdell> and i would be the new instant required
432 2014-06-20 20:56:24 <GAit> I am not sure I follow mr_burdell
433 2014-06-20 20:56:25 <mr_burdell> or would you use a completely separate name like bitcoininstant:https://link
434 2014-06-20 20:56:46 <mr_burdell> I'm talking about how the wallet would know given a URI link
435 2014-06-20 20:56:53 <mr_burdell> before it even makes the request
436 2014-06-20 20:57:08 <GAit> https://github.com/bitcoin/bips/blob/master/bip-0071.mediawiki these would be different
437 2014-06-20 20:57:45 <GAit> maybe some application/bitcoininstant-paymentrequest, or you get the idea
438 2014-06-20 20:57:58 <mr_burdell> right... but how does the client know the different?
439 2014-06-20 20:58:12 <GAit> that's the whole point
440 2014-06-20 20:58:16 <mr_burdell> if it sees an r= parameter, it's supposed to use BIP70 paymentrequest
441 2014-06-20 20:58:22 <GAit> you don't want someone to accidentally send you 'slow' bitcoin
442 2014-06-20 20:58:27 <GAit> if you 'require' instant
443 2014-06-20 20:58:30 <mr_burdell> so you would need a separate URI
444 2014-06-20 20:58:38 <mr_burdell> like i=
445 2014-06-20 20:58:43 <mr_burdell> or bitcoininstant:
446 2014-06-20 20:58:48 <mr_burdell> which is what I was talking about
447 2014-06-20 21:00:46 <mr_burdell> your service isn't the payment processor though, right?
448 2014-06-20 21:01:14 <GAit> perhaps yes but you could do backwards-incompatible bitcoin:?r=http.. without address and amount https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki "then the bitcoin address portion of the URI may be omitted "
449 2014-06-20 21:01:41 <mr_burdell> right... so you wouldn't put an address
450 2014-06-20 21:01:59 <GAit> i am quite open to suggestions actually :)
451 2014-06-20 21:02:10 <mr_burdell> so it would be bitcoin:?i=https://link
452 2014-06-20 21:02:21 <mr_burdell> that way bip70 only compatible clients also ignore it
453 2014-06-20 21:02:47 <mr_burdell> although they probably wouldn't give an error message either, so that wouldn't be good for usability
454 2014-06-20 21:03:01 <GAit> yeah perhaps some ibitcoin: thing :(
455 2014-06-20 21:05:14 <GAit> as mike said in this case you are not accepting bitcoin but bitcoin via some list of explicit providers. I can see the use case but i don't really like this option.
456 2014-06-20 21:05:21 <mr_burdell> can you set the outputs array to nothing?
457 2014-06-20 21:05:32 <GAit> i can but is not within bip70 spec
458 2014-06-20 21:05:42 <GAit> you can't have no output in the array
459 2014-06-20 21:05:50 <GAit> you can imagine a buggy bip70 impl?
460 2014-06-20 21:06:22 <mr_burdell> well, it could just assume outputs sum to 0 in that case
461 2014-06-20 21:06:23 <GAit> i want to avoid any miserable experience
462 2014-06-20 21:06:35 <GAit> that has a special meaning in BIP70
463 2014-06-20 21:06:40 <mr_burdell> right
464 2014-06-20 21:06:47 <GAit> it means user sets the amount i think
465 2014-06-20 21:07:20 <GAit> let's set it to 22 millions BTC!!
466 2014-06-20 21:07:22 <GAit> :P
467 2014-06-20 21:07:57 <GAit> i can already imagine some wallet realizing 22 are not in the wallet and setting the amount to the total in the wallet
468 2014-06-20 21:08:09 <mr_burdell> there's still so many unresolved issues about bip70
469 2014-06-20 21:08:12 <mr_burdell> like this: Broadcast the transactions on the Bitcoin p2p network.
470 2014-06-20 21:08:26 <GAit> i like that the merchant can broadcast it
471 2014-06-20 21:08:32 <mr_burdell> last I heard, mike hearn was saying the client shouldn't do that, but the merchant should
472 2014-06-20 21:08:40 <GAit> well that or maybe both
473 2014-06-20 21:08:44 <mr_burdell> that's under the section for the client
474 2014-06-20 21:09:00 <mr_burdell> i prefer for the client to do it
475 2014-06-20 21:09:23 <GAit> why? that takes longer
476 2014-06-20 21:09:52 <GAit> if you meant that it should reach the merchant via mempool
477 2014-06-20 21:09:53 <mr_burdell> because if they send to the merchant and the merchant says they don't accept it, that could give the users a false sense of security about the transaction
478 2014-06-20 21:10:01 <mr_burdell> they could still broadcast it later
479 2014-06-20 21:10:09 <mr_burdell> it should be both
480 2014-06-20 21:10:17 <mr_burdell> mempool and payment message
481 2014-06-20 21:13:19 <Vinnie_win> Where in the bitcoin source do we compare the miner's proposed solution against the block's hash and difficulty?
482 2014-06-20 21:41:51 <andytoshi> Vinnie_win: main.cpp:2438 AcceptBlockHeader() checks that the block's stated difficulty is correct. main.cpp:1291 CheckProofOfWork() checks that the hash is correct for that difficulty
483 2014-06-20 21:43:10 <andytoshi> here "stated difficulty" is the 'bits' field of the block, which is a 32-bit float representation of the target
484 2014-06-20 21:49:03 <tm4> ya, it's kind of a weird floating point format.
485 2014-06-20 21:49:19 <sipa> with well-defined rounding
486 2014-06-20 21:49:48 <AWeSomeAo> I am trying to set up bitcoin-qt so it only communicates with tor nodes... is there any way to verify that? i.e. list all connected nodes?
487 2014-06-20 21:49:55 <AWeSomeAo> wrong channel, sorry
488 2014-06-20 21:50:03 <tm4> I guess it's because it's only intended for use as a mask.
489 2014-06-20 21:50:26 <sipa> it has 21-23 bits of mantissa, which is more than enough
490 2014-06-20 21:50:31 <sipa> we could do with 3 bits
491 2014-06-20 21:51:33 <andytoshi> it is defined (by example) at https://en.bitcoin.it/wiki/Difficulty
492 2014-06-20 21:51:48 <andytoshi> and the CheckProofOfWork() code also gives a definition
493 2014-06-20 21:52:22 <tm4> pragmatically, it's specifying the number of leading zeros, so it sounds like you'd only need 8 bits really.
494 2014-06-20 21:52:29 <cfields> sipa: whenever you can spare a few min, would you mind looking into hooking up libsecp256k1 -> travis ?
495 2014-06-20 21:52:48 <sipa> cfields: i'm here
496 2014-06-20 21:53:24 <cfields> sipa: should just take a few clicks, but obviously a repo admin has to do it
497 2014-06-20 21:53:52 <cfields> and obviously that repo admin needs to decide if it's in any way risky :)
498 2014-06-20 21:54:54 <coinheavy> are all transactions on the blockchain cointaining any occurance of OP_RETURN in “scriptPubKey”[“asm”] necessarily burned or are there ways that OP_RETURN could be present and the output remain spendable?
499 2014-06-20 21:54:55 <sipa> ok, any documentation you can point me to?
500 2014-06-20 21:55:05 <cfields> sipa: https://travis-ci.org/
501 2014-06-20 21:55:12 <cfields> click sign-in with github
502 2014-06-20 21:55:13 <sipa> coinheavy: OP_RETURN by definition marks an output as unspendable
503 2014-06-20 21:55:47 <cfields> from there, iirc it redirects you to github to request api permissions
504 2014-06-20 21:55:52 <sipa> coinheavy: if it appears at the start of the script at least
505 2014-06-20 21:56:21 <coinheavy> sipa: so there are edge cases/alternatives if it is not the first op code?
506 2014-06-20 21:56:31 <cfields> sipa: here are the docs on the requested api permissions: http://docs.travis-ci.com/user/github-oauth-scopes/
507 2014-06-20 21:56:33 <kazcw> if op_return is within op_if it isn't necessarily executed
508 2014-06-20 21:56:49 <coinheavy> kazcw: ah! that makes sense, thank you
509 2014-06-20 21:57:40 <coinheavy> how about this as a simpler check for whether or not a transaction output is spendable — if there is no “addresses” field within “scriptPubKey” — is that a better check for spendable/unspendable?
510 2014-06-20 21:58:09 <kazcw> no, that isn't reliable
511 2014-06-20 21:58:18 <kazcw> an empty scriptpubkey is spendable by anyone
512 2014-06-20 21:58:47 <sipa> coinheavy: addresses are simply shorthands for some often-occurring script types
513 2014-06-20 21:59:00 <sipa> coinheavy: it's the script that matters; addresses do not exist at the protocol level
514 2014-06-20 21:59:01 <coinheavy> hmm.. would the entire scriptpubkey hash have to be completely empty (no fields whatsoever) for it to be spendable by anyone?
515 2014-06-20 21:59:20 <kazcw> I don't know what you mean by scriptpubkey hash or fields
516 2014-06-20 21:59:21 <sipa> that statement makes no sense; a hash is a number; it has no "fields"
517 2014-06-20 21:59:43 <coinheavy> oh sorry — I”m thinking about it through the abstraction of viewing the data from a call to the daemon (rpc)
518 2014-06-20 22:00:01 <sipa> rpc has even less to do with it
519 2014-06-20 22:00:12 <sipa> spendability is probably the most essential consensus concet
520 2014-06-20 22:00:55 <coinheavy> with a call to ‘bitcoind getrawtransaction <txid> 1’ is there a shortcut to determining spendability without processing the entire script to check for OP_return resolution?
521 2014-06-20 22:01:03 <sipa> no
522 2014-06-20 22:01:20 <coinheavy> roger that — thanks for the clarification
523 2014-06-20 22:01:53 <sipa> you are maybe confusing spendability with the concept of "provably unspendable"
524 2014-06-20 22:02:12 <sipa> as far as the protocol rules go, OP_RETURN outputs _are_ spendable, as they have not yet been spent
525 2014-06-20 22:02:48 <sipa> however, because we know no script can possibly ever legally spend them, we bypass it in the database and mark them as unspendable anyway
526 2014-06-20 22:03:15 <sipa> they are provably unspendable, but that is just a shortcut in the software
527 2014-06-20 22:03:41 <sipa> the protocol rules are much simpler: if you can construct a script to satisfy the rules in an unspent output's script, you can spend it
528 2014-06-20 22:04:02 <sipa> cfields: nothing is happening
529 2014-06-20 22:04:10 <sipa> cfields: i think i may need to push a new commit
530 2014-06-20 22:04:38 <coinheavy> thanks for the distinction — that makes sense
531 2014-06-20 22:04:45 <cfields> sipa: sec
532 2014-06-20 22:05:53 <cfields> sipa: at the travis site, when you click on settings at the top-right, 'build pushes' and 'build pull-requests' are on?
533 2014-06-20 22:06:44 <sipa> i don't see any 'settings'
534 2014-06-20 22:06:58 <cfields> it's the stupid gear thing that everyone uses these days :)
535 2014-06-20 22:07:03 <sipa> Step 2:   Adding Travis
536 2014-06-20 22:07:04 <sipa> Once you've enabled one of your projects, add a .travis.yml to your project, push some code, and we'll start processing your builds.
537 2014-06-20 22:07:13 <sipa> no gear thing
538 2014-06-20 22:07:43 <cfields> well, it exists at least...
539 2014-06-20 22:07:57 <cfields> sec, i'll close one of my prs and open a new one
540 2014-06-20 22:08:19 <sipa> already doing
541 2014-06-20 22:10:01 <sipa> done
542 2014-06-20 22:10:07 <cfields> https://travis-ci.org/bitcoin/secp256k1/builds/28081844
543 2014-06-20 22:10:08 <cfields> :)
544 2014-06-20 22:10:27 <cfields> thanks for hooking that up
545 2014-06-20 22:11:14 <cfields> crap, gtg.
546 2014-06-20 22:11:17 <sipa> is that service free?
547 2014-06-20 22:11:35 <maaku> travis? yes
548 2014-06-20 22:11:39 <maaku> very high quality too
549 2014-06-20 22:11:45 <sipa> crazy
550 2014-06-20 22:11:53 <maaku> free for open source
551 2014-06-20 22:12:27 <jgarzik> nice
552 2014-06-20 22:14:23 <maaku> sipa: well, i'd say the same about github ;)
553 2014-06-20 22:15:06 <sipa> true
554 2014-06-20 22:37:37 <jgarzik> sipa, thanks a bunch for the univalue review.  The UniValue class definitely needs nit-picking on small details (like pass-by-const-ref)
555 2014-06-20 22:38:21 <sipa> jgarzik: i've skipped the hard parts for now, but i like the simplicity :)
556 2014-06-20 22:38:45 <sipa> and no objections to replacing jsonspirit with such a design
557 2014-06-20 22:40:05 <gmaxwell> I saw that code and was very happy.
558 2014-06-20 22:40:30 <jgarzik> besides resource advantages (UniValue generated code much smaller than json-spirit), json-spirit forces us to use multiple classes (Array, Object, ..) when the underlying behavior is really more mutable than that.
559 2014-06-20 22:40:40 <jgarzik> Also, UniValue stores numbers as string, a la sqlite.
560 2014-06-20 22:40:49 <jgarzik> Major ++ for us, IMO