1 2012-01-13 00:25:07 <CIA-100> bitcoin: Kamil Domanski * re4cee05d67f0 gentoo/net-p2p/libbitcoin/libbitcoin-9999.ebuild: net-p2p/libbitcoin-9999: changed src_prepare http://tinyurl.com/73d69jb
  2 2012-01-13 00:25:09 <CIA-100> bitcoin: Kamil Domanski * rd5dc44230dc5 gentoo/ (12 files in 5 dirs): Merge branch 'master' of gitorious.org:bitcoin/gentoo http://tinyurl.com/7h96j9y
  3 2012-01-13 00:25:23 <CIA-100> libbitcoin: Kamil Domanski * rbfeb4593682c /include/bitcoin/bitcoin.hpp: bitcoin.hpp: removed include of bdb backend because installation of this file is conditional http://luke.dashjr.org/programs/bitcoin/w/libbitcoin.git/commitdiff/bfeb4593682c040fabf580f5abab4dd9bc36a991
  4 2012-01-13 00:25:25 <CIA-100> libbitcoin: Kamil Domanski * ra565a62c89cc / (11 files in 7 dirs): Merge branch 'master' of gitorious.org:libbitcoin/libbitcoin http://tinyurl.com/6wepgrc
  5 2012-01-13 01:35:23 <CIA-100> libbitcoin: Kamil Domanski * r98cb4b236f31 /include/bitcoin/types.hpp: 8-bit port number? ooops... http://tinyurl.com/7dpzmhu
  6 2012-01-13 01:52:57 <BlueMatt> luke-jr: ok, keepnode rebased
  7 2012-01-13 01:54:05 <BlueMatt> oops, missed one thing
  8 2012-01-13 02:11:05 <BlueMatt> luke-jr: ok, should be good
  9 2012-01-13 03:10:48 <devrandom> BlueMatt: I'm building 0.5.2... I hear you are too?
 10 2012-01-13 03:13:22 <luke-jr> devrandom: BlueMatt did days ago :P
 11 2012-01-13 03:13:49 <devrandom> luke-jr: but he didn't publish his signature in the usual place?
 12 2012-01-13 03:17:54 <luke-jr> dunno
 13 2012-01-13 04:02:41 <devrandom> luke-jr, BlueMatt: 0.5.2 signature uploaded - https://github.com/bitcoin/gitian.sigs/tree/master/0.5.2/devrandom
 14 2012-01-13 04:03:01 <devrandom> and a second build matched the first
 15 2012-01-13 04:03:09 <kiba> I heard luke-jr issued solidcoin some DMCA takedown
 16 2012-01-13 04:04:58 <kiba> I hate the fucking drama that circulate around bitcoin these days
 17 2012-01-13 04:17:25 <gmaxwell> kiba: thats kinda ot for #bitcoin-dev
 18 2012-01-13 04:17:31 <gmaxwell> This is a drama free zone".
 19 2012-01-13 04:17:46 <luke-jr> lol
 20 2012-01-13 04:30:59 <BlueMatt> devrandom: I havent built 0.5.2, only 0.5.2rc1, though it got renamed to final, so no I never got around to uploading my sigs
 21 2012-01-13 04:31:11 <BlueMatt> devrandom: Ill probably do that tomorrow
 22 2012-01-13 04:37:38 <luke-jr> BlueMatt: would the version affect the sigs at all?
 23 2012-01-13 04:49:58 <nanobyte> Have a good one, thanks for the interesting read
 24 2012-01-13 06:51:38 <glisignoli> Evening! I have a quick question. I'm running bitcoind and just trying to get my head around how it works. Does it create a "wallet" to store my bitcoins in, or do I have to already have a wallet and tell bitcoind what it is?
 25 2012-01-13 06:53:30 <gmaxwell> glisignoli: bitcoin creates a wallet for you (stored in wallet.dat) when you start it.
 26 2012-01-13 06:58:35 <glisignoli> gmaxwell: Ah ok. Yep I see that now (in ~/.bitcoin). So When I do "bitcoin getnewaddress" that generates a new address for me to send bitcoins to?
 27 2012-01-13 06:58:46 <gmaxwell> Correct.
 28 2012-01-13 06:58:57 <glisignoli> excellent
 29 2012-01-13 06:59:10 <glisignoli> So how do the different accounts work?
 30 2012-01-13 06:59:15 <gmaxwell> Make sure to make periodic backups of your wallet (backwallet command).
 31 2012-01-13 06:59:27 <gmaxwell> glisignoli: https://en.bitcoin.it/wiki/Accounts_explained
 32 2012-01-13 06:59:33 <glisignoli> Ah thanks!
 33 2012-01-13 07:06:07 <luke-jr> glisignoli: the accounts are merely a client-side abstraction for convenience
 34 2012-01-13 07:07:07 <glisignoli> ah ok cool
 35 2012-01-13 07:07:46 <glisignoli> One more question, is there a command to check for new incomming transaction?
 36 2012-01-13 07:07:53 <glisignoli> I don't know if thats correct or now
 37 2012-01-13 07:08:02 <glisignoli> or can I only check my balance?
 38 2012-01-13 07:08:42 <luke-jr> listtransactions
 39 2012-01-13 07:08:58 <glisignoli> ah awesome
 40 2012-01-13 07:09:06 <glisignoli> ok I think that will be enough to get me going for now
 41 2012-01-13 07:50:06 <UukGoblin> piuk hasn't replied to email
 42 2012-01-13 11:19:43 <Eliel> glisignoli: about getnewaddress, it does give you a new unused address, however, it doesn't create it on the spot. Instead, it takes an address from a reserve of 100 addresses, gives you that and replaces the reserve address with a new one it just generated.
 43 2012-01-13 11:20:27 <Eliel> glisignoli: this is to allow backuped wallets to have some future proofing so you don't need to take a new backup every time you give out an address.
 44 2012-01-13 13:19:03 <helo> Eliel: that's not entirely correct iirc... it only generates new addresses once you run out of pre-generated ones, at which point it refills the pool
 45 2012-01-13 13:22:41 <gmaxwell> helo: Thats not correct. It continually generates addresses to keep the pool full when it can*.
 46 2012-01-13 13:22:57 <gmaxwell> *[can is subject to the wallet being unlocked, if you're using wallet encryption]
 47 2012-01-13 13:23:19 <gmaxwell> helo: if it did not then you'd constantly be at risk of data loss.
 48 2012-01-13 13:23:49 <gmaxwell> (because you might backup one key before it did it's refill and then the next key you go wouldn't be in your backup)
 49 2012-01-13 13:36:10 <helo> so when you revert to your backup the new ones that were generated since the backup are lost, but that's ok since they were never shown?
 50 2012-01-13 13:41:12 <helo> it would be nice if the client could keep track of which pool addresses were created after the last backup, and display a warning when giving out addresses that haven't been backed up
 51 2012-01-13 13:41:43 <gmaxwell> correct.
 52 2012-01-13 13:42:04 <gmaxwell> helo: thats hard, because it could only work if you only used backupwallet as your backup method.
 53 2012-01-13 13:42:22 <gmaxwell> If you backed up the wallet file directly it wouldn't know
 54 2012-01-13 14:07:39 <gavinandresen> Is the CIA bot really slow or was it turned off?  I pulled into master a while ago...
 55 2012-01-13 14:46:46 <nanotube> see, if gribble was still doing the whole feed, you'd have seen it :)
 56 2012-01-13 15:52:29 <helo> what if some group decided to use bitcoin for an election? each person receives a private/public keypair with 0.00500001 (1 satoshi for vote, 0.005 for fee) btc to spend to the address representing the person they are voting for
 57 2012-01-13 15:53:23 <helo> obviously devs would discourage this as it would contribute to blockchain bloat
 58 2012-01-13 15:54:34 <Diablo-D3> helo: it'd be easier to just use an altchain for that
 59 2012-01-13 15:55:16 <helo> wouldn't hashpower/visibility be a problem?
 60 2012-01-13 15:55:32 <helo> anyone can get on bitcoin's network and grab the blockchain to verify anything
 61 2012-01-13 15:55:38 <UukGoblin> helo, what about intimidation, someone could easily force you to vote for someone
 62 2012-01-13 15:55:46 <Diablo-D3> helo: not quite
 63 2012-01-13 15:55:51 <Diablo-D3> helo: if you require merged mining, its fine
 64 2012-01-13 15:55:58 <helo> UukGoblin: nobody would be able to tell who anyone else voted for, so you could say you voted for whoever
 65 2012-01-13 15:56:53 <lianj> bitcoin is not anonymous to that extend
 66 2012-01-13 15:56:58 <helo> the public keys of all accounts that were given out to voters could be published in a central place
 67 2012-01-13 15:57:30 <helo> it would be pretty difficult to tell who everyone voted for, but it might be possible to figure out who some voted for
 68 2012-01-13 15:57:31 <Diablo-D3> helo: a bitcoin-like system can be used for this
 69 2012-01-13 15:57:34 <UukGoblin> people could run DPI to check who voted who
 70 2012-01-13 15:57:39 <Diablo-D3> but what you'd do is hand out preloaded wallet.dats
 71 2012-01-13 15:57:43 <Diablo-D3> that have exactly one key in it
 72 2012-01-13 15:57:47 <Diablo-D3> and 1 votecoin
 73 2012-01-13 15:58:00 <helo> how could you get bitcoin miners to merge-mine it?
 74 2012-01-13 15:58:09 <helo> what incentive would be in it for them?
 75 2012-01-13 15:58:10 <Diablo-D3> have the "vote machines" merge mine it.
 76 2012-01-13 15:58:11 <UukGoblin> helo, also, if public keys were published, an intimidator could force you to show him what key you got
 77 2012-01-13 15:58:17 <Diablo-D3> helo: merged mining isnt about incentive
 78 2012-01-13 15:58:24 <Diablo-D3> lets say I merged mine btc and nmc
 79 2012-01-13 15:58:25 <helo> UukGoblin: hmm good point
 80 2012-01-13 15:58:31 <Diablo-D3> my card does 400 mhash
 81 2012-01-13 15:58:39 <Diablo-D3> 400 mhash goes to btc, 400 mhash goes to nmc
 82 2012-01-13 15:58:42 <UukGoblin> and I'm not sure why a chain is needed there at all
 83 2012-01-13 15:59:02 <Diablo-D3> UukGoblin: it technically isnt, but it'd allow a confirmed cryptographically signed vote.
 84 2012-01-13 15:59:27 <UukGoblin> Diablo-D3, you could just as well give people keys and get them to submit votes to a central server
 85 2012-01-13 15:59:29 <Diablo-D3> bitcoin is a cyrpto logging system.
 86 2012-01-13 15:59:34 <Diablo-D3> UukGoblin: true, but the problem is
 87 2012-01-13 15:59:35 <Diablo-D3> people dont
 88 2012-01-13 15:59:41 <Diablo-D3> they go to physical places and vote on machines
 89 2012-01-13 15:59:45 <Diablo-D3> instead of just doing it over the internet
 90 2012-01-13 15:59:51 <Diablo-D3> Im thinking big picture here
 91 2012-01-13 15:59:55 <helo> so either let people vote at a central location with voting machines, or let them vote at home (or abroad)
 92 2012-01-13 15:59:55 <lianj> which is a good thing
 93 2012-01-13 16:00:09 <Diablo-D3> lianj: nope, the machines are broken
 94 2012-01-13 16:00:14 <Diablo-D3> they do not verify anything
 95 2012-01-13 16:00:21 <UukGoblin> Diablo-D3, I was thinking about an internet-only voting system that would have all the properties of physical systems, and figured it's either very hard or impossible
 96 2012-01-13 16:00:27 <Diablo-D3> they dont verify the person is the person, they dont verify that they didnt vote somewhere else earlier
 97 2012-01-13 16:00:33 <Diablo-D3> they dont even protect the integrity of the votes
 98 2012-01-13 16:00:34 <lianj> most voting machines are broken aswell, even worse
 99 2012-01-13 16:00:42 <Diablo-D3> UukGoblin: its not impossible
100 2012-01-13 16:00:58 <Diablo-D3> use a centralized authority that sends a physical key out
101 2012-01-13 16:01:07 <Diablo-D3> and then type the number into a browser
102 2012-01-13 16:01:09 <Diablo-D3> it is use once
103 2012-01-13 16:01:27 <UukGoblin> Diablo-D3, how do you prevent someone with a gun from forcing your vote?
104 2012-01-13 16:01:30 <Diablo-D3> you can use a bitcoin-like system to synchronize and secure the servers running the system
105 2012-01-13 16:01:43 <Diablo-D3> UukGoblin: nothing, that is done in every election
106 2012-01-13 16:01:51 <Diablo-D3> example: "vote for this guy or you're fired"
107 2012-01-13 16:01:51 <UukGoblin> no.
108 2012-01-13 16:01:57 <Diablo-D3> yes, it IS done.
109 2012-01-13 16:02:02 <UukGoblin> Diablo-D3, but they can't verify it
110 2012-01-13 16:02:06 <helo> only if you go into a safe isolated place to vote can they prevent vote-forcing
111 2012-01-13 16:02:07 <UukGoblin> you can just lie
112 2012-01-13 16:02:14 <Diablo-D3> if the guy doesnt win, they fire a few people randomly.
113 2012-01-13 16:02:28 <UukGoblin> pfft.
114 2012-01-13 16:02:46 <Diablo-D3> idont pfft me, rich people are dangerous terrorists
115 2012-01-13 16:03:04 <Diablo-D3> UukGoblin: anyhow, even if they put a gun to my head
116 2012-01-13 16:03:05 <Diablo-D3> Im one vote
117 2012-01-13 16:03:08 <Diablo-D3> out of millions
118 2012-01-13 16:03:20 <Diablo-D3> vote fraud doesnt happen on the small scale
119 2012-01-13 16:03:24 <Diablo-D3> it happens on the large scale
120 2012-01-13 16:03:35 <UukGoblin> there's over 2 million north koreans in active military :-)
121 2012-01-13 16:03:49 <Diablo-D3> like those tens of thousands of al gore votes they found at a bottom of a lake in florida
122 2012-01-13 16:03:54 <Diablo-D3> thats how you do it.
123 2012-01-13 16:03:56 <helo> putting up a request for merge-mining if there is no reward given to those who expend the effort to do implement it seems in vain
124 2012-01-13 16:04:04 <UukGoblin> Diablo-D3, sure.
125 2012-01-13 16:04:11 <Diablo-D3> and no
126 2012-01-13 16:04:17 <Diablo-D3> north korea does not have an active military
127 2012-01-13 16:04:23 <UukGoblin> no doubt there's lots of bullshit around voting as it is done
128 2012-01-13 16:04:25 <Diablo-D3> they have a forced slave labor camp.
129 2012-01-13 16:04:35 <Diablo-D3> UukGoblin: bullshit will always happen
130 2012-01-13 16:04:38 <Diablo-D3> the trick is to minimize it.
131 2012-01-13 16:04:39 <UukGoblin> but you can't duplicate a system that'll have all the theoretical advantages of a physical one
132 2012-01-13 16:04:51 <Diablo-D3> the physical ELEECTRONIC one has none
133 2012-01-13 16:04:56 <Diablo-D3> and dont pretend it does.
134 2012-01-13 16:05:02 <UukGoblin> ah, physical electronic, fine
135 2012-01-13 16:05:06 <UukGoblin> but that's not vote-from-home
136 2012-01-13 16:05:13 <Diablo-D3> no, but thats what Im bitching about
137 2012-01-13 16:05:24 <Diablo-D3> I want that entire system replaced with a cryptographically secured one.
138 2012-01-13 16:05:38 <UukGoblin> ah
139 2012-01-13 16:05:39 <Diablo-D3> a bitcoin-like system would prevent vote fraud largely.
140 2012-01-13 16:05:40 <UukGoblin> right
141 2012-01-13 16:05:55 <UukGoblin> you still don't need bitcoin or chains at all
142 2012-01-13 16:06:02 <Diablo-D3> even if you tamper with the system, every single vote machine in the US, all hundreds of thousands of them, would already know how someone voted
143 2012-01-13 16:06:05 <Diablo-D3> see above
144 2012-01-13 16:06:12 <helo> what if you'd go into the physical voting place, and vote as usual on their machines (which would be running bitcoin), and they'd print out the public key used to place your vote for you to verify later against the blockchain?
145 2012-01-13 16:06:27 <helo> so it would be exactly as it is now, just verifiable for each individual
146 2012-01-13 16:06:31 <luke-jr> how about just get rid of voting?
147 2012-01-13 16:06:34 <Diablo-D3> helo: having reciepts alone would stop a lot of fraud
148 2012-01-13 16:06:52 <UukGoblin> +1 for luke-jr
149 2012-01-13 16:06:55 <Diablo-D3> machines currently do not print reciepts, or they dont print useful ones
150 2012-01-13 16:06:59 <Diablo-D3> -1 luke
151 2012-01-13 16:07:04 <Diablo-D3> its how our country is ran
152 2012-01-13 16:07:10 <luke-jr> unfortunately.
153 2012-01-13 16:07:12 <Diablo-D3> if you want to go live in china, then go ahead, move
154 2012-01-13 16:07:15 <UukGoblin> helo, there's already good electronic voting systems developed
155 2012-01-13 16:07:16 <luke-jr> that can change, though!
156 2012-01-13 16:07:23 <lianj> Diablo-D3: vote by paper
157 2012-01-13 16:07:30 <luke-jr> vote to end voting!
158 2012-01-13 16:07:31 <Diablo-D3> lianj: thats what I recommend people do
159 2012-01-13 16:07:35 <helo> UukGoblin: where each voter can independantly verify their vote?
160 2012-01-13 16:07:39 <UukGoblin> helo, yes
161 2012-01-13 16:07:40 <Diablo-D3> lianj: every place has to offer paper votes in most states
162 2012-01-13 16:07:43 <Diablo-D3> if they don't, sue
163 2012-01-13 16:08:03 <helo> UukGoblin: so the ones we use aren't like that because we suck? :)
164 2012-01-13 16:08:06 <lianj> we have that in germany
165 2012-01-13 16:08:10 <luke-jr> if you really want voting, at least let people vote per candidate.
166 2012-01-13 16:08:11 <Diablo-D3> we dont here
167 2012-01-13 16:08:21 <Diablo-D3> otherwise bush would retroactively not be president
168 2012-01-13 16:08:35 <luke-jr> so people can say "I don't like any of these jerks, but I like Obama a whole lot less than the rest" ;)
169 2012-01-13 16:08:35 <UukGoblin> helo, not sure what we use
170 2012-01-13 16:08:38 <UukGoblin> but quite likely so
171 2012-01-13 16:08:59 <Diablo-D3> the government keeps saying such a system is unfeasable
172 2012-01-13 16:09:07 <helo> what would keep someone from bloating up the blockchain with scenarios like this?
173 2012-01-13 16:09:17 <Diablo-D3> yet the banking system processes that many transactions a day, every day, all year long.
174 2012-01-13 16:09:18 <lianj> voting machines have been proven to easily tamper with, thats why german state and other eu states abandoned them
175 2012-01-13 16:09:26 <helo> seems like starting an altchain would require a lot more work, and wouldn't work well for multiple uses, etc
176 2012-01-13 16:09:32 <Diablo-D3> lianj: you cant tamper with EVERY SINGLE MACHINE
177 2012-01-13 16:09:36 <Diablo-D3> which is why you'd run an altchain
178 2012-01-13 16:09:40 <UukGoblin> helo, I saw one where you got a transparent film with a printout of some random dots, a website would show you some other random dots, and when you put the film over the screen it'd show something to verify your vote
179 2012-01-13 16:09:48 <Diablo-D3> every single machine would tell every other single machine the entire voting record thus far
180 2012-01-13 16:10:12 <Diablo-D3> if you tamper with it, it wouldnt matter
181 2012-01-13 16:10:13 <lianj> Diablo-D3: yes, full ack on a real crypto voting sytem. but most uses ones today are just blackboxes
182 2012-01-13 16:10:23 <Diablo-D3> lianj: this is what Im bitching about,
183 2012-01-13 16:10:25 <Diablo-D3> get up to speed ;)
184 2012-01-13 16:10:38 <luke-jr> on topic&
185 2012-01-13 16:10:45 <lianj> stop bitching, fix it
186 2012-01-13 16:10:47 <luke-jr> anything we can do about all this "green address" spam?
187 2012-01-13 16:11:06 <UukGoblin> what's "green address"?
188 2012-01-13 16:11:39 <luke-jr> UukGoblin: MtGox and DeepBit are apparently adding an extra input/output to every transaction to flag "this is from me. you should trust me with 0 confirms"
189 2012-01-13 16:11:52 <helo> where i'm getting at is: how would bitcion handle being perverted for uses such as this?
190 2012-01-13 16:11:56 <theymos> /join #bitcoin-otc
191 2012-01-13 16:12:49 <Diablo-D3> lianj: cant fix it
192 2012-01-13 16:13:00 <Diablo-D3> people have repeatedly came up with fuck-proof voting machines
193 2012-01-13 16:13:10 <UukGoblin> luke-jr, ah, cool
194 2012-01-13 16:13:28 <helo> it seems blockchain bloat is going to happen, and there's nothing that can be done to stop it... miners will just become more fee-hungry over time
195 2012-01-13 16:13:51 <UukGoblin> I think what we should do with it is provide a way for a regular user to put whatever data he wants alongside with a transaction and consider it standard practice, rather than spam
196 2012-01-13 16:13:56 <UukGoblin> imho.
197 2012-01-13 16:14:00 <helo> right...
198 2012-01-13 16:14:15 <UukGoblin> well, imo, it's not that humble.
199 2012-01-13 16:14:51 <luke-jr> UukGoblin: not in the blockchain
200 2012-01-13 16:14:56 <UukGoblin> standardizing it would make it less painful.
201 2012-01-13 16:15:00 <luke-jr> UukGoblin: out-of-band, like email or IM
202 2012-01-13 16:16:07 <helo> "keep the blockchain small" vs "let everyone submit things to the blockchain"
203 2012-01-13 16:16:43 <helo> as long as the latter is possible, the former will not be
204 2012-01-13 16:17:19 <UukGoblin> if you provide a standardized way to put it, you'll have an easy life of removing it
205 2012-01-13 16:17:57 <luke-jr> UukGoblin: yes, that's why I'm trying to get signmessage stuff merged&
206 2012-01-13 16:18:01 <UukGoblin> just prune it like a spent output
207 2012-01-13 16:18:18 <luke-jr> you send your txn, then copy a base64 string as "proof of payment" to a website or something
208 2012-01-13 16:18:20 <theymos> Data put in scriptSigs can be pruned immediately without protocol extensions.
209 2012-01-13 16:18:30 <luke-jr> theymos: not by full nodes
210 2012-01-13 16:18:45 <theymos> Why?
211 2012-01-13 16:19:09 <Joric> i was always wondering how bitcoinj handles blocks they're smaller aren't they
212 2012-01-13 16:19:09 <sipa> because full nodes need to be able to provide the entire blockchain to those who ask
213 2012-01-13 16:19:15 <sipa> that is how they are defined
214 2012-01-13 16:19:39 <sipa> you can have almost-full-nodes which verify everything, but do not advertize as NODE_NETWORK, which prune
215 2012-01-13 16:20:02 <sipa> such an almost-full-node is sufficient for a miner, but the network still needs full nodes
216 2012-01-13 16:20:34 <sipa> luke-jr: why not just send the transaction itself to the website?
217 2012-01-13 16:21:07 <sipa> a proof of payment may be useful, but to me, just providing the transaction itself is a far superior solution
218 2012-01-13 16:21:29 <sipa> (which requires more work still, true)
219 2012-01-13 16:23:19 <UukGoblin> sipa, imho, whenever someone needs access to a transaction that's pruned by almost-full-nodes, they should just provide it themselves
220 2012-01-13 16:23:38 <UukGoblin> i.e. if you care about shit you put in blockchain being accessible, you host it yourself
221 2012-01-13 16:23:46 <sipa> UukGoblin: nobody should ever need access to a pruned transaction
222 2012-01-13 16:23:57 <sipa> but the protocol cannot live without non-pruning nodes
223 2012-01-13 16:25:18 <UukGoblin> sipa, I'm thinking of a scenario, "txout1: send 1 BTC to address $foo; txout2: message 'for my new teddy bear'". Then almost-full-nodes prune txout2 and leave txout1 (I'm not actually sure if pruning works based on outputs or txns)
224 2012-01-13 16:25:48 <theymos> Long-term, I don't think anyone in the network really *needs* to know about very old transactions (older than 10,000 blocks, say). Old nodes know that their chain is correct, and new nodes can figure out which chain is correct using some out-of-band method.
225 2012-01-13 16:26:05 <UukGoblin> however, one year later, a judge asks, "what was that transaction for", and then you provide your own-hosted info about that transaction to prove a claim, "for my then-new teddy bear"
226 2012-01-13 16:26:24 <phantomcircuit> basically at somepoint you instruct nodes to simply assume transactions far enough back in the blockchain are valid
227 2012-01-13 16:26:39 <sipa> UukGoblin: of course, for non-protocol-related matters, but that is no problem, you keep the transaction itself, if you are legally obliged to
228 2012-01-13 16:26:57 <luke-jr> sipa: can you pull https://github.com/bitcoin/bitcoin/pull/755 ?
229 2012-01-13 16:27:35 <sipa> luke-jr: i'd like gavin's comments on that first
230 2012-01-13 16:27:56 <luke-jr> sipa: I don't like Gavin forcing people to vote for things they reject.
231 2012-01-13 16:28:51 <gribble> New news from bitcoinrss: luke-jr opened pull request 755 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/755>
232 2012-01-13 16:29:13 <luke-jr> that's hardly a vote
233 2012-01-13 16:30:14 <CIA-100> bitcoin: various explicit_p2sh * redccb1..a1de57 bitcoind-personal/src/ (32 files in 2 dirs): (8 commits) http://tinyurl.com/7mdc392
234 2012-01-13 16:30:17 <CIA-100> libbitcoin: Kamil Domanski * r45f2dddc7e20 / (2 files in 2 dirs): discovery: IRC talks to us http://tinyurl.com/7lcparu
235 2012-01-13 16:30:18 <theymos> Which way is [Tycho] voting?
236 2012-01-13 16:30:23 <CIA-100> libbitcoin: Kamil Domanski * rb7a03c12f6c0 / (development-makefile tests/irc.cpp): IRC discovery unit test http://luke.dashjr.org/programs/bitcoin/w/libbitcoin.git/commitdiff/b7a03c12f6c0917c6d5f4ca62991c8f69cccad93
237 2012-01-13 16:30:25 <CIA-100> libbitcoin: Kamil Domanski * rea27aa40d150 /.gitignore: add Eclipse project files to .gitignore http://tinyurl.com/7dfnfk7
238 2012-01-13 16:31:38 <luke-jr> theymos: Tycho opposes, but I don't know if he'll bother with coinbase.
239 2012-01-13 16:32:01 <sipa> luke-jr: i understand your concern, but a) every block without /p2sh/ is a vote against already, and 2) hardly any hasing power comes from unpatched bitcoind's anyway
240 2012-01-13 16:32:12 <luke-jr> sipa: Gavin is forcing people to add /P2SH/
241 2012-01-13 16:32:39 <Diablo-D3> what is p2sh?
242 2012-01-13 16:32:56 <luke-jr> Diablo-D3: P2SH is pay-to-script-hash: OP_EVAL and this new '/P2SH/' proposal
243 2012-01-13 16:33:09 <luke-jr> Diablo-D3: OP_EVAL was sane, but not entirely staticly analyzable
244 2012-01-13 16:33:22 <Diablo-D3> OP_EVAL is not sane
245 2012-01-13 16:33:22 <UukGoblin> oh hang on, there's already voting happening in the blocks?
246 2012-01-13 16:33:27 <luke-jr> Diablo-D3: this new one is more analyzable, but special-cases a magic script template
247 2012-01-13 16:33:29 <Diablo-D3> Ive already bitched loudly about it on irc
248 2012-01-13 16:33:29 <theymos> It'll be interesting to see whether the development group's decision will actually be defeated by miners. I don't think that's happened before.
249 2012-01-13 16:33:36 <luke-jr> Diablo-D3: OP_EVAL was more sane than the new one
250 2012-01-13 16:33:41 <Diablo-D3> op_eval is not secure.
251 2012-01-13 16:33:57 <luke-jr> UukGoblin: yes, and Gavin is forcing his decision on people running latest git master
252 2012-01-13 16:34:04 <Diablo-D3> is basically a retardedly designed virtual machine.
253 2012-01-13 16:34:17 <Diablo-D3> luke-jr: then fork the client and make people use yours.
254 2012-01-13 16:34:20 <Diablo-D3> otherwise, stfu
255 2012-01-13 16:34:48 <UukGoblin> but but most miners are using pools!
256 2012-01-13 16:34:59 <sipa> and pools will decide for themselves what they choose
257 2012-01-13 16:35:27 <UukGoblin> luke-jr, since which commit?
258 2012-01-13 16:35:40 <Diablo-D3> UukGoblin: yes, but most CLIENTS run the main branch
259 2012-01-13 16:36:06 <Diablo-D3> what happens if gavin just adds a patch that rejects blocks after a specific point with op_eval txen
260 2012-01-13 16:36:09 <luke-jr> UukGoblin: 922e8e2
261 2012-01-13 16:36:15 <Diablo-D3> pools no longer matter if they cant make blocks
262 2012-01-13 16:36:15 <UukGoblin> luke-jr, thanks
263 2012-01-13 16:36:44 <luke-jr> UukGoblin: earlier, for an obsolete vote (OP_EVAL)
264 2012-01-13 16:38:46 <UukGoblin> hang on, this whole voting stuff seems kinda backwards...
265 2012-01-13 16:38:57 <UukGoblin> why not just miners decide what txns they relay and mine?
266 2012-01-13 16:39:03 <UukGoblin> let*
267 2012-01-13 16:39:14 <sipa> UukGoblin: we are introducing a backward-compatible change to the protocol
268 2012-01-13 16:39:16 <luke-jr> UukGoblin: including invalid ones?
269 2012-01-13 16:39:24 <sipa> this means that things that used to be valid, become invalid
270 2012-01-13 16:39:41 <UukGoblin> sipa, you mean backward-incompatible?
271 2012-01-13 16:39:45 <sipa> no
272 2012-01-13 16:39:49 <theymos> Without voting there would be a big mess of incompatible rules.
273 2012-01-13 16:39:53 <sipa> things that were invalid, remain invalid
274 2012-01-13 16:40:13 <luke-jr> UukGoblin: old clients will accept everything, so backward compatible
275 2012-01-13 16:40:19 <sipa> this causes no blockchain split under the condition that a supermajority of miners have expressed their intention to switch to the new rules once deployed
276 2012-01-13 16:40:37 <Diablo-D3> sipa: change your nick, its too close to sopa
277 2012-01-13 16:40:44 <sipa> Diablo-D3: i was first
278 2012-01-13 16:41:03 <UukGoblin> wait, which rules is this changing: the accept-in-mined-block, or relay?
279 2012-01-13 16:41:09 <luke-jr> UukGoblin: both
280 2012-01-13 16:41:18 <Diablo-D3> sipa: yes, and so was I, I'm still waiting for royalty checks from Blizzard
281 2012-01-13 16:41:19 <UukGoblin> oh...
282 2012-01-13 16:41:20 <luke-jr> nuts, Eligius is only 4%
283 2012-01-13 16:41:25 <Diablo-D3> it doesnt stop people from going HEY YOU LIKE DIABLO?
284 2012-01-13 16:41:29 <Diablo-D3> no, I like nethack, go fuck yourself
285 2012-01-13 16:41:56 <Diablo-D3> http://githire.com/about
286 2012-01-13 16:41:57 <theymos> luke-jr: What does [Tycho] think about your "CHC" proposal. That seems like the best one to me.
287 2012-01-13 16:42:02 <Diablo-D3> dear lord, chunky bacon again
288 2012-01-13 16:42:07 <UukGoblin> luke-jr, I thought even non-standard are accepted-in-mined-blocks?
289 2012-01-13 16:42:09 <luke-jr> Eligius + Eclipse + BTCMine + BTC Guild would be needed to stop it without Tycho
290 2012-01-13 16:42:16 <luke-jr> theymos: haven't discussed it with him
291 2012-01-13 16:42:18 <Diablo-D3> luke-jr: yes....
292 2012-01-13 16:42:22 <Diablo-D3> unless I start my own pool
293 2012-01-13 16:42:24 <Diablo-D3> DiabloPool
294 2012-01-13 16:42:29 <Diablo-D3> which would take tycho's over in a heart beat
295 2012-01-13 16:42:30 <luke-jr> UukGoblin: we're not talking about accepting more
296 2012-01-13 16:42:38 <Diablo-D3> I'd be the 99%. In a bad way.
297 2012-01-13 16:42:50 <UukGoblin> are we talking about rejecting some?
298 2012-01-13 16:43:02 <luke-jr> UukGoblin: yes
299 2012-01-13 16:43:33 <UukGoblin> so if someone created a P2HS transaction now, before the vote finishes, and it'd become rejected later, wouldn't that cause an insta-chainsplit?
300 2012-01-13 16:43:46 <theymos> The rules will only apply to new blocks.
301 2012-01-13 16:43:53 <luke-jr> UukGoblin: no, because the rules for /P2SH/ start at a block #
302 2012-01-13 16:44:05 <UukGoblin> ah, right
303 2012-01-13 16:44:11 <Diablo-D3> luke-jr: see any more threads that are like LOL LUKE CRUSHED CLC WITH ELIGIUS-BOMB?
304 2012-01-13 16:44:20 <luke-jr> UukGoblin: also, "P2SH" is a general concept everyone agrees we need; "/P2SH/" is the problem implementation
305 2012-01-13 16:44:26 <luke-jr> Diablo-D3: haven't looked
306 2012-01-13 16:44:33 <Diablo-D3> well if you find any, pm me
307 2012-01-13 16:44:44 <Diablo-D3> I nuke them on sight now to keep the trolls to a minimum
308 2012-01-13 16:44:53 <Diablo-D3> er, only tell me about ones in the mining subforum
309 2012-01-13 16:44:54 <UukGoblin> luke-jr, oh, right... I was looking at BIP 16, where's /P2SH/ described then?
310 2012-01-13 16:44:59 <Diablo-D3> anywhere else is out of my jurisdicktion
311 2012-01-13 16:45:09 <luke-jr> UukGoblin: BIP 16 is /P2SH/
312 2012-01-13 16:49:29 <UukGoblin> isn't 15 Feb 2012 a bit early to implement a major change like this? I mean, shouldn't it be a year or so in advance?
313 2012-01-13 16:49:56 <UukGoblin> ah, actually, maybe it's not as severe because it's backwards-compatible
314 2012-01-13 16:50:20 <sipa> under the condition that sufficient mining power is behind it
315 2012-01-13 16:50:41 <UukGoblin> that could cause stale blocks for the minority of miners I guess
316 2012-01-13 16:50:52 <UukGoblin> (if it's accepted)
317 2012-01-13 16:50:58 <sipa> it could, yes
318 2012-01-13 16:51:20 <UukGoblin> ok, I think I'm beginning to understand it
319 2012-01-13 16:51:36 <UukGoblin> let me read up what the verification actually does
320 2012-01-13 16:51:42 <theymos> The features provided by P2SH, OP_EVAL, etc. are pretty important. They allow a lot of new stuff in a backward-compatible way.
321 2012-01-13 16:52:07 <UukGoblin> yeah, I get that
322 2012-01-13 16:52:18 <UukGoblin> I'm not yet sure what transactions will have to be rejected
323 2012-01-13 16:53:39 <theymos> Transactions redeeming scriptPubKeys of the form "OP_HASH160 [20-byte-hash-value] OP_EQUAL" are rejected unless they meet certain extra conditions.
324 2012-01-13 16:54:48 <UukGoblin> you mean "will be if /P2SH/ is implemented"?
325 2012-01-13 16:54:55 <theymos> Yes.
326 2012-01-13 16:55:56 <theymos> The old conditions imposed by Script also apply, but some extra restrictions not specified in the script will also be imposed when the scriptPubKey takes that exact form.
327 2012-01-13 16:56:52 <UukGoblin> hmm I thought OP_EVAL was to allow transactions of the type "Redeemable if 3 out of 5 parties agree"... Will P2SH allow for that too?
328 2012-01-13 16:57:14 <UukGoblin> (among others of course)
329 2012-01-13 16:57:50 <sipa> UukGoblin: yes, but it is not directly related
330 2012-01-13 16:58:19 <sipa> p2sh means i can you a short address which represents a simple or complex script, and you can pay to it
331 2012-01-13 16:58:25 <sipa> without knowing what the script is
332 2012-01-13 16:58:36 <sipa> effectively making the script transparent to the payer
333 2012-01-13 16:58:39 <helo> how could someone make the argument that not having /P2SH/ is better than having it? it doesn't sound like another implementation with similar features and security is forthcoming... the /P2SH/ alternative seems to be stagnation
334 2012-01-13 16:59:02 <sipa> helo: OP_EVAL was an alternative preferred by some
335 2012-01-13 16:59:13 <helo> without the security though
336 2012-01-13 16:59:58 <helo> i.e.- People That Matter have determined that OP_EVAL is not safe enough, so it's not an alternative
337 2012-01-13 17:00:14 <theymos> This particular way of doing it is kind of hack. It isn't consistent with how the rest of Script works because no opcode is saying to do this extra stuff.
338 2012-01-13 17:00:35 <helo> it's not as if OP_EVAL will be integrated if /P2SH/ fails
339 2012-01-13 17:01:21 <sipa> it is absolutely a hack
340 2012-01-13 17:01:32 <helo> hopefully people who oppose /P2SH/ think there is a clean and safe way to do it that hasn't been thought of
341 2012-01-13 17:01:42 <sipa> helo: there have been several other proposals
342 2012-01-13 17:01:52 <sipa> some of them much cleaner
343 2012-01-13 17:01:56 <theymos> I like luke-jr's CHC proposal here: https://bitcointalk.org/index.php?topic=56969.msg687795#msg687795
344 2012-01-13 17:02:52 <sipa> yes, if we disregard the half-verification by old nodes, that is probably the best proposal
345 2012-01-13 17:03:00 <UukGoblin> so how would you create a "redeemable if 3 parties agree" transaction with P2SH?
346 2012-01-13 17:03:22 <sipa> UukGoblin: you create the necessary script for that, hash it, and send the hash as payment address to the payer
347 2012-01-13 17:03:34 <theymos> UukGoblin: You'd put the OP_CHECKMULTISIG stuff in the serialized script.
348 2012-01-13 17:03:37 <sipa> he creates a magic hash script that says "redeemable by a script whose hash is X"
349 2012-01-13 17:03:50 <sipa> and when spending, you provide the script plus its arguments
350 2012-01-13 17:04:19 <theymos> Bitcoin can already do multi-sig transactions. You'd just need a really long address (and a new address format) to transmit that info, and the payer would probably need to pay extra fees. These proposals fix those problems.
351 2012-01-13 17:04:19 <UukGoblin> ah, right
352 2012-01-13 17:04:42 <UukGoblin> right, I see
353 2012-01-13 17:05:01 <UukGoblin> so OP_CHECKMULTISIG is probably non-standard yet?
354 2012-01-13 17:05:11 <UukGoblin> or am I confusing something badly?
355 2012-01-13 17:05:20 <Diablo-D3> dude
356 2012-01-13 17:05:23 <Diablo-D3> Im going to add a patch
357 2012-01-13 17:05:27 <Diablo-D3> OP_GIVEDIABLOMONEY
358 2012-01-13 17:05:35 <Diablo-D3> not only does it give me the money of your tx
359 2012-01-13 17:05:43 <Diablo-D3> it gives me the money of all tx in that block
360 2012-01-13 17:05:55 <theymos> UukGoblin: It has been non-standard, though maybe it has been made standard recently. There was discussion about that, at least.
361 2012-01-13 17:06:02 <Diablo-D3> :3
362 2012-01-13 17:06:03 <UukGoblin> theymos, right.
363 2012-01-13 17:06:11 <Diablo-D3> oh fuck would that be hilarious
364 2012-01-13 17:06:16 <Diablo-D3> like, theymos would merge that patch
365 2012-01-13 17:06:22 <Diablo-D3> and then everyone would be doomed
366 2012-01-13 17:06:27 <UukGoblin> Diablo-D3, yes, haha, very funny.
367 2012-01-13 17:06:50 <theymos> I don't.
368 2012-01-13 17:07:00 <Diablo-D3> sipa: he runs the largest pool and is 35% of the hashing power
369 2012-01-13 17:07:04 <Diablo-D3> I mean "merge into his private branch"
370 2012-01-13 17:07:08 <Diablo-D3> as in "apply the patch"
371 2012-01-13 17:07:13 <theymos> I don't run any pool...
372 2012-01-13 17:07:16 <luke-jr> sipa: my post explains why the half-verification is useless anyway
373 2012-01-13 17:07:20 <Diablo-D3> er, I mean tycho
374 2012-01-13 17:07:27 <Diablo-D3> too many names that start with t
375 2012-01-13 17:07:40 <sipa> luke-jr: i know
376 2012-01-13 17:07:51 <Diablo-D3> I have to remmeber. [ then t for tycho
377 2012-01-13 17:07:53 <Diablo-D3> not just t
378 2012-01-13 17:08:08 <Diablo-D3> theymos just like, runs a forum or something, I dunno
379 2012-01-13 17:10:13 <UukGoblin> so what's the difference between CHC and P2SH? :-P
380 2012-01-13 17:11:32 <theymos> The main difference is that CHC uses an opcode to indicate what to check instead of a "script template".
381 2012-01-13 17:11:39 <Diablo-D3> how the fuck do I tell wine to use linux libraries
382 2012-01-13 17:13:48 <luke-jr> https://bitcointalk.org/index.php?topic=58579.0
383 2012-01-13 17:14:33 <Diablo-D3> http://developer.amd.com/sdks/AMDAPPSDK/downloads/Pages/default.aspx
384 2012-01-13 17:14:38 <Diablo-D3> click "sdk 2.6 for windows 32"
385 2012-01-13 17:14:42 <Diablo-D3> wtf AMD
386 2012-01-13 17:15:11 <luke-jr> UukGoblin: CHC uses a new instruction for new behaviour; P2SH just runs new unexpected behaviour for a specific script
387 2012-01-13 17:16:27 <UukGoblin> does CHC also require miners to upgrade?
388 2012-01-13 17:16:37 <luke-jr> UukGoblin: yes, every possible solution does.
389 2012-01-13 17:16:45 <luke-jr> well, for certain meanings of "require"
390 2012-01-13 17:17:03 <luke-jr> non-upgrading miners will only be affects if they accept "non-standard" transactions, or build on one
391 2012-01-13 17:17:12 <luke-jr> affected*
392 2012-01-13 17:17:22 <luke-jr> but in all cases, a majority of miners need to support it
393 2012-01-13 17:18:10 <UukGoblin> right, so no stale blocks for old solo miners
394 2012-01-13 17:18:27 <luke-jr> UukGoblin: only if they build on a block with a (now invalid) transaction in it
395 2012-01-13 17:18:37 <luke-jr> so slightly higher risk of stales, but not notable
396 2012-01-13 17:18:44 <UukGoblin> so no stale blocks for old solo miners who used official bitcoin versions
397 2012-01-13 17:18:57 <UukGoblin> (above 0.3.10 of course)
398 2012-01-13 17:19:15 <UukGoblin> actually
399 2012-01-13 17:19:27 <UukGoblin> above the one where non-standard got introduced
400 2012-01-13 17:19:40 <helo> has there been an informal vote of devs to decide between /P2SH/ and CHC?
401 2012-01-13 17:19:52 <luke-jr> UukGoblin: I think you misunderstood me
402 2012-01-13 17:20:01 <luke-jr> UukGoblin: two possible cases:
403 2012-01-13 17:20:09 <luke-jr> 1. you accept non-standard transactions, and these blocks are always invalid
404 2012-01-13 17:20:20 <luke-jr> 2. you build on someone else's block with non-standard transactions that are now invalid
405 2012-01-13 17:20:31 <luke-jr> helo: no
406 2012-01-13 17:21:00 <helo> is there anyone screaming "CHC is terrible, i will stop it in any way possible!"?
407 2012-01-13 17:21:13 <luke-jr> helo: not that I've heard. Gavin seems to be ignoring it
408 2012-01-13 17:21:39 <luke-jr> roconnor pointed out a potential flaw regarding OP_IF, but that can be addressed in a formal BIP
409 2012-01-13 17:22:17 <UukGoblin> luke-jr, oh, right...
410 2012-01-13 17:23:44 <UukGoblin> rushing anything that fast for a network that mature seems a bit reckless
411 2012-01-13 17:24:09 <helo> if the problems with OP_EVAL lead to postponement/reconsideration (which most agree was a good thing), why can't the same happen with /P2SH/?
412 2012-01-13 17:24:39 <helo> particularly when it appears that there are solutions that satisfy everyone
413 2012-01-13 17:25:40 <luke-jr> yet I'm "trying Gavin's patience" somehow&
414 2012-01-13 17:26:41 <UukGoblin> hopefully he'll count "no" votes as much stronger than lack-of-vote-in-coinbase
415 2012-01-13 17:26:58 <UukGoblin> bbl
416 2012-01-13 17:27:04 <UukGoblin> thanks for the info guys
417 2012-01-13 17:28:21 <helo> it kind of seems like OP_EVAL was abandoned out of fear that a "developer split" would create bad PR
418 2012-01-13 17:28:34 <theymos> I voted for both P2SH and CHC in that forum poll. They both seem acceptable to me, though I prefer CHC somewhat.
419 2012-01-13 17:30:15 <luke-jr> helo: IMO, /P2SH/ is even worse
420 2012-01-13 17:30:45 <luke-jr> wtf, someone actually voted against multi-factor auth entirely?
421 2012-01-13 17:47:35 <UukGoblin> so what's this static verifiability and why do we need it?
422 2012-01-13 17:48:54 <helo> allows one to put bounds on the computation required to execute a script afaik
423 2012-01-13 17:49:05 <luke-jr> UukGoblin: my P.S. tried to explain that we don't :P
424 2012-01-13 17:50:29 <CIA-100> libbitcoin: Kamil Domanski * re09b219dc054 /include/bitcoin/ (network/discovery.hpp network/network.hpp types.hpp): typedef deduplication http://luke.dashjr.org/programs/bitcoin/w/libbitcoin.git/commitdiff/e09b219dc054ddeae49f532d8f716f5a8076d2eb
425 2012-01-13 18:02:28 <UukGoblin> right
426 2012-01-13 18:02:49 <UukGoblin> so this whole thing is basically to have shorter dodgy addressess
427 2012-01-13 18:03:27 <UukGoblin> ah, ok, but I do see it sometimes useful, maybe
428 2012-01-13 18:04:30 <luke-jr> dodgy?
429 2012-01-13 18:15:09 <edcba> ;;bc,mtgox
430 2012-01-13 18:15:10 <gribble> {"ticker":{"high":6.83333,"low":6.50001,"avg":6.676008988,"vwap":6.679500533,"vol":59838,"last_all":6.53623,"last_local":6.53623,"last":6.53623,"buy":6.56,"sell":6.5798}}
431 2012-01-13 18:28:05 <gmaxwell> UukGoblin: They're the same length as current addresses. But if you had a 3 of 5 escrow, for example, the address would be less than 1/5th the size in p2sh form rather than an alternative.
432 2012-01-13 18:29:24 <BlueMatt> can someone else test https://github.com/bitcoin/bitcoin/pull/454 ?
433 2012-01-13 18:30:36 <gmaxwell> helo: OP_EVAL is unsatisfactory because it makes script turing complete. A very clear major design goal of script was to not be turing complete. There was a feeling for a while that the recursion limits bounded it enough to be acceptable but then more people spoke up
434 2012-01-13 18:31:52 <gmaxwell> helo: in particular roconnor protested loudly, and he's one of the few people who have been creating a from scratch implementation of the complete system, and he's also an established expert in the field of formally validated software, so his opinions and arguments had a fair amount of weight.
435 2012-01-13 18:33:09 <gmaxwell> This caused some reevaluation, and P2SH was propose as a safer alternative. I think OP_EVAL would never have been proposed if P2SH had been thought of first.
436 2012-01-13 18:33:56 <gmaxwell> s/propose/proposed/
437 2012-01-13 18:36:32 <roconnor> helo: if you what to know why OP_EVAL was bad, you should watch Meredith's recent CCC talk.
438 2012-01-13 18:37:40 <gmaxwell> roconnor: one piece of weird misinformation I've seen circulating is apparently people think that OP_EVAL was one of the pre-existing but disabled OPcodes. Seems this confusion is partially caused by the fact that its introduction is a non-forking change.
439 2012-01-13 18:39:37 <roconnor> indeed; as you've said before, it looks more like satoshi when out of his way to not have OP_EVAL
440 2012-01-13 18:45:31 <UukGoblin> hang /win 25
441 2012-01-13 18:45:44 <UukGoblin> errm don't hang it, mistyped ;-P
442 2012-01-13 18:46:19 <luke-jr> gmaxwell: BIP 16 is *less* in line with the Script system than OP_EVAL
443 2012-01-13 18:50:51 <gmaxwell> luke-jr: OP_EVAL violates what is pretty clearly the most fundimental design objective of script. I'm not one for being too married to principles, but it's wrong to say otherwise.
444 2012-01-13 18:51:40 <theymos> I was originally thinking that OP_EVAL scripts would be self-contained enough that they couldn't be used for any kind of looping.
445 2012-01-13 18:53:05 <diki> damn
446 2012-01-13 18:53:17 <diki> No matter what I do gcc wont static link...
447 2012-01-13 18:53:50 <gmaxwell> when it was first suggested came up I thought OP_EVAL wouldn't be able to recurse at all
448 2012-01-13 18:54:20 <gmaxwell> But then I guess when gavin implemented it there was the question of how to limit that, and 'limited recursion is useful' was suggested.. which is true.
449 2012-01-13 18:54:31 <gmaxwell> and it sorta oozed in there, at least from my perspective.
450 2012-01-13 18:55:54 <roconnor> the most important property OP_EVAL violates is the security principle of validate input first and then interpret it.
451 2012-01-13 18:59:28 <luke-jr> gmaxwell: BIP 16 violates the entire script
452 2012-01-13 19:00:35 <luke-jr> since it's not a script, it's a special-case
453 2012-01-13 19:01:51 <gmaxwell> luke-jr: everything is a special case.
454 2012-01-13 19:01:58 <gmaxwell> The existance ofthe alt stack is a special case.
455 2012-01-13 19:01:58 <luke-jr> nonsense
456 2012-01-13 19:02:05 <gmaxwell> Anyone can pay is a special case.
457 2012-01-13 19:02:31 <gmaxwell> That checksig runs ECDSA over the (mostly)whole txn as a single opaque opcode is a special case.
458 2012-01-13 19:02:37 <gmaxwell> None of this is natural law.
459 2012-01-13 19:02:58 <theymos> Other than checksig, most things in script are pretty consistent, though.
460 2012-01-13 19:03:31 <luke-jr> gmaxwell: no, it's an opcode
461 2012-01-13 19:03:46 <luke-jr> checksig is a big too CISC, but it's STILL an opcode
462 2012-01-13 19:05:34 <roconnor> luke-jr: I hope your campagin against P2SH is successful
463 2012-01-13 19:06:18 <roconnor> as before, it probably comes down to what [Tycho] decides
464 2012-01-13 19:06:34 <luke-jr> roconnor: I hope I didn't come off too hard against static analysis.
465 2012-01-13 19:06:59 <roconnor> I have no hard feelings against anyone
466 2012-01-13 19:07:12 <UukGoblin> is static analysis this "security principle of validate input first and then interpret it."?
467 2012-01-13 19:07:49 <roconnor> UukGoblin: more or less.  I sort of rephrased it that way after watching Meredith's talk
468 2012-01-13 19:07:54 <luke-jr> UukGoblin: yes, static analysis is being able to look at it and say "this break the rule of too complex" before running it
469 2012-01-13 19:08:07 <luke-jr> though I disagree with it being security-related.
470 2012-01-13 19:08:27 <UukGoblin> k
471 2012-01-13 19:08:28 <UukGoblin> damn
472 2012-01-13 19:08:29 <luke-jr> it's an optimization, that doesn't *practically* help in this case AFAICT
473 2012-01-13 19:08:34 <UukGoblin> I can't vote until I learn how Script works
474 2012-01-13 19:08:38 <luke-jr> >_<
475 2012-01-13 19:08:43 <roconnor> well, maybe I have a bit of hard feelings towards ByteCoin, but I'll get over it
476 2012-01-13 19:08:47 <luke-jr> lol
477 2012-01-13 19:08:53 <luke-jr> what did he do?
478 2012-01-13 19:09:04 <roconnor> I think he gave me the hardest time :D
479 2012-01-13 19:09:14 <UukGoblin> and I can't learn how script works before voting starts... so... I should vote no to postpone :->
480 2012-01-13 19:09:46 <roconnor> UukGoblin: I think that is reasonable IMHO.
481 2012-01-13 19:10:06 <roconnor> UukGoblin: I really think this proposoal is being pushed too fast (in addition to being a bad proposal)
482 2012-01-13 19:10:36 <roconnor> I'd like to think I'd think it is being pushed too fast even if I thought it was a good proposal.
483 2012-01-13 19:14:19 <luke-jr> I wish /P2SH/ wasn't so difficult to back out of master -.-
484 2012-01-13 19:16:16 <UukGoblin> "REPLACE" op_eval with P2SH? :-O
485 2012-01-13 19:16:20 <UukGoblin> so op_eval is there already?!
486 2012-01-13 19:20:28 <UukGoblin> luke-jr, won't you break getinfo for people who rely on it?
487 2012-01-13 19:20:44 <gmaxwell> I've posted a long post on the subject: https://bitcointalk.org/index.php?topic=58579.msg690093#msg690093
488 2012-01-13 19:20:45 <UukGoblin> (with the getmininginfo branch?)
489 2012-01-13 19:21:20 <gmaxwell> luke-jr: If I've said anything there you believe is counterfactual, please yell at me and I'll fix it.
490 2012-01-13 19:23:01 <UukGoblin> rotfl @ Nachtwind
491 2012-01-13 19:23:19 <UukGoblin> gtfo from the technical thread
492 2012-01-13 19:23:41 <UukGoblin> "I don't like your technical comments because I think you're a bad person"
493 2012-01-13 19:23:44 <luke-jr> UukGoblin: ?
494 2012-01-13 19:23:58 <luke-jr> UukGoblin: it only removes 3 things from getinfo, but yes
495 2012-01-13 19:24:09 <luke-jr> UukGoblin: I originally just deprecated them in getinfo, but jgarzik said to remove them entirely
496 2012-01-13 19:24:18 <UukGoblin> ah.
497 2012-01-13 19:24:28 <UukGoblin> well, I don't use it I think ;-)
498 2012-01-13 19:24:46 <luke-jr> gmaxwell: OK, I'm yelling at yoou
499 2012-01-13 19:25:06 <luke-jr> gmaxwell: I've tried to raise these problems before, multiple times, and gavin is content with ignoring them.
500 2012-01-13 19:25:12 <luke-jr> so implying I haven't is wrong
501 2012-01-13 19:25:24 <makomk> UukGoblin: there's a fundamental issue with both P2SH and OP_EVAL where if you can take out enough of the mining nodes that validate it you can attack Bitcoin is some interesting ways. I expect Luke's proposal is the same.
502 2012-01-13 19:25:56 <makomk> I reported at least one security vulnerability that could do this, which I regret doing now.
503 2012-01-13 19:26:22 <makomk> The only time Bitcoin should find out about security holes is when someone exploit s them.
504 2012-01-13 19:26:25 <gmaxwell> makomk: well, you failed to manage to exploit it.
505 2012-01-13 19:26:37 <makomk> gmaxwell: I didn't try.
506 2012-01-13 19:26:38 <gmaxwell> Or at least someone failed.
507 2012-01-13 19:26:55 <theymos> What security problem was that?
508 2012-01-13 19:27:04 <gmaxwell> (because they didn't meet the eligius fee rules)
509 2012-01-13 19:27:20 <makomk> gmaxwell: intentionally so.,
510 2012-01-13 19:27:38 <gmaxwell> makomk: I'd, perhaps unfairly, assumed it was you that failed to exploit it because you only bothered to disclose the issue long after you were shipping code that didn't have it.
511 2012-01-13 19:27:50 <makomk> I seem to recall he blocks payments with lots of duplicate outputs, amoonst other thins?
512 2012-01-13 19:28:09 <UukGoblin> makomk, I definitely can't agree to that
513 2012-01-13 19:28:17 <makomk> gmaxwell: I didn't get around to figuring out whether it was actually an issue until shipping fixed code.
514 2012-01-13 19:28:30 <gmaxwell> theymos: difference in validation code between block validation and mining inclusion decision.
515 2012-01-13 19:28:54 <gmaxwell> makomk: Okay, fair enough. I apologize for thinking evil of you then!
516 2012-01-13 19:29:10 <theymos> gmaxwell: Ah, thanks.
517 2012-01-13 19:29:17 <makomk> Was changing the transaction validation rules anyway for an unrelated reason. The "fix" I'd used wasn't suitable for Bitcoin.
518 2012-01-13 19:29:39 <roconnor> gmaxwell: that's a nice post
519 2012-01-13 19:29:51 <roconnor> gmaxwell: you were very kind to me :)
520 2012-01-13 19:33:15 <makomk> The only version of my demo exploit I created refuses to run except on testnet. Would be easy to edit out the check... except I was fairly sure it would fail Eligius' criteria for inclusion even if they did and had concluded no-one else really used OP_EVAL. This was undocumented for obvious reasons ;-)
521 2012-01-13 19:34:45 <UukGoblin> 201620 <@UukGoblin> so op_eval is there already?!
522 2012-01-13 19:35:31 <gmaxwell> UukGoblin: no. I mean, the code exists of course.
523 2012-01-13 19:36:13 <UukGoblin> gmaxwell, but was it on master? before 922e82?
524 2012-01-13 19:36:20 <UukGoblin> gah
525 2012-01-13 19:36:21 <UukGoblin> 922e8e
526 2012-01-13 19:36:31 <gmaxwell> It's been in master but never in released code.
527 2012-01-13 19:36:43 <UukGoblin> oh!
528 2012-01-13 19:36:48 <gmaxwell> I'm not looking at the checkout right now so I have no idea where 922e82 is.
529 2012-01-13 19:37:09 <UukGoblin> 922e8e is "Replace OP_EVAL (BIP 12) with Pay-to-script-hash (BIP 16).
530 2012-01-13 19:37:21 <gmaxwell> ah, well thats why it's a replace.
531 2012-01-13 19:38:06 <gmaxwell> also, "op_eval is there" depends on what you mean by is there. The code in master validated OP_EVAL but wouldn't add any of it to the blockchain.
532 2012-01-13 19:38:28 <UukGoblin> right, ok
533 2012-01-13 19:38:46 <UukGoblin> I perhaps shouldn't be running master so carelessly ;-)
534 2012-01-13 19:40:13 <makomk> I thought it validated it, added transactions that used it, and would allow you to make transactions to OP_EVAL addresses, it was just creating them that was disabled.
535 2012-01-13 19:41:52 <gmaxwell> makomk: no the added transaction part was date-gated.
536 2012-01-13 19:42:19 <gmaxwell> (Unless I missed somethign shocking!)
537 2012-01-13 19:42:30 <makomk> Hmmmm. I thought the only date-checked part was fully validating OP_EVAL transactions that were already in a block.
538 2012-01-13 20:05:27 <midnightmagic> there are weekly development meetings? where are these held?
539 2012-01-13 20:09:19 <gmaxwell> midnightmagic: here, on tuesdays. 21:00 utc.
540 2012-01-13 20:09:34 <gmaxwell> midnightmagic: here is the report from the last: https://en.bitcoin.it/wiki//10_Jan_2012
541 2012-01-13 20:09:39 <pusle> how about a competition! Unleash the proposals on the testnet and have prizes to those who can find exploits/hacks  ^-^
542 2012-01-13 20:09:51 <pusle> "Last code standing"
543 2012-01-13 20:09:55 <midnightmagic> damn, it is regular. I should really be attending. :(
544 2012-01-13 20:10:03 <gmaxwell> pusle: they've been in use on testnet.
545 2012-01-13 20:10:20 <gmaxwell> pusle: unfortunately, it's not the attacks you find that matter, it's the ones you miss. :(
546 2012-01-13 20:10:24 <pusle> okay, who won? :D
547 2012-01-13 20:10:55 <pusle> well if it sucks so bad, it should be easy to attack it
548 2012-01-13 20:11:36 <gmaxwell> pusle: I think we're up to four critcial problems discovered in OP_EVAL after everyone though it was done and reviewed.
549 2012-01-13 20:11:44 <pusle> and perhaps look at chain bloat, ease of use (in practise) as factors to decide a winner if none have security problems
550 2012-01-13 20:12:28 <gmaxwell> pusle: The use is identical. The implementation of P2SH is clearly much simpler (OP_EVAL needs a buch of code to prevent it from being horribly insecure)
551 2012-01-13 20:12:29 <pusle> I was thinking about the two proposed alternatives
552 2012-01-13 20:13:09 <pusle> even I understand a turing complete script system is a bad idea
553 2012-01-13 20:13:23 <gmaxwell> pusle: well, I'm glad you do go convince luke. :)
554 2012-01-13 20:13:23 <pusle> CODEHASHCHECK vs P2SH
555 2012-01-13 20:13:31 <pusle> are there more alternatives?
556 2012-01-13 20:14:12 <makomk> The question is, what vulnerabilities did OP_EVAL have that P2SH is fundamentally immune to? They have quite a bit in common...
557 2012-01-13 20:14:19 <pusle> Seems to me Luke too sees that OP_EVAL needs to be replaced, but with what
558 2012-01-13 20:14:46 <gmaxwell> pusle: CODEHASHCHECK is not an alternative which can be compared to P2SH right now, really.
559 2012-01-13 20:14:47 <pusle> it sucks that I don't have the skills to get into this properly :/
560 2012-01-13 20:14:51 <gmaxwell> because no code for it exists.
561 2012-01-13 20:15:11 <gmaxwell> makomk: ... er, P2SH doesn't have recursion.
562 2012-01-13 20:15:24 <gmaxwell> makomk: so the limits bugs don't apply.
563 2012-01-13 20:15:32 <pusle> luke camp should make one then, or demonstrate in practise why p2sh is a disaster
564 2012-01-13 20:15:38 <gmaxwell> And thats a fundimental immunity.
565 2012-01-13 20:15:41 <roconnor> P2SH has less "shootgun" validation code
566 2012-01-13 20:16:03 <makomk> That turned out to be an irritating bug but not actually a vulnerability of any kind, as I recall.
567 2012-01-13 20:16:06 <gmaxwell> And right, the reducntion in validation code is fundimental too, and it's differences in validation code that gave rise to the issue you found makomk.
568 2012-01-13 20:16:20 <helo> p2sh isn't a disaster, it's just ugly and inelegant afaik
569 2012-01-13 20:16:22 <pusle> less bloat and pruning seems like benefits to me
570 2012-01-13 20:16:47 <gmaxwell> makomk: No, IIRC it only wasn't a vulnerability in bitcoind simply because we run with ginormous stacks. (so it ran out of instructions before running out of stack space)
571 2012-01-13 20:17:18 <gmaxwell> But that says nothing about what it might have been in bitcoind a year from now, or another implementation which had to be bug compatible and thus omit the recursion check.
572 2012-01-13 20:17:42 <gmaxwell> Morover, it completely invalidated our belief that "the turing completeness is okay because its constrained by the limited recursion"
573 2012-01-13 20:18:21 <pusle> so you can't contain it by simply saying "the stack can max be 16kbyte" or something
574 2012-01-13 20:18:25 <pusle> if overflow = terminate
575 2012-01-13 20:18:26 <makomk> Also, P2SH would've had the exact same differences in validation flaw with mining if Gavin hadn't fixed it; that was in common code between the two.
576 2012-01-13 20:19:28 <gmaxwell> makomk: That one, perhaps, but differences in the validation code (within an implementation or between implementations) could exist at any one of the validation checks, so having fewer of them is a clear advantage
577 2012-01-13 20:19:47 <helo> stackless recursion?
578 2012-01-13 20:20:28 <gmaxwell> pusle: you can't really do things like that because all implementations have to behave exactly the same or you get forks. So it's very important that it be easy to impose exactly the same rules everywhere, and those rules shouldn't depend on the details of the implementation.
579 2012-01-13 20:20:48 <gmaxwell> Some implementor should be able to JIT compile script into x86_64 code and still behave exactly as the interperter does.
580 2012-01-13 20:21:16 <pusle> well, I'm not sure if it would close all "holes" but it would be up to the script maker to see too there wasn't an overflow = invalid script
581 2012-01-13 20:21:23 <pusle> to
582 2012-01-13 20:21:40 <pusle> I see your point
583 2012-01-13 20:21:49 <gmaxwell> whew I didn't want to try to explain that again.
584 2012-01-13 20:21:59 <pusle> so, anyone smarter than me who can make something elegant everybody is happy with ? :)
585 2012-01-13 20:22:10 <gmaxwell> We thought we had that.
586 2012-01-13 20:22:20 <pusle> :&
587 2012-01-13 20:22:22 <gmaxwell> At least for a period of a few hours we did!
588 2012-01-13 20:22:26 <pusle> hehe
589 2012-01-13 20:22:45 <pusle> "<helo> p2sh isn't a disaster, it's just ugly and inelegant afaik"
590 2012-01-13 20:22:54 <pusle> so there are at least two who are not 100% happy
591 2012-01-13 20:23:04 <gmaxwell> helo is parroting luke.
592 2012-01-13 20:23:17 <gmaxwell> (thus the AFAIK)
593 2012-01-13 20:23:40 <pusle> ah, he is to Luke-jr as Baldrik is to Black Adder? :P
594 2012-01-13 20:23:41 <gmaxwell> piuk seemed to argue that position on the forum though, so I'll grant you two.
595 2012-01-13 20:23:55 <UukGoblin> tcatm, looks like I wasn't actually better off sending piuk an email. He still hasn't replied to it, yet he's been active on other threads on the forums.
596 2012-01-13 20:26:04 <gmaxwell> pusle: During a prior discussion it was suggested that simply sticking and OP_MAKEITSO  on the end of the P2SH scripts 'fixed' the inelegance luke-jr and piuk are complaining about.
597 2012-01-13 20:26:45 <gmaxwell> It makes it 'elegant' though it doesn't actually change anything objectively measurable except that it also makes the outputs one byte larger.
598 2012-01-13 20:27:23 <pusle> if one byte is all he needs to be happy then...
599 2012-01-13 20:27:25 <gmaxwell> I'd kind of suggested that we do that just to shut up luke-jr, but gavin indicated that he didn't like the idea of bloating every transaction by a byte just to make one person happy.
600 2012-01-13 20:27:27 <pusle> :)
601 2012-01-13 20:27:34 <pusle> hehe
602 2012-01-13 20:27:44 <UukGoblin> well, wouldn't it (MAKEITSO, as well as CHC I think) require the senders of the transaction to know about it?
603 2012-01-13 20:27:49 <gmaxwell> pusle: but it's not just a byte, its one byte in every output script forever. so it's not like its that easy.
604 2012-01-13 20:28:11 <gmaxwell> UukGoblin: the senders would need to have the behavior sure but that would be programmed in.
605 2012-01-13 20:28:20 <pusle> I still can't quite follow his complaints
606 2012-01-13 20:28:42 <pusle> he says it breaks standard transactions
607 2012-01-13 20:28:46 <gmaxwell> I follow them, but I think they're stupid. Someone who thinks they are not stupid should explain them rather than me.
608 2012-01-13 20:28:54 <pusle> because you always must evaluate a script , and that's new
609 2012-01-13 20:28:56 <pusle> ?
610 2012-01-13 20:28:58 <gmaxwell> pusle: no, it breaks the standard 'form'.
611 2012-01-13 20:29:18 <UukGoblin> regarding a byte, couldn't it replace OP_EQUALVERIFY and/or OP_CHECKSIG?
612 2012-01-13 20:29:36 <gmaxwell> UukGoblin: no because we need to be backwards compatible with existing nodes.
613 2012-01-13 20:29:45 <UukGoblin> i.e. <scriptHas> OP_CHECKSCRIPTHASH
614 2012-01-13 20:29:47 <UukGoblin> ah...
615 2012-01-13 20:29:56 <UukGoblin> but it seems to me we aren't
616 2012-01-13 20:30:14 <UukGoblin> we're compatible with just some of them
617 2012-01-13 20:30:25 <gmaxwell> UukGoblin: though you could choose to interpert P2SH as replacing OP_EQUAL with OP_MAKEITSO_OR_EQUAL that happens to have the same encoding as OP_EQUAL if that helps you sleep. :)
618 2012-01-13 20:30:29 <UukGoblin> by the same token I believe we're compatible with 0.3.9
619 2012-01-13 20:30:50 <gmaxwell> UukGoblin: ... no. You don't understand it, bleh. but I'm not sure where your understanding is falling down.
620 2012-01-13 20:31:09 <UukGoblin> that is correct, I admit, I don't fully understand all this.
621 2012-01-13 20:31:49 <gmaxwell> UukGoblin: it basically looks like a specially constructed hashed locked transaction to older nodes and passes fine. (though it only validates the scripthash not the script itself)
622 2012-01-13 20:31:55 <pusle> neither do I, but I do care...
623 2012-01-13 20:32:05 <UukGoblin> we need the majority of hashpower to upgrade, right?
624 2012-01-13 20:32:50 <gmaxwell> UukGoblin: no, we need a majority of hash power for P2SH transactions to be safe, and/or for people who are mining P2SH to not be at risk of being on a smaller end of a fork should a non-p2sh node mine an invalid p2sh transaction.
625 2012-01-13 20:33:08 <gmaxwell> (perhaps you wouldn't consider that a disagreement? the details are important)
626 2012-01-13 20:34:01 <pusle> and this can happen, because P2SH is a subset of previous hashing script "possibilities"
627 2012-01-13 20:34:02 <pusle> ?
628 2012-01-13 20:34:07 <gmaxwell> P2SH takes transactions that previously all nodes would accept and rejects some of them (ones where the p2sh provided script fails to validate), but doesn't make anything that failed before pass.
629 2012-01-13 20:34:12 <gmaxwell> pusle: ^ exactly.
630 2012-01-13 20:34:20 <UukGoblin> gmaxwell, I thought that old mining nodes would create stale blocks because they'd be accepting invalid P2SH transactions
631 2012-01-13 20:34:54 <luke-jr> gmaxwell: just special-casing it with an OP_NOP1 is no better.
632 2012-01-13 20:34:59 <UukGoblin> just like 0.3.9 would create stale blocks because it'd be accepting invalid overflowed integer transactions
633 2012-01-13 20:35:01 <gmaxwell> UukGoblin: oh, thats what you mean by pre 0.3.9.
634 2012-01-13 20:35:17 <gmaxwell> UukGoblin: yes, they'd be at risk of that, though they're already exposed as you point out.
635 2012-01-13 20:35:18 <luke-jr> UukGoblin: all solutions require the senders to know they're sending to a scripthash
636 2012-01-13 20:35:41 <pusle> couldn't you enforce the new rules for a while before actually start to use P2SH
637 2012-01-13 20:36:04 <UukGoblin> luke-jr, ok, I thought P2SH didn't, but that doesn't matter much, actually
638 2012-01-13 20:36:11 <gmaxwell> pusle: sure, I expect people won't use p2sh for some time.. it'll take a while for support of the new addresses to get deployed.
639 2012-01-13 20:36:21 <luke-jr> pusle: that's why people are trying to rush it
640 2012-01-13 20:36:31 <pusle> makes sense
641 2012-01-13 20:36:40 <gmaxwell> pusle: but when you start enforcing you create the fork risk, which is why you need a majority to start enforcing.
642 2012-01-13 20:37:02 <UukGoblin> gmaxwell, I'd definitely prefer for people to first be ready from their end (i.e. merchants, points of sale, exchanges, etc) before the whole change goes live
643 2012-01-13 20:37:03 <gmaxwell> (Otherwise the enforcers may be on the minority of a fork created due to a troublemaker mining an invalid p2sh)
644 2012-01-13 20:37:08 <pusle> but fork would only happen if somebody tried to use script which are now "banned" ?
645 2012-01-13 20:37:09 <UukGoblin> one month is nowhere near enough
646 2012-01-13 20:37:16 <gmaxwell> UukGoblin: You have it backwards, I think.
647 2012-01-13 20:37:35 <gmaxwell> UukGoblin: it must be firmly established in the chain before all those people can deploy it.
648 2012-01-13 20:37:36 <pusle> ok
649 2012-01-13 20:37:49 <luke-jr> I don't have time for this discussion right now, sorry. Keep chatting if you want, but don't complain later that I wasn't here for it ;)
650 2012-01-13 20:38:17 <gmaxwell> UukGoblin: Esp since p2sh transactions won't be fully secure until its clear that there is a perpetual majority of mining power enforcing the rules.
651 2012-01-13 20:38:32 <pusle> well Luke, you kinda have to articulate how P2SH can be changed to not suck. Just saying "Kill it" won't cut it
652 2012-01-13 20:39:00 <pusle> in the forums is better than here
653 2012-01-13 20:39:04 <gmaxwell> UukGoblin: (going back to what you said before) no, with p2sh the sender has to know they are sending a p2sh transaction. They'll know this via the use of a '3' address type.
654 2012-01-13 20:39:20 <gmaxwell> And the body of the address will provide the hash of the script that they're paying to.
655 2012-01-13 20:39:28 <gmaxwell> Same way '1' types work, but with a different transaction template.
656 2012-01-13 20:40:09 <UukGoblin> wait... won't that make older nodes unable to validate the transaction?
657 2012-01-13 20:40:17 <gmaxwell> Nope.
658 2012-01-13 20:40:56 <UukGoblin> "pay 5 BTC to a 3-address" "ok here's me with my privkey for 3-address, I'm redeeming my 5 BTC" "hey but I'm an old node, wtf is a 3-address?"
659 2012-01-13 20:41:10 <gmaxwell> UukGoblin: ah ha! thats not what a transaction looks like.
660 2012-01-13 20:41:18 <gmaxwell> the the address version never shows up in the chain at all.
661 2012-01-13 20:41:36 <gmaxwell> No transaction says "pay 5 BTC to a 1-address"
662 2012-01-13 20:42:23 <UukGoblin> oh, damn blockexplorer for making it look so :-P
663 2012-01-13 20:43:31 <gmaxwell> instead they say something like
664 2012-01-13 20:44:50 <gmaxwell> "Take the top element of the stack (provided by the spending txn), duplicate it, hash it (pops it, pushes the hash), check that the hash is equal to <data I pulled from the address> (pops the hash), check that the signature of the spending txn validates with the public key on the stack"
665 2012-01-13 20:45:07 <gmaxwell> it's a little program in the script language.
666 2012-01-13 20:45:32 <UukGoblin> and regarding the implementation direction... have everyone who wants to use p2sh (mtgox, points of sale, etc) implement it so that "IF block number is > x AND n blocks below x have /P2SH/ in coinbase THEN we work with P2SH"
667 2012-01-13 20:46:14 <UukGoblin> (at least n blocks)
668 2012-01-13 20:46:26 <gmaxwell> I don't think it's being recommended right now that users check for the proof themselves, but the P2SH flag was intended to make that possible.
669 2012-01-13 20:46:50 <UukGoblin> yeah, just way too early imho, gavin proposed 15 feb 2012!
670 2012-01-13 20:47:16 <gmaxwell> 15 feb 2012 isn't for mtgox though, it's for mining nodes to start enforcing the rules.
671 2012-01-13 20:47:45 <gmaxwell> p2sh doesn't mean you're enforcing the rules it means that you're aware of them and willing to start enforcing them after that date.
672 2012-01-13 20:47:50 <UukGoblin> ok, yeah, I was aware of the script stuff going on. My point was more about the spending transaction. I thought spending P2SH required something special that old nodes couldn't understand?
673 2012-01-13 20:48:31 <gmaxwell> To send to or spend from P2SH requires software that understands P2SH. To permit P2SH in the chain works for everyone.
674 2012-01-13 20:49:28 <gmaxwell> E.g. the software needs to know how to write P2SH style scripts in response to '3' addresses to send to.  And to spend from you need to reconize p2sh style transactions as yours in the chain and know how to write the scripts that spend from them
675 2012-01-13 20:49:31 <UukGoblin> ok everyone would permit P2SH in the chain, but think they're some dummy transactions that will never be spent
676 2012-01-13 20:49:47 <UukGoblin> by "everyone" I mean the everyone from "works for everyone"
677 2012-01-13 20:50:03 <gmaxwell> UukGoblin: think they're some dummy transactions that anyone who knows X where H(X)=Y for some Y (the address).
678 2012-01-13 20:50:17 <gmaxwell> e.g. old nodes think that they are purely hash locked transactions.
679 2012-01-13 20:50:27 <UukGoblin> yes
680 2012-01-13 20:50:41 <gmaxwell> New nodes know about the implicit validation of the script contained in X.
681 2012-01-13 20:51:17 <gmaxwell> Luke's complaint (I think) is mostly that that validation is implicit. (though he's blowing up my understanding by saying merely adding an opcode wouldn't make him happy, so now I'm confused again)
682 2012-01-13 20:51:56 <gmaxwell> We could make it explicit, e.g. OP_MAKEITSO by wasting a byte in the output of every P2SH transaction forever.
683 2012-01-13 20:52:29 <gmaxwell> Probably two bytes, actually an OP_DUP, otherwise the stack would be empty when it got to makeitso, plus an OP_MAKEITSO
684 2012-01-13 20:52:47 <UukGoblin> so, let me rephrase again, with Alice, who has 0.3.20, and Bob, who has 0.6.0 with p2sh, as well as 10 BTC on Bob's account which were paid to Bob's 3-address. Could Alice's node accept payment from Bob?
685 2012-01-13 20:52:57 <UukGoblin> and show it on Alice's balance?
686 2012-01-13 20:53:25 <gmaxwell> oh. sure. Absolutely. Bob willpay to Alice's 1-address and this will work fine.
687 2012-01-13 20:53:57 <gmaxwell> Alice will see a txn that has input: some hashlocked crap that validates, output: a regular payment to alice.
688 2012-01-13 20:54:19 <UukGoblin> would the hashlocked crap validate? :-O
689 2012-01-13 20:54:29 <gmaxwell> Sure.
690 2012-01-13 20:54:49 <UukGoblin> let me see...
691 2012-01-13 20:55:18 <gmaxwell> Bob pushed some stuff (the real input script) onto the stack, then HASH_160 OP_EQUAL.  Alice stops there, and it's all good.
692 2012-01-13 20:55:44 <gmaxwell> A p2sh validation node would do all that but go further and execute the 'stuff' and only consider the txn good if Bob's txn obeyed the stuff _too_.
693 2012-01-13 20:57:37 <gmaxwell> Of course, alice couldn't pay bob back unless bob has a 1-address she can use. And bob couldn't pay alice using p2sh. (duh, she hasn't given him a 3-address)
694 2012-01-13 20:58:06 <pusle> Luke is proposing to make the P2SH a new "class" of script, in order to not break the old OP_EVAL ?
695 2012-01-13 20:58:33 <gmaxwell> pusle: what do you mean by "the old OP_EVAL"?
696 2012-01-13 20:58:47 <gmaxwell> Are you also laboring under the impression that OP_EVAL was originally part of bitcoin?
697 2012-01-13 20:58:50 <pusle> maybe I don't understand
698 2012-01-13 20:58:50 <UukGoblin> gmaxwell, right, I'm perhaps missing this thing: What does ScriptSig actually sign?
699 2012-01-13 20:59:11 <UukGoblin> it should... sign... the script... right? ;-)
700 2012-01-13 20:59:23 <pusle> no, but it seems like Luke thinks OP_EVAL will be broken
701 2012-01-13 20:59:26 <pusle> coz you limit the rules
702 2012-01-13 20:59:27 <pusle> right?
703 2012-01-13 20:59:39 <pusle> so he wants a separate system, with narrower rules
704 2012-01-13 20:59:42 <pusle> so they are both valid
705 2012-01-13 20:59:52 <pusle> and then perhaps as time goes by, miners will drop support for OP_EVAL
706 2012-01-13 20:59:59 <gmaxwell> ha, no. It's the signature provided by the script. :)  The signatures cover all the output side of transaction with the other inputs masked out.
707 2012-01-13 21:00:00 <pusle> and only have "new script", ie P2SH
708 2012-01-13 21:00:26 <gmaxwell> pusle: No, you don't understand. OP_EVAL doesn't exist yet either.
709 2012-01-13 21:00:49 <pusle> so what is it that Lukes pool supports today, that will not be supported with this P2SH upgrade?
710 2012-01-13 21:00:57 <pusle> there must be something he wanna keep?
711 2012-01-13 21:00:59 <gmaxwell> We originally proposed OP_EVAL as a new feature to solve a need, then people complained OP_EVAL was too dangerous, so we changed to P2SH.
712 2012-01-13 21:01:24 <pusle> uhm
713 2012-01-13 21:01:32 <gmaxwell> pusle: Luke's pool is running the older OP_EVAL code a patch that gavin backported for him.
714 2012-01-13 21:01:39 <UukGoblin> gmaxwell, well OK let's put that aside for a sec, I'll try to come back to it later...
715 2012-01-13 21:01:45 <pusle> and he likes it so much he wanna keep that?
716 2012-01-13 21:01:51 <gmaxwell> but none of this code has ever been in a release of the bitcoin software.
717 2012-01-13 21:01:53 <UukGoblin> old nodes won't be able to mine successfully if the change goes live <- correct?
718 2012-01-13 21:01:57 <pusle> mkay
719 2012-01-13 21:02:01 <UukGoblin> ah, perhaps no
720 2012-01-13 21:02:11 <gmaxwell> UukGoblin: They're fine so long as they enforce IsStandard or something like it.
721 2012-01-13 21:02:14 <UukGoblin> cause they won't accept non-standard
722 2012-01-13 21:02:19 <gmaxwell> Bingo.
723 2012-01-13 21:03:13 <gmaxwell> If they accept non-standard _and_ if some jackass produces a P2SH script that doesn't actually validate in the P2SH-interior part, and they mine that, then that block will get orphaned.
724 2012-01-13 21:03:43 <gmaxwell> Though objective testing indicates that ~no one is accepting non-standard TXN except luke.
725 2012-01-13 21:04:14 <pusle> so then Luke kinda have to get all the other miners to wanna have OP_EVAL too?
726 2012-01-13 21:04:34 <pusle> if there is to be any point
727 2012-01-13 21:04:35 <gmaxwell> pusle: if OP_EVAL is to be useful for anyone, as well as the software authors.
728 2012-01-13 21:04:50 <gmaxwell> and none of the software authors like it, I believe.
729 2012-01-13 21:04:50 <pusle> mhm
730 2012-01-13 21:05:11 <UukGoblin> gmaxwell, cool, thanks for all the help, and the useful post, too :-)
731 2012-01-13 21:05:35 <gmaxwell> (by software authors I mean the authors of other client softare)
732 2012-01-13 21:05:38 <UukGoblin> I'll get some rest, I'll try to understand more of it tomorrow :-)
733 2012-01-13 21:05:46 <gmaxwell> (I wasn't intending to suggest that luke isn't a software author. :) )
734 2012-01-13 21:06:09 <pusle> I think you have to make this clear to the miners in the " Bitcoin BIP 16 /P2SH/ is bad, your action is needed!" thread
735 2012-01-13 21:06:24 <pusle> all of this is something new
736 2012-01-13 21:07:20 <gmaxwell> I'm saddened by the people who won't even bother to read my post there.
737 2012-01-13 21:07:22 <pusle> any of the suggestions adds functionality, question is how it's done and how much functionality
738 2012-01-13 21:07:33 <gmaxwell> I know it was long winded, but hell I actually avoided the technical details.
739 2012-01-13 21:07:52 <pusle> you have to dumb it down for us others :)
740 2012-01-13 21:08:15 <gmaxwell> I did dumb it down, my post was long not complicated.
741 2012-01-13 21:08:29 <pusle> abstracted then
742 2012-01-13 21:08:46 <pusle> for a long time now, I thought this is a replacement to something that exists
743 2012-01-13 21:08:50 <gmaxwell> and I'm currently resisting the urge to respond to Holliday, where he says "I think there are other, better ways to go about "fixing" that issue. "
744 2012-01-13 21:08:51 <pusle> but that's only true for blocks from Luke's pool
745 2012-01-13 21:09:00 <forrestv> gmaxwell, you should have included a TOC and headings :P
746 2012-01-13 21:09:02 <pusle> hehe
747 2012-01-13 21:09:25 <gmaxwell> with something like "You won't even bother to read what people are saying about the subject enough to know what the subject is, and you expect anyone to give a fuck what you think?"
748 2012-01-13 21:09:27 <UukGoblin> lol
749 2012-01-13 21:09:37 <pusle> perhaps not ;)
750 2012-01-13 21:09:52 <gmaxwell> pusle: it doesn't even exist from luke's pool either.
751 2012-01-13 21:09:54 <pusle> people are people, don't let that bring you down
752 2012-01-13 21:10:05 <gmaxwell> pusle: the function doesn't enable itself until mid feburary in the code he was running.
753 2012-01-13 21:10:16 <pusle> nobody gets the credit they deserve while they are alive :D
754 2012-01-13 21:10:18 <gmaxwell> and he actually turned it off because of the vulnerability makomk found.
755 2012-01-13 21:10:28 <pusle> hmpf
756 2012-01-13 21:10:31 <UukGoblin> gmaxwell, I believe if all that you said was correct, this would be also correct?: And no-one other than Bob could send Alice a transaction that'd spend Bob's coins originating from a 3-address?
757 2012-01-13 21:10:46 <gmaxwell> UukGoblin: kinda!
758 2012-01-13 21:11:36 <UukGoblin> kinda?
759 2012-01-13 21:11:42 <gmaxwell> UukGoblin: If bob had used that address before, then I would know the script related to that address. I could send a txn to alice that alice would accept as valid.  But it would not get mined by the P2SH enforcing miners, because I couldn't makethe P2SH internal part valid (I don't have his private keys)
760 2012-01-13 21:12:06 <gmaxwell> If bob had not spent from the address before I couldn't even trick alice with a zero confirm txn.
761 2012-01-13 21:12:31 <gmaxwell> In either case, so long as p2sh miners have a majority of the mining power, the transaction will not confirm/stay confirmed for alice.
762 2012-01-13 21:12:34 <UukGoblin> don't you have to spend ALL inputs from an address when you make a txn?
763 2012-01-13 21:12:45 <UukGoblin> ah, no, just all money from an input
764 2012-01-13 21:12:55 <gmaxwell> UukGoblin: No. You have to spend all of an input. But you only use inputs as you need them.
765 2012-01-13 21:12:58 <gmaxwell> right.
766 2012-01-13 21:13:23 <gmaxwell> so bob can increase his security in the face of uncertanty about p2sh mining power by using addresses only once.
767 2012-01-13 21:13:38 <gmaxwell> but he doesn't have to so long as p2sh has a majority going forward.
768 2012-01-13 21:14:15 <gmaxwell> (an I think your extrapolation there shows you understand it)
769 2012-01-13 21:15:18 <UukGoblin> (nah, I extrapolated from what you said, and I assumed it was correct; I don't yet fully understand WHY what you said was correct)
770 2012-01-13 21:15:31 <UukGoblin> (I'll try to get there tomorrow I think)
771 2012-01-13 21:17:08 <UukGoblin> well, to be precise, I don't get why Alice can validate Bob's input if she doesn't know how Bob got the money in the first place
772 2012-01-13 21:18:40 <UukGoblin> but that's probably hidden somewhere in that script magic
773 2012-01-13 21:22:32 <the_batman> is there data on the size, demographic, psychographic, and behavioral breakdown of the bitcoin community?
774 2012-01-13 21:23:04 <helo> fat, white, bipolar, never exercise
775 2012-01-13 21:23:13 <pusle> hehe, behavioral?
776 2012-01-13 21:23:15 <midnightmagic> psychographic?
777 2012-01-13 21:23:16 <the_batman> I'm trying to prepare a business plan and spell out the value for my customer
778 2012-01-13 21:23:17 <pusle> star trek freak
779 2012-01-13 21:23:20 <the_batman> I need numbers :\n2623752
780 2012-01-13 21:23:32 <helo> the_batman: bitcoin people are generally technically-minded people
781 2012-01-13 21:23:53 <the_batman> is there data somewhere?
782 2012-01-13 21:24:03 <helo> no
783 2012-01-13 21:24:11 <midnightmagic> are you requesting data from us so you can make money, without telling us anything about what you're doing?
784 2012-01-13 21:24:22 <the_batman> yep
785 2012-01-13 21:24:32 <the_batman> I thought you'd sympathize, as this is bitcoin-dev
786 2012-01-13 21:24:44 <midnightmagic> the software, protocol, methods, mining software, and operation are all open-source.
787 2012-01-13 21:24:53 <midnightmagic> bitcoin is a democratization of the money system.
788 2012-01-13 21:25:17 <midnightmagic> I respect you have a business idea.
789 2012-01-13 21:25:55 <midnightmagic> I wish you the best in implementation. :)