1 2014-05-18 01:21:39 <Guest23221> Hello. I'm going to pass a multisig spend tx to the participants. After each participant signs, he will pass the tx back to me. What can I do to prevent the first participant, who has received the unsigned tx, from altering the outputs?
  2 2014-05-18 01:35:04 <aegis> ;;ident biggestnaf
  3 2014-05-18 01:35:05 <gribble> Nick 'biggestnaf', with hostmask 'biggestnaf!62e8ce3d@gateway/web/freenode/ip.98.232.206.61', is identified as user 'biggestnaf', with GPG key id None, key fingerprint None, and bitcoin address 1HCZsTjU7z3sNPjKnCi51vzi9ffM33FkiZ
  4 2014-05-18 02:59:43 <mikey85> message me if you want to join my channel. IT is for Christians, new Christians, and people interested In learning about Jesus
  5 2014-05-18 03:25:34 <finway> Hello, can ECDSA verification be accelerated by specific hardware ?  Can we make a professional FULL NODE like CISCO ROUTER ?
  6 2014-05-18 03:26:16 <gmaxwell> finway: certantly but its almost totally uninteresting.
  7 2014-05-18 03:27:14 <finway> gmaxwell, if block size is lifted to 1GB, it maybe.
  8 2014-05-18 03:27:36 <gmaxwell> With Sipa's code the E3-1230 (3.2GHz i7) here does over 40k verifies a second. Nodes are bandwidth bottlenecked before signature throughput normally.
  9 2014-05-18 03:28:59 <gmaxwell> (and if you can afford the multigigabit connectivity blocks that large would require, then having the two E3-1230 cpus required to keep up with blocks of that size isn't much of a barrier)
 10 2014-05-18 03:30:24 <finway> gmaxwell, ok, i didn't know that.  are you still pro block size limit ?
 11 2014-05-18 03:31:44 <gmaxwell> finway: without a limit we still have no argument as to what would fund security in the future once subsidy is gone, so seeing as how I'm not crazy and that I think a bitcoin that has lost its decenteralization due to throughputs so high custom hardware is required... uh. yes.
 12 2014-05-18 03:34:54 <finway> What i'm worried about is off-chain txes would create Fractional Reserved Banks.
 13 2014-05-18 03:35:16 <finway> like Coinbase, Circle, BitReserved.org
 14 2014-05-18 03:37:08 <Luke-Jr> finway: good thing we have proof-of-reserves?
 15 2014-05-18 03:37:30 <finway> Bitcoin will become too HEAVY liike GOLD, people will switch to use LIGHT PAPER like Coinbase bitcoins, Circle bitcoins,etc.
 16 2014-05-18 03:37:40 <gmaxwell> finway: They can do that regardless of anything going on inside bitcoin, some things like instant confirmations need external system help. Risking the decenteralization in bitcoin itself, as well as the argument for its scurity in the long term, isn't a good answer to some centeralized services doing insecure things that can be avoided.
 17 2014-05-18 03:38:08 <Luke-Jr> finway: so the solution is to turn gold into light paper?
 18 2014-05-18 03:39:08 <gmaxwell> In any case, it's not necessary to make that kind of compromise. It's possible to build scalable transaction without totally cramming everything under the sun into one huge blockchain no one can verify.
 19 2014-05-18 03:42:06 <finway> gmaxwell, luke-jr,  uhh, i'lll think more.
 20 2014-05-18 03:42:33 <finway> gmaxwell, luke-jr, but i guess 100MB is better ?
 21 2014-05-18 03:42:50 <Luke-Jr> finway: 1 MB is fine for now
 22 2014-05-18 03:42:57 <Luke-Jr> finway: we aren't exactly hitting the limit
 23 2014-05-18 03:43:14 <Luke-Jr> finway: and keep in mind we'll probably have daughter-chains in a while
 24 2014-05-18 03:43:49 <gmaxwell> finway: certantly you can make an argument that some other limit is reasonable and good. I wouldn't disagree there. It's just the no-limit stuff I think is crazy. :)
 25 2014-05-18 03:43:50 <Luke-Jr> which seems like a pretty solid way to appease people who want blocks of any size
 26 2014-05-18 03:44:14 <Luke-Jr> you could have a daughter-chain with 1 GB blocks if you liked ;)
 27 2014-05-18 03:45:04 <finway> luke-jr, you mean side-chains? but it still requires verification and storage ?
 28 2014-05-18 03:45:08 <gmaxwell> Luke-Jr: well do take care that that isn't a magic bullet, that extreme might be a bit inadvisable for the same reasons its problematic in bitcoin— but at least being able to hit multiple design tradeoffs at once is good.
 29 2014-05-18 03:45:19 <Luke-Jr> finway: of course it does
 30 2014-05-18 03:45:54 <gmaxwell> finway: yes, by interested parties, which could be just the parties who are interested in that subsystem— so not everyone. "Have your cake, and eat it too" to some extent at least.
 31 2014-05-18 03:45:55 <Luke-Jr> gmaxwell: sure, but it'd work fine as a "big blocks blockchain" to the same extent making the main chain would
 32 2014-05-18 03:46:15 <gmaxwell> Luke-Jr: ::nods::
 33 2014-05-18 03:46:36 <gmaxwell> I'm still disappointed that no altchain has tested these boundaries yet.
 34 2014-05-18 03:46:52 <finway> gmaxwell, luke-jr, doing some experiment on side-chains is a good idea.
 35 2014-05-18 03:46:55 <jcorgan> that would require something besides pump and dump
 36 2014-05-18 03:47:06 <Luke-Jr> jcorgan: I'm sure they could spin it to pump :p[
 37 2014-05-18 03:47:17 <Luke-Jr> "more transactions per second than bitcoin!"
 38 2014-05-18 03:47:32 <Luke-Jr> otoh, yesterday I saw a scamcoin which just defines "confirmation blocks: 4"
 39 2014-05-18 03:47:34 <Luke-Jr> lol
 40 2014-05-18 03:47:39 <gmaxwell> hard to spin that as an advantage when most have basically no transaction load. :)
 41 2014-05-18 03:47:41 <Luke-Jr> "it's faster because we say it is"
 42 2014-05-18 03:47:49 <gmaxwell> Luke-Jr: yea lol they are almost all doing that now.
 43 2014-05-18 03:48:06 <gmaxwell> Giving some random number for "confirmation blocks" as if that were a system parameter.
 44 2014-05-18 03:50:25 <jcorgan> i haven't followed zerocoin/zerocash lately, though i guess they are getting ready to release sometime soon.  I do wonder if the original zerocoin protocol would work better on a side chain than the new stuff they are doing on an independent chain.
 45 2014-05-18 03:56:20 <Evilmax> hi all
 46 2014-05-18 03:56:38 <Evilmax> where i can read real time blocks chain?
 47 2014-05-18 03:56:58 <Evilmax> i mean all signle transactions
 48 2014-05-18 03:58:29 <Luke-Jr> p2p network
 49 2014-05-18 03:58:54 <Evilmax> what you mean?
 50 2014-05-18 03:59:05 <Evilmax> i use qt
 51 2014-05-18 03:59:52 <Luke-Jr> this is not an end-user channel
 52 2014-05-18 03:59:57 <Evilmax> because now it seem not working on bitcoin-watch
 53 2014-05-18 04:00:12 <Luke-Jr> yes, too much traffic. if you want to figure out a solution, I'd be glad to fix it :/
 54 2014-05-18 04:00:44 <Evilmax> but it will be restored on that chan?
 55 2014-05-18 04:00:46 <Evilmax> you knoe?
 56 2014-05-18 04:00:50 <Evilmax> know*
 57 2014-05-18 04:02:41 <gmaxwell> Luke-Jr: you can ask for an excemption from freenode.
 58 2014-05-18 04:02:47 <gmaxwell> otherwise— setup a seperate IRC server.
 59 2014-05-18 04:05:02 <Luke-Jr> gmaxwell: I don't think they have the ability to make exceptions :/
 60 2014-05-18 04:05:37 <Evilmax> Luke-Jr: there is another place where i can find the same service that once used on bitcoin-watch? sorry my english
 61 2014-05-18 04:05:39 <gmaxwell> they did at one point in the past... perhaps not anymore.
 62 2014-05-18 05:42:43 <nanotube> Luke-Jr: use several bots in a round robin. :)
 63 2014-05-18 05:42:55 <Luke-Jr> nanotube: yeah, but that takes time which I don't have :<
 64 2014-05-18 05:43:12 <nanotube> ah
 65 2014-05-18 05:44:55 <sipa> time is an illusion
 66 2014-05-18 16:18:33 <Guest34124> Bitcoin-Qt. Since the RPC password and the wallet passphrase are in place, is there any reason not to supply CORS headers back to a browser?
 67 2014-05-18 16:54:27 <devthink> Bitcoin-Qt: Since the RPC password and the wallet passphrase are in place, is there any reason Bitcoin-Qt can't return CORS headers to a browser?
 68 2014-05-18 16:57:11 <michagogo> devthink: huh?
 69 2014-05-18 16:57:28 <michagogo> Could you elaborate, and explain hat you're trying to do?
 70 2014-05-18 16:57:57 <devthink> michagogo: to allow a page script to send RPC commands to the wallet
 71 2014-05-18 16:58:14 <michagogo> Ah, interesting.
 72 2014-05-18 16:58:34 <devthink> the browsers have a "same origin" policy that precludes access outside the domain
 73 2014-05-18 16:59:05 <devthink> the CORS headers from the destination site (the wallet) tells the browser it's ok
 74 2014-05-18 16:59:10 <michagogo> That's a good question. You could create a PR, if you want, and see where the discussion on that goes
 75 2014-05-18 16:59:35 <michagogo> Or if you can't, you can create an issue for discussion and maybe someone'll add it
 76 2014-05-18 17:01:32 <sipa> i don't see how it could hurt, but RPC isn't exactly designed to be accessed from a browser either
 77 2014-05-18 17:02:55 <michagogo> Does anyone know if Jerry Felix is in here?
 78 2014-05-18 17:03:12 <michagogo> Related question: Does anyone know what the story is with the bananas in his photos?
 79 2014-05-18 17:05:39 <devthink> sipa: typlically it would be a page script, downloaded from a Bitcoin site, that access the wallet at localhost:8332.
 80 2014-05-18 17:05:50 <devthink> accesses
 81 2014-05-18 17:06:20 <Skirmant> i keep getting this: #error missing boost sleep implementation
 82 2014-05-18 17:06:35 <Skirmant> any ideas how to solve it?
 83 2014-05-18 17:07:17 <michagogo> Skirmant: what system are you on?
 84 2014-05-18 17:07:22 <michagogo> What are you trying to build?
 85 2014-05-18 17:07:25 <Skirmant> win7
 86 2014-05-18 17:07:29 <Skirmant> the bitcoin client
 87 2014-05-18 17:07:31 <michagogo> What version, which tag, which git commit?
 88 2014-05-18 17:07:52 <michagogo> What build system / compiler?
 89 2014-05-18 17:07:53 <sipa> what compiler, what boost version?
 90 2014-05-18 17:08:19 <Skirmant> git: v0.9.1
 91 2014-05-18 17:08:26 <Skirmant> compiler: mingw
 92 2014-05-18 17:08:45 <Skirmant> boost: 1.55.0
 93 2014-05-18 17:10:57 <michagogo> Hm, I don't know if we actually support building on Windows
 94 2014-05-18 17:11:04 <michagogo> Does anyone actually do it?
 95 2014-05-18 17:11:23 <sipa> Diapolo does
 96 2014-05-18 17:11:29 <michagogo> Recently?
 97 2014-05-18 17:11:47 <sipa> no idea
 98 2014-05-18 17:12:04 <michagogo> Is it considered supported?
 99 2014-05-18 17:15:47 <sipa> i would say no
