1 2015-01-04 00:07:37 <justanotheruser> extrapolation doesn't usually work with bitcoin in general does it :P
  2 2015-01-04 00:09:26 <moa> extrapolation doesn't usually work in general.
  3 2015-01-04 00:17:29 <nullops> Why is OP_RETURN limited to 40 bytes, when I can just use PUSH_DATA in a redeemscript and use 10,000 bytes?
  4 2015-01-04 00:18:21 <justanotheruser> nullops: What standard transaction allows 10,000 byte redeem scripts?
  5 2015-01-04 00:18:40 <nullops> justanotheruser: pay to script hash
  6 2015-01-04 00:18:47 <nullops> or is it 9000 bytes? whatever. same thing
  7 2015-01-04 00:18:58 <justanotheruser> that is standard?
  8 2015-01-04 00:19:00 <nullops> yes
  9 2015-01-04 00:19:10 <justanotheruser> are you sure?
 10 2015-01-04 00:19:12 <nullops> yes
 11 2015-01-04 00:19:28 <nullops> your scriptsig is allowed to be very large
 12 2015-01-04 00:20:59 <nullops> just seems stupid to me that theres a 40 byte limit on OP_RETURN, but no limit on scriptsig. is that for political purposes only so reddit and luke-jr don't throw a hissy fit if we allow OP_RETURN to be larger?
 13 2015-01-04 00:22:03 <justanotheruser> well the 40 byte limit is for harm reduction
 14 2015-01-04 00:22:06 <kkode> for some reason bitcoind isn't writing data to the datadir specified in the argument. any ideas?
 15 2015-01-04 00:22:23 <justanotheruser> that way people can store data in the blockchain and only hurt it a little bit rather than a lot
 16 2015-01-04 00:22:25 <nullops> I'm genuinely curious why the devs put a limit on OP_RETURN but not scriptsigs?? I either recommend reducing scriptsigs limits bytes, or increasing OP_RETURN
 17 2015-01-04 00:23:15 <nullops> any devs who want to chime in, i'll be idling here all night..
 18 2015-01-04 00:24:26 <justanotheruser> "This allows payment to non-standard pubkey script almost as easily as payment to standard pubkey scripts. However, when you go to spend that output, peers and miners using the default settings will check the redeem script to see whether or not it’s a standard pubkey script. If it isn’t, they won’t process it further—so it will be impossible to spend that output until you find a miner who disables the default settings."
 19 2015-01-04 00:24:27 <petertodd> justanotheruser: ~1600 bytes passes IsStandard; 10,000 bytes is the hard limit set by EvalScript()
 20 2015-01-04 00:25:03 <petertodd> nullops: yeah, this is a political thing... they don't want to "give the impression" that op-return is encouraged
 21 2015-01-04 00:26:04 <justanotheruser> petertodd: is that quote correct?
 22 2015-01-04 00:26:30 <petertodd> justanotheruser: that's not a quote, it's a paraphrase :) (though I could probably find that exact quote on github somewhere)
 23 2015-01-04 00:27:06 <justanotheruser> its a quote of the developer guide
 24 2015-01-04 00:27:20 <nullops> petertodd: is storing data in scriptsigs some sort of big secret then?
 25 2015-01-04 00:27:41 <petertodd> justanotheruser: oh, sorry, misunderstood you there, that quote above isn't 100% correct
 26 2015-01-04 00:27:51 <justanotheruser> ok gtg
 27 2015-01-04 00:28:38 <petertodd> nullops: lol, open secret, heck, I made a general purpose library enumerate all the ways to publish data with transactions: https://github.com/petertodd/blockpop
 28 2015-01-04 00:28:40 <nullops> petertodd: so, any scriptsig under 1600 bytes regardless of the content, will be mined by default?
 29 2015-01-04 00:29:25 <petertodd> nullops: starting with v0.10, that's mostly true - there's a sigop limit of, IIRC, 16 sigops
 30 2015-01-04 00:30:17 <nullops> http://webbtc.com/script/e6ff83a41715a87dad0b181febfaee2845e2a4334c3ce8bcb6ec697a6cfed5ed:0
 31 2015-01-04 00:30:25 <nullops> thats a huge tx, mined recently
 32 2015-01-04 00:30:55 <petertodd> nullops: yup, I created that redeemScript - decode the hex at the start and you'll see
 33 2015-01-04 00:31:27 <petertodd> nullops: that one does *not* pass IsStandard() on v0.10, however some pools like Eligius don't use IsStandard()
 34 2015-01-04 00:31:49 <petertodd> nullops: blockchain.info's pushtx notably will relay scriptSigs of any size too
 35 2015-01-04 00:31:55 <nullops> The fee was .00072370, or about $0.20 in FIAT for storing 7k of data permanently in the most secure db on earth...  seems cheap to me.
 36 2015-01-04 00:32:20 <petertodd> nullops: don't think of this stuff as *storing* data, think of it as *publishing* data
 37 2015-01-04 00:32:42 <petertodd> nullops: that was proof that some data was published to a very big audience; it's quite possible in the future actually getting that data back will be hard due to pruning
 38 2015-01-04 00:32:55 <nullops> petertodd: wtf.. are you serious?  interesting that Eligius of all pools would be the one to allow 'spam' transactions like this... considering luke-jr's address blacklist patches
 39 2015-01-04 00:33:12 <petertodd> nullops: well, luke-jr is an interesting guy...
 40 2015-01-04 00:33:52 <nullops> how many other miners allow non-standard scriptsigs?
 41 2015-01-04 00:34:15 <petertodd> nullops: Discus Fish was allowing them, and non-standard scriptPubKey's too
 42 2015-01-04 00:34:36 <nullops> is that currently not the case? would be interesting to have a site that shows this info
 43 2015-01-04 00:34:50 <petertodd> nullops: I'm not sure - haven't checked recently
 44 2015-01-04 00:35:09 <petertodd> nullops: very few people use non-std scriptPubKeys for anything; micropayment channels is something where they'd be useful
 45 2015-01-04 00:36:28 <nullops> hmm intesting... brb...
 46 2015-01-04 01:06:21 <fanquake> Has anyone watched the Reproducible Builds talk from 31c3 yet? Or maybe saw it in person?
 47 2015-01-04 01:06:25 <sipa> morcos: thanks for reminding me
 48 2015-01-04 01:15:16 <gmaxwell> nullops: It may be surprising to you, but not everyone is a sociopath who will do whatever they _can_ do, regardless of the harm it causes to others. Because of that drawing boundaries around supported and unsupported uses is useful and changing the software we distribute to enable a behavior which we, with cause, believe to be harmful to most of its users would not make sense. This is doubly true be
 49 2015-01-04 01:15:22 <gmaxwell> cause there is at least some implied promise that behavior that works now will continue to work, so an additional bit of permissiveness imposes a cost on the future.
 50 2015-01-04 01:16:03 <gmaxwell> nullops: as far as scriptsigs go, because they're not under signature the normal ways of using them can easily be stripped out by any node in the network. (And presumably would be, if people started stuffing huge amounts of data into signatures)
 51 2015-01-04 01:32:24 <Juicers25> Bitcoin Fall like a rock 200$ today dont miss it! look at the news wtf.. http://bitcoingreatnews.com/The-Bitcoin-Rock-Dont-Stop/
 52 2015-01-04 02:12:55 <petertodd> gmaxwell: "nullops: as far as scriptsigs go, because they're not under signature the normal ways of using them can easily be stripped out by any node in the network." <- thanks for providing me with a perfect example of how you guys are happy to mislead people on this subject
 53 2015-01-04 02:16:02 <phantomcircuit> petertodd, que?
 54 2015-01-04 02:16:38 <phantomcircuit> er what?
 55 2015-01-04 02:16:45 <phantomcircuit> (remember you dont spanish)
 56 2015-01-04 02:16:49 <gmaxwell> petertodd: huh? the fuck, peter? Care to employ some professionalism?  I have no clue what you're talking about.
 57 2015-01-04 02:18:01 <petertodd> gmaxwell: what nullops and I were just talking about: http://webbtc.com/script/e6ff83a41715a87dad0b181febfaee2845e2a4334c3ce8bcb6ec697a6cfed5ed:0
 58 2015-01-04 02:18:19 <petertodd> gmaxwell: and some might think professionalism involves not calling people sociopaths
 59 2015-01-04 02:18:54 <gmaxwell> petertodd: Thats a label you put on yourself there, not I.
 60 2015-01-04 02:19:42 <petertodd> gmaxwell: I'm not claiming you're calling me a sociopath, just that you're using that term for a whole class of people using bitcoin
 61 2015-01-04 02:20:19 <gmaxwell> And it's the definition of the word; if it really is the case that you feel its right to do whatever you can get away with even if it harms other people, then it's the word that would apply.  Now, I don't think thats true for you; but the fact that it isn't true for most people (including, I think, you) is why it's useful to not endorse things even when they can't be completely prevented.
 62 2015-01-04 02:21:01 <petertodd> well, then in that case I'm happy to say I think you guys intentionally mislead people about what's possible to do with bitcoin
 63 2015-01-04 02:21:18 <gmaxwell> I've encountered people who quite expicitly have said that they'll do whatever they want, at whatever cost it is to others. That kind of person is a rarity. I think the people you think you're defending are largely not like that; though some are just ignorant.
 64 2015-01-04 02:23:14 <gmaxwell> petertodd: The person asked about adding 10,000 bytes of data as a PUSH_DATA in a signature. You failed to point out that such a thing can be _trivially_ stripped out. It didn't for a moment occure to me that you might have been intentionally deceptive for political reasons. Should it have?   I responded, after the guy left, for posterity completing the part you didn't mention.
 65 2015-01-04 02:23:32 <petertodd> I would say they are *less* ignorant than others, and design secure systems rather than insecure alternatives
 66 2015-01-04 02:23:38 <petertodd> gmaxwell: look at that script...
 67 2015-01-04 02:24:01 <petertodd> gmaxwell: I've brought it up multiple times with you
 68 2015-01-04 02:24:15 <sipa> don't think there is anything wrong (even though it is against my personal preference) for you to suggest proof of publication for purposes where it at least benefits the user, but you seem often to argue in favor of it for cases where it does not matter at all. i think that it equally misleading, but overall it leads to a system that scales less and costs more
 69 2015-01-04 02:25:12 <sipa> *is
 70 2015-01-04 02:25:20 <sipa> *because
 71 2015-01-04 02:25:31 <petertodd> sipa: well, I think you're rather mistaken there - I *frequently* argue to *not* use it when it doesn't make sense - notice above how I was correcting nullop's misconception re: data storage and publication for starters
 72 2015-01-04 02:25:41 <sipa> fair enough
 73 2015-01-04 02:26:15 <sipa> can you explain me why you think stealth address transactions cannot be made safe without storage in the chain?
 74 2015-01-04 02:26:30 <petertodd> sipa: equally, note my work on systems that securely function without actually publishing much data in the chain - e.g. the block-chain as anti-replay device
 75 2015-01-04 02:27:23 <sipa> i'll never claim that your work is useless, or that i consider your ideas olandnsuggestiins bad
 76 2015-01-04 02:27:34 <petertodd> sipa: safety is to be atomic - a lost shared secret leads to lost funds in many cases. the alternative is to send recipients transactions via some messaging system, however that leads to awkward cases where you can't spend your funds because you've used up all your txouts
 77 2015-01-04 02:28:11 <gmaxwell> petertodd: what of it? I didn't claim that there was _no_ way to store data in scriptsigs just that "just use a huge pushdata" that he was suggesting doesn't actually work right. You linked to your page describing mechenisms.
 78 2015-01-04 02:28:14 <sipa> that can easily be circumvented using a wallet policy that creates some soare change outputs
 79 2015-01-04 02:28:16 <petertodd> sipa: as I've said many times, the original design for stealth addresses by amir was to do exactly that, and we had to reject it after going through all the ways that funds could get lost
 80 2015-01-04 02:28:53 <petertodd> sipa: indeed, and when you do the math on that you find you're putting more data in the blockchain than just using stealth in the first place
 81 2015-01-04 02:29:11 <sipa> interesting; i don't think i agree though
 82 2015-01-04 02:29:13 <petertodd> sipa: a really awful example being "just create a txout to spend for the tx sending money to the recipient"
 83 2015-01-04 02:29:24 <sipa> duh
 84 2015-01-04 02:29:31 <petertodd> sipa: which *is* how far you need to be able to go to ensure the user can always spend the funds in their wallet
 85 2015-01-04 02:29:40 <gmaxwell> petertodd: that particular tx you linked to uses a huge scrippubkey... which sort of defeats the "store in the scriptsig instead" that the poster was talking about. Though I do see you get a 16x size multiplier. Which is fine enough.
 86 2015-01-04 02:31:53 <petertodd> gmaxwell: no, that's a huge scriptSig - it's a p2sh redemption
 87 2015-01-04 02:33:07 <gmaxwell> petertodd: hm? p2sh redeemscript is limited to the size of a single push. Oh I see it's cascaded. Quite cute. (that viewer is really hard to read)
 88 2015-01-04 02:33:31 <petertodd> gmaxwell: I've told you about that exact address before, and have brought up that technique in discussions many times before
 89 2015-01-04 02:33:37 <petertodd> gmaxwell: e.g. blockpop
 90 2015-01-04 02:33:44 <gmaxwell> Whats blockpop?
 91 2015-01-04 02:34:07 <gmaxwell> petertodd: I have no recollection of that example at all.
 92 2015-01-04 02:34:26 <petertodd> https://github.com/petertodd/blockpop <- generic proof-of-publication decoder
 93 2015-01-04 02:34:36 <petertodd> I find that rather hard to believe...
 94 2015-01-04 02:35:49 <petertodd> heck, my "increase scriptSig IsStandard() size to 1600 bytes pull-req" mentions data-in-blockchain as a consideration for the design
 95 2015-01-04 02:38:44 <gmaxwell> There is no mention of that transaction in any of my logs, public or private, other than the mention here. There is one mention of blockpop without a url in -wizards.  Yes sure, data in blockchain doesn't imply a specific encoding.
 96 2015-01-04 02:46:57 <gmaxwell> petertodd: Had I seen that before I would have pointed out that it would be more efficient with RIPEMD_160.
 97 2015-01-04 02:47:15 <petertodd> gmaxwell: see https://github.com/bitcoin/bitcoin/pull/5286#issuecomment-65928544 for starters
 98 2015-01-04 02:48:27 <gmaxwell> petertodd: never saw it. (and you can see in the message you're responding to, I certantly wasn't thinking about that.)
 99 2015-01-04 02:49:03 <gmaxwell> hm I think I did actually see it but didn't realize what it was.
