1 2014-02-16 00:48:22 <implr> I've got a question regarding the key reuse issue
2 2014-02-16 00:48:51 <implr> lets say I were implementing a webwallet/exchange/any other service that holds large sums of money
3 2014-02-16 00:49:07 <implr> obviously most of the funds would be in cold storage
4 2014-02-16 00:49:38 <implr> which would be implemented by creating a p2sh multisig address, where each key is held by a different person
5 2014-02-16 00:50:12 <implr> but then I either have to reuse that address(and keys)
6 2014-02-16 00:51:07 <implr> or generate new keys and create a new one, but that would mean that all those people would have to meet IRL to safely exchange keys
7 2014-02-16 00:51:34 <implr> and that might be difficult
8 2014-02-16 00:58:53 <Ademan> I know the transaction malleability issue isn't new, but does it have any implications for the payment protocol? It looked like users actually send entire transactions to the merchant, so as long as the merchant pulls the input/output information out of those transactions, everything should work normally, right?
9 2014-02-16 01:00:00 <lnovy> malleability will be no issue at all when protocols are out
10 2014-02-16 01:05:12 <jgarzik> 2014-02-16 01:02:59 init message: Verifying wallet...
11 2014-02-16 01:05:13 <jgarzik> .
12 2014-02-16 01:05:13 <jgarzik> 2014-02-16 01:02:59 dbenv.open LogDir=/home/jgarzik/bitcoin/data/database ErrorF
13 2014-02-16 01:05:13 <jgarzik> 2014-02-16 01:02:59 Error: Salvage found errors, all data may not be recoverable
14 2014-02-16 01:05:13 <jgarzik> 2014-02-16 01:02:59 Renamed wallet.dat to wallet.1392512579.bak
15 2014-02-16 01:05:13 <jgarzik> ile=/home/jgarzik/bitcoin/data/db.log
16 2014-02-16 01:05:15 <jgarzik> 2014-02-16 01:02:59 Salvage(aggressive) found no records in wallet.1392512579.ba
17 2014-02-16 01:05:17 <jgarzik> k.
18 2014-02-16 01:05:19 <jgarzik> 2014-02-16 01:02:59 : wallet.dat corrupt, salvage failed
19 2014-02-16 01:05:36 <jgarzik> certainly worrisome.
20 2014-02-16 01:06:00 <kjj> what happened to it?
21 2014-02-16 01:06:00 <thrasher`> ouch
22 2014-02-16 01:06:02 <thrasher`> any backups?
23 2014-02-16 01:08:40 <jgarzik> kjj, in theory nothing, besides running bitcoind git HEAD on it
24 2014-02-16 01:08:51 <jgarzik> thrasher`, yes, have backups
25 2014-02-16 01:09:02 <jgarzik> But this should not have gotten corrupted in the first place :/
26 2014-02-16 01:09:29 <wallet42> HD fail?
27 2014-02-16 01:09:56 <jgarzik> nope. encrypted+checksummed filesystem. nothing as simple as that.
28 2014-02-16 01:10:13 <jgarzik> I wish it were that easy :)
29 2014-02-16 01:10:47 <Apocalyptic> jgarzik, so you're implying the corruption was software-induced ?
30 2014-02-16 01:11:09 <kjj> is the wallet still bdb in head?
31 2014-02-16 01:12:40 <jgarzik> kjj, yes
32 2014-02-16 01:14:18 <kjj> I haven't been following the commits, but in general scrubbing the keys out of the wallet.dat file isn't easy to do
33 2014-02-16 01:15:17 <kjj> did this come from the head version? or did you run head once, then revert?
34 2014-02-16 01:24:49 <maaku> knotwork: just as likely your system clock is out of sync
35 2014-02-16 01:35:48 <jgarzik> kjj, run HEAD yes, revert no
36 2014-02-16 01:45:23 <Ademan> lnovy: Sorry I don't understand that answer. You referred to "protocols" when I was specifically referring to the payment protocol.
37 2014-02-16 01:46:47 <Ademan> maaku: I was hoping to rebase on/steal ideas from your coinjoin, is there any chance you'll be pushing soon?
38 2014-02-16 01:48:11 <Ademan> last we talked I was fighting python-bitcoinlib over some inconsistent hashing, otherwise I'd have pushed my changes (for what little they're worth)
39 2014-02-16 01:49:37 <Ademan> (I know you're using python-bitcoin not python-bitcoinlib, but I opted for python-bitcoinlib due to ubiquity and my own familiarity)
40 2014-02-16 02:26:40 <maaku> Ademan: I'm reformulating it into a BIP and will probably just start work on a bitcoin-qt integrated solution directly
41 2014-02-16 02:32:07 <maaku> Ademan: the purpose of the python coinjoin client was to experiment with the basic protocol & ideas
42 2014-02-16 02:32:38 <maaku> between work I've done, and what andytoshi and others have done, I think there's enough experience to formulate a reasonable integrated p2p solution
43 2014-02-16 02:36:47 <jcorgan> maaku: will you be documenting this as an extension to the wire protocol then, so it isn't bitcoin-qt specific?
44 2014-02-16 02:39:07 <maaku> jcorgan: yes
45 2014-02-16 02:39:23 <maaku> that's what the bip would be, a wire protocol extension
46 2014-02-16 02:39:39 <maaku> and my first implementation of the bip would be in bitcoind directly
47 2014-02-16 02:39:47 <jcorgan> cool. very much looking forward to it.
48 2014-02-16 02:40:17 <maaku> i don't know a timeframe .. it's what I was working on before this malleability snafu
49 2014-02-16 02:40:48 <jcorgan> sure
50 2014-02-16 02:44:05 <Ademan> maaku: oh... well good to know. I suppose there's nothing useful I can contribute to this then? you were obviously significantly farther along than I knew
51 2014-02-16 02:44:54 <maaku> Ademan: just in terms of reformulating the protocol messages. the other stuff hasn't really been worked on
52 2014-02-16 02:45:09 <maaku> and those changes (which are more like haphazard notes) are what I'm putting into the BIP
53 2014-02-16 02:45:26 <maaku> and on the malleability front i'm going to try my hand at sipa's soft fork proposal. we'll see how long that takes
54 2014-02-16 02:47:19 <maaku> Ademan: my ideas for handling coin selection for mixing, and anonymity set size estimation, etc. are all still just that - ideas
55 2014-02-16 02:50:17 <jcorgan> also, while your first implementation will be for the full node bitcoin-qt, please consider how it might work differently if it were to be added as a capability to an SPV node
56 2014-02-16 02:50:22 <jcorgan> (if at all)
57 2014-02-16 02:52:26 <maaku> jcorgan: it shouldn't matter, as it is all wallet code
58 2014-02-16 02:53:33 <jcorgan> well, i'll have to wait for the bip, but i'd assume you are defining new p2p messages for what will have previously been out-of-band stuff?
59 2014-02-16 02:53:56 <maaku> yeah
60 2014-02-16 02:55:15 <maaku> optional of course, to just the nodes which expose the joint-transaction service bit
61 2014-02-16 02:57:27 <jcorgan> right then. i'm not trying to pick nits but that isn't just wallet code. is it correct to assume that the joint-transaction bit with be orthogonal to any other capabilities? again, i'm just wanting to ensure that a lightweight wallet that operates purely in SPV mode over p2p would still be able to do CJ sessions
62 2014-02-16 03:02:42 <maaku> jcorgan: right i'm saying it shouldn't need to interact with the UTXO chainstate database, just the wallet outputs. i assume that's what you mean by full node
63 2014-02-16 03:03:13 <maaku> without being able to check the spend status of other outputs you are more vulnerable to DoS (UTXO committments alleviate this)
64 2014-02-16 03:04:45 <maaku> but checking spend status of other outputs is not *required* for operation
65 2014-02-16 03:04:46 <jcorgan> i mean NODE_COINJOIN (or whatever you call it) must not also require NODE_NETWORK in the services field
66 2014-02-16 03:06:05 <maaku> remind me what NODE_NETWORK means please?
67 2014-02-16 03:06:24 <jcorgan> it means you are a full node that can be asked for blocks from your local copy of the full blockchain
68 2014-02-16 03:06:54 <maaku> yes that is not required
69 2014-02-16 03:10:38 <jcorgan> very exciting
70 2014-02-16 03:14:07 <jcorgan> back when CJ was first proposed, there was the idea that 2-party transaction joining could be automated, with the notion that it would save space on the blockchain
71 2014-02-16 03:16:05 <jcorgan> probably too controversial
72 2014-02-16 03:16:45 <gmaxwell> it requires getting a lot of details right.
73 2014-02-16 03:16:59 <gmaxwell> and dealing with the fact that your txn has doublepsend exposure from the other participant.
74 2014-02-16 03:17:57 <gmaxwell> a related idea I had later is that it would be neat if there were a future extension to the payment protocol where you could specify "while writing this txn to me, please also spend this other coin" e.g. allowing the payment requester to have the payments consolidate some of their other holdings.
75 2014-02-16 03:18:19 <gmaxwell> also also obsecure the amount actually being paid.
76 2014-02-16 03:18:51 <gmaxwell> e.g. 2-party CJ with the person you're paying. But this removes the doublespend risks.
77 2014-02-16 03:19:05 <gmaxwell> (e.g. that the other CJer will doublespend and force you to reissue the transaction)
78 2014-02-16 03:22:36 <kjj> gmaxwell: wouldn't that just be a pp request with multiple endpoints?
79 2014-02-16 03:22:58 <gmaxwell> kjj: no, not endpoints _inputs_.
80 2014-02-16 03:23:24 <gmaxwell> "and spend this 10 BTC coin too, and add it to the output(s) you're paying me"
81 2014-02-16 03:23:29 <kjj> ahh. erm, that gets tricky
82 2014-02-16 03:23:57 <kjj> the protocol becomes a 2 way thing
83 2014-02-16 03:24:13 <gmaxwell> it should be in any case, so you can return a refund address.
84 2014-02-16 03:24:42 <gmaxwell> PP provides _very_ little value if you can't reliably provide a refund address.
85 2014-02-16 03:24:50 <gmaxwell> might as well give someone a freeking bitcoin uri.
86 2014-02-16 03:25:04 <kjj> a *signed* bitcoin URL. :)
87 2014-02-16 03:25:42 <gmaxwell> in any case, I was suggesting it as an optional thing in any case, as an extension some users wouldn't understand it and could just ignore it.
88 2014-02-16 03:26:45 <kjj> I haven't paid that much attention to work on the protocol since I made my objections to PB known
89 2014-02-16 03:28:05 <kjj> but, such an extension to it would have some implications that may be hard to figure out in advance. does it make the payer a willing accomplice in money laundering if used? for example
90 2014-02-16 03:29:31 <gmaxwell> kjj: it's just consolidating bills. E.g. "if you pay me with that 10 I can give you a 20 in change". kind of thing. But it also means that you can consolidate your bills with less private data leakage to the general public.
91 2014-02-16 03:30:25 <gmaxwell> (and less transaction volume)
92 2014-02-16 03:31:06 <Luke-Jr> gmaxwell: I think some people consider that to be laundry :/
93 2014-02-16 03:31:08 <gmaxwell> In commerce people have a requirement to keep their transaction values private from their competition and from other customers.
94 2014-02-16 03:32:14 <ajoul> Looking to hire someone for a small task
95 2014-02-16 03:32:23 <ajoul> I need a pool set up
96 2014-02-16 03:33:34 <Luke-Jr> that's no small task, and not on-topic here.
97 2014-02-16 03:33:55 <Luke-Jr> pools require ongoing maintenance, and you generally want the person setting it up to be the one who will maintain it
98 2014-02-16 03:34:14 <ajoul> I just need someone to set it up leave maintaince out of the question
99 2014-02-16 03:34:26 <ajoul> and yeah I am willing to hire
100 2014-02-16 03:35:32 <Luke-Jr> ajoul: try #bitcoin-otc
101 2014-02-16 07:37:46 <shaileshg> but it is constantly giving me Error: Error parsing JSON:[{txid
102 2014-02-16 07:37:46 <shaileshg> with following command: lockunspent unlock? [{"txid":txid,"vout":n}]
103 2014-02-16 07:38:15 <kjj> figure out how to quote it properly for your system
104 2014-02-16 07:38:22 <gmaxwell> add single quotes most likely
105 2014-02-16 07:38:24 <kjj> most likely, you need to wrap the whole thing in ''
106 2014-02-16 07:38:38 <shaileshg> kjj: ok. trying out
107 2014-02-16 07:40:47 <shaileshg> but still the same error
108 2014-02-16 07:40:47 <shaileshg> this time.. i did lockunspent true [{'txid' : 'eb95f11ec160beb7490fc8d20ecd3b254e82c49a513202983134424245da4fed', 'vout' : 1}]
109 2014-02-16 07:41:06 <kjj> you didn't need to swap your double quote for single quotes
110 2014-02-16 07:41:21 <kjj> you needed to stick single quotes around the outside of the whole thing
111 2014-02-16 07:41:27 <shaileshg> you mean to say '[]' ?
112 2014-02-16 07:42:05 <shaileshg> or ['{}']
113 2014-02-16 07:42:08 <gmaxwell> gah, no. like '[{"txid" : "eb95f11ec160beb7490fc8d20ecd3b254e82c49a513202983134424245da4fed", "vout" : 1}]'
114 2014-02-16 07:42:09 <kjj> lockunspent true [{"txid...}] becomes lockunspent true '[{"txid...}]
115 2014-02-16 07:42:11 <kjj> '
116 2014-02-16 07:42:16 <anddam> shaileshg: I guess so, the shell till catch a few parenthesis otherwise
117 2014-02-16 07:42:32 <anddam> s/till/will
118 2014-02-16 07:43:28 <shaileshg> Ah! got it.
119 2014-02-16 08:56:33 <anddam> per gmaxwell request: https://gist.github.com/anddam/e5659b88a2240f46ba99 Bitcoin 0.8.6 with pull request 2802 applied build on OS X 10.9
120 2014-02-16 08:57:21 <gmaxwell> ^ leveldb out of file descriptors on OSX.
121 2014-02-16 08:57:36 <anddam> the GUI application is sill running but the server isn't, should I kill -Qt ?
122 2014-02-16 09:02:20 <anddam> updated gist with db.log as well
123 2014-02-16 09:12:09 <anddam> btw my ma descriptor is hard limit is unlimited IIRC
124 2014-02-16 09:12:33 <shesek> implr, each person can have a known master public key
125 2014-02-16 09:12:52 <shesek> and you can derive keys from it for usage with multisig
126 2014-02-16 09:14:35 <anddam> gmaxwell: actually not unlimited but my max files limit is >10k
127 2014-02-16 09:21:56 <venzen> hi all, as far as i'm aware there is no clear doc explaining the TM issue in layman's terms (well, it's not a layman's issue!). I am writing an article by way of clarifying the issue for the average user and distinguishing between events of the past week (since Gox,DDoS and SR have all been grouped under TM by the media, thereby increasing confusion)
128 2014-02-16 09:23:12 <venzen> in the Bitcoin wiki page we have Sig Malleability and scriptSig malleability defined
129 2014-02-16 09:24:03 <venzen> may i ask someone to please explain why txid is the main term being refered to?
130 2014-02-16 09:26:14 <venzen> as i understand, txid is a sig hash - but which one? Sig or scriptSig?
131 2014-02-16 09:27:34 <wumpus> txid is a hash of the entire serialized transaction
132 2014-02-16 09:27:37 <shesek> txid is the transaction hash, not the sig hash
133 2014-02-16 09:27:46 <wumpus> so simply sha256(transaction)
134 2014-02-16 09:28:24 <venzen> ok, and that's separate and in addition to there being sig and scriptsig hashes?
135 2014-02-16 09:28:41 <wumpus> the scriptSig is included in this, which is the part that is being mutated by the DOS
136 2014-02-16 09:30:08 <venzen> thanks wumpus, so by changing the scriptSig a node malleates the txid...
137 2014-02-16 09:30:34 <wumpus> yes: the transaction signatures cover everything but the input scriptSigs, so that's where malleability exists
138 2014-02-16 09:30:55 <wumpus> changing any other field of the transaction would invalidate the transaction (and need it to be re-signed)
139 2014-02-16 09:31:30 <venzen> understood :)
140 2014-02-16 09:32:12 <venzen> are these "other fields" called the tarnsaction inputs?
141 2014-02-16 09:32:22 <wumpus> the proposed normalized transaction hash (#3656) is the value that would get signed by transaction signing, so is by definition not malleable without having to compute a new signature
142 2014-02-16 09:32:52 <wumpus> no, there are quite some other fields
143 2014-02-16 09:33:54 <wumpus> version number, input.prevout, input.sequence for every input, all output data, nlocktime all are part of the signature
144 2014-02-16 09:34:14 <wumpus> just not input.scriptSig
145 2014-02-16 09:34:48 <wumpus> (that would be impossible as the signature cannot sign itself :-)
146 2014-02-16 09:34:55 <venzen> agreed
147 2014-02-16 09:36:57 <venzen> so if i understand correctly then only the input.scriptSig can be changed and if it IS changed then the txid hash changes as a result...
148 2014-02-16 09:37:08 <wumpus> yes
149 2014-02-16 09:37:17 <venzen> great (sigh of relief)
150 2014-02-16 09:38:01 <wumpus> the scriptSig can be changed due to redundancy of representation, but there is only limited wiggle room and further restricting it is being worked on
151 2014-02-16 09:38:59 <gmaxwell> 01:32 < wumpus> the proposed normalized transaction hash (#3656) is the value that would get signed by transaction signing, so is by definition not malleable without having to compute a new signature
152 2014-02-16 09:39:15 <gmaxwell> ^ only true for a subset of transactions (though the overwhelmingly most common subset!)
153 2014-02-16 09:39:34 <gmaxwell> since the sighash flags allow the signatures to cover less of the transaction.
154 2014-02-16 09:40:15 <wumpus> gmaxwell: but that needs 'permission' of the signer of the transaction
155 2014-02-16 09:41:07 <gmaxwell> wumpus: sure but its critical if you're talking about from the perspective of a reciever. I've already run into developers who thought they could use this on recived transactions and not get confused by them.
156 2014-02-16 09:41:08 <wumpus> some transactions types are by nature more malleable, but they're quite uncommon
157 2014-02-16 09:41:24 <venzen> gotcha, ad this is not something i would include in the article - other than saying in the "most common transaction scenario"
158 2014-02-16 09:41:28 <gmaxwell> it was just a pedantic aside in any case.
159 2014-02-16 09:41:29 <venzen> *and
160 2014-02-16 09:41:49 <venzen> :)
161 2014-02-16 09:41:52 <phantomcircuit> gmaxwell, im thinking a certain block explorer type site
162 2014-02-16 09:42:00 <gmaxwell> venzen: To be frank, do you really believe you're qualified to write such an article when you just came here asking for an explination of a transaction id? I think we've already had far too much of the blind leading the blind.
163 2014-02-16 09:42:03 <phantomcircuit> which recently crashed and it was lul hilarious
164 2014-02-16 09:43:20 <shesek> at least he's trying to do it right, which is something I can't say about a lot of reporters
165 2014-02-16 09:43:33 <venzen> @gmaxwell, fair point and i would answer that my audience are the average user, so i am really trying to understand for my own confidence before attempting to simplify a cmplex issue
166 2014-02-16 09:43:40 <shesek> some of them aren't qualified, don't even realize that and don't care enough to ask those questions
167 2014-02-16 09:43:48 <wumpus> yes at least he's asking here in a normal tone
168 2014-02-16 09:44:25 <venzen> it's a reasonable question a
169 2014-02-16 09:45:05 <gmaxwell> I've stayed up all night twice now explaining things to people, sorry if I'm being testy. I went asked other people to help venzen, when he asked. FWIW. None of them have alas.
170 2014-02-16 09:45:41 <wumpus> it's understandable gmaxwell
171 2014-02-16 09:46:26 <venzen> indeed, understandable challenge/question and one i think i have answered honestly - the issue is just if it is acceptible to ask here (i think it is given the low traffic atm) but that is up to you guys to decide
172 2014-02-16 09:46:53 <TheSeven> hm... receiving quite a bit of dust spam on random never used addresses recently...
173 2014-02-16 09:47:05 <gmaxwell> it'll get diverted if it's in the way.
174 2014-02-16 09:47:14 <gmaxwell> TheSeven: then they're less never used than you thought?
175 2014-02-16 09:47:15 <shesek> TheSeven, never used? that doesn't make sense
176 2014-02-16 09:47:27 <shesek> did you publish the addresses somewhere online?
177 2014-02-16 09:47:39 <wumpus> TheSeven: they must be in the block chain, for example as change address
178 2014-02-16 09:47:55 <gmaxwell> I still think it's very interesting that none of my wallets have recieved even a single one of those spams.
179 2014-02-16 09:48:00 <shesek> I think it might be reasonable to start a -press channel or something like that for technical inquiries and to allow a dialog between reporters and developers
180 2014-02-16 09:48:14 <wumpus> gmaxwell: I only got it on my android 'bitcoin wallet'
181 2014-02-16 09:48:21 <gmaxwell> which suggests some connecting factor which isn't true for me.
182 2014-02-16 09:48:21 <shesek> but I'm not sure if anyone would actually go there... it'll probably become a dead channel quite fast
183 2014-02-16 09:48:34 <wumpus> not in any of my reference client wallets, maybe they filter it by default, it's 1 satoshi amounts
184 2014-02-16 09:48:52 <gmaxwell> It's generally a bad hour for such questions a lot of the people who have been doing a lot of explaing are asleep.
185 2014-02-16 09:48:54 <venzen> shesek: good idea, because it seems like botheration to come asking laymen level q's here
186 2014-02-16 09:49:04 <gmaxwell> wumpus: nah, we don't filter it.
187 2014-02-16 09:49:18 <gwillen> I'd help explain if I could
188 2014-02-16 09:49:28 <gwillen> but frankly I don't trust my knowledge of the issues
189 2014-02-16 09:49:31 <gmaxwell> venzen: we normally redirect lay questions to #bitcoin (and often will go in there and answer them if no one else is)
190 2014-02-16 09:50:06 <gmaxwell> andytoshi has been doing an epic job of explaining, but I suspect he's asleep.
191 2014-02-16 09:50:06 <wumpus> gmaxwell: I wonder: could it be away of finding the IP behind addresses? after all, many clients rebroadcast also transactions sent to them that don't get confirmed
192 2014-02-16 09:50:17 <venzen> i think that may be more appropriate (also considering the hour as you say) - i'll do that
193 2014-02-16 09:50:36 <gmaxwell> wumpus: it could be. though I spoke to someone who thought they found the source and said they were just an idiot.
194 2014-02-16 09:50:48 <TheSeven> I got some blockchain.info eWallet notifications, but I can't even see which particular addresses caught them, they don't show up in the transaction list
195 2014-02-16 09:51:08 <gmaxwell> wumpus: in interesting point there is that my wallets are all on tor.
196 2014-02-16 09:51:23 <wumpus> gmaxwell: mine too, except for the android one.... hmm :-)
197 2014-02-16 09:51:31 <gmaxwell> so if it were that kind of attack perhaps you connect to a node and by monitoring it guess its addresses and then spam it to confirm?
198 2014-02-16 09:51:39 <shesek> I wonder, if wallets would start displaying textual content in OP_RETURN in the gui... how long will it take for spammers to start abusing it with satoshi transactions advertising viagra websites?
199 2014-02-16 09:52:10 <gmaxwell> ACTION really regrets including the OP_RETURN <data> change now.
200 2014-02-16 09:52:23 <gmaxwell> shesek: we forsaw that, however.
201 2014-02-16 09:52:34 <gmaxwell> So "don't do that" sadly people will.
202 2014-02-16 09:52:57 <gwillen> gmaxwell: why do you regret that now in particular
203 2014-02-16 09:53:16 <shesek> "that" being displaying OP_RETURN data it in the gui?
204 2014-02-16 09:53:39 <gmaxwell> gwillen: because of all the bad things people are planning with it, for example I got excited email about someone who'd written a f@#$@ VFS driver to store data in the blockchain, inspired in part by the "approval" that they felt they'd recieved.
205 2014-02-16 09:53:39 <wumpus> bitcoin-qt will never display OP_RETURN data in the GUI
206 2014-02-16 09:53:41 <shesek> or did you mean something else?
207 2014-02-16 09:53:50 <wumpus> except in hex maybe in the tx details, it's for internal purposes
208 2014-02-16 09:54:05 <gmaxwell> shesek: displaying. yes. we won't do it, but I won't be shocked when every other wallet does. :(
209 2014-02-16 09:54:28 <gmaxwell> then I won't be shocked when someone finds a string handling exploit and takes their funds or an XSS vulnerability either. :P
210 2014-02-16 09:54:37 <gmaxwell> but I'm pessimistic like that
211 2014-02-16 09:55:00 <wumpus> hah - or someone storing it in a sql database, ';drop tables :p
212 2014-02-16 09:55:12 <TheSeven> ACTION is somewhat confident that increasing transaction volume and increasing fees will fix that kind of storage/spam problems
213 2014-02-16 09:55:13 <shesek> I really think OP_RETURN should be limited to hashes, but that boat already sailed :-\
214 2014-02-16 09:55:31 <wumpus> shesek: how can an algorithm know?
215 2014-02-16 09:55:50 <shesek> wumpus, gmaxwell had a few ideas on how to accomplish that
216 2014-02-16 09:56:17 <shesek> one was providing the pre image (separately from the tx/block itself) and penalize blocks that don't have that
217 2014-02-16 09:56:38 <gmaxwell> I came up with a way to prove a value is a hash, actually two ways. Thats one.
218 2014-02-16 09:56:50 <shesek> and there was some other way for hashes to prove they are indeed hashes with pairing crypto or something like that, but I'm not sure how realistic it is to use
219 2014-02-16 09:56:56 <shesek> the proof size and all that
220 2014-02-16 09:57:32 <uiop> where would the preimage be provided if not in the tx/block ?
221 2014-02-16 09:57:39 <gmaxwell> The other is that I invented (? can't find it else where) a kind of self-certifying hash. shesek: it's just 2x the size for the proof.
222 2014-02-16 09:57:40 <wumpus> gmaxwell: nice
223 2014-02-16 09:58:05 <wumpus> I was imagining horrible cat and mouse games, but crypto to the rescue again :)
224 2014-02-16 09:58:19 <shesek> oh, really? that's very good
225 2014-02-16 09:58:24 <gmaxwell> shesek: e.g. for 256 bit security its a 64 byte value.
226 2014-02-16 09:58:45 <shesek> was it seriously considered? I think using that is a great idea
227 2014-02-16 09:59:08 <shesek> perhaps even just penalizing data without that proof with higher fees requirements
228 2014-02-16 09:59:42 <shesek> but ideally, completely forbidding non-hash data is the way to go imho
229 2014-02-16 09:59:55 <gmaxwell> shesek: well its something we could still deploy in the future. probably the downside of it is that it takes a pairing operation to verify.
230 2014-02-16 10:00:02 <gmaxwell> so like 1ms to verify. :(
231 2014-02-16 10:00:02 <venzen> wumpus: thanks for taking the time to explain earlier!
232 2014-02-16 10:00:03 <venzen> i'm off to #bitcoin
233 2014-02-16 10:00:50 <shesek> gmaxwell, I think the overall effect of allowing arbitrary data will be far worse than that though :-\
234 2014-02-16 10:01:51 <gmaxwell> probably, but there are many ways to do that now. we block non-hashes in OP_RETURN and people will encode into hash160 junk outputs, and I think thats worse.
235 2014-02-16 10:02:06 <gmaxwell> I do wish the op_return had been limited to 32 or 32+small bytes.
236 2014-02-16 10:02:34 <wumpus> gmaxwell: we could still do that right? 0.9 is not released
237 2014-02-16 10:02:57 <gmaxwell> It got discussed before.
238 2014-02-16 10:03:04 <shesek> ideally, that proof should be provided everywhere, with pay-to-pubkey-hash and p2sh
239 2014-02-16 10:03:10 <gmaxwell> maybe others will have changed their mind after seeing some of the response. :P
240 2014-02-16 10:03:16 <shesek> it is a problem with pay-to-pubkey, though
241 2014-02-16 10:03:52 <wumpus> I don't understand how that got merged at all if it's still so controversial
242 2014-02-16 10:04:11 <wumpus> then again, yes the alternatives are worse
243 2014-02-16 10:04:30 <wumpus> but the size is unlimited now?
244 2014-02-16 10:04:43 <xiando> TheSeven: there you go, wanting to increase fees again. No wonder dogecoin is more popular
245 2014-02-16 10:05:08 <shesek> the alternatives are worse, but OP_RETURN makes it look officially approved
246 2014-02-16 10:05:12 <gmaxwell> wumpus: it's limited to ~80 bytes now IIRC.
247 2014-02-16 10:05:32 <TheSeven> xiando: I don't want to increase fees, but I estimate that an increase in fees will be unavoidable as a result of increasing adoption
248 2014-02-16 10:05:38 <shesek> gives it a "gushpanka", as we say in Israel
249 2014-02-16 10:06:03 <gmaxwell> exactly as shesek said, well I supported including it, I thought 80 was too big since it wouldn't encourage hashes. My opinion has soured a bit as I've seen people promote stuff as "officially endorsed data storage"
250 2014-02-16 10:06:31 <gmaxwell> shesek: "it's kosher"
251 2014-02-16 10:06:36 <uiop> what about with p2sh? you can't require a preimage for the "sh" (?) (or am i not speaking in the correct context here?)
252 2014-02-16 10:06:40 <shesek> gmaxwell, yeah... I also got a couple of emails about that
253 2014-02-16 10:06:52 <wumpus> ah https://github.com/bitcoin/bitcoin/commit/22de68d and https://github.com/bitcoin/bitcoin/commit/a793424
254 2014-02-16 10:06:58 <shesek> people wanting to attach contracts to transactions and stuff like that
255 2014-02-16 10:06:59 <wumpus> the second one indeed mentions 80 bytes as limit
256 2014-02-16 10:07:44 <gmaxwell> uiop: p2sh isn't put in an op_return, ... but see my p2sh^2 post. Though that was before I thought of self-certifying hashes.
257 2014-02-16 10:09:30 <shesek> even if using self-certifying hashes for OP_RETURN won't prevent people from stuffing arbitrary data elsewhere, at least it gives a formal declaration about what data is expected to be on the blockchain and what isn't
258 2014-02-16 10:09:35 <wumpus> a hash of 80 bytes would exceed the security guarantees of bitcoin itself, so there indeed must have been other reasons behind the value of 80
259 2014-02-16 10:09:42 <shesek> I think it should be reconsidered, if its not too late
260 2014-02-16 10:10:45 <shesek> is there a consensus with the core dev team that arbitrary data is bad, or are some people supporting it?
261 2014-02-16 10:10:50 <gmaxwell> shesek: I'd worry about deploying them so fast, though they're pretty simple. it's the sort of thing I ought to write up in a publication.
262 2014-02-16 10:11:16 <gmaxwell> shesek: I think there is a general consensus that arbitrary data is bad. We didn't have any internal controversy about the dust threshold stuff, IIRC.
263 2014-02-16 10:11:50 <shesek> why not delay OP_RETURN then?
264 2014-02-16 10:12:40 <shesek> or even add it now with high fees, with a future update that cancels the fees when the proof is provided?
265 2014-02-16 10:12:42 <uiop> it makes me nervous the the bitcoin protocol definition can be modified at the (however justified) whim of a particular implementation
266 2014-02-16 10:13:09 <gmaxwell> uiop: dunno wtf you're talking about.
267 2014-02-16 10:13:10 <uiop> (i'm coming from the pov of compilers/proglangs here)
268 2014-02-16 10:13:14 <wumpus> uiop: this is not about changing the protocol definition
269 2014-02-16 10:13:18 <gmaxwell> We're certantly not talking about the protocol definition here.
270 2014-02-16 10:13:32 <wumpus> just about what gets relayed by default
271 2014-02-16 10:13:34 <uiop> hmm, i'm totally confused then :)
272 2014-02-16 10:13:45 <uiop> ahh, ok
273 2014-02-16 10:14:00 <shesek> bbl
274 2014-02-16 10:14:01 <uiop> i consider relay rules to be essentially protocol-ish
275 2014-02-16 10:14:18 <gmaxwell> wumpus: we should probably poll the other core folks and see if anyone would hate restricting it back down to 32 bytes.
276 2014-02-16 10:14:35 <wumpus> uiop: no, they're not, they are node policy and can be changed without even a softfork
277 2014-02-16 10:14:51 <wumpus> gmaxwell: good idea
278 2014-02-16 10:15:04 <gmaxwell> I think ~32 bytes at least communicates "this is for hashes"
279 2014-02-16 10:15:25 <gmaxwell> and differs on systems all over the network. My systems, for example, have pretty much never run stock relay rules.
280 2014-02-16 10:15:53 <uiop> wumpus: right, i mean "in-spirit" though, since they (in the current situation of one de-facto implem) effectively determine "the rules"
281 2014-02-16 10:16:08 <wumpus> uiop: it's the power of defaults, nothing more
282 2014-02-16 10:16:27 <gmaxwell> uiop: if you don't like my relay rules, don't freeking connect to my nodes. There is, as I mentioned a diveristy.
283 2014-02-16 10:17:20 <uiop> i just wonder what would happen if another implementation comes along and gains market-share, *and* relay policy has become a primary method of discouraging various things, will this all come undone if the other implem which now has market share refuses to honor the same relay policy?
284 2014-02-16 10:17:56 <hno> uiop, no.
285 2014-02-16 10:18:11 <gmaxwell> For the most part discouraging things is short term growth stuff, ultimately abusive use should be greatly constrained by the fees market.
286 2014-02-16 10:18:28 <uiop> i suppose you could always push your tx directly to miners regardless
287 2014-02-16 10:18:36 <wumpus> uiop: so large groups of people running nodes can decide that they want a different relay policy, that's not a problem in itself, that's good
288 2014-02-16 10:18:57 <gmaxwell> indeed, nothing wrong with that.
289 2014-02-16 10:19:05 <uiop> wumpus: hmm, yeah viewed that way it sounds better
290 2014-02-16 10:19:13 <gmaxwell> this is why rules are not the protocolâ no need for systems to match.
291 2014-02-16 10:21:46 <uiop> after all, it's impossible to *require* a node to relay *anything* i suppose (just like a proglang spec can't require a compiler which doesn't claim to be an implem of said spec to do *anything*)
292 2014-02-16 10:23:07 <uiop> "good faith is unenforceable" i guess
293 2014-02-16 10:48:27 <Mallstromm> what do you guys think of stealth addresses? Any chance to see them implemented in QT soon?
294 2014-02-16 10:50:24 <wumpus> Mallstromm: I don't know anyone working on that
295 2014-02-16 11:01:28 <Mallstromm> having coinjoin and SX addresses in the reference client would be a huge step forward IMO
296 2014-02-16 11:02:29 <wumpus> well, submit a patch
297 2014-02-16 11:05:08 <wumpus> has some standard way of doing coinjoin rendezvous been defined already?
298 2014-02-16 11:13:12 <Mallstromm> wumpus: I wouldn't know how to write that patch... I was just chiming in my 0.0000002BTC.
299 2014-02-16 11:13:26 <Mallstromm> never used blockchain.info until it became the easiest way to use Coinjoin
300 2014-02-16 11:14:06 <Mallstromm> I'd personally like all my transfers to use Coinjoin by default. That'd be desiderable for everybody IMO. its an important step forward
301 2014-02-16 11:15:29 <wumpus> yes that would be nice, although it would introduce more moving parts so more things that can go wrong while sending transactions
302 2014-02-16 11:31:24 <Mallstromm> I understand
303 2014-02-16 11:41:44 <_syslog> saluy
304 2014-02-16 11:41:47 <_syslog> *t
305 2014-02-16 11:55:19 <Bisbee> seems like btc$ on mtgox may reach 0 within 48hrs, all other exchanges healthy; preparing my data analysis to not rely on gox in any way :)
306 2014-02-16 11:55:36 <Diablo-D3> yeah thats the end of mtgox
307 2014-02-16 11:59:54 <jcorgan> \o/
308 2014-02-16 12:08:38 <Bisbee> Fitting: http://gatherer.wizards.com/pages/Card/Details.aspx?multiverseid=191096
309 2014-02-16 12:10:17 <wumpus> ...lol...
310 2014-02-16 12:10:43 <uiop> hah
311 2014-02-16 12:10:58 <uiop> ACTION right-click save-image-as
312 2014-02-16 12:13:47 <jcorgan> it doesn't get much loller than that
313 2014-02-16 12:15:02 <jcorgan> sad, though--could you imagine how much the bitcoin community would have rallied around mtgox and help them to address their issues if karpeles had simply mea culpa'd instead of shitting in the pool?
314 2014-02-16 12:19:28 <Bisbee> reliance on any one exchange is a foolish move tbh, I'd like to see a p2p secure exchange built
315 2014-02-16 12:20:30 <jcorgan> Bisbee: how to you handle fiat in a p2p, decentralized manner?
316 2014-02-16 12:23:47 <Bisbee> jcorgan: If I find an answer I'll share it :)
317 2014-02-16 12:25:15 <jcorgan> please do :) solving counterparty risk for fiat payments in a distributed way would be...enormous.
318 2014-02-16 13:27:44 <wallet42> is blockchain.info\s coinjoin not affected by tx malleability?
319 2014-02-16 13:32:31 <jcorgan> don't see any reason why it should be
320 2014-02-16 13:35:13 <wallet42> as far as i understand it, a coinjoin operation is a series of transactions, depending on each other. if the txid[0] changes, txid[1] becomes invalid
321 2014-02-16 13:36:22 <Aurigae> test
322 2014-02-16 13:37:24 <jcorgan> coinjoin is a single joined transaction that get broadcast all at once
323 2014-02-16 13:39:21 <Aurigae> Found Berkeley DB other than 4.8 <--- got this while compiling bitcoind, obv i have 5.1, in my sources i have no libdb4.8++ only, libdb4.8 , is that ok to replace libdb 5.1? or should i do âwith-incompatible-bdb
324 2014-02-16 13:39:23 <Aurigae> ?
325 2014-02-16 13:39:44 <sipa> Aurigae: yes, if you don't need your wallets to be compatible with release binaries
326 2014-02-16 13:40:02 <Aurigae> thx, so its safe to go with 5.1
327 2014-02-16 13:40:04 <Aurigae> ?
328 2014-02-16 13:40:05 <sipa> yes
329 2014-02-16 13:40:08 <Aurigae> thx
330 2014-02-16 13:40:09 <Aurigae> :)
331 2014-02-16 13:40:18 <sipa> but it means your wallet.dat file won't work anymore with bitcoind versions that use 4.8
332 2014-02-16 13:40:33 <Aurigae> im fine with that :)
333 2014-02-16 13:40:36 <sipa> apart from that, perfectly safe
334 2014-02-16 14:08:08 <Aurigae> {
335 2014-02-16 14:08:08 <Aurigae> [1] 18336
336 2014-02-16 14:08:08 <Aurigae> nodes@39175:~/bitcoin/src$ ./bitcoind &
337 2014-02-16 14:08:08 <Aurigae> nodes@39175:~/bitcoin/src$ ./bitcoind getinfo
338 2014-02-16 14:08:08 <Aurigae> thx sipa, works like a charm
339 2014-02-16 14:08:09 <Aurigae> "protocolversion" : 70002,
340 2014-02-16 14:08:09 <Aurigae> "version" : 90000,
341 2014-02-16 14:08:10 <Aurigae> "balance" : 0.00000000,
342 2014-02-16 14:08:10 <Aurigae> "walletversion" : 60000,
343 2014-02-16 14:08:11 <Aurigae> "blocks" : 6500,
344 2014-02-16 14:08:11 <Aurigae> "timeoffset" : 0,
345 2014-02-16 14:08:12 <Aurigae> "connections" : 4,
346 2014-02-16 14:29:54 <wallet42> is there a service that tracks all coinjoin transactions?
347 2014-02-16 14:30:13 <wallet42> (seem like) coinjoin transactions
348 2014-02-16 14:30:26 <wallet42> i wonder how many there are per hour
349 2014-02-16 14:31:15 <shesek> I think its more reasonable to ask once in how many hours there's one
350 2014-02-16 14:31:38 <shesek> there aren't that many...
351 2014-02-16 16:41:15 <michagogo> cloud|12:05:41 <shesek> gives it a "gushpanka", as we say in Israel
352 2014-02-16 16:41:20 <michagogo> cloud|Ohhh, is that what that word means?
353 2014-02-16 16:42:21 <shesek> heh, yes :)
354 2014-02-16 16:42:29 <shesek> I wondered if you were around when I wrote that
355 2014-02-16 16:42:45 <michagogo> cloud|I was not, but IRCCloud was :-)
356 2014-02-16 16:42:57 <shesek> according to wikitonary, "×××ª× ×¨×©×× ×©× ××¢× ×¡×××ת (××× ×× ××ס×) ××ס××, ×××ª× ×××ת ×× ×פע×××" or "××ª× ××××××צ××, ××ש×ר, ×× ×ס×××."
357 2014-02-16 16:43:12 <michagogo> cloud|Ahhhh
358 2014-02-16 16:46:42 <michagogo> cloud|16:08:10 <Aurigae> nodes@39175:~/bitcoin/src$ ./bitcoind &
359 2014-02-16 16:46:54 <michagogo> cloud|Aurigae1: You may want the "daemon" option
360 2014-02-16 16:47:06 <michagogo> cloud|either on the command line or in the config file
361 2014-02-16 16:47:22 <michagogo> cloud|Also, as of 0.9.0 there's the `bitcoin-cli` executable for RPC calls\
362 2014-02-16 16:47:26 <michagogo> cloud|s/\//
363 2014-02-16 16:48:33 <arubi> does bitcoin-cli drop to a shell of itself or is it just a call for rpc from the regular shell?
364 2014-02-16 16:49:37 <michagogo> cloud|arubi: it does exactly what bitcoind does when you use bitcoind for an rpc call
365 2014-02-16 16:49:47 <michagogo> cloud|It's just a separate executable
366 2014-02-16 16:50:06 <michagogo> cloud|And IIRC the plan is to remove that functionality from bitcoind in 0.10
367 2014-02-16 16:50:07 <arubi> alright, thanks
368 2014-02-16 16:50:13 <michagogo> cloud|(don't quote me on that, though)
369 2014-02-16 16:50:27 <arubi> seems logical with bitcoin-cli
370 2014-02-16 16:50:37 <arubi> to drop cli support from bitcoind that is
371 2014-02-16 16:52:43 <sipa> yeah, mixing rpc server and client in one has always been confusing
372 2014-02-16 16:53:06 <sipa> up to the point where some people believe that the only way to use it is through that binary
373 2014-02-16 16:53:32 <sipa> whether bitcoind <command> is dropped in 0.10 will depend on when it is released, i guess
374 2014-02-16 16:54:43 <michagogo> cloud|I seem to recall someone saying that the plan was to drop it, but I could be wrong
375 2014-02-16 16:55:08 <sipa> yeah, eventually for sure
376 2014-02-16 16:55:32 <michagogo> cloud|Though we may want to have a release that prints a message to stderr when bitcoind is used
377 2014-02-16 17:02:51 <kinlo> shouldn't that be in 0.9 already?
378 2014-02-16 17:03:35 <kinlo> also, it is not a big change, I'll have much more troubles with the other 0.9 changes :)
379 2014-02-16 17:08:34 <michagogo> cloud|;;cjs
380 2014-02-16 17:08:35 <gribble> Coinjoin Status: There is no currently open session. Visit https://www.wpsoftware.net/coinjoin/ or http://xnpjsvp7crbzlj3w.onion/ to start one.
381 2014-02-16 17:08:42 <michagogo> cloud|kinlo: Yeah, it probably should be
382 2014-02-16 17:08:44 <michagogo> cloud|but it's not
383 2014-02-16 17:08:50 <michagogo> cloud|ACTION pokes gribble
384 2014-02-16 17:09:11 <michagogo> cloud|ACTION wonders if it's andytoshi's server or ,,gribble causing the delay
385 2014-02-16 17:09:12 <gribble> yes I am gribble. why do you keep bothering me?
386 2014-02-16 17:09:43 <andytoshi> michagogo|cloud: looks like my server is being weird
387 2014-02-16 17:10:03 <andytoshi> which is weird, considering i'm SSH'd into the same physical box right now to say this..
388 2014-02-16 17:10:45 <michagogo> cloud|Is gribble not threaded?
389 2014-02-16 17:11:11 <michagogo> cloud|(or whatever the term is for "can do two things at once")
390 2014-02-16 17:11:12 <andytoshi> nvr mind, it's fine, it's just not responding to pings. that's a router setting i never got around to changing..
391 2014-02-16 17:34:28 <shaileshg> Hi. Has anyone tried OP_RETURN here?
392 2014-02-16 17:35:04 <shaileshg> any tool to create transaction with OP_RETURN scriptPubKey
393 2014-02-16 17:35:36 <michagogo> cloud|shaileshg: OP_RETURN is not intended to be used.
394 2014-02-16 17:35:59 <shaileshg> michagogo|cloud: it is intended to be used for inserting up to 80 bytes data in blockchain
395 2014-02-16 17:36:00 <michagogo> cloud|Don't stuff arbitrary data into the blockchain.
396 2014-02-16 17:36:04 <michagogo> cloud|shaileshg: No, it's not
397 2014-02-16 17:36:12 <michagogo> cloud|It's a way of making doing so less harmful
398 2014-02-16 17:36:50 <shaileshg> michagogo|cloud: https://github.com/bitcoin/bitcoin/pull/2738 says it has been merged
399 2014-02-16 17:37:03 <michagogo> cloud|shaileshg: To borrow an analogy from Luke-Jr, OP_RETURN is "Please don't rape me, but if you do, at least do it gently"
400 2014-02-16 17:37:22 <michagogo> cloud|Yes, it's merged, but it's not something that's good to use
401 2014-02-16 17:37:28 <shaileshg> michagogo|cloud: whatever. In either case, it has been merged
402 2014-02-16 17:37:40 <michagogo> cloud|If you insist on stuffing data into the blockchain, OP_RETURN is the least bad way of doing it
403 2014-02-16 17:37:47 <sipa> ^- that makes me want to argue for removing it again
404 2014-02-16 17:37:50 <michagogo> cloud|But you shouldn't do it.
405 2014-02-16 17:37:54 <michagogo> cloud|sipa: Yes, me too
406 2014-02-16 17:37:55 <shaileshg> then what do you suggest to use if I want to insert some meta-data for later use in blockchain per transaction
407 2014-02-16 17:38:00 <sipa> shaileshg: don't
408 2014-02-16 17:38:03 <michagogo> cloud|shaileshg: don't
409 2014-02-16 17:38:05 <michagogo> cloud|sipa: jinx
410 2014-02-16 17:38:09 <sipa> shaileshg: there is no point in putting in the blockchain
411 2014-02-16 17:38:18 <sipa> where you burden every node in the world forever with it
412 2014-02-16 17:38:42 <sipa> if you have meta-data that needs to be associated with the transaction, send it to the receiver directly
413 2014-02-16 17:38:53 <sipa> that is what the payment protocol accomplishes, for example
414 2014-02-16 17:39:06 <sipa> the blockchain is only for what is necessary for the world to validate the transfer
415 2014-02-16 17:39:25 <shaileshg> sipa: if I want to provide some particular kind of service to end users in a way that they can verify the service just by looking up the blockchain instead of pinging my server everytime for it.. i think inserting some small data would be a way to do it
416 2014-02-16 17:39:54 <gmaxwell> shaileshg: no, not reallyâ you should just publish the data for them and then they don't need to ping you.
417 2014-02-16 17:40:34 <shaileshg> gmaxwell: you are saying kind of web page or api..?
418 2014-02-16 17:40:56 <michagogo> cloud|Since it's been merged, seeing how people are reacting to it makes me think that it was a bad idea
419 2014-02-16 17:42:36 <wallet42> my coinjoin tx got anuallated
420 2014-02-16 17:42:44 <michagogo> cloud|;;cjs
421 2014-02-16 17:42:45 <gribble> Coinjoin Status: There is no currently open session. Visit https://www.wpsoftware.net/coinjoin/ or http://xnpjsvp7crbzlj3w.onion/ to start one.
422 2014-02-16 17:42:51 <shaileshg> sipa: but its auto-prunable without being relayed to other nodes
423 2014-02-16 17:42:57 <sipa> shaileshg: you misunderstand
424 2014-02-16 17:43:03 <sipa> shaileshg: it does not enter the UTXO set
425 2014-02-16 17:43:10 <shaileshg> so, i don't think it will burden every node forever with it
426 2014-02-16 17:43:19 <sipa> shaileshg: but it becomes part of the blockchain, and associated bandwidth with it
427 2014-02-16 17:43:39 <sipa> shaileshg: it still hurts
428 2014-02-16 17:43:44 <sipa> shaileshg: just slightly less badly
429 2014-02-16 17:44:16 <sipa> if it were not relayed to other nodes, it could just as well be not there in the first place, right?
430 2014-02-16 17:44:22 <sipa> it IS relayed, and stored
431 2014-02-16 17:44:33 <sipa> but not in the database, just in the blockchain
432 2014-02-16 17:44:40 <shaileshg> sipa: I see. What you are saying is that it will be with every node having that block or blockchain.. just that it won't show up in listunspent?
433 2014-02-16 17:44:43 <andytoshi> does anyone remember roughly when gox started using their nonstandard signatures? (sorry to be OT, i think that question could cause a shitstorm on #bitcoin)
434 2014-02-16 17:44:57 <michagogo> cloud|19:37:04 <+michagogo|cloud> shaileshg: To borrow an analogy from Luke-Jr, OP_RETURN is "Please don't rape me, but if you do, at least do it [slightly more] gently"
435 2014-02-16 17:45:04 <sipa> shaileshg: listunspent is a wallet RPC, that has nothing to do with it, wallets work indepdently
436 2014-02-16 17:45:10 <michagogo> cloud|andytoshi: A very long time ago, IIRC
437 2014-02-16 17:45:13 <wallet42> i'm pretty sure that the sharedcoin operstion got canceled because of tx maleablity
438 2014-02-16 17:45:18 <sipa> shaileshg: the RPC it affects is gettxoutsetinfo
439 2014-02-16 17:45:20 <michagogo> cloud|It was only recently that they *stopped*, IIRC
440 2014-02-16 17:45:56 <sipa> shaileshg: nodes keep a fast-accessible database of all unspent transaction outputs, in order to be able to quickly validate transactions and blocks
441 2014-02-16 17:46:04 <sipa> shaileshg: OP_RETURN outputs do not enter that database
442 2014-02-16 17:46:25 <shaileshg> sipa: hmm
443 2014-02-16 17:47:01 <shaileshg> sipa: and that is local db if I m running client on my machine..
444 2014-02-16 17:47:06 <sipa> yes
445 2014-02-16 17:47:12 <sipa> it's in $DATADIR/chainstate
446 2014-02-16 17:47:15 <shaileshg> so it doesn't matter much in lowering the burden on blockchain
447 2014-02-16 17:47:17 <shaileshg> hmm
448 2014-02-16 17:47:49 <michagogo> cloud|shaileshg: Correct. The *only* thing it does is keep the output out of the UTXO set.
449 2014-02-16 17:48:15 <michagogo> cloud|Rather, that's what OP_RETURN does
450 2014-02-16 17:48:49 <michagogo> cloud|What relaying OP_RETURN+smalldata outputs does is simply make it as easy to use OP_RETURN as it is to use other methods
451 2014-02-16 17:49:38 <shaileshg> hmm
452 2014-02-16 17:50:06 <shaileshg> if i want to check how transaction behave with OP_RETURN in testnet.. how can i check it
453 2014-02-16 17:50:47 <michagogo> cloud|shaileshg: Erm, what do you mean, how it behaves?
454 2014-02-16 17:51:15 <michagogo> cloud|Testnet already has IsStandard disabled, so #2738 is irrelevant to it
455 2014-02-16 17:51:23 <shaileshg> michagogo|cloud: I think it answered my question.. it will get accepted thr..
456 2014-02-16 17:51:24 <shaileshg> hmm
457 2014-02-16 17:51:41 <michagogo> cloud|The only thing to test would be the pruning from the utxo set
458 2014-02-16 17:51:52 <shaileshg> michagogo|cloud: if isStandard is enabled.. will #2738 be accepted by miners?
459 2014-02-16 17:51:59 <michagogo> cloud|Uh, what?
460 2014-02-16 17:52:18 <shaileshg> in mainnet.. will transaction having OP_RETURN be registered in block by miners?
461 2014-02-16 17:52:42 <michagogo> cloud|It depends on the miner
462 2014-02-16 17:52:50 <sipa> miners do what they want
463 2014-02-16 17:52:54 <michagogo> cloud|Each miner decides what to mine
464 2014-02-16 17:53:10 <michagogo> cloud|I believe some miners do mine OP_RETURN transactions, yes
465 2014-02-16 17:53:47 <michagogo> cloud|Whether or not the transaction will *get* to the miner, though, is a different story
466 2014-02-16 17:53:58 <shaileshg> ?
467 2014-02-16 17:54:53 <shaileshg> why so? won't it be relayed to the miner through other nodes
468 2014-02-16 17:55:24 <michagogo> cloud|Yes, but only if a chain of nodes that will relay the transaction from you to the miner exists
469 2014-02-16 17:56:34 <wallet42> how is the terminology of a) tx beeing forwarded, b) blocks with tx are accepted ?
470 2014-02-16 17:57:01 <shaileshg> michagogo|cloud: when I said I wanted to check how transaction with OP_RETURN will behave in testnet, I precisely wanted to check if it will be relayed from my machine to the miner..
471 2014-02-16 17:57:26 <wallet42> for instance a block with a tx habing 1 satoshi output would be protocol valid, but not forwarded in the bitcoind client right?
472 2014-02-16 17:57:30 <shaileshg> Also, it will be gr8 if you can explain it in context of mainnet with IsStandard() check
473 2014-02-16 17:57:32 <michagogo> cloud|shaileshg: Yes, I can guarantee that it will be relayed from you to the miner in testnet, because on testnet, everything is relayed
474 2014-02-16 17:57:40 <michagogo> cloud|IsStandard is disabled on testnet
475 2014-02-16 17:57:49 <Luke-Jr> s/disabled/not used/
476 2014-02-16 17:57:56 <michagogo> cloud|Right.
477 2014-02-16 17:58:07 <shaileshg> yeah.. I know that now.. what about mainnet..
478 2014-02-16 17:58:08 <michagogo> cloud|wallet42: Anything that's in a block reaches everyone, assuming it's not actually invalid
479 2014-02-16 17:58:47 <michagogo> cloud|wallet42: A transaction with a 1-satoshi output will generally not be relayed, but if it gets into a block, it will reach everyone through that block.
480 2014-02-16 17:58:52 <shaileshg> does the current release have any technical implementation to prevent such a transaction to propagate in the network..
481 2014-02-16 17:59:00 <michagogo> cloud|shaileshg: The current release is 0.8.6
482 2014-02-16 17:59:10 <michagogo> cloud|0.8.6 does not relay OP_RETURN transactions by default.
483 2014-02-16 17:59:15 <shaileshg> or can I assume it will be relayed from me to miner
484 2014-02-16 17:59:39 <shaileshg> michagogo|cloud: sorry.. means upcoming 0.9.* version
485 2014-02-16 17:59:57 <michagogo> cloud|In current git head, OP_RETURN+smalldata is relayed, yes
486 2014-02-16 18:00:04 <shaileshg> okay
487 2014-02-16 18:00:08 <michagogo> cloud|But there's no guarantee that that will be the case in 0.9.0
488 2014-02-16 18:00:16 <shaileshg> hmm
489 2014-02-16 18:00:23 <wallet42> if it reads "is not relay", does this mean it wont be accepted by a node at all or will it be accepted but not forwarded? meaning, if i throw it directly to a miner node it will eventually be included?
490 2014-02-16 18:00:28 <michagogo> cloud|I've seen a few people talking about reverting that particular change
491 2014-02-16 18:00:40 <shaileshg> hmm.. i could sense that
492 2014-02-16 18:01:03 <michagogo> cloud|wallet42: AFAIK, if it fails IsStandard, unmodified Bitcoin Core will not accept it into the mempool
493 2014-02-16 18:01:13 <michagogo> cloud|So it won't be relayed nor mined
494 2014-02-16 18:01:21 <wallet42> okay thx
495 2014-02-16 18:01:30 <michagogo> cloud|(keeping in mind that most large miners use modified bitcoind)
496 2014-02-16 18:02:55 <shaileshg> michagogo|cloud: has anyone done analysis on size by which blockchain will bloat if OP_RETURN is allowed in the mainnet viz-a-viz many ways people can use that feature to inject important information regarding a txn in the blockchain for anyone to confirm at any later point in time..
497 2014-02-16 18:03:09 <sipa> shaileshg: that's an impossible question
498 2014-02-16 18:03:13 <michagogo> cloud|shaileshg: How would such analysis be done?
499 2014-02-16 18:03:23 <michagogo> cloud|You'd need to know/predict how much it would be used
500 2014-02-16 18:03:34 <Luke-Jr> shaileshg: there is no legit value in injecting data into the blockchain