01:17:14	tacotime:	I'm still hacking away on my derivative of Cunicula's PoW/PoS system. Cunicula himself seemed hopeful I'd get mine off the ground sometime this year.
05:06:52	phantomcircuit:	gmaxwell, ping
05:06:54	phantomcircuit:	;;seen gmaxwell
05:06:54	gribble:	gmaxwell was last seen in #bitcoin-wizards 6 hours, 35 minutes, and 9 seconds ago: sure, and they're all easily found e.g. just go extract every script that isn't one of the few common patterns.
07:12:38	antephialtic:	are the videos from the princeton btc conference archived anywhere?
08:30:37	Emcy:	theyre probably not up yet
08:31:08	Emcy:	i wish someone would throw a torrent of this stuff up, youtube can be amazinly shitty for me oftentimes
09:04:28	Elriel:	tacotime: I'm happy to hear there's someone working on it :)
09:23:32	fanquake:	fanquake has left #bitcoin-wizards
09:47:29	justanot1eruser:	Couldn't a merkle tree with a hash of every tx (or whatever you're calling it in XCP and colored coins) be in a single OP_RETURN TX per block?
09:47:52	justanot1eruser:	And then used fine for consensus
09:47:56	justanot1eruser:	*be used
09:58:32	topynate:	doesn't really address someone who includes the hash but withholds the transaction, or what happens if there are contradictory merkle tree hashes in the same block.
12:35:20	lnovy_:	lnovy_ is now known as lnovy
14:01:03	tacotime:	justanot1eruser, I proposed that for UTXO sets a while ago; publish the root of the merkle tree with OP_RETURN signed by the coinbase keypair, then have the blockchain as a rolling proof of the UTXO set.
14:02:37	tacotime:	Not sure whether it's a good or bad idea; you need to handle cases where a miner would maliciously publish false hashes well. If you start a coin with the UTXO set embedded it's not so much of an issue because you can just make the network reject blocks with invalid root hashes. But you also need to keep the entire thing into memory and be able to do the updates/removals extremely quickly.
14:03:23	tacotime:	I think it's more a hardfork method if anything, and I'm not sure how well it'd work in practice. Anyway I have to run, bbl
14:49:08	rdponticelli:	rdponticelli has left #bitcoin-wizards
16:33:51	iddo:	new paper on multisig: https://freedom-to-tinker.com/blog/stevenag/new-research-better-wallet-security-for-bitcoin/
16:34:34	iddo:	reading now... appears to be interesting starting from last paragraph on 1st page
16:34:35	maaku:	tacotime: what does signing by the miner get you at all?
16:35:20	maaku:	justanot1eruser: yes, that is the committed JTXO validation hash tree proposed by gmaxwell years ago
16:35:23	maaku:	I'm working on it
16:36:17	BCB:	anyone know that "bits" value refers to in get block?
16:36:58	maaku:	BCB: compact representation of the target (inverse difficulty)
16:37:53	BCB:	thx
17:07:32	tacotime:	maaku: It ensures that the person who did the amount of work equivalent to block submission submitted the root hash.
17:07:54	tacotime:	You could always stick it in the header if you're hardforking, though.
17:10:17	tacotime:	iddo: just sounds like an application of Shamir's Secret Sharing
17:10:25	tacotime:	for the private key
17:22:38	maaku:	tacotime: no, you make it a validation rule that the hash is correct
17:22:56	maaku:	that way you get a better level of assurance
17:23:52	maaku:	other miners don't build on blocks with invalid hashes
17:40:33	jaekwon:	iddo: is that with ECDSA?
17:41:49	jaekwon:	yeah it is. how very exciting.
18:06:12	andytoshi:	hey, i know many people here are tired about talking about POW but can i get some comments on my #bitcoin-level discussion of asics and scrypt? https://download.wpsoftware.net/bitcoin/asic-faq.pdf
18:28:27	maaku:	andytoshi: only had time to skim it but it looks good
18:29:23	Emcy:	andytoshi doesnt the concept of a scrypt asic sort of make the whole thing pointless
18:29:32	iddo:	tacotime: jaekwon: the main point is about aggregating/squashing multiple signatures into a single signature, this is well known... but maybe their paper has some interesting observations
18:29:57	Emcy:	litecoin et al should hardfork and pick better scrypt parameters
18:30:00	Emcy:	brutal ones
18:30:24	tacotime:	Emcy, if you'd like the blockchain to never be able to validate, sure
18:30:52	Emcy:	why wouldnt it validate
18:31:27	Emcy:	theyll never be able to hardfork it now though because politics
18:31:32	tacotime:	The more memory you use, the longer it takes per hash. Then to validate the list of headers for any new node on the network, you're multiplying by this constant factor.
18:32:19	Emcy:	does not scrypt conform to the pow expensive validation cheap paradigm
18:32:24	tacotime:	Nope.
18:32:34	tacotime:	It's a key derivation algorithm. :P
18:32:38	Emcy:	well i never
18:32:49	Emcy:	theyre boned then
18:33:01	nsh:	in the long-run, we're all boned.
18:33:23	Emcy:	#thoughtprovoking
18:34:41	andytoshi:	thx maaku. Emcy, you should read the doc :)
18:34:43	Muis:	What is the process to determine an address balance if you start from scratch?
18:35:01	Emcy:	yes i will get round to it
18:35:15	Muis:	Connect to a peer, set bloom filter, and request all blocks from block 0?
18:36:57	Muis:	Or can it be done even faster (without requesting every block)?
18:37:33	Emcy:	something something birthday
18:38:16	Luke-Jr:	Emcy: lol, you think I've been saying scrypt is a failure all this time for nothing? XD
18:38:38	Emcy:	ive been pretty harsh on litecoin too
18:38:48	Emcy:	but all ive ever got is "yeah whatever kid"
18:39:12	maaku:	Emcy: read andytoshi's doc. it does a good summary of the reasons why no scrypt of any kind is good
18:39:51	Emcy:	i came to the conclusion a while ago that actively trying to avoid optimisations or certains archs is futile
18:40:36	Emcy:	or even harmful since you raising the bar for doing it anyway via brute force some to very well resourced people whom you probably wouldnt want doing that
18:41:23	Emcy:	im not sure why litecoin didnt putter out the minute someone out a gpu miner out there
18:41:53	Emcy:	makes me wonder what would actually happen if bitcoin miners all got compelled to fork and add tax accounting and shit int he protocol
18:45:06	kazcw:	the protocol doesn't need tax accounting
18:45:12	kazcw:	that would go in the client
18:45:36	Emcy:	i mean more forcible
18:45:41	Emcy:	just an example
18:46:26	Emcy:	if you want another one then perhaps to pay tithe to scientology or something
18:46:34	Emcy:	would people care enough to cause a fuss lol
18:47:09	nsh:	andytoshi, i love that you conservatively leave room open for the possibility that the universe affords for infinite computational resources :)
18:47:24	nsh:	"it appears that computational resources are physically bounded by available time, space and energy"
18:48:56	Emcy:	a for objectivity
18:57:16	andytoshi:	nsh: i have been jumping between crypto, real analysis, and arguing about souls for the last week, i actually did not notice how silly that sounded :)
18:58:24	nsh:	must make for an interesting headspace
18:58:32	nsh:	:)
19:12:46	maaku:	nsh: well there's always the possibility of a break-out from the matrix
19:13:02	nsh:	true
19:13:59	maaku:	http://lesswrong.com/lw/qk/that_alien_message/
19:21:18	Emcy:	wow shit maaku i read that once and was looking for it ever since
19:21:25	Emcy:	n1 m8
19:22:11	Emcy:	i sort of subscribe to simulism so that stuff gives me a chubby
19:25:33	maaku:	Emcy: yeah although the setup is completely backwards. the time inside the simulation should run slower than outside
19:26:35	Emcy:	yeah
19:26:47	Emcy:	you know something strange happens to me when i sleep
19:26:50	nsh:	i'm not 100% convinced that inside-time and outside-time are even commensurate
19:27:04	Emcy:	in my dreams im likw 10x sharper and more witty and affable than irl.
19:27:12	nsh:	* nsh smiles
19:27:12	maaku:	nsh: ?
19:27:31	maaku:	well I suppose we can make no assumptions about the physics of an outside world
19:27:41	nsh:	right, they might have three temporal dimensions
19:27:47	nsh:	or something more bizarre still
19:27:53	Emcy:	and i thought my average subjective dream time is about 20 mins, map that onto absolute REM sleep dreaming of maybe 3 hours a night
19:28:07	Emcy:	so im getting 3 hours of brain time compressed into a subjective 20 mins
19:28:33	Emcy:	and i thought perhaps thats why all my jokes are cool and funny when im dreaming
19:28:43	maaku:	if we assume that they have laws of thermodynamics analagous to ours, then there's no way for our simulation to be running faster than their universe
19:28:49	maaku:	but that's an assumption
19:31:45	Emcy:	maaku you read the omega point story?
19:32:38	maaku:	Emcy: I don't know. Maybe? Is it by Yudkowsky?
19:35:39	gmaxwell:	Odd question but: Has anyone here ever looked into how hard it would be to implement a bit-reversed sha256 in software? That is— a function that takes in X^0xFFF... and outputs SHA256(X)^0xFFF...
19:36:18	sipa:	so a function x -> ~SHA256(~x) ?
19:36:26	maaku:	gmaxwell: just invert before and after right?
19:36:33	gmaxwell:	sipa: yep.
19:36:52	sipa:	i'm doubtful whether you can make that more efficient than just doing ~, sha256, ~
19:37:08	nsh:	* nsh muses
19:37:10	gmaxwell:	Right of course but can it be acceptably efficient without?
19:37:13	gmaxwell:	maaku: My motiviation is: making key derrivation code which is robust against faulty hardware. :)
19:37:51	nsh:	robust in what sense?
19:39:26	gmaxwell:	nsh: the concern is that in bitcoin we generate keys and then irreversably send large sums of funds to them. What happens if the generation is faulty and generates some key for which we do not know the private component for? While this is an unlikely problem faulty generation has been known to happen— so how can we make software which is much less likely to do it without unacceptable cost.
19:40:01	gmaxwell:	(e.g. the best practice would be to use multiple pieces of hardware but this has significant additional costs to users and so few will do it, in practice)
19:40:06	nsh:	right
19:40:10	maaku:	gmaxwell: test a signature after generation?
19:40:29	gmaxwell:	maaku: can't if you're doing a type-1-ish homorphic derrivation.
19:40:36	maaku:	ah
19:40:38	sipa:	type-2, you mean?
19:40:41	gmaxwell:	er right. :P
19:40:48	sipa:	(you invented this stuff)
19:40:51	maaku:	got what you meant though
19:41:14	gmaxwell:	Plus you might correctly sign and verify but you just computed a different key than another correct system.
19:42:09	gmaxwell:	So for the G multiply you can basically do (S*G)+(2*G) == (S+2)*G or the like. too be quite confident that the multiply is correct.
19:42:26	gmaxwell:	But I was wondering how you could be more confident that the HMAC-SHA512() was correct.
19:42:46	maaku:	does BIP32 use SHA512?
19:42:50	sipa:	yes
19:42:56	sipa:	hmac-sha512
19:43:10	gmaxwell:	obviously running it twice is the easy basic step... but it wouldn't catch something like one of the SHA512 constants in memory getting corrupted.
19:43:14	maaku:	that's one more primitive to add to the script 2.0 opcode list, gmaxwell
19:43:18	gmaxwell:	though you'd probably fail shortly thereafter.
19:44:51	gmaxwell:	maybe another approach would be some kind of bitslice sha512 though that would have a lot of overhead if you only wanted to sha512 one value. :)
19:45:22	maaku:	gmaxwell: test vectors?
19:45:38	sipa:	ha, run test vectors before and after every actual computation
19:45:41	gmaxwell:	yea, thats an interesting idea. Just always run it on a test vector after every computation.
19:45:49	gmaxwell:	I like that.
19:46:23	gmaxwell:	fortunately the computation of this stuff is stupidly fast so doing something like making it 4x slower is really no big deal.
19:47:17	gmaxwell:	the reason I was thinking about inverted sha256 was because differential logic is one technique that gets used to build higher reliablity hardware.
19:47:32	gmaxwell:	(it's also used to do things like decrease power side channels)
19:49:02	sipa:	it seems that all primitives used in sha256 are actually commutative with bit inverting
19:49:05	maaku:	i wonder what the minimal set of test vectors would be to make sure that you're protected from all algorithmic errors
19:49:11	sipa:	apart from addition
19:49:12	maaku:	probably one, but I wonder if you can prove that
19:49:19	sipa:	and fixed constants, of course
19:54:20	sipa:	soo... bitinvert(+)(x,y) = x+y+1
20:01:33	gmaxwell:	sipa: doh, I should have read here. I also reached the same conclusion and tested it on all values: http://0bin.net/paste/xuTEzLlADbggFrRD#LgkqFaNvAKfS7K9MYo+MWkLs3ytRu5m/u435mRscOUI=
20:02:04	sipa:	rotations and xors are unchanged
20:02:07	sipa:	and and or swap
20:02:17	sipa:	inversions are unchanged
20:02:46	gmaxwell:	so yea, I think a bitinverted sha2 must be trivial then.
20:07:43	sipa:	yup
20:11:51	gmaxwell:	the fun thing about having an inverted one is that you can store two copies of the chain code, one inverted, thus protecting the chain code in memory too.
20:18:59	gmaxwell:	too bad the order of the curve and sha2 are not the same or you could carry the inverted value all the way through and then add them and end end up with the point at infinity.
20:20:35	gmaxwell:	hm. though I suppose since you can promise that sha2(x) will be less than the order (otherwise you retry) you could have a bitflipped G* multiply table too.
20:21:20	sipa:	interesting
20:21:49	gmaxwell:	if both were run concurrently this might give some pretty strong power analysis immunity too.
20:23:17	nsh:	and if you run them with one reversed on the same gates simultaneously, it would totally reduce your power consumption
20:23:18	nsh:	:)
21:46:47	rdponticelli:	rdponticelli has left #bitcoin-wizards
22:00:54	jaekwon:	if we can have a global consensus on the ordering of arbitrary lines of data, then is that sufficient to host many coins?
22:01:30	jaekwon:	* er, to secure the consensus of multiple coins
22:02:20	jaekwon:	i suppose it is, in the sense of mastercoin or counterparty.
22:04:31	zooko:	zooko has left #bitcoin-wizards
22:05:30	Luke-Jr:	jaekwon: don't do that though
22:06:10	jaekwon:	why not, Luke-Jr?
22:06:29	Luke-Jr:	jaekwon: because we already have bitcoin?
22:06:41	Luke-Jr:	and it's not SPV-safe
22:06:42	Luke-Jr:	etc
22:08:17	Luke-Jr:	(also, there are better ways to do it)
22:08:28	jaekwon:	what's the better way to do it?
22:09:11	nsh:	jury's out
22:09:22	jaekwon:	or, what's the other ways to do it?
22:09:39	Luke-Jr:	jaekwon: merged mining
22:10:00	jaekwon:	i'm not a fan of PoW
22:10:16	jaekwon:	which might sound funny because that's the only scheme that works right now
22:10:20	Luke-Jr:	…
22:10:29	Luke-Jr:	abusing bitcoin's blockchain is still PoW
22:10:43	jaekwon:	i think i have something else.
22:11:27	Luke-Jr:	not if it relies on bitcoin; then you still have PoW
22:11:35	jaekwon:	it doesn't.
22:13:13	arubi:	jaekwon, why ordering in particular?
22:13:23	arubi:	what's the goal?
22:13:51	jaekwon:	i just mean to say "consensus".
22:14:04	jaekwon:	as in, a blockchain.
22:14:07	Luke-Jr:	jaekwon: you seem to be talking about two different things then
22:14:11	arubi:	can you think of a consensus system without a trusted party?>
22:14:15	Luke-Jr:	oh
22:14:23	Luke-Jr:	I misread your original statement
22:14:25	Luke-Jr:	that explains it
22:14:54	jaekwon:	arubi: without a trusted centralized party
22:15:02	arubi:	explain
22:15:16	arubi:	(please)
22:15:32	jaekwon:	i want to. let me get the kinks out and post it here when i'm ready.
22:15:57	arubi:	good luck, it's probably the holy grail of blockchains
22:16:04	jaekwon:	i know that.
22:16:06	arubi:	no pow, and no trus needed
22:16:18	arubi:	trust*
22:17:28	jaekwon:	it's not SPV-safe, that's a good point.
22:17:46	arubi:	at least one honest node must exist
22:17:56	Luke-Jr:	jaekwon: I think it can be made so, maybe.\
22:18:02	Luke-Jr:	jaekwon: but let's get the initial idea out :p
22:18:32	jaekwon:	yeah, but then you guys are going to go implement something in C++, and i just really prefer golang.
22:18:51	arubi:	just lay out the algorithm
22:18:56	arubi:	that should be enough
22:19:19	jaekwon:	are you suggesting that, given a consensus on a log of arbitrary data, you can create an SPV protocol on top?
22:19:46	jaekwon:	Luke-Jr, if so, that's interesting.
22:20:17	arubi:	jaekwon, as long as you have at least one trusted node on your list of peers that you can periodically check against, you should be fine even with every other node as malicious
22:20:27	Luke-Jr:	jaekwon: a SPV-safe protocol; then SPV becomes possible
22:20:33	arubi:	any other deal, and you'll have to check your own blockchain
22:20:48	arubi:	at least that's my final thoughts on this
22:21:15	jaekwon:	arubi: that's like ripple.
22:21:26	arubi:	yea, or bitshares
22:21:40	jaekwon:	luke-jr: what do you mean spv-safe?
22:21:49	arubi:	my only other idea was having a really easy pow
22:22:15	arubi:	easy on processing, hard to come by on your own
22:22:24	Luke-Jr:	jaekwon: I mean full nodes enforce rules on all content, and only recognise valid transactions
22:22:58	arubi:	Luke-Jr, that doesn't solve any other problems like censoring
22:23:30	sipa:	arubi: is SHA256 not 'really easy' ?
22:23:33	jaekwon:	luke-jr: right, except for coins built on top of the base coin layer, like mastercoin/counterparty, which don't get the SPV benefits.
22:23:39	Luke-Jr:	arubi: I never said it did.
22:23:54	Luke-Jr:	jaekwon: broken ideas are broken ideas.
22:23:56	sipa:	jaekwon: that's just (depending on your viewpoint) either wasteful or abuse
22:24:06	arubi:	sipa, the solution that's being searched is being found in no relation to other nodes
22:24:16	arubi:	Luke-Jr, agreed
22:24:20	sipa:	arubi: where?
22:24:34	jaekwon:	sipa: valid argument, but if people pay by the storage, then perhaps it's worth it.
22:24:46	sipa:	jaekwon: you can't pay for storage on my hard drive, as i don't mine
22:24:53	Luke-Jr:	jaekwon: you have a way to reimburse full nodes?
22:25:08	arubi:	sipa, well I'm searching for a solution that I'll more likely to come by if I invest more hashing power
22:25:10	Luke-Jr:	also, I don't want to store Joe's CP even if he pays me
22:25:21	jaekwon:	luke-jr: actually, yeah.
22:25:23	sipa:	arubi: how does bitcoin's sha256 not suffice?
22:25:57	sipa:	what problem are you trying to solve?
22:25:57	arubi:	sipa, not saying it doesn't, but not for a consensus system, that I think will take an easy pow as a must
22:26:14	sipa:	arubi: i have no idea what you're trying to achieve
22:26:25	arubi:	sipa, an easy pow meaning something that's not computational, but rather physical like storage space
22:26:32	jaekwon:	ok then. perhaps you suggest, that if i have this fancy new consensus algorithm, instead of trying to one-up ethereum or whatever, making it general, i should just make it one solid coin.
22:26:41	arubi:	but that's where Luke-Jr is right when he doesn't wanna host cp
22:26:49	sipa:	arubi: ok
22:27:18	Luke-Jr:	jaekwon: why make an altcoin at all?
22:27:21	jaekwon:	arubi: i'm not sure what you are trying to do is meaningful.
22:27:50	Luke-Jr:	jaekwon: if it's a good idea, why not just use it for bitcoin?
22:28:00	arubi:	jaekwon, bittorrent gets close with private trackers holding ratios for torrent seeding
22:28:01	jaekwon:	luke-jr: you can't remove pow from bitcoin.
22:28:11	Luke-Jr:	jaekwon: you can
22:28:13	arubi:	convert that into decentralized coins, and you're there
22:28:25	jaekwon:	luke-jr: think through the politics with the miners. no way.
22:28:41	Luke-Jr:	jaekwon: they won't care if they get the coin introduction
22:28:43	arubi:	jaekwon, miners follow code, or get forked
22:28:59	Luke-Jr:	arubi: miners follow economics*
22:29:25	arubi:	well yea, but what good is a forked bitcoin
22:29:43	arubi:	if they all defect, we're screwed, I agree
22:29:52	Luke-Jr:	actually
22:29:58	jaekwon:	besides, what i want to build is an ecosystem of many coins. small and large.
22:30:02	Luke-Jr:	if jaekwon's alternative means no miners are needed
22:30:10	Luke-Jr:	then we could ignore miners altogether really
22:30:17	arubi:	jaekwon, meh, multiple coins
22:30:19	Luke-Jr:	jaekwon: why?
22:30:59	Luke-Jr:	jaekwon: there are zero benefits to multiple incompatible coins using the same technology
22:31:11	jaekwon:	because i like the model of a company or startup, or group, crowdfunding via selling shares of "equity".
22:31:26	Luke-Jr:	all the possible benefits to incompatible altcoins, require different technologies
22:31:32	arubi:	just issue transaction signatures
22:31:43	arubi:	I'll happily take that then a bitcoin
22:31:43	Luke-Jr:	jaekwon: if you want a stock exchange, that isn't "coins"
22:31:50	arubi:	cash that out when I want to
22:31:58	jaekwon:	luke-jr: what do you mean
22:32:18	sipa:	Luke-Jr, jaekwon: but it's perfectly doable to have blockchain technology that supports private issuing
22:32:32	sipa:	jaekwon: and it's way more useful than doing it in a completely separate chain
22:32:41	Luke-Jr:	jaekwon: and centralised things don't need a consensus system
22:32:48	jaekwon:	sipa: yeah, that's what i mean.
22:33:13	sipa:	jaekwon: separate chains is almost certainly a bad idea
22:33:33	jaekwon:	a new share can be contractually bound to issue given cryptographic conditions, or stop issue at a certain time… then it's just a coin.
22:33:35	Luke-Jr:	sipa: O.o
22:33:47	sipa:	*completely separate, i mean
22:34:10	Luke-Jr:	sipa: a stock exchange should almost certainly use separate private blockchains for each stock, IMO :P
22:34:16	jaekwon:	luke-jr: it wouldn't be a centralized system, that's the point. the SEC would shut it down if it were.
22:34:19	sipa:	Luke-Jr: yup, fully agree
22:34:31	Luke-Jr:	jaekwon: how is it not?
22:34:39	Luke-Jr:	*someone* holds the value.
22:35:06	jaekwon:	luke-jr: that someone may be pseudonymous.
22:35:16	sipa:	you need to distinguish the centralization of issuing (which is inevitable, you need to trust someone to promise to pay back IOUs), and the centralization of exchanging
22:35:21	sipa:	the latter is possible
22:35:25	Luke-Jr:	jaekwon: a stock is only worth something, if you can get dividends or property in exchange for it. that's inherently centralised.
22:35:31	Luke-Jr:	even if the central party is pseudonymous
22:35:49	topynate:	this might be connected to stuff i've seen gmaxwell write about fungibility. if you send someone a stock inside a bitcoin transaction - and the bitcoin protocol acknowledges that, it's effectively a bitcoin transaction where a transaction output has encumbrances from the inputs.
22:36:03	sipa:	topynate: sounds like colored coins
22:36:04	topynate:	as in, the output must also carry the 'i am a stock' tag
22:36:40	arubi:	topynate, that sounds "dirty"
22:36:48	arubi:	to put in a blockchain I mean
22:37:01	topynate:	let me see if i can find a link
22:37:16	topynate:	gmaxwell hated the idea of inputs encumbering outputs btw
22:37:27	sipa:	you're talking about coincovenant
22:37:58	Luke-Jr:	topynate: I think that was a month or longer ago <.<
22:38:22	topynate:	yep
22:38:28	topynate:	wow, august 2013
22:38:34	topynate:	sipa: yep
22:42:26	topynate:	i suppose if you only make zero-value outputs capable of encumbering inputs, it might avoid the problem of capturing Bitcoin - as in Bitcoin value - inside encumbered transactions?
22:43:51	jaekwon:	luke-jr: if each stock were a separate chain, how would you secure each one?
22:43:52	sipa:	that assumes your scripting mechanism has an explicit way of disabling it
22:44:12	Luke-Jr:	jaekwon: the issuer signs each block
22:44:34	sipa:	that sounds not very useful
22:46:46	jaekwon:	luke-jr: oh right. i'm more interested in a system where the issuer doesn't.
22:47:16	jaekwon:	that way the shares are fungible & the issuer doesn't have to manage it
22:47:41	Luke-Jr:	jaekwon: they're no less fungible this way.
22:48:00	Luke-Jr:	and the issuer must manage it either way..
22:48:06	jaekwon:	if the issuer isn't available to sign a block, bob can't give alice his stock.
22:48:39	Luke-Jr:	sure he can
22:48:41	Luke-Jr:	just create a transaction
22:48:56	jaekwon:	how can alice know that bob won't doublespend?
22:49:17	jaekwon:	issuing is a independent of managing consensus.
22:50:02	Luke-Jr:	jaekwon: how can alice know the issuer won't allow bob to doublespend off the blockchain?
22:50:43	jaekwon:	alice can know, if the system managing consensus isn't the issuer, but a larger global network.
22:51:05	arubi:	jaekwon, that doesn't answer the question really
22:51:34	jaekwon:	just think of it as… how ethereum might be used to issue shares for many companies.
22:51:39	Luke-Jr:	jaekwon: Alice can't know the issuer won't say "I don't recognise this transaction, Bob already sold it off-chain"
22:51:48	Luke-Jr:	I didn't say Ethereum made sense either.
22:51:52	jaekwon:	except we don't care about the TC part
22:52:08	jaekwon:	nor the pow part.
22:53:08	jaekwon:	alice doesn't care what the issuer says. the issuer can only issue new shares, bound by contractual limitations enforced by another network.
22:53:14	maaku:	jaekwon: PoW isn't "the only scheme that works right now" - it's "the only scheme that works, period"
22:53:47	jaekwon:	maaku: there's no theoretical work that you can cite, that proves that.
22:53:48	arubi:	jaekwon, but the issuer also creates blocks, right?
22:54:19	Luke-Jr:	jaekwon: … the shares only have value if the issuer recognises them
22:54:24	jaekwon:	arubi: not in my system.
22:55:14	arubi:	jaekwon, does the issuer ultimately approves any transactions that have to do with his shares?
22:55:27	jaekwon:	luke-jr: that's a separate concern from whether the issuer needs to manage a blockchain for shares to be fungible in real time.
22:55:38	Luke-Jr:	jaekwon: no, it's not separate..
22:55:51	phantomcircuit:	Luke-Jr, the only advantage that im aware of is that you can prove the issuer is cheating you... but in nearly all cases that is not helpful
22:56:07	topynate:	jaekwon: the ethereum way is to program a centralized multi-company ledger and put that program on the blockchain
22:56:22	Luke-Jr:	phantomcircuit: you can prove that anyway, you have the transaction they aren't accepting
22:56:50	maaku:	jaekwon: there most certainly is. it's called 60 years of distributed systems research
22:56:57	jaekwon:	arubi: no.
22:57:12	phantomcircuit:	Luke-Jr, ah yeah you're right
22:57:27	maaku:	PoW only works because of economic incentives, and the 2nd law of thermodynamics
22:57:43	phantomcircuit:	Luke-Jr, there is still some marginal value to third parties being able to act independently of the issuer
22:57:44	jaekwon:	topynate: i like the ethereum way, but i'm wondering if i should find a way that doesn't involve TC scripts.
22:57:51	phantomcircuit:	but in general i dont think that would be legal anyways
22:58:00	phantomcircuit:	so it doesn't much matter outside of fake companies
22:58:01	maaku:	there isn't really any other law to use as a basis, and distributed systems research shows that without that economic baking it's an impossible task
22:58:06	phantomcircuit:	in which case it's entirely pointless
22:58:09	maaku:	so, qed. pow is the only option
22:58:39	Luke-Jr:	maaku: meh, I wouldn't rule out another breakthrough in theory. whether jaekwon has one, I highly doubt, but might as well look
22:58:45	maaku:	if you want the same properties of bitcoin
22:59:53	maaku:	Luke-Jr: i don't think so... security of bitcoin's pow comes not directly from its construction, but indirectly from the underlying physics
23:00:21	Luke-Jr:	maaku: not long ago, we were all sure the Earth orbitted the Sun (or vice-versa, if you still think that)
23:00:22	maaku:	strip out the entropy-based physical backing, and the task is impossible
23:00:40	maaku:	Luke-Jr: science progresses forward, not backwards
23:00:56	Luke-Jr:	maaku: my point exactly
23:01:13	Luke-Jr:	breakthroughs happen. things we never imagined before become possible
23:01:16	jaekwon:	maaku, you haven't provided a proof.
23:01:18	maaku:	i don't think you understood my point then. no new theory will overturn the fact that the earth goes about the sun
23:01:48	Luke-Jr:	maaku: that's off-topic, and why I provided the parenthesis
23:01:55	maaku:	jaekwon: because I'm already wasting more time than I should on IRC? I'm not going to go pull up citeseer and hunt references because someone is wrong on the internet
23:02:07	jaekwon:	maaku, you won't find such a thing.
23:02:19	jaekwon:	if you do, i'll make it worth your while and pay you say, 2 BTC.
23:02:28	jaekwon:	so go ahead.
23:02:35	jaekwon:	i'm known to pay what i promise to pay.
23:03:25	jaekwon:	of course the paper must be correct, not just some hand wavy argument like the one here.
23:03:41	phantomcircuit:	jaekwon, 2 btc is probably worth about 2.5 hours of his time as a consultant
23:03:42	Luke-Jr:	side note: if I was actually convinced PoW was the only solution, I'd probably give up on Bitcoin being viable. the end result of PoW is inherently spending over 50% of the world electric production on mining..
23:03:52	phantomcircuit:	im guessing proving something like that would take at least 4x that long
23:03:56	phantomcircuit:	that is all
23:04:02	maaku:	jaekwon: start with this : http://macs.citadel.edu/rudolphg/csci604/ImpossibilityofConsensus.pdf
23:06:03	jaekwon:	no, no. that paper has restrictive priors that don't apply to what we can build, namely, that all processes are deterministic.
23:06:09	jaekwon:	see counter: http://dl.acm.org/citation.cfm?id=806707
23:06:25	jaekwon:	intuitively, if that paper were correct, pow wouldn't work either.
23:08:56	maaku:	no pow works because the economic restriction provided by the 2nd law : even though you can't know you're in the consensus set, you can put a raw economic cost on the probability of you being tricked
23:09:11	maaku:	pow *fixes* the problem pointed out by this paper
23:10:06	jaekwon:	pow fixes what problem pointed out by the paper?
23:10:13	jaekwon:	the paper has no problem.
23:12:34	tromp:	jaekwon: so you and maaku disagree on whether NXT is secure
23:12:42	jaekwon:	i'm sorry. the paper *is* correct, i meant it doesn't apply to our conversation.
23:12:56	jaekwon:	no, we're probably in agreement that NXT isn't very secure.
23:13:36	Luke-Jr:	lol
23:13:43	Luke-Jr:	does anything think NXT is secure?
23:13:52	Luke-Jr:	anyone*
23:13:56	tromp:	i don't mention PPC because its PoS still involves nontrivial work
23:14:46	jaekwon:	Luke-Jr: some less privy to algorithms do, but then again, nobody has really quantified the (economic) upper bound on its security.
23:15:02	tromp:	i'd like to see a reasoned discussion between the NXT developers and those denouncing its secutiry:)
23:15:55	gmaxwell:	Luke-Jr: the limited code they released early before they released their code was very very obviously not secure. But perhaps they were able to fix it.
23:16:02	tromp:	at this time NXT isn't valuable enough to have its secutiry seriously challanged
23:16:10	Luke-Jr:	tromp: NXT has developers⁈
23:16:35	tromp:	i think the main one goes by the name of jeanlucpicard?!
23:17:42	tromp:	the released source had 3 planted bugs that have all been identified
23:18:13	tromp:	the last one getting the biggest bounty of 100k NXT
23:18:23	Luke-Jr:	"planted"
23:18:35	jaekwon:	so, NXT uses a variant of days-destroyed, i think?
23:20:13	jaekwon:	oh no. NXT uses a scheme that selects the next block-issuer.
23:20:19	gmaxwell:	Luke-Jr: I strongly disagree with your end result comment. Thats like arguing that the end result of guarded bank vaults is spending 50% of the worlds resources on valuts and guns for guards (otherwise attackers with _more_ guns can over power them)... it turns out thst people want to do other things than attack and defend, so the only defense you need is enough so that you overpower the attacks... resources tied up doing other ...
23:20:25	gmaxwell:	... things than attacking or defending are out of the picture.
23:21:03	Luke-Jr:	gmaxwell: I'm assuming no upper bound on bitcoin value.
23:21:05	gmaxwell:	jaekwon: the early released source had an issue where you could just grind your block to select yourself as the next miner and so on (same issue PPC had). The code was even setup so you could pretty trivally modify it to do that.
23:21:26	tromp:	gmaxwell: that'
23:21:33	tromp:	gmaxwell: that was the last flaw found
23:21:38	jaekwon:	it has some exponential time function to determine how much to lower the difficulty requirement. of course it doesn't work because "nothing is at stake".
23:22:05	tromp:	seems you should've won that 100k NXT:)
23:22:10	jaekwon:	gmaxwell: ah. all kinds of issues.
23:22:13	gmaxwell:	tromp: I mean, I pointed this out publically months before their full source release. But it's a deep problem which isn't easily fixed completly. PPC 'fixed' it by forever putting PoW in the loop.
23:22:45	tromp:	they clasim the fix is some kind of deterministic signature
23:22:49	gmaxwell:	lol
23:22:53	Luke-Jr:	O.o
23:22:59	sipa:	jaekwon, maaku: fwiw, if you want a system with bitcoin's security properties, i believe that propf of work is the only option. i don't have nearly read enough research to prove that so won't claim it as a fact, but i believe that the only way to obtain probabilistic consensus is to commit to one branch with resources otherwise lost (work being the only fair one i can imagine) and that resource cannot be defined by the chain itself
23:23:04	gmaxwell:	tromp: a determinstic ECDSA is not possible.
23:23:18	Luke-Jr:	gmaxwell: not provable* ?
23:23:43	gmaxwell:	maybe they're using a single show signature. That might be interesting.
23:23:43	sipa:	jaekwon, maaku: that does not exclude completely different ssystems with different assumptions and properties which may be even more useful
23:23:44	tromp:	well, the official "true" source code release is April 3.
23:24:08	gmaxwell:	tromp: they released a chunk of code before the network was available and it had this issue.
23:24:11	Luke-Jr:	gmaxwell: you could still grind a dummy transaction, no?
23:24:23	jaekwon:	sipa: i think we agree on the assumptions. i still think I might have a solution that doesn't require PoW.
23:24:26	gmaxwell:	Luke-Jr: I don't know, I just observed you could grind the ECDSA.
23:24:50	sipa:	jaekwon: for which problem?
23:24:52	jaekwon:	with comparable strength as bitcoin's PoW.
23:25:00	gmaxwell:	Luke-Jr: I actually think they set it up so that only the signature is used to decide the winner.
23:25:26	Luke-Jr:	a real fix would IMO be something where you didn't know the miner for block X until block X-1, but it was based on the results from block X-100..X-1
23:25:28	jaekwon:	sipa: what do you mean? the same problem that bitcoin's pow solves.
23:25:35	gmaxwell:	jaekwon: a _lot_ of people have thought this. The problem is that its relatively easy to slather on obfscuation so that it take a lot of work to show it not secure— but without actually making it secure.
23:25:36	Luke-Jr:	gmaxwell: lol
23:25:53	Luke-Jr:	gmaxwell: but the signature still changes based on the transactions inside, I'd hope
23:25:58	sipa:	jaekwon: then i'm very interested in hearing but, but very skeptical :)
23:26:31	jaekwon:	gmaxwell: would you like to read the draft when i write it?
23:26:35	gmaxwell:	Sure.
23:26:41	tromp:	you can make a system so simple that there's obviously no bugs, or so complex that there's no obvious bugs:)
23:26:58	gmaxwell:	But I can't promise to analyize it. As I said, it may be very difficult to analyize it. :(
23:27:03	jaekwon:	sipa: i'm also skeptical. i know what it's like to fool myself. i only say that i might have a solution.
23:27:20	gmaxwell:	well thats a good perspective at least.
23:27:36	gmaxwell:	the folks who are convinced they couldn't possibly be wrong are basically impossible to work with.
23:27:46	jaekwon:	:)
23:28:53	gmaxwell:	jaekwon: when you write it up be sure to be clear on your assumptions and limitations. E.g. if past participants of the system can censor future participants from joining.
23:29:21	maaku:	sipa, jaekwon: my physics-based understanding of bitcoin is that uses work to tie bitcoin consensus to a fundamentally scarce resource: entropy
23:30:10	maaku:	it is possible to use other physically scarce resource instead, but there is no alternative with the universal scarcity of entropy
23:30:41	arubi:	maaku, it wouldn't matter if energy was free
23:30:42	arubi:	the problem itself is a search problem
23:31:25	maaku:	arubi: sure it would matter. if energy were free you could do infinite search
23:31:58	arubi:	well free and infinite is too out there, really cheap is what I meant
23:32:25	maaku:	really cheap is not free
23:32:51	arubi:	right, there is no free energy as there's no infinite search
23:33:00	maaku:	yeah the two go hand in hand
23:33:10	maaku:	which is where bitcoin derives its security properties from
23:33:40	arubi:	but still no end in sight for more efficient asics
23:33:51	arubi:	the math is still the same though
23:34:00	maaku:	you could make scarcity with some sort of artificial construction, but if it is not rooted in work than you are strictly speaking introducing additional assumptions into the model
23:34:18	gmaxwell:	things like hardware efficiency are just twiddling around constant factors, at the end of the day you're still converting energy into proofs.
23:34:51	maaku:	arubi: there is an ultimate end, although perhaps over the horizon. there are fundamental costs to computation
23:35:12	gmaxwell:	An interesting observation is that if we had a true strong publically verifyable captcha— so that a human had to mine— you're still ultimately turning energy into proofs (e.g. instead you could mine by having baby farms where you turn out more people to solve the captchas. :) )
23:35:41	maaku:	gmaxwell: chinese gold farmers...
23:36:00	gmaxwell:	maaku: well maybe there are fundimental costs to computation. Certantly there are fundimental costs to the kinds of computation we actually know how to do. And there are fundimental costs to any computation that has output or is error free.
23:36:25	arubi:	maaku, I think we'll have to come up with some new math to really make bitcoin obsoloete
23:36:29	arubi:	obsolete*
23:36:55	arubi:	energy really is practically free
23:37:00	gmaxwell:	but bitcoin itself solved an impossible problem by relaxing some constraints, so perhaps there are relaxations or changes that are just as useful but make other things work.
23:37:52	sipa:	exactly
23:38:18	sipa:	bitcoin's pow is (afaik) the only type that solves the problem that bitcoin tries to solve
23:38:31	sipa:	but that may not be the only interesting or useful problem
23:40:36	maaku:	sipa: hashcash is interesting because it achieves universalality of the proof-of-work, assuming no breakage of SHA-256^2
23:41:30	maaku:	i could be an AI trapped in a simulation with no knowledge of the outside world other than the foundational laws of physics, and from that be able to assert the validity of proof-of-work
23:41:38	gmaxwell:	amiller and adam3us both like to point out that Bitcoin's POW actually only work with a subset of hashcash solutions.
23:41:56	gmaxwell:	yea, it's nice that a header POW is compelling all on its own.
23:42:17	gmaxwell:	(the subset point: e.g. low variance hashcash versions also prove work, but are not sutiable for bitcoin)
23:42:32	maaku:	but yes, in real life maybe we could design an alternative construction which was in some way dependent on the actual details of the world we inhabit, but still secure with those added assumptions
23:43:10	maaku:	it wouldn't convince an alien intelligence, but it may work for our terrestrial economy
23:43:22	gmaxwell:	maaku: well for example, I think that a relaxation which requires that all nodes 'somehow' have a consensus about the long ago state is probably viable, for some definition of long ago.
23:44:22	gmaxwell:	their is some time horizon under which all of man kind is very strongly and unjammably connected... though it might be years, that horizion probably actually exists.
23:46:19	gmaxwell:	andytoshi: your PoW whitepaper problably needs some points on why progress freeness and high variance are requirements.
23:46:20	maaku:	at the other extreme there's also possibilities for things like quantum consensus, where you entangle photons to 'somehow' force consensus on binary decisions
23:46:31	maaku:	which would be secure for the people involved, but not demonstratable after the fact
23:47:17	tromp:	gmaxwell: do you have a url or reference for andy's whitepaper?
23:47:23	gmaxwell:	(both are highly related (identical?) factors that go hand and hand: progress freeness prevents it from being a race where the fastest always wins. or you can talk about variance being required to create convergence instead of risking getting consecutive ties)
23:47:32	gmaxwell:	tromp: https://download.wpsoftware.net/bitcoin/asic-faq.pdf
23:47:48	gmaxwell:	maaku: have you seen the 'quantum money' papers?
23:47:57	tromp:	thx
23:48:39	maaku:	no, but i know of them. the lack of demonstrability seemed like academic wankery so I never read them. maybe i should
23:49:03	gmaxwell:	maaku: the general idea there, I think, is that you have something like a physical level one time signature. It's all pure conjecture and wankery making all kinds of assumptions about things we have no clue how to engineer.
23:49:52	gmaxwell:	But basically if we could someout stably store some qbits and do some operations on them, then the mathmatics appear to allow for a kind of way to have a random key which can be non-destructively queried to identify it, but then can only sign through a destructive process.
23:50:34	gmaxwell:	but any such money is inherently local, a kind of cash.
23:50:56	andytoshi:	tch
23:54:44	topynate:	has anyone tried to do something like that with economic guarantees instead of physical ones? you could try something with a ZKP
23:54:51	maaku:	interesting
23:55:49	topynate:	each participant can prove consensus, and each participant also knows that if anyone else reveals his proof, that can be used to access funds he controls
23:55:57	topynate:	something like that
23:57:46	gmaxwell:	topynate: zooko was talking about things along those lines, generally this ideas run into problems that if you're controlling the state via your misdeeds you can just jam the attempts to reveal them (e.g. don't let them mine the bond captures)
23:58:06	gmaxwell:	or you can at least double spend them— but there may be a way involving long quieting periods.
23:58:18	gmaxwell:	But the way zooko described it had a censorship problem.
23:59:10	gmaxwell:	E.g. you first mine a special transaction which locks up your funds for some long time, but after the lockup is good and burried you gain the possibility of mining. Your funds stay locked for a long time after you are eligible to mine, and if someone can prove your mined two blocks your funds are lost.
23:59:37	gmaxwell:	but the issue that arose which I couldn't figure out how to solve was that prior minors could just censor your initial mining bond.
23:59:53	gmaxwell:	er haha. s/minors/miners/