100 2015-01-04 02:49:16 <gmaxwell> at least "Proof-of-concept developed at the Barclay's Distributed Banking Hackathon to ensure the uniqueness of data published under a topic using proof-of-publication and the Bitcoin blockchain" seems familar to me.
101 2015-01-04 02:49:44 <gmaxwell> I probably read the directly link and not the rest.
102 2015-01-04 02:50:09 <gmaxwell> (e.g. thought it was about commitments to encryption keys in scriptpubkeys)
103 2015-01-04 02:50:41 <petertodd> well, my apologies if that's a genuine mistake, but I'm not going to lie, I find it very hard to believe that you haven't figured out that technique for yourself long ago
104 2015-01-04 02:53:56 <gmaxwell> petertodd: It's obvious, but not obvious that its actually _interesting_. It requires making two transactions, and the amount of data you can fit inside is still bounded, just turns out that 'bounded' happens to be pretty not bounded; which is only obvious if you think about it.
105 2015-01-04 02:54:48 <gmaxwell> as I've also pointed out in the past, I'm generally less concerned about data shoved in signatures.. and certantly haven't given as much thought to preventing 'junk' there.
106 2015-01-04 02:55:04 <petertodd> gmaxwell: which is why what *I* would have told someone like nullops is "yes you can do that with p2sh, but you need two transactions"
107 2015-01-04 02:55:26 <gmaxwell> Except you didn't tell him that.
108 2015-01-04 02:56:12 <petertodd> gmaxwell: I referred him to the actual transaction; that's pretty damn clear and obvious after five minutes of inspecting it
109 2015-01-04 02:57:06 <petertodd> gmaxwell: after all, he found it first, so I suspect he's figured it out by now
110 2015-01-04 02:57:07 <gmaxwell> (and I wasn't aware that you could actually get 10kb in, if you'd presented it as a challenge I probably would have realized it... otoh I might not have supported that IsStandard change if I had;  kinda crappy that you didn't think to disclose that, I see the blockpop repo is considerable older than the IsStandard discussion...)
111 2015-01-04 02:58:36 <petertodd> gmaxwell: I proposed well before gavin changed IsStandard()
112 2015-01-04 03:00:14 <gmaxwell> I'm not suggesting you did anything wrong.
113 2015-01-04 03:00:17 <petertodd> gmaxwell: the commit message specifically calls how "data-in-chain", mentioning how not much has changed because the rest of the commits in the pull-req force the CHECKMULTISIG dummy value to be exactly OP_0
114 2015-01-04 03:00:56 <petertodd> gmaxwell: that's from March 10th - gavin's change is Jun 27th
115 2015-01-04 03:04:53 <Luke-Jr> petertodd: you should have pointed out to nullops that scriptSig never hits the database :p
116 2015-01-04 03:05:25 <petertodd> Luke-Jr: I did, I mentioned pruning specifically as to why he was technically wrong to think it was data storage vs. proof-of-publication
117 2015-01-04 03:05:59 <petertodd> Luke-Jr: of course, in practice, scriptSigs will probably be stored somewhere for the forseeable future
118 2015-01-04 03:06:31 <gmaxwell> petertodd: they aren't cheaply retrievable, which is something that a lot of people talking about this stuff miss though.
119 2015-01-04 03:07:22 <gmaxwell> A lot of people think they can just use the network as a freeform content hash key value like a DHT, and they can't without overhead and state (e.g. keeping track of which block it got mined in, etc.)
120 2015-01-04 03:07:34 <gmaxwell> (I know these are distinctions you know.)
121 2015-01-04 03:08:22 <petertodd> gmaxwell: what does "cheaply retrievable" have to do with publication?
122 2015-01-04 03:08:28 <sipa> nothing
123 2015-01-04 03:08:45 <petertodd> and hell, lots of way to make this stuff cheaply retrievable... if it wasn't cheaply retrievable, SPV wallets wouldn't work
124 2015-01-04 03:08:45 <sipa> but people are often looking for cheaply retrievable
125 2015-01-04 03:10:28 <gmaxwell> petertodd: yea, nothing, except joe-blow who wants to store data is frequently (not always) looking for file storage or a communications channel. Not proof of publication; which is a concept that is still outside most people's thinking.
126 2015-01-04 03:12:00 <petertodd> gmaxwell: like I say, even the people are looking for that - especially censorship resistant communications channels - should be told honestly what the properties of Bitcoin are
127 2015-01-04 03:12:25 <petertodd> gmaxwell: e.g. why I explain how it gives you good ability to detect censorship, not necessarily strong resistance to it
128 2015-01-04 03:13:17 <petertodd> gmaxwell: and e.g. bring up bitmessage in relation: no ability to detect censorship, and unknown levels of resistance to it, but cheap
129 2015-01-04 03:13:49 <gmaxwell> petertodd: far cheaper systems make censorship very detectable. E.g. just having a ack with a hash of the recieved messages; or protocols like old blue give you "all communications stop across a line of censorship".  Bitcoin still is not especially interesting there.
130 2015-01-04 03:17:21 <petertodd> gmaxwell: ...which is also why I explain the difference between two-way and one-way broadcast communications
131 2015-01-04 03:18:33 <petertodd> gmaxwell: hell, I've had this discussion with 100% finance people re: decentralized marketplaces and specifically brought up how a viable model in some cases might be to have a fixed set of market participants who ACK orders
132 2015-01-04 11:04:15 <Tampl_> http://goo.gl/QveNoq FREE. LItcoin, Bitcoin, Dogecoin. Two new bot buttons and casino.  Bot to bitcoin/dogecoin/litecoin... Pass RAR - 17falz http://goo.gl/WLFRPS or  http://rghost.ru/60124584
133 2015-01-04 11:16:35 <melik> http://i.imgur.com/TuIVm5O.png << looking for some feedback on the design.
134 2015-01-04 11:17:34 <op_mul> melik: #bitcoin
135 2015-01-04 11:17:44 <melik> oops
136 2015-01-04 11:17:47 <melik> wrong channel
137 2015-01-04 11:17:57 <melik> sorry
138 2015-01-04 14:43:45 <lclc> anyone has some C++ code that checks if an Bitcoin address is valid?   I could take it from Bitcoin Core, but maybe somebody already did cut the needed parts from there..
139 2015-01-04 14:45:24 <sipa> https://github.com/bitcoin/libbase58 ?
140 2015-01-04 14:51:23 <lclc> mh right, thx
141 2015-01-04 17:02:32 <enkwire> I can't seem to find data on the total number of bitcoin transactions, total number of outputs, and total number of unspent outputs. Anyone know where I can find this?
142 2015-01-04 17:03:41 <crypto_guy> hi, i need a lib to check balance from privet key.
143 2015-01-04 17:03:45 <crypto_guy> php
144 2015-01-04 17:03:49 <sipa> enkwire: bitcoin core logs the total number of transactions in each block and cummulative in debug.log
145 2015-01-04 17:04:18 <sipa> enkwire: you can use gettxoutsetinfo for querying the total number of unspent outputs, and total number of transactions with at least one unspent output
146 2015-01-04 17:04:51 <Luke-Jr> enkwire: why do you think this is useful information?
147 2015-01-04 17:06:22 <enkwire> thanks. It's for teaching purposes--not so important, but just a fact I wanted to include
148 2015-01-04 17:06:47 <Luke-Jr> AFAIK there's nothing keeping track on total number of outputs
149 2015-01-04 18:37:32 <jtimon> Luke-Jr in luke_policy there's your stuff on top of #5180, but I don't like having attributes in the interface...
150 2015-01-04 21:26:51 <laurentmt> hi there !
151 2015-01-04 21:27:04 <laurentmt> Is it possible, with the RPC api, to retrieve the SIGHASH applied to an input ?
152 2015-01-04 22:05:33 <laurentmt> I mean, is there a better solution than decoderawtraction() + "manual" decoding of vin.scriptSig.hex ?
153 2015-01-04 22:08:55 <phantomcircuit> lachesis, iirc there's another parameter to spit out json
154 2015-01-04 23:51:00 <happycamper> hi
155 2015-01-04 23:52:40 <dzyk> привет
156 2015-01-04 23:54:37 <dzyk> Даун новой крипты не будеть
157 2015-01-04 23:54:51 <dzyk> Биток 9.09
158 2015-01-04 23:55:53 <dzyk> Дроч будет
159 2015-01-04 23:56:26 <phantomcircuit> wat