User:Genjix/Meetings/3 Jan 2012

Agenda:

• OP_EVAL

Log:

20:55 < genjix> we still has 10 mins
20:55 < luke-jr> or better still, 7 Anuary 
20:55 < genjix> BlueMatt: good idea
20:55 <@gribble> New news from bitcoinrss: gavinandresen opened pull request 743 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/743>
20:55 < sipa> what's wrong with you people? just use 0x4D2238D0
20:55 < gavinandresen> There's an RFC for dates... I think 3 Jan 2012  adheres to the standard
20:56 < luke-jr> 2012-01-03 does too
20:56 < genjix> hoooo lol i put 2011
20:56 < sipa> the first days of the next year actually belong to the previous one
20:56 < sipa> everybody knows that
20:57 < gavinandresen> I like eleven, but I don' t think I'll get away with dating my checks  34 Dec 2011
20:57 < luke-jr> :P
20:58 < genjix> so i guess there is no new OP_EVAL now
20:59 < genjix> instead there's a new script template which will be evaluated implicitly
20:59 < sipa> the magic hash script
20:59 < jrmithdobbs> gavinandresen: that rfc basically makes every known human date format "valid" and is a bitch
21:00 -!- diki [diki@46.40.126.253] has quit [Ping timeout: 276 seconds]
21:00 < sipa> fine; meating time?
21:00  * BlueMatt still thinks we should add a flagging OP_NOP1 to the front
21:00 < sipa> meeting!
21:00 < phantomcircuit> gavinandresen, there are several RFCs for dates
21:00 < gavinandresen> mmmm, meat
21:00 < genjix> yep
21:00 < sipa> i definitely wouldn't mind an OP_NOP1 in front
21:01 < gavinandresen> I'm firmly against putting an extra byte in front.
21:01 < genjix> i would like an OP_NOP1 too if simply for the future when things become muddled.
21:01 < justmoon> I'm against adding an extra byte and using up OP_NOP1 for no good reason
21:01 < gavinandresen> ... but is that the first item on the agenda?  Is there an agenda?
21:01 < justmoon> if you mean that script add OP_NOP to the front
21:01 < genjix> the python mantra: in the face of ambiguity, avoid the temptation to guess
21:01 < justmoon> i.e. if you *don't* want code replacement to happen
21:02 < justmoon> add OP_NOP
21:02 < sipa> justmoon: it's not using up; OP_NOP1 can still be used to signify other "special" scripts later
21:02 < genjix> OP_NOP1 = this script, OP_NOP1 OP_NOP1 = another script, ...
21:02 < justmoon> sipa: well, I'm trying to use the logic of the people who are in favor of the OP_NOP1
21:03 < justmoon> sipa: i.e. that people are going to want to actually use some awkward script you should never use in practice
21:03 < sipa> justmoon: i don't like giving a special meaning to an otherwise ordinary and perfectly valid script
21:03 < justmoon> sipa: I don't like adding a byte purely to make you happy
21:03 < sipa> fair point
21:03 < genjix> yeah there's also the issue of blockchain bloat
21:04 < luke-jr> I don't think scripts should be special-cased.
21:04 < gavinandresen> I don't like adding extra rules to the BIP that say what happens if the first byte is OP_NOP1 and the next ones are NOT HASH <> EQUAL
21:04 < genjix> and then what gavin said about extra rules
21:04 -!- Carmivore [~carmivmor@ec2-184-73-17-110.compute-1.amazonaws.com] has quit [Remote host closed the connection]
21:05 < genjix> ok, well i dont feel too strongly about having the byte. it would be nice. whatever.
21:05 < luke-jr> I prefer the original OP_EVAL.
21:05 < luke-jr> with recursion fixed.
21:05 < gavinandresen> I hate to bring it up.... but the byte could be in the scriptSig
21:06 < luke-jr> gavinandresen: so an attacker can just say "don't execute this" and bypass the whole thing?
21:06 < genjix> so you're saying that OP_DUP OP_HASH160 <> OP_EQUAL would be valid?
21:06 < genjix> what's to stop me spending that
21:06 < justmoon> o_O - I think gavin just means putting the OP_NOP1 marker byte somewhere else
21:06 < gavinandresen> luke-jr: you're right, that wouldn't work.  never mind
21:07 < genjix> what's the timescale for this last idea?
21:07 < genjix> because it is pretty good imo and is good enough
21:07 <@BlueMatt> who wants to volunteer to implement it?
21:07 < justmoon> genjix: two weeks delay compared to OP_EVAL
21:07 < genjix> and it's simple enough that there doesn't seem to be any problems
21:08 < sipa> i don't like "doesn't seem to be"
21:09 < justmoon> *crickets*
21:09 < genjix> well the other ideas all had nagging feelings for me
21:09 < gavinandresen> I implemented it yesterday, it is only about 20 lines of code to do the validation
21:09 < Eliel> how does the current version react to transactions with one of the reserved opcodes in them?
21:09 < genjix> but this one is nice it seems
21:09 < genjix> Eliel: well in bitcoin there are a bunch of OP_NOP... which are ignored
21:09 < Eliel> ah, ok, so those are the reserved ones.
21:09 < genjix> the idea was before to replace them, but now there won't be any new OPs introduced
21:10 < justmoon> gavinandresen: does EvalScript() need any modification at all for PayToScriptHash?
21:10 < gavinandresen> justmoon: no
21:10 < justmoon> yeah, so that's something I really like
21:10 < gavinandresen> justmoon: It is all done a level higher, in VerifyScript
21:10 < justmoon> exactly
21:10 < gmaxwell> meh, byte bloat.
21:10 < genjix> so the old transaction was DUP HASH160 <pubkey hash> EQUALVERIFY CHECKSIG : <sig> <pubkey>.
21:10 -!- Carmivore [~carmivmor@ec2-50-16-157-158.compute-1.amazonaws.com] has joined #bitcoin-dev
21:10 < genjix> the new one is like:
21:11 < Eliel> I'd personally favor redefining one of the NOPS but that wouldn't be backwards compatible I guess. perhaps have this hackiness be temporary measure so you can cut out even more bytes in the future once all clients have support?
21:11 <@BlueMatt> gavinandresen: oh, is there a pull?
21:11 < genjix> DUP HASH160 <hash of code> EQUAL : <sig> <<pubkey hash> CHECKSIG>
21:11 < gavinandresen> BlueMatt: no pull yet, still testing/polishing.  And waiting for the results of this meeting
21:12 < gavinandresen> genjix:  No, new would be:    HASH160 <> EQUAL
21:12 < genjix> and the client sees the output script and understands implicitly to execute the top stack item at the end or start
21:12 <@BlueMatt> so, what, do we vote on if we are all good with this solution?
21:12 < gavinandresen> (no need to DUP)
21:12 < genjix> ok
21:12 < luke-jr> what is the current spec we're discussing?
21:12 < sipa> magic hash script
21:12 < sipa> or how is it called?
21:12 < luke-jr> so exactly the worst possible option
21:12 < luke-jr> ?
21:12 < genjix> magic hash script will do :p
21:12 < justmoon> sipa: PayToScriptHash
21:13 <@BlueMatt> (for the record /me is lagging by anywhere from 10 to 60 sec, so dont expect responses...)
21:13 -!- coblee [~coblee@173-167-113-73-sfba.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds]
21:14 < genjix> i think the only checks done during block validation which regard the scripts are the sig ops count
21:14 -!- spaola [~spaola@unaffiliated/ne0futur/bot/spaola] has quit [Quit: ne0futur]
21:14 -!- dvide [jack@87-194-145-96.bethere.co.uk] has quit [Ping timeout: 260 seconds]
21:14 -!- rjk2 [rjk@rjk.happy-customers.bitvps.com] has quit [Quit: Over and out]
21:15 < luke-jr> and what if i really want my data to be DATA and NOT a script?
21:15 <@BlueMatt> in the interest of time (since Id assume most people understand the current magic hash script idea pretty well) can we vote on using an OP_NOP1, and then vote on the final solution?
21:15 < justmoon> luke-jr: OP_NOP OP_HASH160 <> OP_EQUAL
21:15 < sipa> then don't place it in a place that is declared by the protocol to contain a script?
21:16 < genjix> eh i prefer not voting on dangerous issues.
21:16 < gavinandresen> luke-jr: or OP_RIPEMD160 <> OP_EQUAL
21:16 -!- spaola [~spaola@unaffiliated/ne0futur/bot/spaola] has joined #bitcoin-dev
21:16 < justmoon> luke-jr: or OP_HASH160 <> OP_EQUALVERIFY OP_1
21:16 < gmaxwell> genjix: likewise.
21:16 < luke-jr> and how about if I want to use a single SHA256 for the hash?
21:16 < justmoon> but I guess gavinandresen's way saves one byte ;)
21:17 < genjix> luke-jr: just put a NOP in there?
21:17 < luke-jr> no, I mean for a script
21:17 <@BlueMatt> luke-jr: so that you get regular-looking addresses
21:17 < sipa> i'm not too sure about hardcoding HASH160 as hash-function
21:17 < sipa> but i guess it's equally easy to extend it in the future if necessary
21:17 < justmoon> hmm
21:17 < genjix> wait
21:17 < luke-jr> OP_EVAL was far better than this ugly thing
21:18 < sipa> (note that secp256k1 only has 128 bits of security anyway)
21:18 < gavinandresen> Yeah, we're already in the HASH160 boat.
21:18 -!- dvide [jack@87-194-145-96.bethere.co.uk] has joined #bitcoin-dev
21:18 < genjix> why not define OP_X to be OP_HASH160 + ... + OP_EQUAL?
21:18 < genjix> OP_X ...
21:18 <@BlueMatt> if you dont hardcode hash function, you have to put hash function in addresses...
21:18 < genjix> OP_X <code hash>
21:18 < gmaxwell> I'm not super keen on the hardcoded hash either. But, meh.
21:18 -!- user__ [~user@201.86.150.60.dynamic.adsl.gvt.net.br] has joined #bitcoin-dev
21:18 < gmaxwell> BlueMatt: nah, the address can imply OP_HASH160 without putting it in the script.
21:18 < sipa> BlueMatt: no, the address type defines the function
21:18 < justmoon> sipa: that doesn't necessarily means it's weaker than RIPE160
21:18 < genjix> that would solve the extra rules, the ambiguity and wanting a marker byte
21:18 -!- ByteCoin [~ByteCoin@188-223-73-61.zone14.bethere.co.uk] has joined #bitcoin-dev
21:19 < genjix> it is a composition of operations
21:19 < gavinandresen> genjix: because having old clients half-validate the transaction is valuable.
21:19 < genjix> ah damn that's right
21:19 < gmaxwell> genjix: ++++
21:19 < gmaxwell> oh
21:19 < luke-jr> how about prepending the script data with <script version> and <hash type> ?
21:19 <@BlueMatt> sipa: yea, and youd have to change the address type...
21:19 < genjix> yeah i lost it there :p
21:19 < sipa> justmoon: no, indeed, but assuming RIPEMD160 + SHA256 is secure, you don't lose any of secp256k1's security by only using 160 bits
21:19 < justmoon> gavinandresen: I recently argued that half-validation really is no validation, so...
21:20 < gavinandresen> luke-jr: ... and while we're at it, lets change the standard DUP HASH160 <> EQUALVERIFY transaction too... NOT.
21:20 -!- b4epoche_ [~textual@dssl.mne.psu.edu] has joined #bitcoin-dev
21:20 < luke-jr> gavinandresen: I mean only for the eval'd scripts
21:21 < justmoon> sipa: right, it's the "assuming RIPEMD160 + SHA256 is secure" part that I wanted to point out
21:21 -!- b4epoche [~textual@dssl.mne.psu.edu] has quit [Ping timeout: 240 seconds]
21:21 -!- b4epoche_ is now known as b4epoche
21:22 < sipa> i have no problem with the current proposal as such, assuming we can still do some nice, more extensive script-tweaking by introducing a more complete OP_EVAL (with possibly changed script language inside) later
21:22 < sipa> however, i fear that will not happen at all then
21:22 < justmoon> sipa: why not?
21:22 < genjix> i think the script system is going to die
21:22 < sipa> there won't be any need
21:22 < genjix> why hasten the inevitable
21:22 < sipa> i hope it doesn't
21:22 < justmoon> sipa: I have no problem with having an OP_EVAL, just with having it be needed for the very basic use case of moving scripts to the scriptSig
21:22 < gavinandresen> sipa: I know of at least two mining pool operators who are excited about a better scripting system...
21:23 -!- diki [diki@46.40.126.253] has joined #bitcoin-dev
21:23 < sipa> good then
21:23 < gmaxwell> I also hope it doesn't. Script is one of the most mindblowing and exciting parts of the system.
21:23 < sipa> exactly
21:23 < sipa> (and underexplored)
21:23 < luke-jr> special-casing a specific template = fail
21:24 < justmoon> more than not die I'm hoping that one day you'll be able to use it on the p2p network
21:24 < genjix> yeah lol
21:24 < gmaxwell> In order to grow bitcoin we need a big tent, too. And scripts make our tent bigger.
21:24 < gavinandresen> Agreed, but I also agree with roconnor-- nobody fully understands it  (CODESEPARATOR has to have a use... right?  right?)
21:24 < genjix> @luke-jr
21:24 -!- BlueMatt [~matt@unaffiliated/bluematt] has quit [Ping timeout: 252 seconds]
21:24 < gmaxwell> gavinandresen: thats why I'm not currently opposed to IsStandard... dampens down the scarriest stuff.
21:25 < groffer> is the question of eliminating IsStandard off topic for this meeting?
21:25 < genjix> no way lol
21:25 < justmoon> gmaxwell: there are ways to slowly expand IsStandard, that was my main argument for static analyzability
21:25 < gavinandresen> I had a couple of other things on my agenda:  first, what to do with BIP 12.  Outdate/rewrite, or update?
21:26 < genjix> might be good for hisotorical purposes to keep it around
21:26 < luke-jr> gavinandresen: BIP 12 is fine IMO
21:26 < sipa> if we eliminate it, the only reasonable way is in steps... first incresasing number of scripts, maybe later have a list of safe instructions that are always permitted, then ...
21:26 < genjix> but reject it
21:26 < sipa> i'd just add a new BIP
21:26 < genjix> sipa: how about a new script system that is phased in somehow
21:26 < gavinandresen> Rejecting and adding a new BIP sounds good to me, I can write it up.
21:27 < sipa> it's a different proposal altogether
21:27 < genjix> yep thats the way
21:27 < luke-jr> I gtg
21:27 < genjix> keep the old one for history
21:27 < luke-jr> hopefully there won't be a final decision made today - or at least not one that sucks
21:27 < luke-jr> bbl
21:28 < groffer> sipa: IsStandard is not applied to the blockchain itself
21:28 < groffer> it creates a false sense of security
21:28 < gavinandresen> Second, I think we should think about rules for counting CHECKMULTISIG sigOps when the CHECKMULTISIG is 'hidden' inside the scriptSig
21:28 < gmaxwell> groffer: It makes any 'attack' involving funky txn costly.
21:29 -!- BlueMatt [~matt@unaffiliated/bluematt] has joined #bitcoin-dev
21:29 -!- mode/#bitcoin-dev [+o BlueMatt] by ChanServ
21:29 < gmaxwell> groffer: in practice it's effective. I don't think anyone here thinks isstandard protects us from outright vulnerabilties.
21:29 -!- chrisb__ [~chrisb__@host86-164-166-37.range86-164.btcentralplus.com] has joined #bitcoin-dev
21:29 < groffer> gmaxwell: just pass the !IsStandard txns to eligius - they will mine it
21:29 < gmaxwell> groffer: rather it lets us discover "opps, add really subtracts, lets fix that because it's unused"
21:29 < MC1984> so this is where the real action is
21:29 < gmaxwell> groffer: no, not really. They'll mine some of them, sometimes, maybe.
21:30 < justmoon> gavinandresen: I liked your proposal from the other day, count OP_1 - OP_16 followed by OP_CHECKMULTISIG as such and a lone OP_CHECKMULTISIG as 20
21:30 < gavinandresen> justmoon: great, I'll make that part of the BIP  (and will have to write that code...)
21:30 < sipa> justmoon: is that backward compatible?
21:31 < sipa> it makes things that were illegal legal
21:31 < justmoon> sipa: yes, as long as it applies only to the script literal
21:31 < sipa> in that case, agree
21:31 < gavinandresen> Yes, and it will have to be enforced only after the "full validation switchover" date.
21:31 < gavinandresen> Which was my other agenda item:  how much to slip the rollout?
21:31 -!- nhodges [u3985@gateway/web/irccloud.com/x-ygihttxbcrrqgiaa] has joined #bitcoin-dev
21:32 < CIA-100> bips: genjix master * r7c1296b / bip-0012.md : BIP0012: Accepted -> Withdrawn. To be replaced by new proposal. - http://git.io/Zym2Pw https://github.com/genjix/bips/commit/7c1296b7b62b5a9c09668e1fd66817596d91e6d3
21:32 < justmoon> gavinandresen: don't slip it at all, live dangerously!
21:32 < justmoon> I kid I kid
21:32 < gavinandresen> I'm proposing two weeks, so we look at the blockchain on Feb 1 for miner support, and, assuming 50+% support, rollout Feb 15
21:32 < genjix> sounds good
21:32 < sipa> what % do we require?
21:32 < sipa> 60%, 70% ?
21:32 < genjix> 50.01% :)
21:32 < gavinandresen> Good question.  Eleven is my favorite number.... so 61% ?
21:33 < justmoon> the bitcoin paper says 51% will do the job pretty quickly, doesn't it?
21:33 < genjix> haha
21:33 < gavinandresen> Oooh, yeah, 50.11%
21:33 < genjix> XD
21:33 < sipa> not too close to 50%...
21:33 < justmoon> gavinandresen: I really thought your favorite number would be 12 now
21:33 -!- baz [~barry@109.144.226.199] has joined #bitcoin-dev
21:33 < gavinandresen> blasphemy
21:34 < justmoon> but that question was serious - do we care about 51% vs 70%?
21:34 < roconnor> I propose two months; also how specifically are you going to measure support and what will your sampling error be?
21:34 < justmoon> I guess the measurement isn't perfectly accurate
21:34 < genjix> roconnor: ask miners to put a string in their coinbase as a vote
21:34 < gavinandresen> roconnor: I'll be asking the miners to put a string in their coinbase transactions
21:35 < justmoon> I agree with roconnor as a developer but would like to distance myself from his position for political reasons (i.e. not being lynched)
21:35 < gavinandresen> roconnor: ... and I've got a tool that tells me how many of the previous N blocks had a given string.
21:35 < justmoon> two weeks sounds ok to me
21:35 < roconnor> gavinandresen: and the N you plan to use is?
21:36 < gavinandresen> roconnor: about 24 hours.  But I'll take a look at 24, 48, and maybe more, just to see variance
21:36 < genjix> lets say 80% confidence
21:36 < genjix> so i guess 1.5 sigma?
21:36 < gmaxwell> genjix: it should be something like x% confidence on y% with y picked so that we don't reduce 6 confirms to less than 5 confirms security.
21:36 < sipa> ;;bc,help
21:36 <@gribble> Alias bc,24hprc, Alias bc,altprofit, Alias bc,avgprc, Alias bc,bcm, Alias bc,bitpenny, Alias bc,blockdiff, Alias bc,blocks, Alias bc,bounty, Alias bc,btceur, Alias bc,btcgbp, Alias bc,btcguild, Alias bc,btcrub, Alias bc,btcto, Alias bc,calc, Alias bc,calcd, Alias bc,channels, Alias bc,convert, Alias bc,deepbit, Alias bc,diff, Alias bc,diffchange, Alias bc,eligius, Alias bc,estimate, Alias (2 more messages)
21:36 < MC1984> this al sounds so hacky teehee
21:36 < sipa> ;;bc,diffchange
21:36 <@gribble> Estimated percent change in difficulty this period | 4.69534022467 % based on data since last change | 8.01215569553 % based on data for last three days
21:36 < genjix> yeah maybe hypothesis testing is better here
21:37 < gmaxwell> MC1984: thats because almost any criteria is acceptable.
21:37 < sipa> ;;bc,stats
21:37 <@gribble> Current Blocks: 160487 | Current Difficulty: 1159929.4972244 | Next Difficulty At Block: 161279 | Next Difficulty In: 792 blocks | Next Difficulty In About: 5 days, 7 hours, 9 minutes, and 36 seconds | Next Difficulty Estimate: 1214392.13348545 | Estimated Percent Change: 4.69534022467
21:37 -!- jon_corzine [48c67aa6@gateway/web/freenode/ip.72.198.122.166] has joined #bitcoin-dev
21:37 < gavinandresen> Can we assign one of you to figure out what x and y aught to be?
21:37 -!- larg78 [~bender32@184-99-167-125.tcso.qwest.net] has joined #bitcoin-dev
21:37 < genjix> sure we can do that
21:37 < sipa> gavinandresen: what about using an entire 2016-wide list of blocks
21:37 < genjix> however it comes down to what amount of blocks come from which sources
21:38 < genjix> i'm guessing mining pools are the majority of blocks
21:38 < genjix> so it doesnt matter too much.
21:38 < sipa> let's say from the 3rd to the 4th difficulty change from now
21:38 < genjix> so the variance isnt going to be huge in sampling rates
21:38 < genjix> because we have a large sample for a small population
21:39 < LightRider> I'm getting a large number of log files in bitcoin/database is that normal?
21:39 < gavinandresen> LightRider: yes, they'll get cleaned up if you restart
21:39 <@BlueMatt> LightRider: yes, patches welcome
21:39 < LightRider> ok thanks
21:40 < gmaxwell> sipa: one option is to use a criteria similar to one we might use if we were making this automatic.
21:40 < genjix> BlueMatt: you want the log files kept. they are from WAL
21:40 <@BlueMatt> genjix: yea, but you want to limit the log files after stuff has been committed (takes too much disk during initial download)
21:42 < genjix> if the new standard is documented then thats good
21:42 < genjix> and the documentation is the code
21:43 < genjix> reading the code helped me understand bitcoin, not forum or wiki posts because they can be ambiguous or unclear
21:43 < ByteCoin> I'd like to point out an apparent inconsistency in the decisionmaking over the functionality enabled by OP_EVAL. Casascius' original proposal changed the way in which OP_CHECKSIG worked in a roughly analogous fashion to what Gavin is suggesting now. The proposal was rejected in favour of OP_EVAL at the time which was seen to be "cleaner".
21:44 < sipa> yes, the current proposal is ugly, no doubt about it
21:44 < sipa> the magic hash, i mean
21:44 < genjix> yeah well whoever writes the BIP or code, gets to set the standard
21:44 < ByteCoin> So why is the current "magic hash" proposal in danger of being adopted while Casascius' was rejected?
21:45 < gmaxwell> This is still a general mechensism for pay to script if less general than OP_EVAL.
21:45 < justmoon> it's ugly because of being backwards compatible - arguably the txout should have contained a hash of the script to begin with
21:45 < justmoon> and then instead of scriptPubKey we would have right now a nHashType and scriptPubKeyHash
21:45 < gmaxwell> where IIRC Casascius' was not pay to script.. it was pay to a hashes of address sets which is _far_ less general.
21:45  * BlueMatt takes this opportunity to point out that with an OP_NOP1, it becomes 100% less ugly
21:45 < justmoon> which is what the new proposal is
21:45 < genjix> imagine in the future if the input eval-script was a new custom script system in bitcoin
21:46 < gmaxwell> justmoon: right, I think we should have always been pure pay to script(-hash).
21:46 < ByteCoin> I agree too.
21:47 < justmoon> so that's how i see this proposal - maybe future documentations won't even think of the scriptPubKey as a script anymore
21:47 < genjix> yeah i mean all that junk with hash type would not be needed
21:47 < justmoon> as such I don't think it's "ugly" just cause it's "magic"
21:47 < justmoon> anyway
21:47 < gmaxwell> (and I think a year or so for now I may find myself calling for miners to stop mining any new pay-to-address outputs, depending how addoption goes)
21:47 < genjix> the bitcoin standard is on its path to becoming complicated and obtuse
21:48 < genjix> gogogo
21:48 < gmaxwell> genjix: as are all production systems. There are worse fates. :)
21:48 < genjix> it's inevitable
21:48 < sipa> there is a certain truth there
21:49 < sipa> we do not lose anything by adooting the current proposal for basically everything
21:49 < sipa> except 23 bytes
21:49 < genjix> well it's good *right now*
21:49 < justmoon> sipa: how do we lose 23 bytes?
21:49 < genjix> but 100 small paper-cuts
21:50 < gmaxwell> justmoon: it's like losing 10 pounds.
21:50 < sipa> justmoon: that is assuming you just put the script in scriptSig, and use the magic hash script in the scriptPubKey
21:50 < sipa> you can do optimizations of course, as you don't need the address anymore, but can do a pay-to-pubkey directly
21:51 < roconnor> how many bytes fit in a typical QR-code or whatever 2-D bar code is popular?
21:51 < gavinandresen> Speaking of old, crufty stuff we'd like to get rid of... anybody want to start an informational BIP to keep track of changes we want to make if/when a 'hard' blockchain split is scheduled?
21:51 < justmoon> roconnor: depends on the size
21:51 < genjix> gavinandresen: maybe an informal list is better
21:51 < genjix> then when it comes we make a proper BIP
21:51 < roconnor> justmoon: naturally
21:51 < justmoon> roconnor: the absolute max is like 4k or so, but those guys are HUGE
21:51 < genjix> what do you think?
21:51 < justmoon> or even more if you lower the error correction level
21:52 < justmoon> (don't quote me, speaking from memory)
21:52 < justmoon> http://www.denso-wave.com/qrcode/vertable4-e.html
21:52 < justmoon> there you can see the tables for the largest ones
21:52 < gavinandresen> genjix: ok.  I just fear that if it is a wiki page we'll be constantly removing "I want my bitcoin client to clean my room for me" -type features
21:52 < justmoon> 23k is absolute max
21:53 < genjix> ok lets see what happens. if it gets bad, ill lock the page
21:53 < sipa> justmoon: 23k in a QR code? no way
21:53 < roconnor> what I don't quite get is why, if people want send-to-script, don't people just send to script?
21:53 < justmoon> sipa: that's bits, but yes
21:53 < Eliel> could the proposal also include support for only having the hash in txout, no opcodes at all? To be enabled once significant majority of users have migrated.
21:53 < genjix> https://en.bitcoin.it/wiki/Hardfork_Wishlist
21:54 < genjix> Eliel: not backwards compatible
21:54 < gmaxwell> ByteCoin: where is your post on flipping the chanin direction to instead approve trees of open txn?
21:54 < Eliel> genjix: hence, won't be enabled until significant majority of users are compatible.
21:54 < genjix> ok thats a hard change
21:54 < jim618> justmoon: Andreas Schildbach did some work on having tx as QR codes - said he started having scanning problems above about 1KB
21:54 <@nanotube> <roconnor> I propose two months... <- i would agree that more time rather than less time is better. we don't lose anything by leaving more time for eyes to look at things and point out the stupid stuff.
21:55 < ByteCoin> gmaxwell: On the forum probably titled "Most of the block chain can be forgotten"
21:55 <@BlueMatt> gavinandresen: about 1 in 10 times when compiled with DEBUG_LOCKORDER you get a boost::interprocess::lock_exception on exit (last log line is DBFlush(true), so I dont think it matters, just thought Id tell you)
21:55 < justmoon> jim618: yeah, doesn't surprise me
21:55 < sipa> nanotube: the question is whether we will look at it for longer, if it is two months instead of two weeks
21:55 < justmoon> jim618: you need like a Canan 7D or something to scan one of those big ones :D
21:55 < genjix> ok so lets call the meeting "officially" finished in case people wanna leave :p
21:55 < justmoon> Canon*
21:56 <@BlueMatt> genjix: did we get anything done?
21:56 < roconnor> sipa: 2 months worked for debugging OP_EVAL ;)
21:56 < justmoon> yeah, let's recap decisions made
21:56 < ByteCoin> gmaxwell: Alternatively it might be titled "Balance sheets"
21:56 <@nanotube> sipa: yes, and i was basically voting for 2 months, rather than 2 weeks. :)
21:56 < justmoon> (if any)