1 2014-04-05 00:04:57 <Happzz> when i remove an address from the Recieve tab in the new bitcoin-qt, what happens to it
  2 2014-04-05 00:05:07 <Happzz> does it stay in the wallet but just removed from the UI?
  3 2014-04-05 00:20:05 <maaku> Cory gmaxwell: I'm running an exhaustive search to see CScriptNum differs from CBigNum for 32-bit integers
  4 2014-04-05 00:20:23 <maaku> should take a few hours ... otherwise 3965 looks good
  5 2014-04-05 00:22:50 <Cory> coryfields is probably your man, maaku.
  6 2014-04-05 00:23:12 <coryfields> heh
  7 2014-04-05 00:23:36 <maaku> whoops, sorry auto-tab
  8 2014-04-05 00:23:38 <coryfields> maaku: you mean you're looping em all? I did that at one point
  9 2014-04-05 00:24:09 <maaku> yeah nMinOperandValue to nMaxOperandValue, and all 4-byte vch possibilities
 10 2014-04-05 00:24:10 <coryfields> -int_max..int_max, at least
 11 2014-04-05 00:24:18 <coryfields> maaku: great, thanks
 12 2014-04-05 00:24:43 <kazcw> -int_max? isn't that int_min+1?
 13 2014-04-05 00:24:52 <coryfields> maaku: if you think there's something missing from the tests, be sure to PR or let me know
 14 2014-04-05 00:25:19 <coryfields> kazcw: er, int_min :)
 15 2014-04-05 00:25:47 <maaku> coryfields: that conversion code was the only spot where I thought there might be hidden gotcha edge cases
 16 2014-04-05 00:25:54 <maaku> kazcw: yes, but ones-complement
 17 2014-04-05 00:26:31 <coryfields> maaku: i kept thinking of more cases every time i walked away for a few hours
 18 2014-04-05 00:26:47 <coryfields> so i definitely wouldn't be surprised if there was another still lurking
 19 2014-04-05 00:27:18 <maaku> well the math stuff is pretty straight forward at least, unless there are hidden bugs in openssl you're not implementing
 20 2014-04-05 00:27:58 <maaku> i guess I should loop through 2*nMaxOperandValue to handle overflow, but I see you have some overflow edge cases in there
 21 2014-04-05 00:28:05 <coryfields> maaku: it's not that so much as mirroring the old usage
 22 2014-04-05 00:29:21 <coryfields> maaku: for example, getint() doesn't do what you'd expect, but its behavior was lifted from the old way
 23 2014-04-05 00:30:41 <maaku> coryfields: what would you expect getint to do?
 24 2014-04-05 00:31:05 <coryfields> maaku: i'd expect it to be bounded by the operand range or total range
 25 2014-04-05 00:31:37 <maaku> oh yeah the numeric_limits discrepency
 26 2014-04-05 00:32:37 <Happzz> anyone?
 27 2014-04-05 00:32:53 <maaku> btw, that would be a nice unit test to add
 28 2014-04-05 00:33:03 <maaku> to make sure no one 'fixes' that bug later
 29 2014-04-05 00:33:14 <coryfields> maaku: it's there. 'fix' those bounds and the tests explode :)
 30 2014-04-05 00:33:34 <maaku> cool
 31 2014-04-05 00:33:46 <coryfields> in that case, the bignum.getint() != scriptnum.getint()
 32 2014-04-05 00:34:05 <coryfields> so the scriptnum_test fails
 33 2014-04-05 00:37:01 <jaakkos> is there a problem with the 0x4c after OP_RETURN here? https://bitcointalk.org/index.php?topic=453086.0 - shouldn't 0x4b be the max length and 0x4c would be OP_PUSHDATA1 ? or is https://en.bitcoin.it/wiki/Script#Constants out of date?
 34 2014-04-05 00:37:14 <maaku> coryfields: i'll post to your PR sometime later, after my exhaustive test finishes
 35 2014-04-05 00:37:29 <maaku> right now my laptop is generating more heat than is healthy, so I'll find something else to do :)
 36 2014-04-05 00:38:05 <coryfields> maaku: i really appreciate it.
 37 2014-04-05 00:46:58 <jiffe98> is the compiled version of bitcoinjs supposed to work the same as the provided source?  Using the examples trying to call console.log(key.getPub().getAddress()), key.getPub() is returning a byte array
 38 2014-04-05 00:47:14 <kristov> hello
 39 2014-04-05 00:47:59 <kristov> bitcoin core 0.9 doesn't work with tails linux any longer. would you recommend that tails linux users stick with the pre 0.9 version of bitcoin-qt?
 40 2014-04-05 00:48:54 <gmaxwell> kristov: 'doesn't work' is a little vague.
 41 2014-04-05 00:49:00 <melik> kristov: it doesn't compile?
 42 2014-04-05 00:49:17 <kristov> you can't really compile stuff in tails linux. basic programs like "make" are missing.
 43 2014-04-05 00:49:53 <kristov> sorry 1 sec, i will give a more specific user story...
 44 2014-04-05 00:50:11 <coryfields> i assume it's got an older glibc
 45 2014-04-05 00:51:05 <petcat100> what's the point of tails if you can't compile software on it
 46 2014-04-05 00:51:24 <kristov> it's most intended to run the programs that are pre-included and pre-configured.
 47 2014-04-05 00:51:31 <kristov> sadly, bitcoin core is not included.
 48 2014-04-05 00:51:53 <petcat100> so it's like an appliance?
 49 2014-04-05 00:52:11 <melik> petcat100: like a microwave?
 50 2014-04-05 00:52:25 <petcat100> melik: yeah
 51 2014-04-05 00:52:39 <melik> kristov: can it microwave my food?
 52 2014-04-05 00:52:44 <melik> okay i'll stop joking around.
 53 2014-04-05 00:52:56 <kristov> :-P
 54 2014-04-05 00:55:23 <olalonde> mornin'
 55 2014-04-05 01:20:30 <kristov> im back. If I run bitcoin-qt binary 32-bit on tails linux you get: "/lib/libc.so.6: version `GLIBC_2.15' not found" and "/usr/bin/libstdc++.so.6: version `GLIBCXX_3.4.15' not found"
 56 2014-04-05 01:20:35 <kristov> cc gmaxwell
 57 2014-04-05 01:21:31 <vetch> would you really want to download and verify 20gb of blocks over tor?
 58 2014-04-05 01:21:39 <vetch> (you don't want to)
 59 2014-04-05 01:21:49 <kristov> it's possbile to download them on one computer and move them over.
 60 2014-04-05 01:22:16 <GAit> why not dowloading the entire blockchain from a fast service and then verify what matters via SPV ?
 61 2014-04-05 01:22:16 <vetch> using a system designed to not retain any data over sessions for your wallet seems fairly foolish.
 62 2014-04-05 01:22:44 <kristov> all you need to retain is the wallet.dat file, which you can store on a USB drive or whatever.
 63 2014-04-05 01:23:06 <vetch> yeah, and to leave your computer running for however many weeks a sync takes.
 64 2014-04-05 01:23:23 <GAit> kristov: you could use electrum running from the usb drive too
 65 2014-04-05 01:23:25 <kristov> you can even keep the blockchain state on said USB drive and it using -datadir
 66 2014-04-05 01:23:31 <GAit> true
 67 2014-04-05 01:23:42 <kristov> GAit: electrum is unfortunately equally fail on Tails Linux :(
 68 2014-04-05 01:23:48 <GAit> but i wouldn't do the initial sync on tor
 69 2014-04-05 01:24:21 <vetch> kristov: make a virtualenv then. it's just python, you can pack all the dependencies in a folder.
 70 2014-04-05 01:24:29 <GAit> kristov: i got electrum to work on tails, you have to setup the root password first and then install packages
 71 2014-04-05 01:24:37 <GAit> or get electrum from github
 72 2014-04-05 01:24:50 <vetch> virtualenv.
 73 2014-04-05 01:24:54 <GAit> yeah virtualenv
 74 2014-04-05 01:24:57 <kristov> GAit: orly?
 75 2014-04-05 01:25:15 <vetch> ya rly
 76 2014-04-05 01:25:17 <GAit> kristov: you don't need root, just if you want to install apt packages
 77 2014-04-05 01:25:20 <kristov> what's "virtualenv"
 78 2014-04-05 01:25:47 <vetch> virtual environments for Python. a folder containing the python binary and everything else needed, including libraries.
 79 2014-04-05 01:26:50 <GAit> does electrum connect to more than one electrum server at the time?
 80 2014-04-05 01:27:27 <kristov> GAit: so how do I get bitcoin-qt4 and pip on tails?
 81 2014-04-05 01:27:37 <vetch> GAit: yes.
 82 2014-04-05 01:27:52 <vetch> pip is part of the virtual environment.
 83 2014-04-05 01:28:04 <GAit> vetch: at the same time or serially until it finds one that works
 84 2014-04-05 01:28:45 <vetch> GAit: in parallel with a main server for data requests. basically only talks to the other servers to make sure the main server isn't falling behind.
 85 2014-04-05 01:29:05 <GAit> makes sense, or that the main server is talking bullshit
 86 2014-04-05 01:29:30 <vetch> zero knowledge proofs.
 87 2014-04-05 01:29:54 <vetch> the main server can withhold information, but that's a risk in any spv system.
 88 2014-04-05 01:31:24 <GAit> vetch: how would this compare to multibit in your opinion?
 89 2014-04-05 01:33:06 <vetch> GAit: same threat model, only multibit uses random peers in the network rather than dedicated servers. multibit can (but doesn't) add garbage to their bloom filters so it could be a lot more private than electrum if it wanted. an electrum wallet knows the size and contents of a clients wallet exactly.
 90 2014-04-05 01:33:44 <GAit> yeah but you could ask different servers for different keys
 91 2014-04-05 01:34:14 <GAit> and verify all via SPV
 92 2014-04-05 01:34:32 <kristov> vetch: where should I install virtualenv to?
 93 2014-04-05 01:34:39 <GAit> kristov: usb
 94 2014-04-05 01:34:42 <vetch> the electrum server only needs to know the master public ket of the electrum client wallet rather than requesting individual addresses. I imagine this is done to save on bandwidth.
 95 2014-04-05 01:35:04 <GAit> i thought it could do both
 96 2014-04-05 01:36:01 <vetch> GAit: there's also very few electrum servers really. you could correlate between servers at different periods to get a larger picture of their wallet. you can't protect against electrum servers having knowledge of the client in their current model.
 97 2014-04-05 01:42:45 <kristov> any objections to people using bitcoin-qt 0.8.6? I know it doesn't have the same tx malleability protection, but I didn't see any other security -related changes in the 0.9 changelog
 98 2014-04-05 01:44:24 <Luke-Jr> kristov: at least upgrade to 0.8.7
 99 2014-04-05 01:44:48 <kristov> Luke-Jr: I don't see it here
100 2014-04-05 01:44:56 <kristov> pastefail
101 2014-04-05 01:45:06 <kristov> https://bitcoin.org/bin/
102 2014-04-05 01:45:12 <gmaxwell> kristov: your issue is fixed and testing is requested: https://github.com/bitcoin/bitcoin/pull/3914
103 2014-04-05 01:45:32 <Luke-Jr> kristov: because it's not released due to lack of testing (expected to never get enough, since everyone should be using 0.9.0)
104 2014-04-05 01:45:47 <gmaxwell> kristov: if you follow the pulltester links you can find binaries.
105 2014-04-05 01:46:26 <kristov> thank you!
106 2014-04-05 01:51:29 <kristov> Is running bitcoin-cli.static supposed to launch a GUI? it just printed out the command line options for me instead
107 2014-04-05 01:54:10 <vetch> no, that's just the RPC client
108 2014-04-05 03:06:55 <gmaxwell> Anyone know who this person is? https://github.com/oleksii-mdr
109 2014-04-05 03:11:13 <gmaxwell> or https://github.com/jdtaylor/ ?
110 2014-04-05 03:16:40 <vetch> gmaxwell: what's the reason for asking?
111 2014-04-05 03:20:44 <gmaxwell> I suspect they are either up to good, or no good.
112 2014-04-05 03:28:03 <phrackage> Before I go making up my own DB - is there any online service or API that allows me to get the fiat equivalent of historical blockchain transactions (for a couple of popular exchanges)?
113 2014-04-05 03:29:37 <uiop> phrackage: do you mean "the blockchain" or do you mean "historical trades on certain exchanges" ?
114 2014-04-05 03:30:20 <phrackage> i mean "the blockchain"
115 2014-04-05 03:31:41 <uiop> you can get the data either from bitcoind (through various means, i'm not sure the current "best" way) or you could query blockchain.info via their json api (depending on how data you're after)
116 2014-04-05 03:33:36 <gmaxwell> phrackage: this is offtopic for this channel, you would have done better to just ask in #bitcoin but I am not aware of any such thing.
117 2014-04-05 03:33:59 <gmaxwell> uiop: and no, he's asking for "fiat equivalent" (whatever precisely that means)
118 2014-04-05 03:34:04 <phrackage> ok thanks
119 2014-04-05 03:35:35 <vetch> gmaxwell: what sort of no good?
120 2014-04-05 03:39:14 <vetch> gmaxwell: I see they both have branches of bitcoin in their accounts but the one extra commit seems harmless.
121 2014-04-05 03:40:28 <Luke-Jr> gmaxwell: IMO it means "translating bitcoin values to USD/etc at the time of the trade"
122 2014-04-05 03:41:28 <Luke-Jr> which would be not a bad idea
123 2014-04-05 03:41:33 <warren> wumpus: can I help with the bitcoin transifex stuff?
124 2014-04-05 03:41:47 <Luke-Jr> when asked how many bitcoins I've ever traded, it's kinda.. sounds like a lot to n00bs lol
125 2014-04-05 03:42:14 <vetch> gmaxwell: oh wait, there's a lot more than that. GitHub has a confusing interface.
126 2014-04-05 03:43:25 <Luke-Jr> warren: what do you need?
127 2014-04-05 03:44:19 <warren> Luke-Jr: I'd like to help maintain it, to keep the source in sync more often and engage the translators
128 2014-04-05 03:44:28 <warren> Luke-Jr: including a mailing list for the translators
129 2014-04-05 03:44:45 <Luke-Jr> warren: what's stopping you? :p
130 2014-04-05 03:45:14 <warren> Luke-Jr: lack of maintainer permission, which I see you have
131 2014-04-05 03:46:43 <Luke-Jr> warren: is there anything specific I can do to help, or you just want maintainer permission to do it directly? (in which case, I should check with tcatm)
132 2014-04-05 03:47:38 <warren> Luke-Jr: I'd like maintainer permission to do it directly, and need to ask everyone if they're OK with a certain approach to workaround the problem where they don't handle branches.
133 2014-04-05 03:48:26 <warren> Of course I wouldn't change anything without consensus
134 2014-04-05 03:48:35 <Luke-Jr> elaborate? :p
135 2014-04-05 03:48:53 <Luke-Jr> if it's long, maybe the dev ML should get an overview of the plan
136 2014-04-05 03:49:22 <warren> Luke-Jr: basically, in the long period of time after 0.8.x branched from master it was impossible for people to get fixed translations into 0.8 releases.  they were refused in PR's, and changes to transifex would not be in the next several 0.8 releases.
137 2014-04-05 03:50:57 <Luke-Jr> warren: right. I meant how to solve it
138 2014-04-05 03:56:35 <warren> Luke-Jr: I'll explain this later, I'm tired.
139 2014-04-05 05:03:57 <olalonde> what are the rev*.dat files for in blocks/?
140 2014-04-05 05:22:06 <maaku> olalonde: undo blocks
141 2014-04-05 05:22:33 <maaku> contains the information necessary to step backwards when performing a reorg
142 2014-04-05 05:24:39 <msvb-lab> Morning folks.
143 2014-04-05 05:30:56 <olalonde> maaku: I see. I thought reorgs just involved changing the pointer to the tip of the longest branch and rescanning from the common parent of last chain and new chain
144 2014-04-05 05:32:23 <olalonde> well that's my high level understanding.. I guess bitcoind uses this scheme for a good reason
145 2014-04-05 05:32:53 <olalonde> rescanning until*
146 2014-04-05 05:36:05 <kazcw> The node keeps track of the utxo set (because that's what you need to verify transactions). Changing the tip of the active chain alters the utxo set.
147 2014-04-05 05:39:17 <olalonde> ah ok makes sense. so the rev files kind of track which utxos each blocks add/remove from the set so you can run the operation backwards until you reach the common block to both chains
148 2014-04-05 05:40:00 <olalonde> it's a kind of optimization so you don't have to rescan the whole chain right?
149 2014-04-05 05:49:05 <vetch> olalonde: basically. the rev files are just undo instructions so you can back out of a chain and down an alternate one.
150 2014-04-05 05:49:24 <olalonde> makes sense
151 2014-04-05 05:49:33 <vetch> otherwise you would have to, as you say, rebuild from zero again.
152 2014-04-05 06:51:22 <fanquake> ;;blocks
153 2014-04-05 06:51:23 <gribble> 294312
154 2014-04-05 09:11:03 <wumpus> !seen warren
155 2014-04-05 09:11:04 <gribble> warren was last seen in #bitcoin-dev 5 hours, 14 minutes, and 26 seconds ago: <warren> Luke-Jr: I'll explain this later, I'm tired.
156 2014-04-05 09:11:09 <askew> wumpus: warren(~warren@fedora/wombat/warren) was on #bitcoin-dev 19 minutes 10 seconds ago.
157 2014-04-05 09:11:35 <Luke-Jr> who invited askew? O.o
158 2014-04-05 09:52:41 <Happzz> technical question
159 2014-04-05 09:53:03 <Happzz> if i send 1 bitcoin to some address, and use a very low fee that will take a few days to confirm, then broadcast that
160 2014-04-05 09:53:19 <Happzz> and 5 minutes later make another transaction, spending the same bitcoin, and send it to another address
161 2014-04-05 09:53:23 <Happzz> but this time use a decent fee
162 2014-04-05 09:53:38 <Happzz> would nodes reject the later tx, or would they take it and confirm it faster, because of the okay fee?
163 2014-04-05 09:53:54 <Apocalyptic> depends if the miner implements CPFP
164 2014-04-05 09:54:43 <airbreather> Happzz: really, it depends on the node... I think the Satoshi client wouldn't relay the later one unless it hasn't already seen the earlier one, right?
165 2014-04-05 09:55:29 <Happzz> airbreather that's basically my question
166 2014-04-05 09:55:45 <airbreather> (the "right?" was aimed at other folks to confirm my understanding)
167 2014-04-05 09:56:15 <Apocalyptic> Happzz, no that's not your question
168 2014-04-05 09:56:24 <Apocalyptic> what airbreather states is obvious
169 2014-04-05 09:56:32 <Happzz> i can rephrase the question: if you send some bitcoins with an insufficient fee and then send them AGAIN, but with a sufficient fee - would the later tx "save" the coins from being lost due to never being confirmed?
170 2014-04-05 09:56:34 <Apocalyptic> you're asking about whether it will confirm faster or not
171 2014-04-05 09:57:10 <Apocalyptic> Happzz, I answered
172 2014-04-05 09:57:15 <Apocalyptic> <Apocalyptic> depends if the miner implements CPFP
173 2014-04-05 09:57:29 <Apocalyptic> CPFP stands for child pays for parent
174 2014-04-05 09:57:56 <Apocalyptic> aka child tx pays for parent tx
175 2014-04-05 09:57:57 <Happzz> Apocalyptic and if you convert that to technical terms - would the later tx be relayed and thus mined and thus confirmed _at all_ (if it will be relayed, mined and confirmed then it all should happen faster)
176 2014-04-05 09:58:06 <Happzz> uhm
177 2014-04-05 09:58:07 <Happzz> okay
178 2014-04-05 09:58:10 <Apocalyptic> child tx is what you call the later tx
179 2014-04-05 09:58:25 <Happzz> oh, so i lost you here.
180 2014-04-05 09:58:28 <Happzz> can you explain that part?
181 2014-04-05 09:58:42 <Apocalyptic> " would the later tx be relayed and thus mined"
182 2014-04-05 09:58:57 <Apocalyptic> you know that a tx being relayed is no way linked to it being mined ?
183 2014-04-05 09:59:22 <Apocalyptic> these two events are not correlated in any way
184 2014-04-05 09:59:33 <airbreather> I think technically, CPFP only helps in the situation where you use the unconfirmed coins as input to another transaction with a fee that covers both the new transaction and the parent transaction
185 2014-04-05 09:59:45 <Apocalyptic> that's right
186 2014-04-05 09:59:55 <Happzz> Apocalyptic i know, but if a miner gets both of them, it'll most likely deal with the better fee one
187 2014-04-05 09:59:57 <Apocalyptic> i think that's his case
188 2014-04-05 10:00:12 <Happzz> no, that's NOT the case
189 2014-04-05 10:00:14 <airbreather> It looks like Happzz is asking about using a double-spend to replace a "doomed" transaction with one that has a chance of happening
190 2014-04-05 10:00:17 <Happzz> i'm talking about double spending
191 2014-04-05 10:00:21 <Apocalyptic> Happzz, so your later tx is not spending the coins from the unconfirmed tx but it's a double spend ?
192 2014-04-05 10:00:50 <Apocalyptic> then the later would not be relayed at all while it's in the mempool, fee is irrelevant
193 2014-04-05 10:00:53 <Happzz> yes. a double spend. i'm asking if a double-spend (with a better fee at the later tx) will "save" the earlier one
194 2014-04-05 10:02:03 <airbreather> I think the Satoshi client will drop the "doomed" transaction from the mempool after some period of time
195 2014-04-05 10:02:23 <Apocalyptic> according to sipa only if it's restarted
196 2014-04-05 10:02:29 <airbreather> heh
197 2014-04-05 10:02:53 <Apocalyptic> it will never drop on its own
198 2014-04-05 10:03:03 <airbreather> The more nodes that reject the transaction, the longer it'll take for the new transaction to propagate to a miner
199 2014-04-05 10:03:37 <airbreather> Worst-case, I think you can submit the raw transaction directly to Eligius, which has been helpful in the past, via eligius.st/~wizkid057/newstats/pushtxn.php
200 2014-04-05 10:05:09 <Apocalyptic> if it's in the eligius's mempool that won't help
201 2014-04-05 10:06:15 <airbreather> In any case, to answer the original question, it's possible but frustrating
202 2014-04-05 10:06:46 <Apocalyptic> I don't get what he means by "save" the coins
203 2014-04-05 10:06:51 <Apocalyptic> there is nothing to be saved really
204 2014-04-05 10:07:09 <airbreather> try not to get into that situation -- if you can spend one of the outputs from the original transaction, then you can take advantage of CPFP
205 2014-04-05 10:55:08 <vetch> Happzz: the second would be a double spend and rejected by the nodes you sent the first to, no matter the fee.
206 2014-04-05 10:57:19 <Luke-Jr> vetch: assuming current node implementations
207 2014-04-05 10:58:46 <vetch> Luke-Jr: if we don't then almost any question can have a silly answer. I take your point though, this is something liable to change soon.
208 2014-04-05 11:01:49 <Apocalyptic> was there some actual meaningfull improvement in memory management since "version" : 80600 ?
209 2014-04-05 11:53:08 <archrs> any web devs on?
210 2014-04-05 11:53:09 <archrs> BOUNTY [ANN] --  django-bitcoin -- 200,000H2O : https://bitcointalk.org/index.php?topic=557620
211 2014-04-05 11:54:35 <vetch> archrs: that's completely off topic. not even bitcoin.
212 2014-04-05 11:55:00 <archrs> it is bitcoin
213 2014-04-05 11:55:07 <archrs> you need to convert it from btc to something else :)
214 2014-04-05 11:55:15 <speed-> why do you need to convert it?
215 2014-04-05 11:55:25 <archrs> there are some nuances
216 2014-04-05 11:55:25 <speed-> it's same RPC, just change BITCOIND_CONNECTION_STRING = "http://bitcoinuser:password@localhost:8332"
217 2014-04-05 11:55:41 <vetch> archrs: no, this channel is about bitcoin. your post is not.
218 2014-04-05 11:55:43 <archrs> also branding and i'd like the newest patches integrated
219 2014-04-05 11:56:08 <speed-> and yea #h2o-dev probably hehe :p
220 2014-04-05 11:56:32 <archrs> thx for the heads up tho speed-
221 2014-04-05 11:56:37 <s7r> so to prove i control a regular address, one sig address, i can just sign a message / random string with the privkey for that address and that's it. what about a multisig address 3/3 ? if i have one pubkey (one signature right) in that address, can I prove in any way i control or partially control that multisig address?
222 2014-04-05 11:57:29 <vetch> s7r: signing a random string is ill advised. a "proof" can be re used elsewhere. you need to make it clear in the message what you are signing to prove.
223 2014-04-05 11:59:51 <s7r> vetch but a 3/3 multisig address - i have one pubkey there just one . i can sign and what will this prove? that i owe it totally or partially
224 2014-04-05 11:59:59 <s7r> ca anyone see i have just 1 signature in there and it's a 3/3 address?
225 2014-04-05 12:01:12 <vetch> if you have the script public then sure, that proves you are in control of a portion of thee multisig.
226 2014-04-05 12:02:12 <vetch> the multisig script can just be verified to contain that particular address, and that the script also matches the encoded p2sh address.
227 2014-04-05 12:02:56 <vetch> just don't sign vague messages.
228 2014-04-05 12:03:38 <s7r> hmmm .. so i have an address. that address is 1 part of a 3/3 multisig address. i sign a message with that 1 address. the receipient of that signed message is able to verify and confirm that i control partyally (1 out of 3) signatures i that multisig address?
229 2014-04-05 12:04:22 <vetch> only if the script for the multisig is public too. without the script there's no way of knowing what a particular p2sh address is doing.
230 2014-04-05 12:08:22 <s7r> vetch and that script of multisig.. is it any danger to make it public?
231 2014-04-05 12:09:27 <vetch> it will become public when a spend is made from the address anyway. it is immutable and just describes the conditions that must be met to spend.
232 2014-04-05 12:10:55 <s7r> vetch so there is no danger or security flaw to make it public before the spend takes place
233 2014-04-05 12:11:49 <vetch> no more than with any other type of spend. in a normal spend the script is public as soon as funds are sent to the address. with p2sh the script is hidden and only made public by a spend from the address.
234 2014-04-05 12:12:20 <vetch> it means you can have a p2sh address with many spends to it (say a donation address) without every single transaction having to contain the massive script.
235 2014-04-05 12:12:49 <vetch> p2sh addresses contain multiple large public keys and are naturally quite large as a result.
236 2014-04-05 12:18:07 <s7r> wait .. p2sh is different than multisig?
237 2014-04-05 12:18:36 <vetch> p2sh is used for multisig.
238 2014-04-05 12:20:42 <s7r> so a 3/3 multisig address == p2sh address? because i am getting little confused
239 2014-04-05 12:21:01 <GAit> there's two kinds of multisig, one getting slowly deprecated and not accepted by some miners and P2SH
240 2014-04-05 12:22:26 <s7r> GAit so what is the difference
241 2014-04-05 12:22:34 <s7r> ?
242 2014-04-05 12:23:47 <hearn> er
243 2014-04-05 12:23:52 <hearn> sigh
244 2014-04-05 12:24:12 <hearn> it’s not being “slowly deprecated"
245 2014-04-05 12:24:14 <hearn> but whatever
246 2014-04-05 12:24:32 <s7r> ok - p2sh how you generate it any different than a normal multisig?
247 2014-04-05 12:24:33 <GAit> hearn: sorry maybe I got that wrong, I remember someone suggesting it
248 2014-04-05 12:25:01 <hearn> there are some people who think p2sh is the bees knees and should be used for everything. that is not a globally held view
249 2014-04-05 12:25:18 <GAit> hearn: Luke-Jr said gradually filtered by miners https://github.com/bitcoin/bitcoin.org/pull/360#issuecomment-38977911
250 2014-04-05 12:25:53 <GAit> so i didn't realize it wasn't a global held thing
251 2014-04-05 12:26:05 <hearn> luke has a long history of using his (former) pool to try and filter things he doesn’t like
252 2014-04-05 12:26:36 <GAit> i'll be more carefull repeating things without triple checking them :)
253 2014-04-05 12:27:56 <s7r> https://github.com/OutCast3k/bitcoin-multisig/
254 2014-04-05 12:28:14 <s7r> this script here generates deperecated multisig addresses or p2sh safe ones?
255 2014-04-05 12:29:16 <wumpus> GAit: well, you weren't wrong, people just disagree on this; the problem with the non-p2sh multisig is that it can be misused to store larger amounts of data in an output
256 2014-04-05 12:32:54 <vetch> wumpus: ideally wouldn't we want to have people proving that the hashes they submit are indeed hashes?
257 2014-04-05 12:34:03 <GAit> out of band proof?
258 2014-04-05 12:34:33 <wumpus> vetch: sure, ideally, but in the case of p2sh it's a short hash (just as long as the normal pubkey hash) so it's never problematic
259 2014-04-05 12:59:38 <hearn> it’s a rather arbitrary line in the sand
260 2014-04-05 12:59:52 <hearn> “160 bits is OK, but 256 bits is bad”
261 2014-04-05 13:08:15 <dexX7> wumpus: actually p2sh is cheaper to store data at some point, i think.. at least in the case where you include one valid pubkey in each multisig output for redemption purposes
262 2014-04-05 13:24:25 <wumpus> dexX7: that's an additional advantage indeed, the data doesn't end up in the UTXO set but just in the input
263 2014-04-05 13:27:51 <wumpus> hearn: right, everyone agrees that limits are needed, but where to place those limits is pretty much arbitrary
264 2014-04-05 13:29:19 <dexX7> that too, but this is what i meant: p2sh: 1/15 (stores up to 14 data packs while redeemable), standard: 1/3 (stores only two data packs while redeemable - per output though, but the ratio is much worse)
265 2014-04-05 15:10:03 <petertodd> wumpus, vetch: I need to write it up fully for the -dev list, but it appears that the P2SH^2 method of proving hashes are indeed hashes rather perversely makes it cheaper to do proof-of-publication of arbitrary data, and the proof requires an unspendable utxo to be made each time
266 2014-04-05 15:10:34 <petertodd> wumpus, vetch: (well, cheaper in scenarios where publishing via scriptSig has been made expensive)
267 2014-04-05 15:11:47 <petertodd> wumpus, vetch: the problem is that proof-of-publication is distinct from storage, easiest to see in the case of announce/commit sacrifices where there's no need to store the data at al
268 2014-04-05 15:18:34 <vetch> petertodd: it would just be nicer overall if people didn't treat the blockchain as their own personal data storage.
269 2014-04-05 15:19:26 <petertodd> vetch: meh, it's a useful and highly secure proof-of-publication service that can be used as a building block for many other things
270 2014-04-05 15:22:01 <vetch> petertodd: if everybody believed that we would have an even more bloated, heavy blockchain than we already do. that sort of thinking only works when there's a small number of services freeloading.
271 2014-04-05 15:23:24 <vetch> the fact that you can't distinguish a hash from any other 256 bit integer means that it's fairly impossible to stop people including some form of arbitrary data, but all the same.
272 2014-04-05 15:24:11 <sipa> gmaxwell has a scheme that actually does prevent using it for data storage (requiring you to have a preimage for the hash being stored)