03:09:50	jgarzik:	bitcoin's scripts are "written in a programming language called Script"
03:09:52	jgarzik:	http://theumlaut.com/2014/01/08/bitcoin-internet-of-money/
03:10:04	jgarzik:	pretty good article though
03:32:53	Luke-Jr:	jgarzik: I'd concur with that statement.. :P
04:53:45	maaku_:	jgarzik: if that's the grossest error they made, i'd say that's doing pretty well :)
04:59:23	phantomcircuit:	lol
05:02:50	Luke-Jr:	maaku_: what error?
05:03:25	Luke-Jr:	that statement quoted is essentially correct
05:04:31	maaku_:	which is why i said it's pretty minor
05:04:50	maaku_:	more like bytecode than a programming language (which implies compilation)
05:05:03	maaku_:	and i don't know anyone who calls it Script with a capital S
05:05:07	Luke-Jr:	meh, we have an assembly-like form :P
05:05:14	Luke-Jr:	maaku_: it's not that uncommon
05:13:28	justanotheruser:	What do you guys recommend as a proof of sacrifice? Hashcash is more anonymous, but it doesn't work well (someone with a powerful hashing maching/GPU could make a ton of messages) and OP_RETURN associates the sacrifice with you to some extent and remove anonymity. Is there anyway I can get the best of both worlds?
05:16:36	gmaxwell:	justanotheruser: depends on the application, if you'd really be willing to use hashcash, perhaps mine.
05:18:09	justanotheruser:	gmaxwell: perhaps mine? What do you mean by that. I wouldn't want to use hashcash if it allowed people with special hardware to spam the network with as much electricity spent as a regular CPU user.
05:18:36	justanotheruser:	Application is bitmessage fork that isn't vulnerable to the problem I just described
05:20:28	gmaxwell:	justanotheruser: zero knoweldge proof of a bitcoin sacrifice using pinocchio.
05:21:43	justanotheruser:	gmaxwell: is that bleeding edge crypto?
05:22:11	gmaxwell:	yea? so. and a flooding messaging system isn't? the harm of someone breaking it is they can flood your system, whoopiedo.
05:23:14	justanotheruser:	gmaxwell: I was just curious if there were any other applications in use, or if it was just knowledge from research papers
05:23:35	gmaxwell:	justanotheruser: I suggested pinocchio because you can go download an implementation.
05:25:19	justanotheruser:	gmaxwell: where would I find this? Every top google result is research papers and news
05:26:13	gmaxwell:	https://vc.codeplex.com/
05:26:20	justanotheruser:	gmaxwell: thanks a lot
05:26:44	gmaxwell:	They've annoying ripped out the pairing library so one will need to be pached back in.
05:27:28	gmaxwell:	justanotheruser: in any case, I think bitmessage pow would be a great application for this.
05:30:11	justanotheruser:	gmaxwell: ofcourse your anonymity is limited to the recent proof of burns
05:30:17	justanotheruser:	right?
05:32:11	gmaxwell:	you make a sacrifice that contains X=H(random_value) and then to send a message you prove X is in a sacrifice of value >= Z in bitcoin (by evaluating a SPV proof for the transaction), and random_value is the preimage of X, and that Q=H(random_value||date||hour), and that R=H(random_value||pubkey). And you show the network the proof and Q,R,pubkey and sign your message with the pubkey.
05:32:54	gmaxwell:	you basically can get a new anonymous identity from each of your sacrifices once an hour, and then send however many messages the network will let you per identity (maybe just 1)
05:33:19	gmaxwell:	next hour you redo the proof with a new pubkey, and you have a new anonymous identity.
05:33:42	gmaxwell:	and you don't have to keep redoing sacrifices.
05:34:00	gmaxwell:	(unless you wanted to require that)
05:34:36	justanotheruser:	pubkey is separate from the pubkey I used to make the PoB right?
05:35:04	gmaxwell:	you wouldn't even need a ecdsa pubkey in the PoB, effectively H(random_value) is a pubkey in the proof of burn.
05:35:17	justanotheruser:	oh
05:35:25	gmaxwell:	You don't want to run ecdsa inside the zkp because its @#$@ expensive. Where running a hash inside the proof is more realistic.
05:35:42	justanotheruser:	what I mean by that is I use a pubkey to spend the output to OP_RETURN
05:36:24	gmaxwell:	yea, thats irrelevant. youd put H(random_value) in the OP_RETURN and the only thing the proof would look at is the txout value and H(random_value).
05:36:25	justanotheruser:	if that is the correct terminology, not sure what else you would call spending a transaction to something that always returns false
05:37:10	justanotheruser:	gmaxwell: I will be able to write stuff in OP_RETURN in v.9 right?
05:37:28	gmaxwell:	I'd say that even better than a scarifice would just be proving that you have possession of a bitcoin, but to do that you'd have to do a ecdsa signature inside the proof, and that would kinda suck.
05:37:57	Luke-Jr:	justanotheruser: no
05:38:02	justanotheruser:	gmaxwell: I don't see how proving you have bitcoins would help in the future when everyone might be transacting bitcoins
05:38:10	justanotheruser:	Luke-Jr: whenever the miners vote on it?
05:38:15	Luke-Jr:	justanotheruser: hopefully never
05:38:22	gmaxwell:	wtf. there is no "miners vote on it"
05:38:39	Luke-Jr:	and there will never be an interface to do it in any sane client
05:38:49	gmaxwell:	as of right now in git bitcoin allows data in OP_RETURN though given what people are saying I hope we back that out.
05:39:20	gmaxwell:	or at least cut it back to 32 bytes.
05:39:23	justanotheruser:	gmaxwell: I thought miners voted on whether or not they would mine a certain tx type and if a certain amount said yes it would be implemented and the miners would start mining it
05:39:30	gmaxwell:	justanotheruser: no.
05:39:42	gmaxwell:	dunno where the heck you got that idea!
05:39:55	justanotheruser:	gmaxwell: some other fork I remember miners including their votes in their blocks
05:40:03	justanotheruser:	maybe it's because that was a hardfork?
05:40:05	Luke-Jr:	there's no fork going on
05:40:09	Luke-Jr:	at all
05:40:11	gmaxwell:	why are you talking about forks?
05:40:23	justanotheruser:	gmaxwell: Well isn't OP_RETURN an invalid tx?
05:40:29	Luke-Jr:	no
05:40:30	gmaxwell:	No.
05:40:39	Luke-Jr:	just a useless, spam tx
05:40:39	justanotheruser:	oh, well that's where I was getting that idea from
05:40:45	gmaxwell:	it's just not IsStandard
05:42:24	justanotheruser:	"So, with some reluctance, I recently merged pull request #2738 : “Relay OP_RETURN data TxOut as standard transaction type.”" - gavin andresen
05:42:36	justanotheruser:	So will it be standard in .9?
05:42:52	Luke-Jr:	hopefully not
05:43:03	justanotheruser:	gmaxwell: also, how is it a sacrifice to prove you possess bitcoins?
05:43:04	gmaxwell:	21:38 < gmaxwell> as of right now in git bitcoin allows data in OP_RETURN though given what people are saying I hope we back that out.
05:43:21	justanotheruser:	gmaxwell: oh, I missed that
05:44:26	gmaxwell:	justanotheruser: it's not, but what you want is a resource rate limiter. You want to give each user 1/Nth of the capacity, but since users are anonymous you need a way of to prevent a user from claiming that they are 100 users and gobbling it all
05:44:53	gmaxwell:	holding bitcoin at a particular instance of time is something that prevents unlimited cloning.
05:46:29	justanotheruser:	gmaxwell: I suppose an attack on the network would cost as much as in a system with PoB because they would have to create a large number of new addresses with coins and pay the tx fee for all those just like if they were doing a large number of burns
05:47:33	gmaxwell:	yea, well I think a real sacrifice is stronger, but it's not clear to me that something bitmessage like would need a real one, and just showing you were holding coins as of a daily txoutset snapshot would be easier to accept for users, I suspect.
05:48:03	gmaxwell:	in any case, I also think that because of the aformentioned ecdsa an actual sacrifice would be easier to implement.
05:48:57	justanotheruser:	gmaxwell: funny to see you promoting proof of stake btw :D
05:49:24	gmaxwell:	justanotheruser: PoS is fine, so long as you're not expecting it to operate its own consensus.
05:49:30	justanotheruser:	yeah
05:49:46	gmaxwell:	you could mine a PoS altcoin based on bitcoin holdings, you just can't the chain itself. :P
12:40:20	kcla05:	kcla05 has left #bitcoin-wizards
15:41:31	_ingsoc:	_ingsoc has left #bitcoin-wizards
17:08:40	jtimon:	petertodd why does litecoin need a softfork?
17:18:51	TD:	TD is now known as TD[gone]
17:45:59	petertodd:	jtimon: to implement height in coinbase, and warren wants to see single-satoshi dust made unspendable
17:46:22	jtimon:	thanks
17:46:37	_ingsoc:	_ingsoc has left #bitcoin-wizards
17:46:43	jtimon:	so are they making a protocol antidust rule?
17:47:14	petertodd:	jtimon: yup, if nValue == 1 satoshi treat the output like a provably unspendable OP_RETURN
17:47:32	jtimon:	is not only in isStandard, interesting
17:47:49	sipa:	petertodd: why not 0 satoshi?
17:47:54	sipa:	what makes 1 special?
17:48:34	petertodd:	jtimon: Note that this *isn't* because doing so will actually have a big impact on anything, but rather the argument is to do it "symbolicly" for future, more invasive, anti-dust efforts.
17:49:00	petertodd:	sipa: Litecoin had a bunch of 1 satoshi dust spam a while back, and it's conceivable that a future soft-fork feature might want to use 0-value outputs for something.
17:49:05	jtimon:	we haven't even make sub satoshi (sub-kria) outputs unspendable in freicoin. Yes, demurrage still applies to a single satoshi so you won't be able to spend it, but you may want to spend 0 coins?
17:50:23	petertodd:	Indeed, zero-output txouts could be used to implement a increased divisibility soft-fork for instance.
17:50:27	jtimon:	well, maaku was reluctanct to have any form of escheatment
17:50:53	jtimon:	yes, and we also plan to increase divisibility on freimarkets so...
17:51:55	petertodd:	Add nNewValue to transactions and define nSumValue = nNewValue + nValue, then do divisibility by moving value from nValue to nNewValue, which means you can re-combine sub-satoshi outputs, it's just that old clients can't see the fact you've done so.
17:52:51	petertodd:	Note how this depends on the fact that miners can destroy coins forever rather than taking them as fees.
17:53:58	jtimon:	I think that's what we have in freimarkets
17:53:59	jtimon:	nValue :: int64
17:54:00	jtimon:	dValue :: decimal64
17:54:00	jtimon:	dValue = nValue * 10^369
17:54:08	petertodd:	Oh, interesting!
17:54:35	jtimon:	but maaku told me that gmaxwell told him we're not using nVersion as it was intended
17:54:40	petertodd:	how so?
17:54:51	jtimon:	I'm not sure I did understood that
17:54:58	petertodd:	how are you using it?
17:55:29	jtimon:	for us version 2 are transaction with an additional refHeight, necessary for calculating demurrage
17:55:44	jtimon:	so all freicoin transactions are v2
17:55:55	petertodd:	is refHeight actually a different binary format?
17:56:01	jtimon:	and freimarkets introduces v3 with more modifications
17:56:13	jtimon:	it's an additional field
17:56:36	petertodd:	right, nVersion was meant to signify to *interpret* a otherwise backwards-compatible transaction differently
17:56:53	jtimon:	so if bitcoin were to adopt freimarkets, interest bearing assets could be moved with v2 transactions
17:57:39	jtimon:	ours aren't backward compatible, are hardfork changes
17:59:38	jtimon:	here's the commit that adds nRefHeight: https://github.com/freicoin/freicoin/commit/cee818350d857029e0e7148fece35646d479aea1
17:59:50	petertodd:	for instance P2SH could have been done with a nVersion bump
18:01:05	jtimon:	but some other version number was changed for that, no?
18:01:05	petertodd:	jtimon: right, you could have done that as a soft-fork
18:01:37	petertodd:	jtimon: no, that was done with voting by putting the string "P2SH" in the coinbase - not a great mechanism
18:02:00	petertodd:	jtimon: the "height in coinbase" soft-fork was a lesson learned there, and was done with a CBlock.nVersion bump.
18:02:30	petertodd:	jtimon: oh, sorry, and come to think of it the voting *wasn't* software evaluated
18:02:57	petertodd:	jtimon: IE, miners "voted", then a bitcoin was released that turned on P2SH on a specific day IIRC
18:03:10	petertodd:	eh, I might have to double-check the code for that, don't quote me :)
18:04:23	jtimon_:	petertodd: "right, you could have done that as a soft-fork" what? adding the nRefHeight field?
18:04:50	jtimon_:	anyway, the tx-nversion looked ideal for our changes, I'm not sure what we should use instead
18:05:05	petertodd:	jtimon_: yeah, you'd do it by just recording nRefHeight in a different datastructure that was stored along-side the block
18:05:18	jtimon_:	no, no
18:05:32	jtimon_:	the nRefHeight goes with EACH transaction
18:05:46	petertodd:	Yes, and along-side the block you store an nRefHeight array for each tx.
18:05:54	jtimon_:	oh, I see
18:06:05	jtimon_:	but...
18:06:12	jtimon_:	that number has to be signed
18:06:25	jtimon_:	it really belongs in the tx
18:06:54	petertodd:	See, what might be good is a hard-fork to allow arbitrary junk to go at the end of CTransaction's, and then forever after you could add new fields in soft-forks by bumping nVersion.
18:07:15	jtimon_:	interesting
18:07:34	petertodd:	jtimon_: oh right, well, that's another thing: SignatureHash() should have been written so that the presence of unknown flags makes the signature always evaluate as true, so that new flags could be defined in soft-forks.
18:07:51	petertodd:	Additionally you need different OP_CODESEPARATOR there too, long story. :P
18:09:10	petertodd:	(well, actually, better to only define *some* of the unused flag bits as "return true")
18:09:39	petertodd:	(though an even better system wouldn't have a "all-in-one" CHECKSIG anyway, but I digress)
18:09:41	jtimon_:	well, I think it was much simpler to just add the nRefHeight field after nLockTime (if I remember correctly, that's where it is)
18:09:53	petertodd:	sure, given you're doing a hard-fork
18:10:36	jtimon_:	so there's no way to signal hardfork versions for transactions?
18:10:57	petertodd:	point is, if you're doing a hard-fork you don't have too really
18:11:26	jtimon_:	well, it just simplifies the implementation, since older versions will still work the same
18:11:33	petertodd:	yeah, older code
18:12:46	gmaxwell:	petertodd: sig flags are set by the signer. So I write a txn with an unknown flag and freely spend your inputs. :P
18:13:34	jtimon_:	I guess we will keep using the nVersions even if it wasn'te the purpose for a lack of a better alternative
18:14:18	petertodd:	gmaxwell: gah, damn, that's right
18:14:49	petertodd:	gmaxwell: yeah, guess that just leaves the OP_CODESEPARATOR solution so you can put arbitrary signed data in the scriptSig
18:15:36	jtimon_:	the "junk-at-the-end-of-the-tx and nversion for softfork additional fields" is really interesting though
18:16:04	petertodd:	yup, basically you just need to hard-fork in a total-transaction-length field and then go nuts
18:17:18	petertodd:	you probably want OP_CHECKSIG to be made to include the *contents* of the extra data in the signature hash, which nicely can be done backwards compatibile - generally the extra contents are empty
18:17:54	shesek:	though it'll make it impossible to prevent arbitrary data storage on the blockchain, as something like p2sh^2 intends to do
18:18:08	gmaxwell:	petertodd: on another subject I don't know if you saw my musing; wrt coinbase only pooling, if the payout is to some M of N keys, then shares could be submitted to N entities and they could share the shares to achieve a consistent state and then do consensus signing of payouts. So you can even distribute the payout trust in coinbase only mining.
18:18:29	petertodd:	shesek: if you genuinely make arbitrary data storing impossible you've probably made future soft-forks difficult to impossible
18:18:44	petertodd:	shesek: e.g. you need to change the signature algorithm, now what?
18:19:05	maaku_:	are all forms of transaction storage length prefixed though?
18:19:24	petertodd:	gmaxwell: ha, nice
18:19:30	gmaxwell:	petertodd: also the entities need only about 1mbit/sec of bandwidth if you assume eligius' current user count and that each user is targeting 4000 shares / day (which gets them to the point where weekly performance <98.5% if less than 1% likely)
18:19:38	petertodd:	maaku_: not yet, but they can be made to be in a hard-fork
18:19:47	helo:	would those then be unspendable for 100 blocks?
18:19:51	gmaxwell:	which means you could easily support additional observer entities over the N.
18:19:54	maaku_:	regardless though I don't think it will work - before the soft-fork the length-extending version means nothing, after it means there's extra bytes
18:20:18	petertodd:	maaku_: doing that in a soft-fork is much less trivial, I'm talking about a hard-fork
18:20:20	maaku_:	well ok, i guess it'd work if every instance of transaction storage is made length prefixed
18:20:31	gmaxwell:	helo: the payouts in what I'm talking about? yes.
18:20:32	petertodd:	gmaxwell: not bad
18:21:17	gmaxwell:	helo: The payouts to the pool itself are generated, the payouts to the users would be instant spendable.
18:21:37	maaku_:	our current approach (for freimarkets, freicoin we screwed up) is to have the block height indicate the hard-fork transaction format
18:21:42	gmaxwell:	(I think doing coinbase payments in such a model would add a lot of complexity for not a ton of data)
18:21:56	petertodd:	gmaxwell: (U)TXO commitments should be structured such that multiple low-bandwidth parties can create a block co-operatively. Shouldn't be too hard to pull off in a trusted scenario, harder in untrusted. (though could be fidelity bonded)_
18:22:17	maaku_:	which is somewhat undesireable around the transition, although that is one-time and can be mitigated by creating new-format transactions early
18:22:41	petertodd:	maaku_: that's reasonable, although remember that you can do a nVersion voted hardfork too
18:27:41	jtimon_:	kind of off-topic, but now that you're talking about coinbase...nVersion=2 of joke I think I heard here
18:29:19	jtimon_:	The success of coinbase surprises me given that their transactions take 100 blocks to confirm. That latency surprises me even more given that they use mongoDB, whose writes are almost as fast as writes to /dev/null
18:31:01	jtimon_:	just a mix of jokes really
18:31:02	petertodd:	jtimon_: well, that was more funny than the comedian they hired for the san jose conference
18:31:10	jtimon_:	hehe
18:31:41	jtimon_:	I saw him a little bit, but yeah, not funny at all, I couldn't watch the whole video
18:31:56	gmaxwell:	jtimon_: I think it's because they have to send their transactions all the way to blockchain in the UK for processing.
18:32:09	jtimon_:	hehe
18:32:36	petertodd:	gmaxwell: these services need a little button that gives you the raw hex of your tx
18:35:19	gmaxwell:	petertodd: We got blockchain.info to add that. (well not a button but a ?format=hex on the transaction page)
18:35:28	petertodd:	gmaxwell: nice!
20:00:49	orperelman:	Jtimon & Peter, it's all about the PR and marketing, one of the reasons they are so successful, they are doing an amazing PR work - gotta give them that
20:01:38	orperelman:	It's amazing me to this day - there is almost no normal wallet out there today that I can recommend to new bitcoin users heh
20:45:42	adam3us:	gmaxwell: proof of (holding) bitcoin - (for bandwidth allocation in bitmessage etc) but with 100btc i can take 100 shares of bandwidth at no cost (if i was holding them anyway).
20:46:35	adam3us:	gmaxwell: "as of right now in git bitcoin allows data in OP_RETURN though given what people are saying I hope we back that out." dont object to backing out (say NO to block-chain spam!), but what are they saying missing context?
21:17:20	adam3us:	gmaxwell: ps still musing about how to do a subliminal channel free sig (motivated by such things). one thing wondering is the existing possibility to make a ECDSA key that can sig that is valid for two different msg hashes (by chosing public key at time one msg is known). thinking it might be enuf flexibility to do something
21:37:03	gmaxwell:	adam3us: there have been a number of articles about how bitcoin has been "upgraded" to enable "distributed storage" and such horrifying things like that.
21:40:32	adam3us:	gmaxwell: ah yes. its a scary situation indeed. the flip side is there are then people who will stego encode then in multisigs if you dont, and create needless non-compactable TXOs and on. Cant win:( well maybe... there's the subliminal channel plugging drive - could try how far you can get with that. eg all outputs are blinded somehow by the next mining event and unblinded by recipient or inputs blinded by spender and unblinded by mi
21:41:16	gmaxwell:	adam3us: thats why I didn't oppose it initially. Though the trade off of people thinking it is a good non-antisocial and supported application is concerning.
21:41:39	gmaxwell:	Esp what happens if abusive use arises and it must be turned back, but there is also non-abusive use?
21:41:49	adam3us:	gmaxwell: pegged side-chain, pegged side-chain, pegged side-chain
21:42:11	gmaxwell:	I mean there is a whole seperate stupid altcoin "datacoin"
21:43:14	adam3us:	gmaxwell: seriously. if that can be bootstrapped there is no rational excuse for not using one. i mean maybe we'll need a pegged-side-chain-gen.io because of lameness but otherwise...
21:45:00	adam3us:	gmaxwell: yes it seems like the msg was interpreted badly as a big GREEN light, that people can do any random stuff like its an API, or I dunno "HTTP on top of TCP"
23:08:22	maaku_:	maaku_ is now known as maaku
23:13:34	gmaxwell:	andytoshi: I wonder in a public CJ server if there would be a value in using a socialist millionaire protocol so that a prospective CJ player could query the available sessions to test for an output size match, without disclosing what size they're looking for (and without learning what any of the ongoing sizes is)
23:17:18	andytoshi:	gmaxwell: what would they learn in the case that a match exists?
23:18:08	andytoshi:	it seems like they could get a good idea of the sessions just by testing various output values to see if they can join
23:18:36	gmaxwell:	andytoshi: you can limit them by making them show you inputs they're interested in using as a rate limiter.
23:19:54	andytoshi:	ok, fair enough
23:20:10	andytoshi:	i'll put this on my list of "things to do when we have enough people for more than one session at once" :)
23:20:12	gmaxwell:	I mean ultimately what you can do is a multiparty computation where the server has a list of possible CJ's and the user has a set of inputs/outputs they're interested in and the MPC tells the user and the server which one they ought to be joining and no one learns anything beyond that... but thats getting into moon technology where socialist millionaire protocol is straightforward.
23:20:47	andytoshi:	well, if it's tractable moon technology then i'll look into using it one of these days ..
23:21:03	andytoshi:	i am being selfish and using other peoples' privacy desires for my own learning purposes
23:23:11	andytoshi:	if i can get my bitcoind back to life i'll have a coinjoin client written by sunday evening, then this week we'll see if i can spur some popularity
23:23:18	gmaxwell:	It's not intractable, but not a 1 hour hack either.
23:31:35	gmaxwell:	there may be a 'simple' way to implement it where the server and the client disclose a bunch of fake data about the candidate joins and inputs/outputs (including the real data), and then the server and the client compute which would go with which, and then you do a far simpler multiparty computation just to learn a single one of matchups which involve real transactions.
23:32:50	gmaxwell:	(lets you keep the coinjoin matching outside of the multiparty computation.. the multiparty computation would just be "take two bitstrings, return a random index which has a 1 in both bitstrings"
23:32:54	gmaxwell:	)
23:44:51	maaku:	gmaxwell: would there be a chance at analagous technology for the p2p case?
23:45:53	maaku:	for my architecture I'm still assuming a broadcast architecture for requesting potential joins
23:46:00	maaku:	which isn't as privacy enhancing as I would like...
23:48:18	gmaxwell:	maaku: nothing fundimentally prevents it, e.g. you could do multiparty computation with any number of parties. Though I think the complexity of hacks like I suggested to keep the mpc part maximally simple would not scale well.