1 2014-11-03 01:22:40 <SubCreative> Having an issue getting my client to connect over default port, seems my getpeerinfo is only showing peers on random ports like 51088, 39086 etc.. Anyone help me to understand is this UPNP in action
  2 2014-11-03 01:22:42 <SubCreative> ?
  3 2014-11-03 01:24:08 <phantomcircuit> SubCreative, sure those aren't your local ports?
  4 2014-11-03 01:24:50 <gmaxwell> SubCreative: you're seeing your _outbound_ port.
  5 2014-11-03 01:25:27 <SubCreative> gmaxwell: ahh thanks.
  6 2014-11-03 01:35:50 <d_rebel_> anyone here interested in trying to test our backing up and confirming the blockchain via the old bbs message network fidonet?  I think I know how to do it. just need a blockchain developer to help
  7 2014-11-03 01:36:53 <d_rebel_> a lot of countries that block bitcoin would be unable to block this and those countries would be able to continue to use bitcoin this way via a network that is international and already in place. pm me
  8 2014-11-03 01:37:17 <gmaxwell> d_rebel_: I have a modem already for use in network partition healing. :) but using the existing fidonet network would not be polite to the others users of it.
  9 2014-11-03 01:39:34 <d_rebel_> well. if it had a new sub conference that was optional and even hidden it wouldn't be such a big hassle. the issue is tossing packets that include each full block bootstrap and then the machines in the network with Internet access would then be able to confirm and unify the blockchain and return the confirmation to the fidochain
 10 2014-11-03 01:40:29 <gmaxwell> the 'confirmation' ? I'm not sure what you're talking about there.
 11 2014-11-03 01:40:50 <gmaxwell> Bitcoin is autonoymously verified, you don't need to trust anyone elses word that the data you recieved is correct; you check it for yourself.
 12 2014-11-03 01:42:59 <d_rebel_> of course. but what I'm talking about is. say they ban it in Egypt. someone could send a transaction via fidonet and it would then send that to all the other fidonet nodes via a dialup and reach one that has Internet and the transaction can enter the bitcoin process. and then the confirmed blocks could then also be tossed from the Internet bbs back to the Egyptian one etc. no Internet. no worry. am I making sense?
 13 2014-11-03 01:43:41 <gmaxwell> sure that makes fine sense.
 14 2014-11-03 01:44:40 <d_rebel_> I think it would be something to strengthen the network in the event of censorship of the Internet or a blackout or something.  and a new use of a brilliant old network
 15 2014-11-03 01:45:38 <gmaxwell> sure, well as I said, it's a lot of data (relative to fidonet) so care should be taken to make sure it's not considered abusive.
 16 2014-11-03 01:45:55 <d_rebel_> I think it would be something to strengthen the network in the event of censorship of the Internet or a blackout or something.  and a new use of a brilliant old network and also allows for them to send and rec email
 17 2014-11-03 01:46:27 <d_rebel_> i agree. i would think it would be more like the nodes
 18 2014-11-03 01:46:42 <d_rebel_> nodelist base
 19 2014-11-03 01:48:28 <d_rebel_> I'm just trying to find someone to help me make it happen.  tom jennings doesn't want anything to do with fidonet anymore. so I'm kinda a lone ranger on this. i just know it would strengthen the network internationally. as long as a phone line was open you could use bitcoin. Internet or not ultimately
 20 2014-11-03 01:49:22 <d_rebel_> also I'm not talking about storing the entire blockchain on fidonet. that's huge. it's more about using bitcoin core as the holder of that and using fidonet as the transmission network for confirmations
 21 2014-11-03 01:50:01 <d_rebel_> especially if Gavin gets his way about expanding block sizes it would definitely be much more streamlined
 22 2014-11-03 01:50:17 <gmaxwell> 'confirmations' are the blocks... you can't use bitcoin if you're partitioned from the network, and its not terribly interesting to haul data that is only interesting to a single person. The bitcoin blockchain data is sized so that it can be carried realtime over a modem.
 23 2014-11-03 01:50:31 <gmaxwell> well good luck, I'm not interested in the same things as you, I guess.
 24 2014-11-03 01:51:37 <d_rebel_> Hahaha. well it's just an idea. my main obsession is trying to get music in the blockchain using micro transactions and essentially finally killing thr Spotify and Youtube gang rape of music
 25 2014-11-03 01:52:13 <d_rebel_> i see the blockchain as one of the most important inventions of our time.
 26 2014-11-03 01:52:40 <d_rebel_> the possibilities are endless and i believe it's the answer to so many problems
 27 2014-11-03 01:56:05 <d_rebel_> thanks anyway gmaxwell sorry to bother u
 28 2014-11-03 02:13:32 <lechuga_> pkcs#11 needs to support key derivation by hmac
 29 2014-11-03 10:05:39 <cbeams> FYI, the "Is Bitcoin a Decentralized Currency?" paper (originally published in IEEE Privacy and Security, available at http://eprint.iacr.org/2013/829.pdf) was just republished at http://www.infoq.com/articles/is-bitcoin-a-decentralized-currency.
 30 2014-11-03 10:05:46 <cbeams> If anyone has published responses to that paper elsewhere, it might be good to post a link to them in the comment thread of the InfoQ post.
 31 2014-11-03 10:05:52 <Luke-Jr> wumpus: anything left for https://github.com/bitcoin/bitcoin/pull/5106 ?  sipa ok'd the new new name, but should i poke him to comment on github?
 32 2014-11-03 10:07:02 <sipa> done
 33 2014-11-03 10:07:40 <Luke-Jr> cbeams: looks like mostly FUD?
 34 2014-11-03 10:07:46 <Luke-Jr> sipa: thanks
 35 2014-11-03 10:07:48 <justanot1eruser> why are checkpoints still in master? Spamming shouldn't be an issue with headers-first to my understanding?
 36 2014-11-03 10:08:06 <sipa> justanot1eruser: spamming blocks, no; spamming headers, yes
 37 2014-11-03 10:08:29 <sipa> (but i very much like to get rid of checkpoints too)
 38 2014-11-03 10:08:55 <Luke-Jr> maybe we should disable it by default in 0.10?
 39 2014-11-03 10:09:16 <justanot1eruser> sipa: Is the path to preventing that some checkpoint-esque thing where you have to be mining abovie a certain difficulty at a certain block number?
 40 2014-11-03 10:09:31 <cbeams> Luke-Jr: Well, pretty verbose FUD, if so. I mention this as InfoQ is pretty widely read by the enterprise development community, and in my experience that community has relatively little understanding of bitcoin. The article is certainly negative overall, so it would be good to respond in some fashion.
 41 2014-11-03 10:10:55 <justanot1eruser> That would at least guarantee they had to generate a certain number of hashes on average to create this spamchain (that they can spam with forever unfortunately)
 42 2014-11-03 10:12:59 <justanot1eruser> hmm, perhaps the heuristic could be requesting a chain of blocks adding up to a certain diff sum before you download their blockheaders.
 43 2014-11-03 10:14:43 <sipa> justanot1eruser: how do you request a chain (in a verifiable way...) without downloading their headers...?
 44 2014-11-03 10:15:50 <justanot1eruser> sipa: you would just request a chain within the chain and traverse forwards (if forwards at all) then backwards from there
 45 2014-11-03 10:16:06 <justanot1eruser> apologies if you already don't start at the genesis
 46 2014-11-03 10:16:15 <sipa> right, yes, that has been suggested
 47 2014-11-03 10:16:31 <sipa> but that isn't what happens now as there is no way to do so without a protocol change
 48 2014-11-03 10:16:58 <justanot1eruser> Does headers-first not require a protocol change??
 49 2014-11-03 10:17:55 <sipa> no
 50 2014-11-03 10:18:09 <sipa> it uses the getheaders command rather than getblocks
 51 2014-11-03 10:18:16 <sipa> which was added in 2010 somewhere
 52 2014-11-03 10:18:21 <sipa> and is already used by SPV clients
 53 2014-11-03 10:18:53 <justanot1eruser> Do you think that protocol change would be sufficient to remove checkpoints?
 54 2014-11-03 10:19:16 <sipa> i think we can remove checkpoints, they just need to be replaced with something weaker
 55 2014-11-03 10:19:19 <Luke-Jr> cbeams: not even possible to comment
 56 2014-11-03 10:19:37 <justanot1eruser> sipa: something weaker being a difficulty requirement by block x or what?
 57 2014-11-03 10:19:38 <cbeams> Luke-Jr: because of the login requirement?
 58 2014-11-03 10:19:45 <Luke-Jr> cbeams: registering accounts is broken
 59 2014-11-03 10:20:01 <cbeams> Ugh. Well, I have an account and can log in. Can proxy for you if you like :)
 60 2014-11-03 10:20:24 <Luke-Jr> cbeams: http://codepad.org/MRPhiuqQ
 61 2014-11-03 10:21:41 <cbeams> Luke-Jr: will post, thx. I'll attribute it to you when doing so.
 62 2014-11-03 10:21:50 <wumpus> sipa:  the checkpoint data itself is still useful, for example for progress estimation, but indeed it could be weaker
 63 2014-11-03 10:22:03 <sipa> wumpus: yeah, it would be nice if it didn't actually lock in the chain
 64 2014-11-03 10:22:22 <sipa> even if just to remove the misunderstanding that they add security
 65 2014-11-03 10:22:53 <wumpus> yes, or that the bitcoin core devs determine the 'normative' chain
 66 2014-11-03 10:25:15 <MaybeSo> Can someone tell me, is the public key used for bitcoin alerts located below a standard EDCSA pub key?
 67 2014-11-03 10:25:16 <MaybeSo> https://github.com/bitcoin/bitcoin/blob/f157cbb44340dab23f79f914b80ab9925c4cb4c5/src/chainparams.cpp#L115
 68 2014-11-03 10:26:06 <sipa> cbeams: "Imagine what would happen if developers added a rule that doubled the mining payout, and added a extra payout to developers directly. Presumably nobody - except miners and developers - would except such a change, and just stick to an old version of the system. The result would be a blockchain fork, with world where the old miners and developers live their happy world with coins that are worthless, and the rest of the world - together with...
 69 2014-11-03 10:26:12 <sipa> new miners - ignoring them without any further problems."
 70 2014-11-03 10:26:21 <sipa> s/except such a change/accept/
 71 2014-11-03 10:27:02 <sipa> MaybeSo: 'below' ?
 72 2014-11-03 10:27:29 <sipa> needs more grammar fixes :(
 73 2014-11-03 10:27:53 <cbeams> sipa: will post and attribute to you (with grammar fixes :). Thx.
 74 2014-11-03 10:28:52 <t7> sipa: what kinda traffic hits your dns server?
 75 2014-11-03 10:29:18 <MaybeSo> sipa: https://github.com/bitcoin/bitcoin/blob/f157cbb44340dab23f79f914b80ab9925c4cb4c5/src/chainparams.cpp...
 76 2014-11-03 10:29:19 <wumpus> the only thing that would happens if developers added such a rule is a lot of laughing people and that developer never to be taken seriously again :p
 77 2014-11-03 10:30:03 <MaybeSo> sipa: secp256k1 ECDSA key
 78 2014-11-03 10:30:06 <MaybeSo> ?
 79 2014-11-03 10:30:23 <sipa> maybe add "As every node verifies everything, deploying a controversial change to a node ultimately just results in you excluding yourself from the system from everyone else's viewpoint. Yes, developers decide what goes into releases, but it is the people using the system who decide what release to run."
 80 2014-11-03 10:30:47 <sipa> t7: a few QPS
 81 2014-11-03 10:30:56 <sipa> MaybeSo: the alert key is a secp256k1 key, yes
 82 2014-11-03 10:31:08 <sipa> cbeams: ^
 83 2014-11-03 10:31:29 <MaybeSo> ty spia
 84 2014-11-03 10:31:32 <cbeams> sipa: got it, thx
 85 2014-11-03 10:31:32 <MaybeSo> sipa*
 86 2014-11-03 10:39:07 <cbeams> sipa: where did the quote you're responding to come from? I don't see it in the paper.
 87 2014-11-03 10:39:20 <sipa> cbeams: i'm just adding a comment
 88 2014-11-03 10:39:36 <cbeams> sipa: understood.
 89 2014-11-03 10:47:49 <Luke-Jr> wumpus: "Having said that, I don't think it's a blocker to fix this bug, and the alternative would have impact deep into the call chain." <-- do you mean you don't consider fixing submitblock to be a blocker for 0.10, or that the "ugliness" of a temporary signal handler doesn't need to be fixed for the PR?
 90 2014-11-03 10:48:13 <wumpus> Luke-Jr: it's not a blocker, I intend to merge it as-is
 91 2014-11-03 10:48:28 <Luke-Jr> ok
 92 2014-11-03 10:48:31 <wumpus> Luke-Jr: just wanted to let know that I don't agree asthetically, but that shouldn't get in the way of fixing bugs
 93 2014-11-03 10:49:04 <Luke-Jr> wumpus: initially, I didn't either (sipa wanted it) - but when I was done with this way, it ended up being obviously much cleaner than the alternative
 94 2014-11-03 10:49:25 <Luke-Jr> cleaner for the programmer, maybe not the execution
 95 2014-11-03 10:49:30 <sipa> wumpus: you don't agree aesthetically, or for performance reasons?
 96 2014-11-03 10:49:38 <wumpus> ideally the RPC component would register to the signal once
 97 2014-11-03 10:49:59 <sipa> boost::connections::connect is constant-time btw
 98 2014-11-03 10:50:06 <wumpus> sipa: well - asthetically for sure
 99 2014-11-03 10:50:10 <Luke-Jr> ah, a static signal handler that gets manipulated by submitblock?
100 2014-11-03 10:50:21 <wumpus> performance I'm not sure about
101 2014-11-03 10:50:46 <wumpus> the extra class in-between is also overhead; we register six or so signals, but we need only one
102 2014-11-03 10:50:58 <sipa> yeah, that can be broken up
103 2014-11-03 10:52:01 <Luke-Jr> too bad C++ doesn't let you instantise classes with pure virtuals XD
104 2014-11-03 10:52:16 <wumpus> boost::connect is constant-time, but it still needs global locking
105 2014-11-03 10:52:44 <sipa> not more than a spinlock, i expect
106 2014-11-03 10:52:58 <sipa> (but i haven't seen the code)
107 2014-11-03 10:53:04 <wumpus> and I somehow doubt the disconnect is constant time
108 2014-11-03 10:54:04 <sipa> wumpus: let's benchmark :)
109 2014-11-03 10:54:19 <sipa> this is interesting to know
110 2014-11-03 10:54:37 <Luke-Jr> for a process that requires 10 minutes to call? :P
111 2014-11-03 10:55:39 <wumpus> I'd prefer to just not use connect/disconnect in performance-critical places, although it could be argued that `submitblock` is not one of those, checking a block isn't too quick
112 2014-11-03 10:56:42 <wumpus> and the RPC mechanism gives enough overhead ;)
113 2014-11-03 10:57:16 <sipa> i don't worry about submitblock's performance
114 2014-11-03 10:57:31 <sipa> i may worry about the performance of signals otherwise handled by main simultaneously
115 2014-11-03 10:58:17 <wumpus> it does feel like moving a concern that should be local (an action far down the call chain) to a global (registering a global signal handler)
116 2014-11-03 10:59:04 <wumpus> sipa: nah - we're holding the cs_main lock
117 2014-11-03 10:59:28 <sipa> we are, or we are not?
118 2014-11-03 10:59:53 <wumpus> we are?
119 2014-11-03 11:00:02 <sipa> we shouldn't be
120 2014-11-03 11:00:16 <sipa> only ProcessNewBlock itself should lock cs_main
121 2014-11-03 11:01:09 <wumpus> oh, submitblock is marked as thread-safe, no, we're probably not holding it
122 2014-11-03 11:01:24 <sipa> ok, a RegisterValidationSignals() + UnregisterValidationSignals() takes 6.7 microseconds here
123 2014-11-03 11:01:42 <Luke-Jr> it is? I was assuming we had cs_main held..
124 2014-11-03 11:01:45 <sipa> i don't think we'd care even if that was milliseconds
125 2014-11-03 11:01:53 <sipa> (for the purpose of submitblock)
126 2014-11-03 11:03:01 <Luke-Jr> hm
127 2014-11-03 11:03:02 <sipa> wumpus: so, there are two ways of accomplishing this: either set up a simulation environment in which you manually go through the steps, and can observe the results - or you submit the data to the global block validation (where we'll want to send it anyway, afterwards)
128 2014-11-03 11:03:04 <wumpus> right, we don't register a lot of handlers anyhow
129 2014-11-03 11:03:10 <Luke-Jr> don't we need cs_main to prevent the signals from racing?
130 2014-11-03 11:03:20 <sipa> boost signals has its own locking
131 2014-11-03 11:04:15 <wumpus> sipa: well the other way would be to pass the validation interface through the call chain
132 2014-11-03 11:04:34 <Luke-Jr> ok, then can we just merge this as-is for now, to move forward on the ones depending on it? optimisations can be parallel to those easily ;)
133 2014-11-03 11:04:42 <sipa> wumpus: that won't work in more asynchronous processing, which we're moving towards anyway
134 2014-11-03 11:04:58 <wumpus> sipa: this solution won't work for more asynchronous processing anyway
135 2014-11-03 11:05:14 <sipa> not exactly, but it can easily be extended
136 2014-11-03 11:05:20 <wumpus> sipa: as we register the signal before the call and unregister it after, any signals raised afterward would be lost
137 2014-11-03 11:05:28 <wumpus> sipa: not really - it uses the fact that no signal was raised
138 2014-11-03 11:05:41 <wumpus> in the async case that's not possible to determine
139 2014-11-03 11:06:09 <sipa> there can be a signal for 'stable state reached'
140 2014-11-03 11:06:20 <cbeams> Luke-Jr: Comment posted at http://www.infoq.com/articles/is-bitcoin-a-decentralized-currency#anch115795
141 2014-11-03 11:06:34 <sipa> wumpus: and you listen for that signal, make it signal an own condition variable, which the rpc waits for
142 2014-11-03 11:06:52 <wumpus> sipa: sure...
143 2014-11-03 11:07:13 <sipa> anyway, sure, more asynchronous processing will need a lot of work
144 2014-11-03 11:07:14 <cbeams> sipa: I have posted yours as well, but for some reason it is not showing up in any browser other than the one I posted it from. Some caching issue probably. I've emailed them, but assume it will eventually show up. Here's a screenshot in the meantime: http://imgur.com/5IM2Sfp
145 2014-11-03 11:07:27 <Luke-Jr> cbeams: I saw sipa's there
146 2014-11-03 11:07:36 <cbeams> Luke-Jr: weird. ok, thanks.
147 2014-11-03 11:07:51 <sipa> wumpus: i just disagree with passing validation callbacks into an inherently global validation engine
148 2014-11-03 11:08:20 <wumpus> sipa: when I first read that code I supposed that would be needed, I assumed the only reason to register a global callback would be to receive asynchronous signals
149 2014-11-03 11:09:04 <cbeams> Luke-Jr: I see sipa's now too. I guess the cache caught up.
150 2014-11-03 11:10:19 <wumpus> sipa: so if that is the plan later on, I suppose this solution is fine
151 2014-11-03 11:11:00 <sipa> we can always investigate more efficient solutions when they're necessary
152 2014-11-03 11:11:03 <wumpus> it's a weird way if the only goal would be to provide a side-channel to get a result from a call deep in the side chain, but seen that way it makes sense
153 2014-11-03 11:11:21 <sipa> presumably more asynchronous process will mean more signal handlers too
154 2014-11-03 11:12:50 <sipa> wumpus: disconnect is indeed linear in the number of connections
155 2014-11-03 11:12:57 <wumpus> I'm not so worried about efficiency here, but about transparency, signals are useful, but overusing them can result in code that is too fragmented to understand what is going on
156 2014-11-03 11:13:15 <wumpus> anyhow - I consider this settled, future asynchronicity is a good reason
157 2014-11-03 11:13:24 <sipa> understood
158 2014-11-03 11:13:50 <wumpus> good to know about the disconnect
159 2014-11-03 11:16:22 <sipa> wumpus: if you store the 'connection' object that signal.connect returns, i think you can disconnect it in constant time
160 2014-11-03 11:16:42 <wumpus> sipa: ah that makes sense, I forget that that was even possible
161 2014-11-03 11:16:43 <sipa> (i assume it's stored as a doubly-linked list internally)
162 2014-11-03 11:19:16 <wumpus> and in this case it'd make a lot of sense to do that, as the connect and disconnect happens in the same scope
163 2014-11-03 11:19:20 <wumpus> nah, something for later
164 2014-11-03 14:43:16 <dgenr8> <jgarzik> ...questions like that just lead to "what is your risk tolerance?" responses
165 2014-11-03 14:43:18 <dgenr8> expect more adoption by real-time merchants to be met by increasingly sophisticated and easy-to-use double-spending wallets.
166 2014-11-03 14:44:19 <Luke-Jr> dgenr8: maybe. it will be interesting to see the first time someone is prosecuted for double spending.
167 2014-11-03 14:52:03 <paveljanik> wumpus: #5196 - should I squash all commits in a new branch and do new PR?
168 2014-11-03 14:52:25 <wumpus> paveljanik: O it in the same branch and re-use the same PR
169 2014-11-03 14:53:00 <paveljanik> looks like I need to learn something new...
170 2014-11-03 14:53:23 <wumpus> you can do it in a new branch locally - just push to the same one on github
171 2014-11-03 14:53:42 <paveljanik> ah, ok, will try.
172 2014-11-03 14:54:42 <dgenr8> Luke-Jr: whatever, but adoption will beat a hasty retreat
173 2014-11-03 14:55:35 <Luke-Jr> dgenr8: some things are more important than "adoption asap"
174 2014-11-03 14:56:30 <Luke-Jr> (like honesty in "selling points")
175 2014-11-03 15:06:16 <paveljanik> wumpus: looks like I screwed things up :-(
176 2014-11-03 15:07:18 <wumpus> paveljanik: I hope you made a new branch so you still have the old one to start anew from? (if not, don't fear, git keeps a history of everything in 'git reflog')
177 2014-11-03 15:07:44 <paveljanik> I do have a full diff of course and can redo...
178 2014-11-03 15:08:04 <paveljanik> sorry for confusion :-(
179 2014-11-03 15:08:57 <wumpus> git rebase -i (commit on top of your commits), then in the editor that pops up mark all but the first one to 'fixup', exit and save, and it should have squashed
180 2014-11-03 15:09:20 <wumpus> (you can also use 'squash' instead of 'fixup' if you want to combine the commit messages)
181 2014-11-03 15:12:47 <Luke-Jr> wumpus: git reflog is not immortal :|
182 2014-11-03 15:13:00 <Luke-Jr> wumpus: `git branch -M` destroys the target branch's history
183 2014-11-03 15:13:21 <wumpus> Luke-Jr: it usually keeps at least short-term history
184 2014-11-03 15:13:38 <wumpus> unless you tell it to destroy it, of course
185 2014-11-03 15:16:49 <Luke-Jr> wumpus: did you know git stash is just another branch? :P
186 2014-11-03 15:17:22 <Luke-Jr> and the Nth stash is just the branch from N log-history ago..
187 2014-11-03 15:17:32 <Luke-Jr> which means when you pop something, it's removed from the log :\
188 2014-11-03 15:20:37 <paveljanik> wumpus: redid everything from scratch in paveljanik:header-defines2, sorry
189 2014-11-03 15:24:01 <arre> Hi! I was wondering whether the behavior of SIGHASH_ANYONECANPAY is correct in the bitcoin wiki, reading the code the input script is not the only element (as it includes the txid-hash/sequence/etc. of the transaction it is spending), or am I mistaken? https://en.bitcoin.it/wiki/OP_CHECKSIG
190 2014-11-03 15:25:29 <arre> It looks like it was explicitly changed in the wiki to say that the script is the only part being signed and the wiki has said that for over a year, so I'm not sure if I'm missing something obvious
191 2014-11-03 15:29:40 <wumpus> Luke-Jr: I didn't know that stash was interacting with the reflog, no
192 2014-11-03 15:30:15 <wumpus> paveljanik: git push github header-defines2:header-defines
193 2014-11-03 15:30:25 <wumpus> eh, push -f
194 2014-11-03 15:30:31 <wumpus> then it will appear in the same pull request
195 2014-11-03 15:30:53 <justanotheruser> arre: You are wondering why only the script is signed or...?
196 2014-11-03 15:31:32 <arre> in a checksig with anyonecanpay, is the hash of the output which is being spent part of that signature?
197 2014-11-03 15:31:44 <arre> justanotheruser: because the wiki implies it is not
198 2014-11-03 15:32:06 <justanotheruser> arre: No, you are letting anyone pay
199 2014-11-03 15:32:54 <justanotheruser> I can make a tx sign it like that and not have to resign it when they have added more inputs
200 2014-11-03 15:33:10 <arre> so this edit is correct? the txid which is being spent is completely dropped? there is no txid being hashed? https://en.bitcoin.it/w/index.php?title=OP_CHECKSIG&action=historysubmit&diff=34949&oldid=34927
201 2014-11-03 15:34:02 <arre> justanotheruser: I know any other inputs aren't part of the signature, I was wondering about the txid of the output being spent
202 2014-11-03 15:35:34 <justanotheruser> arre: Is your concern that they are going to redeem another tx using that same script?
203 2014-11-03 15:35:47 <arre> Yes, is that possible?
204 2014-11-03 15:36:05 <justanotheruser> arre: if you reuse addresses, no
205 2014-11-03 15:36:21 <sipa> arre: the txid of the output being spent is always signed, afaik
206 2014-11-03 15:36:48 <sipa> and the vout index
207 2014-11-03 15:37:41 <arre> sipa: hrm, that edit in Jan 2013 made me feel like it wasn't and reading the code it looks like the txid was signed, I was just wondering whether I was missing anything obvious or some weird edge case
208 2014-11-03 15:37:56 <justanotheruser> if the outputs being signed wasn't a requirement and the output was malleably you might as well go op_true
209 2014-11-03 15:38:03 <justanotheruser> *malleable
210 2014-11-03 15:38:48 <sipa> arre: no clue what the wiki says - feel free to correct it, but it's not like people actively track the changes there
211 2014-11-03 15:39:58 <justanotheruser> sipa: does ANYONECANPAY sign the whole input (meaning you can specify output redeemed) or just the script?
212 2014-11-03 15:41:16 <arre> justanotheruser: well if you're willing to take anything and aren't signing the txid of any inputs it actually makes malleability concerns moot if you don't reuse addresses, since you'd be able to spend it no matter what the txid being spent is (which is why I was asking)
213 2014-11-03 15:41:49 <sipa> justanotheruser, arre: i suggest just reading the source code
214 2014-11-03 15:41:51 <justanotheruser> arre: indeed. Bitcoin wasn't designed for address reuse, so it very well may be that way
215 2014-11-03 15:42:05 <justanotheruser> sipa: in the middle of trying to find it in interpreter.cpp
216 2014-11-03 15:42:23 <sipa> the older version in test/sighash_test may be more readable
217 2014-11-03 15:43:10 <sipa> the one in script/interpreter is optimized and more direct (just hashes the stuff wanted directly; the older version implements it as a series of transformations)
218 2014-11-03 15:44:35 <arre> sipa: haha yeah thanks, I usually would rely on the code and be done, but I only asked in here because maybe there was some kind of odd undocumented way to do it or something weird (like that crazy SIGHASH_SINGLE 0x01 bug)
219 2014-11-03 17:37:02 <Nova_> Bitcoin newbie here, anyone that can give me some help with questions/concerns?
220 2014-11-03 17:37:33 <Nova_> I would appreciate someone with extensive knowledge that has a minute or two to spare. :\
221 2014-11-03 17:37:33 <sipa> Nova_: not without knowing what your question is
222 2014-11-03 17:37:55 <Nova_> Its about mining/purchasing/trading
223 2014-11-03 17:39:09 <sipa> Nova_: #bitcoin
224 2014-11-03 17:39:53 <sipa> Nova_: don't PM me please; #bitcoin
225 2014-11-03 17:54:57 <justanotheruser> sipa: I don't understand why requesting a header starting at a high work block - 2000 and going backwards would be a protocol change. You are just sending a bunch of getheader inv messages, aren't you?
226 2014-11-03 17:55:12 <sipa> justanotheruser: how would you know where to start?