1 2014-02-09 00:06:13 <jakov> ok
2 2014-02-09 00:06:48 <jakov> well best of luck on your posts, i guess you could also try asking around irc every so often
3 2014-02-09 00:06:56 <jakov> wait you're doing that now arnt you ; )
4 2014-02-09 01:00:06 <michagogo> cloud|Hm, cfields is listed in the Credits section of the release notes twice
5 2014-02-09 01:00:12 <michagogo> cloud|As Cory Fields, and as theuni
6 2014-02-09 05:03:19 <jcorgan> sipa: ever going to pick back up #2802?
7 2014-02-09 05:40:07 <PLM3> fully synced blockchain is 17gigs, this is normal or I'm using wrong FS ?
8 2014-02-09 05:42:36 <fanquake> PLM3 Sounds about right.
9 2014-02-09 12:37:10 <orweinberger> How can I 'listen' to new unconfirmed transactions and block the way blockchain.info does?
10 2014-02-09 12:39:37 <jn> http://www.bitlisten.com/
11 2014-02-09 12:41:21 <sipa> orweinberger: -blocknotify and -walletnotify in the reference client
12 2014-02-09 12:41:47 <sipa> orweinberger: or hse one of the many bitcoin p2p libraries, and listen for the blocks/transactions difectly yourself
13 2014-02-09 12:42:29 <orweinberger> sipa: Thanks!
14 2014-02-09 13:03:02 <_MrB_> are logs of this channel accessible on the web?
15 2014-02-09 13:04:13 <sipa> yes
16 2014-02-09 13:06:26 <_MrB_> i found bitcoinstats.com but that is not searchable
17 2014-02-09 13:06:45 <sipa> google is your friend
18 2014-02-09 13:10:07 <_MrB_> apparently not because it's not giving me anythin useful other than bitcoinstats.com
19 2014-02-09 13:54:03 <sipa> petertodd: how do you feel about my proposed kdf?
20 2014-02-09 14:03:53 <petertodd> sipa: it's fine, I mainly just haven't been bringing it up because I think something truly dead simple is more likely to help the bip39 process along; I'm not sure they need kdf's at all
21 2014-02-09 14:04:31 <petertodd> sipa: (it'd be fair to say your kdf is where I got the idea to grind to a distinguished point)
22 2014-02-09 14:12:28 <sipa> fair enough
23 2014-02-09 14:22:46 <alex_fun> heya
24 2014-02-09 14:23:07 <sipa> petertodd: i just don't want to keep pushing my own solution, as i'm likely not objective about it :)
25 2014-02-09 14:23:32 <petertodd> sipa: heh, same here, so I'll call my solution your one :P
26 2014-02-09 14:23:54 <alex_fun> when btc daemon starts it first looks for trusted nodes that are A record of dns.xyz.com sites? and then does it also checks pnseeds if nodes found already? or only when dns threat returns 0 addresses?
27 2014-02-09 14:24:03 <alex_fun> :)
28 2014-02-09 14:24:03 <alex_fun> heya petertodd )
29 2014-02-09 14:24:07 <petertodd> alex_fun: s/trusted//
30 2014-02-09 14:24:33 <petertodd> alex_fun: you're thinking of the seed nodes, and on a full client they can't do all that much to harm you
31 2014-02-09 14:24:57 <alex_fun> petertodd: yes, I am just curious how it all works
32 2014-02-09 14:25:17 <petertodd> alex_fun: and yeah, I think the logic is to use the seeds first, and only then resort to pnseeds
33 2014-02-09 14:25:44 <alex_fun> it seems dns seed nodes simply serve as name holders for seeds who addresses are IP addresses in A record of dns server domain name
34 2014-02-09 14:25:59 <sipa> alex_fun: most dns seeds return many IP addresses
35 2014-02-09 14:26:02 <petertodd> alex_fun: the dns seed nodes tend to run special software that scans the network looking for ip addresses
36 2014-02-09 14:26:12 <sipa> alex_fun: and return different ones each time
37 2014-02-09 14:26:23 <petertodd> alex_fun: try host testnet-seed.bitcoin.petertodd.org
38 2014-02-09 14:26:23 <sipa> they're just using DNS as a very scalable distribution mechanism
39 2014-02-09 14:26:27 <alex_fun> lol I made test dns node with boxes that run code
40 2014-02-09 14:26:29 <alex_fun> and it works
41 2014-02-09 14:26:47 <alex_fun> but I did not know how to add the aforementioned extra
42 2014-02-09 14:26:49 <petertodd> alex_fun: I can assure you most boxes run code :P
43 2014-02-09 14:27:25 <alex_fun> i did test by running 1 node with diff params and box nr 1 said bad node and removed its IP from addr manager
44 2014-02-09 14:27:31 <alex_fun> something like that
45 2014-02-09 14:27:49 <petertodd> oh, you were messing around making an alt coin?
46 2014-02-09 14:27:52 <alex_fun> to see if i can connect nodes with diff POW params to net somehow and how they are detected
47 2014-02-09 14:28:37 <alex_fun> petertodd: lol 0 comments, lets say I reverse engeneer code to see how it works
48 2014-02-09 14:28:43 <petertodd> yeah, you'll get ignored and eventually wind up on the DoS-ban list of most nodes on the network
49 2014-02-09 14:29:03 <alex_fun> its rather clever
50 2014-02-09 14:29:53 <alex_fun> <petertodd> alex_fun: the dns seed nodes tend to run special software that scans the network looking for ip addresses - yet it seems each node runs it, they have some build it params to detect bad nodes
51 2014-02-09 14:29:57 <petertodd> interesting, someone created a "StealthBit" thing that genuinely implements part of stealth addresses, and they provided binaries that are malware: https://pay.reddit.com/r/Bitcoin/comments/1xf2qj/my_wallet_just_emptied_into_this_address/
52 2014-02-09 14:30:22 <alex_fun> petertodd: what woud sleathbit do?
53 2014-02-09 14:30:50 <petertodd> alex_fun: it basically just did some ECC multiplication; didn't implement anything participarly useful
54 2014-02-09 14:31:08 <petertodd> alex_fun: and it looks like the binaries, but not the soruce code, had some kind of wallet stealing malware
55 2014-02-09 14:32:02 <alex_fun> yes as source code would be too obvious :)
56 2014-02-09 14:32:14 <alex_fun> reddit is FUD land often :)
57 2014-02-09 14:32:21 <petertodd> yup! some plausibile deniability there too, potentially
58 2014-02-09 14:32:44 <alex_fun> anyone can compile btc binaries as mallware too and blame who knows what :D
59 2014-02-09 14:33:04 <petertodd> alex_fun: we have deterministic builds for that reason - multiple independent people compile the bitcoin core binaries
60 2014-02-09 14:33:21 <alex_fun> and sign with pgp?
61 2014-02-09 14:33:33 <alex_fun> or some way to make sure they are those who compiled it?
62 2014-02-09 14:33:33 <petertodd> yup
63 2014-02-09 14:33:47 <alex_fun> oki thats nice
64 2014-02-09 14:34:14 <petertodd> tl;dr: don't ever trust wallet software that isn't pgp signed
65 2014-02-09 14:34:41 <alex_fun> there is way easier solution
66 2014-02-09 14:34:51 <alex_fun> run wallet with 0.1 btc
67 2014-02-09 14:34:55 <alex_fun> and see if it goes or stays :D
68 2014-02-09 14:35:06 <petertodd> necessary, but not sufficient :)
69 2014-02-09 14:35:15 <alex_fun> if it goes , give it to u mother in law :)
70 2014-02-09 14:35:55 <alex_fun> petertodd: with intel cpu there is no 100% security imo
71 2014-02-09 14:36:03 <alex_fun> however I care 0
72 2014-02-09 14:36:14 <petertodd> alex_fun: nah, hiding complex hardware backdoors in ICs isn't as easy as it sounds...
73 2014-02-09 14:36:45 <alex_fun> petertodd: my mate served in Iraq and he told me road mines used there detected intel military hardware ;)
74 2014-02-09 14:36:47 <alex_fun> and well anyways
75 2014-02-09 14:37:24 <petertodd> alex_fun: the hiding part is easy, but making the backdoor actually do something beyond backdoor a specific piece of software isn't easy, which lets you do tricks like get old hardware, run new software on it, and be reasonably confident
76 2014-02-09 14:37:36 <petertodd> alex_fun: guarantee you they didn't; insurgents aren't that sophisticated
77 2014-02-09 14:38:03 <alex_fun> the dns nodes do they have some ability to notify all network of bad nodes? like when new person joins his node knows which nodes to ban?
78 2014-02-09 14:38:16 <alex_fun> :)
79 2014-02-09 14:38:16 <alex_fun> petertodd: insurgents aren't that sophisticated - correct
80 2014-02-09 14:38:17 <petertodd> nope
81 2014-02-09 14:38:22 <alex_fun> would be nice
82 2014-02-09 14:38:39 <petertodd> the whole point of bitcoin is that it doesn't matter if you are connected to a "bad" node anyway
83 2014-02-09 14:38:48 <alex_fun> say there is dust or ddos, dns nodes detect such nodes and add to some globally availble net
84 2014-02-09 14:39:03 <petertodd> I suggest you think harder about what you are saying
85 2014-02-09 14:39:04 <alex_fun> petertodd: how come? cause bad POW is rejected anyway?
86 2014-02-09 14:39:37 <alex_fun> I am trying to see what is role of `dns` servers apart of them been place holders for trusted nodes IP
87 2014-02-09 14:39:43 <alex_fun> hence the questions
88 2014-02-09 14:40:19 <petertodd> you'll understand it when you understand why those nodes aren't trusted
89 2014-02-09 14:40:26 <alex_fun> [16:26] <sipa> they're just using DNS as a very scalable distribution mechanism - ok so just distribute nodes ips
90 2014-02-09 14:40:48 <alex_fun> petertodd: well I know that each node independently verify POW params
91 2014-02-09 14:40:56 <petertodd> alex_fun: that's a start
92 2014-02-09 14:41:04 <alex_fun> else someone can change reward to 100 coins, diff to 1, etc
93 2014-02-09 14:41:05 <alex_fun> as they like
94 2014-02-09 14:41:14 <petertodd> alex_fun: have you read the original satoshi bitcoin paper?
95 2014-02-09 14:41:25 <alex_fun> like 30 times
96 2014-02-09 14:41:35 <alex_fun> or more
97 2014-02-09 14:41:56 <alex_fun> my new plan it to hire mentor who can explain it to me
98 2014-02-09 14:42:01 <alex_fun> lol
99 2014-02-09 14:42:21 <petertodd> heh, well, in that case, how much are you offering?
100 2014-02-09 14:42:28 <alex_fun> the basics are simple its just I dont know what those math symbols mean, I may try in math
101 2014-02-09 14:42:33 <alex_fun> well 50 to 100 usd per hour
102 2014-02-09 14:42:41 <alex_fun> depends how many hours it can take also
103 2014-02-09 14:42:52 <petertodd> how many hours it takes depends on how smart you are :P
104 2014-02-09 14:42:54 <alex_fun> i may decide on lump sum next week dor sure
105 2014-02-09 14:42:56 <alex_fun> yep :D
106 2014-02-09 14:43:13 <petertodd> but you may be able to get a better deal from someone other than me
107 2014-02-09 14:43:19 <alex_fun> I find when Sipa says something I understand well
108 2014-02-09 14:43:30 <alex_fun> when some other people say it well it depends
109 2014-02-09 14:43:46 <alex_fun> and his explanations on wiki is easy to get
110 2014-02-09 14:44:07 <petertodd> there is an art to being a good teacher; I spent six years doing a fine arts degree, and a good chunk of that involved explaining complex technical art to laymen
111 2014-02-09 14:44:44 <alex_fun> yes
112 2014-02-09 14:45:09 <Belxjander> petertodd: being able to simplify the description of anything so even a young child can grasp the basic concepts and then deal with the details in a progressive manner ?
113 2014-02-09 14:45:20 <alex_fun> many people pissed offed by people simplicity
114 2014-02-09 14:45:32 <petertodd> Belxjander: simplify isn't necessarily the right approach
115 2014-02-09 14:45:34 <alex_fun> like Newton said he wants to his mother even
116 2014-02-09 14:45:48 <alex_fun> but Archimedes and Sipa are good at explaning
117 2014-02-09 14:45:50 <petertodd> Belxjander: simplify bitcoin and you quickly aren't describing bitcoin
118 2014-02-09 14:45:56 <alex_fun> and some more people I maybe dont know
119 2014-02-09 14:46:24 <alex_fun> petertodd: yet Archimesed was able to explain in simple terms while correct as well
120 2014-02-09 14:46:31 <Belxjander> petertodd: yup
121 2014-02-09 14:46:40 <alex_fun> Archimedes
122 2014-02-09 14:46:53 <petertodd> alex_fun: note that it helps that bitcoin *is* really simple in many ways
123 2014-02-09 14:47:03 <Belxjander> petertodd: I start with some base concepts using money they already know...and then change a couple of things...just "roughly explaining some parts" of how bitcoin works
124 2014-02-09 14:47:41 <Belxjander> petertodd: I actually have a couple of students where I work now who became interested in looking at bitcoin...no idea if they actually bought any or not
125 2014-02-09 14:47:49 <Belxjander> but they DID ask me for further information
126 2014-02-09 14:47:56 <petertodd> Belxjander: re: money, I tend to start with the analogy of a village where everyone has a book of transactions, and everyone is honest
127 2014-02-09 14:48:28 <petertodd> Belxjander: helps to get people in the model that bitcoin is just a bunch of information too
128 2014-02-09 14:48:48 <petertodd> Belxjander: also, good to hold back on explaining mining until you explain the concept of a shared ledger
129 2014-02-09 14:48:58 <Belxjander> petertodd: well I start with "barter" and explaining that
130 2014-02-09 14:49:05 <Belxjander> THEN connecting "cash" into the money model
131 2014-02-09 14:49:12 <alex_fun> petertodd: to me it seems btc is very simple as idea - what it does it creates longer number, then if u guess is lower than this number u win, then there are blocks where winner reward is recorded along with params he used, then its sha and sha again aka encrypted, then it gives block hash aka its ID, next block got to use same params else hash wont fit?
132 2014-02-09 14:49:13 <alex_fun> and so on
133 2014-02-09 14:49:28 <alex_fun> and target goes lower and lower
134 2014-02-09 14:49:29 <alex_fun> so thats it
135 2014-02-09 14:49:36 <petertodd> Belxjander: right, you're approach is economics driven - I usually talk to bitcoin to people who already understand barter and how modern currencies work
136 2014-02-09 14:49:39 <Belxjander> then explaining about how "cash" and "bitcoins" have some similarities and other points of note are more like "barter" value
137 2014-02-09 14:49:46 <alex_fun> POW prize to reward to chain supprters
138 2014-02-09 14:50:04 <Belxjander> petertodd: I have to explain it this way as I explain it in English for Japanese Students (they don't know the economics terms initially)
139 2014-02-09 14:50:10 <alex_fun> petertodd: so in your view what is say modern fiat and btc similarity? :D
140 2014-02-09 14:50:31 <alex_fun> say usd and btc similarity as currency
141 2014-02-09 14:50:40 <Belxjander> petertodd: it does give them a good idea of what I am discussing and some really interesting questions and "what if"s have come up too
142 2014-02-09 14:50:50 <petertodd> Belxjander: e.g. at my last job, I explained bitcoin to our accountances/controllers, all strong economic/finance backgrounds, and they could already see some of the social implications from the way mining works and so on - by presenting the tech details correctly they understood the gist of it pretty well
143 2014-02-09 14:51:14 <petertodd> alex_fun: of course it is, bitcoin *is* a fiat currency; fiat of the masses in a sense
144 2014-02-09 14:51:48 <alex_fun> petertodd: is bitcoin or say any satoshi paper based coin is holder of value and if yes how?
145 2014-02-09 14:51:49 <alex_fun> ;)
146 2014-02-09 14:52:20 <Apocalyptic> that sentence doesn't make any sense
147 2014-02-09 14:52:21 <petertodd> alex_fun: http://www.theonion.com/articles/us-economy-grinds-to-halt-as-nation-realizes-money,2912/
148 2014-02-09 14:52:29 <alex_fun> petertodd: u answer pls
149 2014-02-09 14:52:40 <alex_fun> if I want to read some site i sure do :D
150 2014-02-09 14:52:45 <alex_fun> I am talking human 2 human
151 2014-02-09 14:52:46 <petertodd> alex_fun: what is or isn't value is OT for -dev
152 2014-02-09 14:52:59 <alex_fun> ok cool
153 2014-02-09 14:53:05 <alex_fun> if it so for u so be be it :D
154 2014-02-09 14:54:11 <alex_fun> petertodd: what do you think about idea to make consensus based checkpoints to nullify double spending?
155 2014-02-09 14:54:38 <petertodd> alex_fun: we have those already
156 2014-02-09 14:54:46 <alex_fun> <petertodd> Belxjander: e.g. at my last job, I explained bitcoin to our accountances/controllers, all strong economic/finance backgrounds, and they could already see some of the social implications - social implication in dev - o my :P
157 2014-02-09 14:54:51 <alex_fun> petertodd: how come?
158 2014-02-09 14:55:01 <alex_fun> they just set in git
159 2014-02-09 14:55:12 <petertodd> alex_fun: simple, consensus==proof-of-work, and double-spending is solved by not being present in the blockchain
160 2014-02-09 14:55:30 <petertodd> alex_fun: your describing the problem bitcoin solves in the first place
161 2014-02-09 14:55:44 <alex_fun> petertodd: any large pool with say 40% can easily double spend
162 2014-02-09 14:55:48 <alex_fun> and its been done already
163 2014-02-09 14:55:53 <Apocalyptic> sigh
164 2014-02-09 14:56:13 <alex_fun> I am talking in practical code terms
165 2014-02-09 14:56:39 <petertodd> alex_fun: so am I, the practical solution is to accept that a transaction that is not in a block doesn't exist yet
166 2014-02-09 14:56:41 <alex_fun> consesus atm is longest chain
167 2014-02-09 14:56:54 <alex_fun> no matter if benevolent or not
168 2014-02-09 14:57:35 <alex_fun> petertodd: yes what u said is correct and logical
169 2014-02-09 14:58:16 <alex_fun> petertodd: as when chain can double spend by virtue of its size there is nothing u can do
170 2014-02-09 14:58:41 <alex_fun> as u cant see it when it does not exist lol
171 2014-02-09 14:58:43 <alex_fun> bingo!
172 2014-02-09 14:59:13 <alex_fun> so - solution is to use like 120 confirms for like tickets like when I sell say house for 600,000 usd?
173 2014-02-09 14:59:21 <alex_fun> *for large tickets
174 2014-02-09 14:59:23 <petertodd> alex_fun: yup
175 2014-02-09 15:00:47 <petertodd> (assuming you're selling a house in a crypto wasteland populated by roving gangs of leather wearing cryptographers untarnished by the rule of law)
176 2014-02-09 15:01:08 <petertodd> (if not, you could try just getting their ID and going to the police if they double-spend you)
177 2014-02-09 15:01:25 <alex_fun> lol I met some last night - pretty cool people btw :D
178 2014-02-09 15:02:42 <petertodd> anyway, work to do, later
179 2014-02-09 15:03:01 <alex_fun> ty dude :D
180 2014-02-09 15:09:00 <alex_fun> ty :)
181 2014-02-09 15:14:28 <gammons> Hi, I had a general question. For the current block, as transactions get added to it, do miners take into account new transactions as they come in?
182 2014-02-09 15:14:58 <sipa> define "the current block" ?
183 2014-02-09 15:15:39 <sipa> miners do update their candidate blocks they're mining on from time to time with new transactions, yes
184 2014-02-09 15:16:08 <gammons> Yeah, i guess I meant the current transactions not in a block yet
185 2014-02-09 15:49:18 <michagogo> cloud|gammons: They may, and usually do
186 2014-02-09 15:49:37 <michagogo> cloud|Often not for every single new transaction that comes in, but periodically
187 2014-02-09 15:50:24 <michagogo> cloud|Also, this is "may" and not "must" -- it's certainly possible to just ignore any new transactions since you started hashing your block
188 2014-02-09 15:50:28 <michagogo> cloud|Oh, s/he left...
189 2014-02-09 15:50:45 <sipa> and came back
190 2014-02-09 15:50:46 <sipa> and left
191 2014-02-09 15:51:34 <michagogo> cloud|indeed.
192 2014-02-09 16:22:06 <chichov> how come the OP_CHECKSIG procedure includes the subscript (with the destination address) in the ScriptSig field, if it is already there in the outputs?
193 2014-02-09 16:22:47 <azariah4> Hi, question about bip-0070: it specifies that the Bitcoin client (of the customer) broadcasts transactions on the network before sending the Payment message to the merchant
194 2014-02-09 16:23:12 <chichov> I know that "this is how OP_CHECKSIG works", but why would we copy the PubKeyScript basically into another field if it is already included in the signature?
195 2014-02-09 16:23:13 <azariah4> However, then it says that the merchant also broadcasts these onto the bitcoin network?
196 2014-02-09 16:23:37 <azariah4> (when it receives the Payment message)
197 2014-02-09 16:23:40 <sipa> chichov: checksig needs to have the full public key
198 2014-02-09 16:23:58 <sipa> azariah4: there's no dispute about that
199 2014-02-09 16:24:11 <sipa> chichov: the previous output only has the address
200 2014-02-09 16:24:39 <sipa> so to spend it you provide both the pubkey and the signature, and the pubkey's hash has to be the address, and the signature must be valid for that public key
201 2014-02-09 16:24:58 <chichov> I believe I've misformulated myself
202 2014-02-09 16:25:04 <chichov> let me try again
203 2014-02-09 16:25:05 <azariah4> sipa: OK, so its broadcasted by both the customer and the merchant? What's the added value of having the merchant broadcast the txs again?
204 2014-02-09 16:25:50 <chichov> when we build the signature for a transaction we have to provide a signature for all outputs we intend to use
205 2014-02-09 16:26:09 <sipa> azariah4: (my personal opinion) the sender should only care about getting his payment to the receiver, his concern is getting his transaction accepted by them
206 2014-02-09 16:26:37 <sipa> azariah4: the receiver is the one who cares about getting the transaction confirmed, as it is necessary to spend it again
207 2014-02-09 16:27:06 <sipa> azariah4: by having the receiver take responsibility of the broadcast, the sender doesn't have to sty online and rebroadcast
208 2014-02-09 16:27:22 <chichov> now, since we are signing the complete transaction and this would include ScriptSig itself, we could leave it blank (for all inputs), serialize the transaction and then build a signature over that
209 2014-02-09 16:27:38 <azariah4> sipa: ah, makes sense, thanks!
210 2014-02-09 16:27:50 <chichov> that we'd basically do for all the inputs
211 2014-02-09 16:28:03 <sipa> chichov: that's more or less what happens
212 2014-02-09 16:28:39 <chichov> but why is it that we put a slightly processed ScriptPubKey into the ScriptSig field?
213 2014-02-09 16:28:47 <sipa> chichov: ask satoshi
214 2014-02-09 16:28:54 <chichov> see https://en.bitcoin.it/w/images/en/7/70/Bitcoin_OpCheckSig_InDetail.png
215 2014-02-09 16:28:55 <sipa> afaik, there is no good reason for it
216 2014-02-09 16:29:15 <chichov> yea, it seems very odd to me
217 2014-02-09 16:29:33 <sipa> we already commit to the entire previous transaction being spent, by including its hash
218 2014-02-09 16:29:44 <sipa> there should be no need to put the output script being spent again in there
219 2014-02-09 16:30:05 <chichov> nevertheless it seems that this is being done
220 2014-02-09 16:30:14 <sipa> my guess is that it seemed "neat"
221 2014-02-09 16:30:17 <sipa> and couldn't hurt
222 2014-02-09 16:30:28 <sipa> and satoshi liked belt-and-suspenders
223 2014-02-09 16:30:39 <chichov> absolutely :D
224 2014-02-09 16:31:14 <chichov> now in that graphic I've provided it also says at the very end that the signature check is done for all inputs and the associated output
225 2014-02-09 16:31:32 <chichov> that'd mean that for 2 outputs this is done 2*#Inputs?
226 2014-02-09 16:31:50 <petertodd> sipa: note how it does mean you don't need to provide the transaction itself to prove what address is being signed for
227 2014-02-09 16:32:10 <petertodd> sipa: if he had added the txout value to that, we'd be golden...
228 2014-02-09 16:32:56 <wallet42> i have a question about this OP_RETURN and OP_DROP. afaiu a tx can have 1 OP_DROP only, if it can be vout 0 but if it is not, the bitcoins are destroyed since unspendable, you can add a 80 bytes arbitrary string after it
229 2014-02-09 16:32:57 <chichov> that'd also be a bit odd as it should be sufficient to only verify all inputs and not iterate everything over all outputs one more time
230 2014-02-09 16:33:11 <petertodd> wallet42: OP_DROP isn't standard
231 2014-02-09 16:33:54 <petertodd> chichov: the point is to be able to verify what is being signed compactly, without needing large proofs (e.g. on a trezor)
232 2014-02-09 16:34:34 <sipa> petertodd: good point
233 2014-02-09 16:34:45 <petertodd> wallet42: as for op_return, yes, one op-ret per tx, and it can be in any position. (which frankly is dumb: just makes people who need more data use other mechanisms)
234 2014-02-09 16:34:46 <sipa> petertodd: though i'm not sure there are cases where you really care
235 2014-02-09 16:35:01 <sipa> petertodd: as signer, you already need to know which inputs and their address you are consuming
236 2014-02-09 16:35:16 <wallet42> okay so waht is OP_RETURN?
237 2014-02-09 16:35:17 <sipa> petertodd: and if the one building the (unsigned) transaction for you lies, the result is invalid anyway
238 2014-02-09 16:35:18 <petertodd> sipa: not necessarily, again, think of the trezor
239 2014-02-09 16:35:53 <sipa> petertodd: which isn't true for the amounts... someone can trick you into dumping your coins into fees
240 2014-02-09 16:36:26 <petertodd> sipa: it's plausible that you could be fooled into signing for a txout whose scriptPubKey was something different, but is still spendable, remember how sighash flags are useful in conjunction with CHECKMULTISIG
241 2014-02-09 16:36:40 <sipa> yeah, sighash flags may complicate matters
242 2014-02-09 16:37:11 <petertodd> wallet42: basically a txout is allowed to have a scriptPubKey in the form OP_RETURN, OP_RETURN <0 to 80 byte pushdata>, and by accident OP_RETURN <some other opcode>
243 2014-02-09 16:37:14 <chichov> petertodd: what do you precisely mean with that?
244 2014-02-09 16:37:26 <petertodd> chichov: by what?
245 2014-02-09 16:37:32 <wallet42> https://github.com/bitcoin/bitcoin/pull/2738
246 2014-02-09 16:37:41 <wallet42> so OP_RETURN is standard?
247 2014-02-09 16:37:49 <sipa> it will be
248 2014-02-09 16:37:49 <wallet42> with 80 bytes?
249 2014-02-09 16:37:55 <petertodd> wallet42: yup and BTC Guild are mining them
250 2014-02-09 16:38:10 <wallet42> and the output is spendable?
251 2014-02-09 16:38:13 <petertodd> wallet42: (and eligius, but they mine all sorts of stuff)
252 2014-02-09 16:38:24 <wallet42> or does the bitcoins are lost?
253 2014-02-09 16:38:31 <petertodd> wallet42: no, not spendable
254 2014-02-09 16:38:42 <petertodd> wallet42: op_return == fail the script immediately
255 2014-02-09 16:38:51 <sipa> you use a 0.00000000 BTC output for OP_RETURN
256 2014-02-09 16:39:03 <petertodd> sipa: well, you can use it to sacrifice btc too
257 2014-02-09 16:39:07 <sipa> sure
258 2014-02-09 16:39:17 <chichov> petertodd: the part about proofs. My question was why would we check the signatures for all inputs and(!) for all outputs?
259 2014-02-09 16:39:30 <petertodd> chichov: you're mistaken
260 2014-02-09 16:39:41 <sipa> chichov: there is just one signature for every input
261 2014-02-09 16:39:44 <petertodd> chichov: by txout I mean the txout being spent
262 2014-02-09 16:39:47 <sipa> there is no validation of outputs
263 2014-02-09 16:39:58 <petertodd> sipa: one scriptSig, there can be multiple signatures evaluated in that scriptSig
264 2014-02-09 16:40:00 <sipa> the scriptPubKey of outputs is basically a byte array
265 2014-02-09 16:40:02 <wallet42> okay. 1 OP_RETURN per tx, not in txoutset since always unspendable, can be vout 0, if not, bitcoins are gone ? correct?
266 2014-02-09 16:40:10 <petertodd> wallet42: correct
267 2014-02-09 16:40:47 <petertodd> incidentally, I realized the other day that being able to have multiple bare OP_RETURN outputs in a tx could be useful with SIGHASH_SINGLE
268 2014-02-09 16:40:48 <wallet42> is a the minfee mandatory?
269 2014-02-09 16:41:04 <petertodd> wallet42: dunno, use the source luke
270 2014-02-09 16:41:07 <wallet42> kk
271 2014-02-09 16:41:12 <chichov> petertodd: have I maybe misread https://en.bitcoin.it/w/images/en/7/70/Bitcoin_OpCheckSig_InDetail.png (see last line)? It seems natural to verify all inputs in order to verify that you indeed own all the inputs, but it does say "Repeat all steps for each TxIn object and associated TxOut"
272 2014-02-09 16:41:33 <chichov> which I read: For all outputs do{ For all inputs do{} }
273 2014-02-09 16:41:48 <wallet42> so i still dont get what is the issue with OP_RETURN vs OP_DROP ?
274 2014-02-09 16:41:50 <sipa> chichov: by assosicated TxOut, it refers the prevouts being spent
275 2014-02-09 16:42:01 <sipa> wallet42: OP_RETURN doesn't end up in the UTXO set
276 2014-02-09 16:42:08 <sipa> wallet42: so it doesn't clutter everyone's database
277 2014-02-09 16:42:16 <wallet42> yes this is what i get
278 2014-02-09 16:42:17 <chichov> sipa: oh, then it makes sense.
279 2014-02-09 16:42:25 <wallet42> so why would anyone want to have OP_DROP then?
280 2014-02-09 16:42:31 <chichov> sipa: thanks
281 2014-02-09 16:42:50 <sipa> wallet42: for some odd reason, people like to think of bitcoin as a communication channel
282 2014-02-09 16:42:52 <wallet42> if OP_RETURN fullfils the issue
283 2014-02-09 16:43:14 <sipa> OP_RETURN doesn't work for data associated with a particular output
284 2014-02-09 16:43:25 <sipa> if its needs to survive coinjoin & co
285 2014-02-09 16:43:42 <petertodd> sipa: well, op_return can go in any location, but yeah, not as easy to use as op_drop in that regard
286 2014-02-09 16:43:52 <wallet42> oh.. so op_drop whould be data per Spendable output?
287 2014-02-09 16:44:17 <sipa> yeah, but it's uglier
288 2014-02-09 16:44:20 <wallet42> now i get it....
289 2014-02-09 16:44:28 <sipa> as it cannot be separated from the actually necessary data
290 2014-02-09 16:45:27 <wallet42> sure⦠the script would be ugly since in some databases it is stored AS IS and in some, OP_DROP is left out
291 2014-02-09 16:45:29 <petertodd> sipa: people like to think of bitcoin as a communication channel because its the only one you have where the message arrives atomically with the payment; why stealth addresses uses it as the com channel
292 2014-02-09 16:45:45 <petertodd> wallet42: we mean ugly as in scalability concerns
293 2014-02-09 16:45:56 <sipa> petertodd: yeah
294 2014-02-09 16:46:13 <wallet42> kk
295 2014-02-09 16:46:27 <wallet42> thx for the clarification :)
296 2014-02-09 16:48:42 <Luke-Jr> DrHaribo: ping
297 2014-02-09 17:12:36 <azariah4> What reference implementations exists for the merchant side of BIP70?
298 2014-02-09 17:41:22 <michagogo> cloud|18:26:08 <sipa> azariah4: (my personal opinion) the sender should only care about getting his payment to the receiver, his concern is getting his transaction accepted by them \n 18:26:35 <sipa> azariah4: the receiver is the one who cares about getting the transaction confirmed, as it is necessary to spend it again
299 2014-02-09 17:41:22 <michagogo> cloud|sipa: Change.
300 2014-02-09 17:41:25 <michagogo> cloud|18:38:12 <petertodd> wallet42: (and eligius, but they mine all sorts of stuff)
301 2014-02-09 17:41:44 <michagogo> cloud|petertodd: Uh, I'm pretty sure Luke said that Eligius does *not* mine OP_RETURN transacctions, because they're spam
302 2014-02-09 17:43:07 <jbitcm-> hello
303 2014-02-09 17:43:18 <jbitcm-> i want to help to develop
304 2014-02-09 17:43:36 <petertodd> michagogo|cloud: he does, just look at the ones that have been mined recently
305 2014-02-09 17:43:47 <michagogo> cloud|Luke-Jr: Oh, did that change?
306 2014-02-09 17:43:50 <michagogo> cloud|er
307 2014-02-09 17:43:51 <michagogo> cloud|;;seen Luke-Jr
308 2014-02-09 17:43:52 <gribble> Luke-Jr was last seen in #bitcoin-dev 55 minutes and 9 seconds ago: <Luke-Jr> DrHaribo: ping
309 2014-02-09 17:44:37 <sipa> michagogo|cloud: sure, but if you're payment someone, they have a very good incentive already to broadcast
310 2014-02-09 17:44:56 <sipa> michagogo|cloud: it's probably to strong to say remove the responsibility, as the sender still has to create something that is confirmable
311 2014-02-09 17:48:16 <Luke-Jr> not sure the current state, but when I get to updating Eligius's bitcoind, blocking OP_RETURN spam is on the todo list
312 2014-02-09 17:49:58 <michagogo> cloud|Luke-Jr: Did something recently change about your setup?
313 2014-02-09 17:50:15 <michagogo> cloud|I know you have, in the past, stated that you don't mine OP_RETURN transactions
314 2014-02-09 17:50:30 <Luke-Jr> michagogo|cloud: if I'm wrong on that, it's a bug âº
315 2014-02-09 17:50:36 <michagogo> cloud|Was that just an "I'm not willing to"?
316 2014-02-09 17:50:44 <michagogo> cloud|Not an actual "We're not"?
317 2014-02-09 17:50:59 <Luke-Jr> michagogo|cloud: I *thought* they were being filtered, but I may be wrong
318 2014-02-09 17:51:31 <Luke-Jr> DrHaribo: when you get a chance, get Nasser's contact info from me; he would like to discuss BitMinter client support for Monarch
319 2014-02-09 17:58:01 <jcorgan> sipa: do you plan to revive the addrindex branch?
320 2014-02-09 17:58:11 <sipa> no
321 2014-02-09 17:58:29 <sipa> at least not in the near future
322 2014-02-09 18:06:18 <jcorgan> do you think the feature is at least worthwhile to have?
323 2014-02-09 18:10:40 <sipa> jcorgan: for debugging or having something like a local built-in blockexplorer, yes
324 2014-02-09 18:11:03 <sipa> jcorgan: but ny fear is people building features on top of it that assumes it being possible
325 2014-02-09 18:11:18 <petertodd> Luke-Jr: heh, you're gonna love my decentralized p2p exchange with honest pricing proposal...
326 2014-02-09 18:11:30 <sipa> making it harder to move to an ecosysyem where people generally don't have the blockchain available
327 2014-02-09 18:12:42 <Luke-Jr> petertodd: ?
328 2014-02-09 18:12:50 <petertodd> Luke-Jr: posted to the -dev list
329 2014-02-09 18:20:27 <deaconboogie> Is it uncouth to ask an altcoin dev question in this channel?
330 2014-02-09 18:20:44 <gribble> Luke-Jr was last seen in #bitcoin-dev 8 minutes and 2 seconds ago: <Luke-Jr> petertodd: ?
331 2014-02-09 18:20:44 <petertodd> ;;seen Luke-Jr
332 2014-02-09 18:20:50 <petertodd> deaconboogie: ^
333 2014-02-09 18:21:26 <deaconboogie> ... ?
334 2014-02-09 18:21:47 <petertodd> deaconboogie: Luke-Jr thinks altcoins are a scam, and will tell you it's uncouth
335 2014-02-09 18:23:53 <deaconboogie> Well, then I guess I'll fire away... ? I upgraded my alt from 0.6.2 to 0.8.6 and on launch it barks about the genesis block being invalid, even though - to the best of my knowledge - I've copied everything over exactly: pchMessageStart, ECDSA key, main and test net genesis blocks, merkelroots, nNonce, etc. There must be something that I've missed...
336 2014-02-09 18:23:59 <andytoshi> i think asking altcoin dev questions is uncouth because the altcoin devs can't program
337 2014-02-09 18:24:17 <deaconboogie> andytoshi: I wouldn't disagree.
338 2014-02-09 18:24:36 <petertodd> deaconboogie: answering that question would be like answering a homework problem :P
339 2014-02-09 18:25:10 <Luke-Jr> petertodd: it has nothing to do with me, altcoins are off-topic in #bitocin*
340 2014-02-09 18:25:11 <deaconboogie> Remedial math or advanced calculus?
341 2014-02-09 18:25:52 <Luke-Jr> deaconboogie: what you've missed (well, one thing) is that Bitcoin is not compatible with 0.6.2 anymore.
342 2014-02-09 18:26:07 <deaconboogie> Luke-Jr: This is why I am upgrading it to 0.8.6.2
343 2014-02-09 18:26:10 <petertodd> deaconboogie: somewhere in between
344 2014-02-09 18:26:47 <Luke-Jr> deaconboogie: you can't just "upgrade" a 0.6.2-based alt to 0.8.6
345 2014-02-09 18:26:58 <Luke-Jr> you would need to do a hardfork procedure on the network
346 2014-02-09 18:27:06 <Luke-Jr> but again, this is all off-topic here
347 2014-02-09 18:27:17 <Luke-Jr> #cryptodev IIRC is the place
348 2014-02-09 18:27:49 <deaconboogie> Luke-Jr: Hardfork is expected at block 27000 when Kimoto Gravity Well goes into effect... But I'll try that other channel, nobody has suggested it before! Thank you!
349 2014-02-09 18:27:52 <jcorgan> sipa: i recall a similar line of thought in the pull request.
350 2014-02-09 18:28:06 <Luke-Jr> Kimoto Gravity Well O.o?
351 2014-02-09 18:28:38 <jcorgan> i indeed am looking at something like a local blockexplorer
352 2014-02-09 18:28:55 <deaconboogie> Luke-Jr: A difficulty scaling algo to protect against auto-switching pools raping the coin.
353 2014-02-09 18:29:52 <warren> Luke-Jr: per-block difficulty adjustment I think
354 2014-02-09 18:30:01 <deaconboogie> Luke-Jr: What warren said.
355 2014-02-09 18:30:02 <Luke-Jr> i c
356 2014-02-09 18:30:24 <warren> Luke-Jr: I wonder to what extent it's vulnerable to time travel attacks
357 2014-02-09 18:30:45 <warren> Luke-Jr: it would mean you need less than 51% to replace the chain, I think
358 2014-02-09 18:30:46 <jcorgan> the branch doesn't merge cleanly with master right now due to conflicting changes in the leveldb code, but I can backtrack the merge until it goes cleanly and replay from there
359 2014-02-09 19:08:19 <sipa> for anyone wondering what secp256k1 looks like: http://bitcoin.stackexchange.com/questions/21907/what-does-the-curve-used-in-bitcoin-secp256k1-look-like/21911#21911
360 2014-02-09 19:10:16 <jcorgan> it's full of stars!
361 2014-02-09 19:11:37 <jakov> what if you dont plot it in a finite field
362 2014-02-09 19:11:42 <jakov> but just a cartesian
363 2014-02-09 19:42:04 <sipa> jakov: added
364 2014-02-09 19:42:44 <jakov> looks like you need to zoom out there
365 2014-02-09 19:43:07 <jakov> not from -128 to 128 but within the characteristic scale of that curve
366 2014-02-09 19:43:18 <jakov> i dont know if thats possible btw, i know little about EC
367 2014-02-09 19:44:08 <sipa> no idea what you mean
368 2014-02-09 19:44:13 <sipa> the first plot is accurate
369 2014-02-09 19:44:21 <sipa> the second is just to give an impression
370 2014-02-09 19:44:50 <jakov> the second looks like you zoomed in too much
371 2014-02-09 19:45:00 <jakov> so like
372 2014-02-09 19:45:30 <jakov> where do the numbers -128 and 128 come from?
373 2014-02-09 19:46:00 <jakov> its as if you're looking at a circle of radius 10, but on a graph that goes from -0.01 to 0.01
374 2014-02-09 19:46:06 <andytoshi> jakov: they give a range of 2^8+1, which is the size of the field
375 2014-02-09 19:46:10 <andytoshi> jakov: no, it's not like that at all
376 2014-02-09 19:46:19 <jakov> okay then
377 2014-02-09 19:47:20 <andytoshi> this is a cool plot sipa, i have wondered this question myself
378 2014-02-09 19:47:31 <andytoshi> and the answer is exactly as unenlightening as i expected :)
379 2014-02-09 19:48:25 <jakov> yeah cool plot
380 2014-02-09 19:48:25 <sipa> the first plot plots the entire coordinate space
381 2014-02-09 19:48:39 <andytoshi> oh, sorry, i see what you're saying jakov
382 2014-02-09 19:49:17 <andytoshi> usually elliptic curve plots look kinda like o<
383 2014-02-09 19:51:20 <sipa> if you zoom in on the real plot, that's what you get
384 2014-02-09 19:51:43 <sipa> the nearest-pixel rounding makes it look a bit differently
385 2014-02-09 19:52:02 <andytoshi> yeah, i see it now, jakov you can do the real-number plot in any graphic calculator, eg kmplot
386 2014-02-09 19:52:13 <jcorgan> andytoshi: EC plots only look like o< when you are calculating them over the reals
387 2014-02-09 19:52:24 <sipa> yeah, of course
388 2014-02-09 19:52:45 <andytoshi> jcorgan: yeah, i know. you are misreading my comment the same as i misread jakov's :P
389 2014-02-09 19:52:51 <jcorgan> lol
390 2014-02-09 19:53:17 <andytoshi> we agree on the finite field plot, there is just suspicion that sipa cut off the 'o' part of the real plot. but in fact there is no such o.
391 2014-02-09 19:53:33 <andytoshi> so all is well, sipa is right
392 2014-02-09 19:53:40 <sipa> \o/
393 2014-02-09 19:53:48 <jakov> without the o that means there are never 3 points that lie on a straight line (?)
394 2014-02-09 19:54:33 <andytoshi> jakov: there are, in the complex plane.
395 2014-02-09 19:54:43 <jakov> doh
396 2014-02-09 19:55:08 <sipa> we must go deeper
397 2014-02-09 19:55:16 <sipa> andytoshi: wanna make a quaternion plot?
398 2014-02-09 19:56:20 <sipa> jakov: every line that intersects the curve in 2 points, intersects it in a third
399 2014-02-09 19:56:22 <andytoshi> lol, that'd be really cool
400 2014-02-09 19:56:36 <andytoshi> i'd need by 16D glasses
401 2014-02-09 19:56:37 <jcorgan> it is sort of mind blowing that ECs retain their group structure over the cartesian plane, over the integers, and over finite fields
402 2014-02-09 19:56:37 <sipa> jakov: no need for the o for that
403 2014-02-09 19:56:54 <sipa> jcorgan: actually, they don't over integers
404 2014-02-09 19:57:00 <jcorgan> oO
405 2014-02-09 19:57:16 <sipa> jcorgan: i think
406 2014-02-09 19:57:30 <sipa> they do over reals and over finite fields
407 2014-02-09 19:59:12 <jakov> when i plot it on kmplot it looks different to your plot on the stackexchange thread
408 2014-02-09 19:59:17 <jakov> it has an o
409 2014-02-09 19:59:22 <jcorgan> well, i'm no expert, just been deep-diving and refamiliarizing myself with this stuff for a few months after not thinking about it for a decade or so
410 2014-02-09 19:59:27 <jakov> y^2 = x^3 + 7 right?
411 2014-02-09 19:59:31 <sipa> yes
412 2014-02-09 19:59:51 <sipa> ACTION install kmplot
413 2014-02-09 19:59:56 <jakov> maybe the one you plotted was y^2 = x^3
414 2014-02-09 19:59:59 <andytoshi> jakov: my copy of kmplot agrees with sipa
415 2014-02-09 20:01:21 <andytoshi> http://download.wpsoftware.net/screenshot.png
416 2014-02-09 20:01:25 <jakov> sec, ill upload mine too
417 2014-02-09 20:01:38 <jakov> wait no, we're agreeing
418 2014-02-09 20:01:57 <jakov> oh hold on, sipa's does have an o
419 2014-02-09 20:01:58 <jcorgan> i don't get an "O"; the plots intersect the y-axis with slope zero due to the 'a' coefficient being zero
420 2014-02-09 20:02:19 <jakov> its just small since the o has a length scale about 2.5
421 2014-02-09 20:02:25 <jakov> which looks small on a 128 scale graph
422 2014-02-09 20:04:03 <jakov> fwiw http://imgur.com/ZDlSU7W
423 2014-02-09 20:04:55 <jcorgan> jakov: mine agrees with your blue line
424 2014-02-09 20:05:04 <jakov> yeah the blue line is + 7
425 2014-02-09 20:05:13 <jakov> green line is without + 7
426 2014-02-09 20:05:49 <jakov> wait a sec, andytoshi's plot crosses y axis at +- 2 while mine seems to cross around 2.5
427 2014-02-09 20:06:25 <jcorgan> sqrt(7) = 2.645...
428 2014-02-09 20:06:38 <BB-Martino> Hi guys. I need general advice or guess what could have happened. Two users withdrew coins from my site with a ~10 seconds difference, the second one ended up being a double spend. I only use sendmany in bitcoind...
429 2014-02-09 20:06:39 <andytoshi> jakov: luckily you can plug in x=0 and do that one by hand..and you get jcorgan's
430 2014-02-09 20:06:50 <andytoshi> yeah, weird. mine is clearly at 2.645. but in the screenshot it has moved o.O
431 2014-02-09 20:06:55 <jakov> yes
432 2014-02-09 20:07:28 <andytoshi> oh, i see, i have a - after the 7 in the sshot, which apparently means "7-3" to kmplot. i think that's a bug..
433 2014-02-09 20:08:00 <sipa> jakov: added a zoomed-in version
434 2014-02-09 20:08:14 <jakov> nice
435 2014-02-09 20:08:26 <jakov> however im gonna stop talking since im interested to see what happened to BB-Martino
436 2014-02-09 20:08:32 <sipa> ?
437 2014-02-09 20:09:45 <BB-Martino> Thanks, but that's all I got.
438 2014-02-09 20:09:56 <BB-Martino> https://blockchain.info/tx/6b557c5dfa22874328fa42c80c6d1b1490329aefdd18479149efcfff759ee30a
439 2014-02-09 20:10:12 <BB-Martino> simple web wallet, been running since xmas 2012, first time i see something like this
440 2014-02-09 20:11:07 <sipa> bitcoind created a double spend of its own?
441 2014-02-09 20:11:16 <BB-Martino> the input addy is probably a change address, it's not any user's deposit address at least. plus we don't confirm coins below 3 confirmations
442 2014-02-09 20:11:18 <sipa> no restart in between, no crash, no raw transaction API?
443 2014-02-09 20:11:35 <BB-Martino> nop. there was a crash like maybe 2-3 weeks ago.
444 2014-02-09 20:11:58 <BB-Martino> i had to restore from a backup wallet.dat from a few hours earlier
445 2014-02-09 20:12:05 <BB-Martino> could that have led to this just now?
446 2014-02-09 20:12:40 <BB-Martino> (i mean restored it weeks ago, from an back a few hours prior to the crash)
447 2014-02-09 20:12:44 <BB-Martino> *a
448 2014-02-09 20:12:53 <BB-Martino> *backup. (jeez).
449 2014-02-09 20:13:37 <sipa> it's not really a double spend
450 2014-02-09 20:13:48 <sipa> looks just like a case of malleability
451 2014-02-09 20:14:03 <sipa> where a transaction is modified by someone else, and the modified version gets accepted
452 2014-02-09 20:14:20 <BB-Martino> umm?!
453 2014-02-09 20:14:32 <jakov> there is data in tx that isnt covered by the digital signature? TIL
454 2014-02-09 20:14:43 <sipa> jakov: yes! the signature itself!
455 2014-02-09 20:14:59 <jakov> but if you change that it still wont verify
456 2014-02-09 20:15:14 <jakov> i know its not deterministic sometimes but you need the private keys to make another sig
457 2014-02-09 20:15:17 <sipa> there are several ways in which signatures can be modified without invalidating the result
458 2014-02-09 20:15:26 <sipa> some are inherent to ECDSA
459 2014-02-09 20:15:27 <jakov> ok then
460 2014-02-09 20:15:36 <sipa> some are oversights in bitcoin's script design
461 2014-02-09 20:16:09 <BB-Martino> ok so
462 2014-02-09 20:16:36 <sipa> in any case, this modified version was not made by bitcoind
463 2014-02-09 20:16:43 <jakov> so theres a node out there that modifies tx
464 2014-02-09 20:16:48 <_alp_> Would a potential solution have been to not include signatures in the tx hash?
465 2014-02-09 20:16:48 <jakov> for a laugh presumably
466 2014-02-09 20:16:57 <sipa> _alp_: yes, but it's not that simple
467 2014-02-09 20:16:59 <BB-Martino> sipa: well both transactions were sent by bitcoind.
468 2014-02-09 20:17:08 <sipa> BB-Martino: how do you know?
469 2014-02-09 20:17:13 <BB-Martino> because it's my site
470 2014-02-09 20:17:32 <sipa> i'd like a bit more elaborate answer :)
471 2014-02-09 20:17:38 <_alp_> Malleability screws up a few use cases for me with unbroadcasted chained transactions, kind of annoying, didn't think it was happening much.
472 2014-02-09 20:17:57 <andytoshi> _alp_: well, if there's incentive to do it then it will happen
473 2014-02-09 20:18:00 <BB-Martino> a user came to me and reported this. users can't generate transactions, they can only provide an amount and an address, which gets passed to bitcoind which does a sendmany
474 2014-02-09 20:18:22 <sipa> BB-Martino: so far, all expected
475 2014-02-09 20:18:28 <sipa> still no proof that bitcoind generated both
476 2014-02-09 20:18:37 <gmaxwell> 12:14 < sipa> where a transaction is modified by someone else, and the modified version gets accepted
477 2014-02-09 20:18:46 <sipa> bitcoind generated one, someone else on the network modified it
478 2014-02-09 20:18:53 <_alp_> andytoshi: you mean incentive to change signatures? Even lulz is sufficient motivation in some case.
479 2014-02-09 20:18:55 <BB-Martino> oh, a node that I passed it to ?
480 2014-02-09 20:19:03 <sipa> BB-Martino: anyone
481 2014-02-09 20:19:14 <BB-Martino> someone can just invalidate a random transaction?
482 2014-02-09 20:19:21 <sipa> not invalidate
483 2014-02-09 20:19:23 <sipa> just modify
484 2014-02-09 20:19:32 <BB-Martino> well it's not going to confirm ,is it
485 2014-02-09 20:19:34 <andytoshi> _alp_: sure, that's why nodes might change transactions that pass by..but if you are doing weird things with chained transactions, the participants may have actualy incentive to break the chain
486 2014-02-09 20:19:48 <sipa> BB-Martino: the modified one is confirmed, and has the exact same effect, for both sender and receiver
487 2014-02-09 20:19:52 <jakov> hmm, this has implications for services that ask you to input the txid as proof you paid
488 2014-02-09 20:20:08 <sipa> yes
489 2014-02-09 20:20:18 <_alp_> andytoshi: sure, in many cases for my use case, anyone involved would be equally harmed if it was changed. Or there is only one participant to begin with.
490 2014-02-09 20:20:26 <BB-Martino> this has implications, period. two users withdrew coins from my site, the second one ended up with the same TXID as the one 10 seconds before it. One person will not get their coins. I'd say this is a problem.
491 2014-02-09 20:20:39 <sipa> BB-Martino: you are confused
492 2014-02-09 20:20:45 <BB-Martino> that's entirely possible.
493 2014-02-09 20:20:46 <_alp_> sipa: if I understand correctly, someone could just add junk on the end of a sigScript to do this? Since the script runs and completes, then anything left on the stack is irrelevant?
494 2014-02-09 20:20:46 <jakov> why do they do that anyway? i can only think that it saves them running bitcoind and watching all transactions as they come
495 2014-02-09 20:20:51 <BB-Martino> please elaborate
496 2014-02-09 20:20:58 <sipa> _alp_: yes
497 2014-02-09 20:21:08 <sipa> BB-Martino: there is no second user involved here
498 2014-02-09 20:21:14 <sipa> BB-Martino: whatever is the problem with that is unrelated
499 2014-02-09 20:21:34 <sipa> BB-Martino: here is a single user that requested a payout, and a modified version of that payout got accepted in the blockchain
500 2014-02-09 20:21:43 <petertodd> _alp_: beginning of a scriptSig (or end with appropriate OP_DROP's)
501 2014-02-09 20:21:46 <sipa> BB-Martino: you lost coins once, he received coins once
502 2014-02-09 20:22:12 <sipa> BB-Martino: oh, unless the second transaction used change output from the first
503 2014-02-09 20:22:19 <sipa> BB-Martino: in that case, it gets invalidated, indeed
504 2014-02-09 20:22:25 <BB-Martino> sipa: no no.... ! Wait. User1 withdraws 0.05 BTC, TXID is 2c0a6fd98d085cd9ac5d0d0e86a33fc9defcdb926d6767f97494d8d8bf17053b. User 2 withdraws 0.12 BTC 12 seconds later, TXID is also 2c0a6fd98d085cd9ac5d0d0e86a33fc9defcdb926d6767f97494d8d8bf17053b
505 2014-02-09 20:22:33 <BB-Martino> ...
506 2014-02-09 20:22:37 <BB-Martino> one user won't get their coins.
507 2014-02-09 20:22:42 <sipa> yes, send them again
508 2014-02-09 20:23:05 <sipa> it's a known problem that little wallet software deals with corectly
509 2014-02-09 20:23:19 <BB-Martino> :-(
510 2014-02-09 20:23:23 <BB-Martino> thanks.
511 2014-02-09 20:23:24 <jakov> BB-Martino they will, right? both addresses get the coins they asked for
512 2014-02-09 20:23:35 <sipa> BB-Martino: you're not entirely correct, though
513 2014-02-09 20:23:42 <sipa> BB-Martino: bitcoind will never spend the same coins twice
514 2014-02-09 20:23:44 <jakov> from the blockchain.info link you showed us
515 2014-02-09 20:23:49 <BB-Martino> jakov: definitely not. two transactions, 2 amounts, two addresses, 1 txid