100 2014-05-18 17:16:13 <sipa> breaking it wouldn't be detected, so there's no guarantee that releases are buildable
101 2014-05-18 17:17:07 <Skirmant> you've got to be fucking kidding me
102 2014-05-18 17:17:29 <Skirmant> a big project like bitcoin and i can't even compile it on windows?
103 2014-05-18 17:17:30 <sipa> all releases are built using a deterministic environment, which runs in linux
104 2014-05-18 17:17:44 <sipa> so for windows it's crosscompiled
105 2014-05-18 17:18:21 <sipa> as none of the core developers use windows, it's hard to do otherwise
106 2014-05-18 17:19:27 <Skirmant> well, thanks for the info. I'll try to compile it on linux
107 2014-05-18 17:19:44 <michagogo> Skirmant: you can read the gitian descriptors to get an idea of how it's done
108 2014-05-18 17:19:49 <michagogo> (or just use gitian)
109 2014-05-18 17:21:04 <Skirmant> michagogo: i'll look into it
110 2014-05-18 17:45:06 <azariah> Hi, where can one find a list of testnet DNS hosts? testnet-seed.bitcoin.petertodd.org times out for me atm
111 2014-05-18 17:46:11 <mr_burdell> azariah: these worked for me... not sure which one was active:
112 2014-05-18 17:46:14 <mr_burdell> seednode=148.251.6.214:18333
113 2014-05-18 17:46:14 <mr_burdell> seednode=188.226.139.138:18333
114 2014-05-18 17:46:14 <mr_burdell> seednode=54.243.211.176:18333
115 2014-05-18 17:46:20 <dhill> testnet-seed.bluematt.me
116 2014-05-18 17:52:03 <azariah> cool, thanks
117 2014-05-18 18:23:01 <devthink> For a multisig 2of4 tx where only one of #3 or #4 gets signed, would it be disruptive to the miners to receive a tx that was incorrectly signed?
118 2014-05-18 18:25:29 <sipa> the network (miners included) will just ignore any invalid transaction
119 2014-05-18 18:25:33 <sipa> and drop in on the floor
120 2014-05-18 18:25:48 <devthink> but would it be disruptive?
121 2014-05-18 18:26:22 <devthink> or do they handle this as a matter of course
122 2014-05-18 18:26:33 <sipa> what do you mean by disruptive?
123 2014-05-18 18:26:36 <Apocalyptic> not really, as it wouldn't even be relayed
124 2014-05-18 18:26:46 <Apocalyptic> it would just cause some wastefull CPU-cycles
125 2014-05-18 18:26:46 <sipa> it's simply illegal, and they would likely disconnect you for sending invalid data
126 2014-05-18 18:27:21 <devthink> ok, that's what I meant
127 2014-05-18 18:27:47 <devthink> so I shouldn't rely on miners to make a payout decision for me...
128 2014-05-18 18:28:28 <sipa> can you explain what you're trying to do?
129 2014-05-18 18:29:18 <devthink> trying to determine how to payout a contract to participant #1 or #2 based on keys supplied by an oracle
130 2014-05-18 18:31:06 <poutine> How does bitcoind determine whether a tranasaction goes towards you?
131 2014-05-18 18:31:34 <poutine> does it check every tx that appears on the chain?
132 2014-05-18 18:31:39 <sipa> if one of the outputs matches a script that the wallet recognizes
133 2014-05-18 18:31:41 <sipa> yes
134 2014-05-18 18:31:57 <poutine> So what if it's ambiguous though, like say I include another condition in the script that makes it spendable?
135 2014-05-18 18:32:30 <sipa> the receiver determines which scripts he acceps, by giving you an address that corresponds to them
136 2014-05-18 18:32:39 <shesek> devthink, using both keys from the oracle isn't a good way to do this. the oracle fully controls the funds that way.
137 2014-05-18 18:32:41 <sipa> if you use another, that's no a payment to him, and you're being silly
138 2014-05-18 18:33:08 <poutine> https://blockchain.info/tx/9f17f3ce43019c24baa6d679edfdddeada856f617cd9c1f6008d49be4542b768 <- Ok I submitted this tx, it's redeemable by any 1 of 2 inputs
139 2014-05-18 18:33:18 <sipa> it's like saying "how do you mean you didn't get my money? i dug a hole in your garden and hid it there. it's your garden, so you got it"
140 2014-05-18 18:33:24 <sipa> poutine: irrelevant
141 2014-05-18 18:33:40 <sipa> poutine: the receiver must know about the multisig script and how to redeem it
142 2014-05-18 18:33:56 <sipa> if they didn't tell you to pay to it, there's no expectation for them to get it
143 2014-05-18 18:34:17 <poutine> hmm
144 2014-05-18 18:34:23 <devthink> shesek: the oracle will publish one of two keys, whether the event occurred or not.  but the key itself does not indicate the outcome, so both participants sign theit contrat with the key and broadcasts.  One will succeed and the other will not.
145 2014-05-18 18:34:36 <devthink> *their
146 2014-05-18 18:34:44 <sipa> poutine: and apparently it even contains some message too
147 2014-05-18 18:34:58 <sipa> poutine: so it's by no means a standard transaction output that you'd expect anyone to recognize
148 2014-05-18 18:35:12 <shesek> devrandom, they publish one of the two keys, but controls both of them
149 2014-05-18 18:35:35 <shesek> the oracle can sign an 2-of-4 transactions on its own, without any of the other keys
150 2014-05-18 18:35:38 <poutine> but couldn't I make it so you running your ScriptVerify with your sig and pubkey would result in a spendable output for you, but also I could spend it with a different input?
151 2014-05-18 18:36:01 <sipa> hell no
152 2014-05-18 18:36:15 <sipa> the receiver determines what addresses he accepts transactions on, and nobody else
153 2014-05-18 18:36:23 <poutine> but I can spend my posted tx with 2 entirely different inputs sipa
154 2014-05-18 18:36:23 <sipa> because their software must support it
155 2014-05-18 18:36:28 <poutine> I just don't get how it'd be any different
156 2014-05-18 18:36:38 <sipa> look at my example
157 2014-05-18 18:36:40 <sipa> i gave about
158 2014-05-18 18:36:43 <sipa> *analogy
159 2014-05-18 18:37:04 <sipa> if they don't know how to use it, they can't be expected to consider it a payment that credits them
160 2014-05-18 18:37:34 <poutine> they do know how to use it, via the script
161 2014-05-18 18:37:41 <poutine> <Sig> <pubkey>
162 2014-05-18 18:37:51 <poutine> on the stack, execute scriptPubKey
163 2014-05-18 18:38:03 <sipa> computers aren't intelligent, you know
164 2014-05-18 18:38:14 <sipa> they can't magically figure out how to satisfy your script
165 2014-05-18 18:38:41 <sipa> and even if they did, that's by no means a guarantee that they should accept it
166 2014-05-18 18:39:09 <sipa> as for example a 1-of-2 multisig means someone else could spend the input out from under them (the other party)
167 2014-05-18 18:39:57 <sipa> and please don't use transactions for spamming your messages
168 2014-05-18 18:57:52 <nick_devl> Hey, is there anyone available who wants to talk about blockchian.info's receive payment API?
169 2014-05-18 18:58:09 <nick_devl> I made this post, but maybe is long winded? https://bitcointalk.org/index.php?topic=609282.0
170 2014-05-18 19:29:35 <michagogo> devthink: I think this came up recently
171 2014-05-18 19:30:01 <michagogo> The trick, IIRC,  is to make use of the ability to combine ecdsa keys
172 2014-05-18 19:30:46 <michagogo> Say I'm betting that the Yankees lose the game they're playing right now.
173 2014-05-18 19:31:09 <michagogo> The oracle publishes 2 pubkeys. One for if they win, and one for if they lose.
174 2014-05-18 19:31:29 <michagogo> The person who's betting that they will win and I will each have a pubkey
175 2014-05-18 19:32:54 <michagogo> We each pay to a 1-of-2, with one key being my public key combined with the loss public key, and the other public key being his public key combined with the win public key
176 2014-05-18 19:33:17 <michagogo> The game ends, the oracle releases the corresponding private key.
177 2014-05-18 19:33:52 <michagogo> The winner of the bet then has the other half of the private key needed to spend the bet money.
178 2014-05-18 19:35:11 <michagogo> And as a backup, we could make the transaction a 1-of-3, where the first two are as described, and the 3rd is the two participants' keys, so if the oracle goes away the two can resolve the bet themselves.
179 2014-05-18 20:35:16 <devthink> michagogo: is the 'combine' of the keys additive? multiplicative?
180 2014-05-18 20:50:36 <michagogo> devthink: sorry, I don't know...
181 2014-05-18 20:50:59 <michagogo> I don't really know much about cryptography and ecdsa and all that
182 2014-05-18 20:51:12 <devthink> can you point me to the original discussion?  Thanks.
183 2014-05-18 20:51:37 <michagogo> I just know that you can somehow combine two public keys to get a public key, the private key to which is a combination of the two private keys
184 2014-05-18 20:51:45 <michagogo> I'll see if I can find it in the logs
185 2014-05-18 20:52:12 <devthink> do you remember the day?
186 2014-05-18 20:53:00 <gwillen> devthink: I believe it's addition in the elliptic curve group
187 2014-05-18 20:53:32 <gwillen> devthink: you add the two private keys, represented as points, and get a new private key; and perform the same operation on the corresponding public keys
188 2014-05-18 20:53:55 <devthink> thanks, i'll give it a try
189 2014-05-18 20:54:24 <gwillen> devthink: there's a discussion of it in this talk from bitcoin 2013, as I recall: https://www.youtube.com/watch?v=qwyALGlG33Q
190 2014-05-18 20:54:55 <michagogo> devthink: http://bitcoinstats.com/irc/bitcoin-dev/logs/2014/05/05
191 2014-05-18 20:55:09 <michagogo> devthink: I didn't but I just opened all of may in tabs and ctrl-f'd for oracle