00:00:33	Taek42:	The hard part I think is being able to validate an entire history of consensus without having a clear validation of economic exertion. It's easy to fake depth on all non-POW models I'm aware of.
00:43:11	tacotime:	tacotime is now known as Guest84227
00:54:03	Guest84227:	Guest84227 is now known as tacotime_
00:54:06	tacotime_:	tacotime_ is now known as tacotime__
01:31:47	bsm117532:	justanotheruser: yes. Taek42: there must be economic exertion.
02:57:51	super3:	tacotime__: you there?
03:43:35	tacotime__:	super3: yeah
03:43:42	tacotime__:	whats up?
03:49:52	super3:	never was able to contact the guy you suggested
04:03:27	tacotime__:	he didn't reply?
04:04:32	tacotime__:	tacotime__ is now known as tacotime
07:10:53	Eliel:	I think I'd prefer a model where the system uses blockchain to provide reputation database for the systems storing files. The system has clients and storage nodes. Clients make storage contracts with storage nodes. Reputation is formed through renewed contracts.
07:11:32	Eliel:	of course, this requires a working micropayment mechanism.
08:05:14	sendak.freenode.net:	topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
08:05:14	sendak.freenode.net:	Users on #bitcoin-wizards: andy-logbot irclouis wallet42 dansmith_btc bsm117532 Aquent CoinHeavy AaronvanW devrandom [Derek] damethos wiretapped Dr-G2 Graftec pen TheSeven ebfull todaystomorrow mr_burdell atgreen tacotime roconnor nuke1989 qualiabyte fanquake spinza_ l_l_l_l_l warren jchp_ Graet HaltingState Emcy grubles GAit go1111111 skinnkavaj epscy jbenet UukGoblin espes__ Taek42 sipa OneFixt Luke-Jr artifexd nsh coryfields michagogo licnep BlueMatt [\\\] zlinn_
08:05:14	sendak.freenode.net:	Users on #bitcoin-wizards: Sangheili dgenr8 [d__d] SDCDev midnightmagic mappum super3 jaekwon drawingthesun Iriez bobke postpre nsh- ericp4 copumpkin Adohgg zenojis pajarillo bbrittain crescend1 jgarzik SomeoneWeird waxwing HM maaku Krellan phantomcircuit sl01 asoltys azariah4 zibbo gmaxwell samson_ Keefe Fistful_of_coins DoctorBTC poggy harrow kmels Hunger- Grishnakh Muis tromp CryptOprah_ digitalmagus7 rs0 iddo btc_ Dyaheon @ChanServ Apocalyptic lianj wumpus nkuttler
08:05:15	sendak.freenode.net:	Users on #bitcoin-wizards: gribble phedny so kinlo wizkid057 petertodd jcorgan optimator_ burcin LaptopZZ_ danneu amiller catcow a5m0 TD-Linux lechuga_ abc56889 weex Guest50253 helo Anduck pigeons smooth otoburb BrainOverfl0w gwillen EasyAt kanzure ryan-c pi07r jaromil comboy LarsLarsen tromp__ tucenaber Starsoccer Logicwax nanotube nickler_ Alanius K1773R Transisto BigBitz Guest47516 throughnothing CodeShark eAndrius Eliel mmozeiko Meeh andytoshi berndj-blackout
08:05:15	sendak.freenode.net:	Users on #bitcoin-wizards: roasbeef
10:30:14	Brizo:	Brizo has left #bitcoin-wizards
11:15:51	wallet42:	wallet42 is now known as Guest28644
11:15:51	wallet421:	wallet421 is now known as wallet42
11:35:20	amiller:	anyone seen this paper: http://alumni.syssec.ch/~karameg/ezc.pdf Hiding Tranasction Amounts and Balances in Bitcoin?
11:36:00	amiller:	adam3us and gmaxwell especially i guess, i'm trying to get more comfortable with the details of ZK protocols like this but still novice at it.
11:36:19	amiller:	the main idea is that this is an extension of zerocoin rather than zerocash, but it provides some of the functionality of zerocash
11:36:56	amiller:	in particular it uses the same RSA accumulator as zerocoin, and it uses ordinary zero knowledge discrete log proofs
11:36:59	amiller:	(not snarks)
11:38:02	amiller:	the main new thing is it lets you do spends of arbitrary amounts, not just fixed unit sizes
12:41:24	andytoshi:	amiller: do you know the date on that paper?
12:41:34	amiller:	andytoshi, june 2014
12:41:51	andytoshi:	thx
13:04:38	amiller:	i think the double discrete log proof from zerocoin that they said was novel is subsumed by this from 2010 http://link.springer.com/chapter/10.1007/978-3-642-14081-5_22#page-3
13:22:38	amiller:	on the other hand, the extension from Hiding Transaction Amounts and Balances in Bitcoin seems not much different than rational zero https://fc14.ifca.ai/bitcoin/papers/bitcoin14_submission_12.pdf
13:24:39	ericp4:	ericp4 has left #bitcoin-wizards
13:48:47	jgarzik:	Having quite a bit of fun flaming the NXT people on twitter
13:49:13	jgarzik:	They sure dig in their heels when you point out all the flaws in their closed dev process
13:52:24	fanquake_:	fanquake_ is now known as fanquake
14:18:48	Taek42:	Eliel there's a major advantage to having a giant network of databases that you distribute files randomly throughout. Without needing to know anything about the reputation or reliability of individual machines/parties, you can make assumptions about the reliability of the files you upload based on the overall reliability of the network, because it's a random process. You also gain access to massively parallel uploading and downloading, which
14:18:48	Taek42:	means you can have high throughput and low latency without needing to manage the reputation of many different nodes.
14:23:04	Taek42:	Paul Brody: "We are forking Ethereum", https://twitter.com/pbrody/status/510311550734073856
14:25:12	pigeons:	"“Side chains remain a conceptual, unproven technology today, as there aren’t yet in any production that you can point to." Yest somehow production ethereum is more than conceptual and unproven to Adept
14:25:30	epscy:	how can you fork vapour ware
14:26:01	amiller:	IBM could fork their yellow paper -> blue paper?
14:26:06	fanquake_:	fanquake_ is now known as fanquake
14:27:22	Eliel:	Taek42: From the user's perspective, certainly. Users won't want to know the specifics. But if you have a functional market that provides reputation database functionality, that's easily automated.
14:29:13	Taek42:	Bluthereum
14:32:40	Taek42:	Do any good reputation systems exist? As far as I was aware decentralized reputation systems aren't ready for primetime. If you had the reputation problem solved, you could replace Uber and Airbnb, and potentially ZipCar and other such services.
14:34:27	epscy:	Taek42: yeah WoT hasn't ever really taken off
14:34:47	Taek42:	WoT?
14:35:08	Taek42:	oh web of trust
14:38:44	pigeons:	the next/distributed version is discussed in #bitcoin-wot and http://privwiki.dreamhosters.com/wiki/Distributed_Web_of_Trust_Proposal_2
14:44:48	tacotime:	adept sounds like something sold in a boardroom to much fanfare, but which doesn't really have much grounding in reality. it's impossible to know what the user demand will actually be like for ethereum.
14:50:27	epscy:	oh there is actually ethereum code on github
14:51:41	tacotime:	epscy: yeah, lots. there's a c++, python, and golang implementation.
14:52:07	tacotime:	and now java too it looks like.
14:55:34	tacotime:	there's a python like language for contract generation too, though I haven't played with it much: https://github.com/ethereum/serpent
14:56:59	pigeons:	i wonder about the decision to fork, you would think ethereum and adept would benefit from a combined larger system
14:57:25	Taek42:	IBM probably wants to build a closed ecosystem
14:57:35	Taek42:	it seems to be all the rage with large corporations these days
14:57:57	tacotime:	heh, looks like vitalik did some weird metaprogramming, as he made in-blockchain ecc: https://github.com/ethereum/serpent/tree/master/examples/ecc
14:58:53	bsm117532:	It just occurred to me that merged mining has exactly the same problem as PoS (in that nothing is at stake).
14:59:13	bsm117532:	Merged mining allows a miner to mine on more than one fork at the same time, and destroys the consensus mechanism of PoW.
14:59:18	bsm117532:	Is this generally known?
15:00:21	Taek42:	Is that true? I thought you just put the header of the previous block of your merged chain in the nonce section of the Bitcoin chain.
15:01:38	amiller:	bsm117532, yes, at least petertodd and i like to point out variations of this occasionally
15:01:48	amiller:	er maybe bsm117532 is trying to say something else, that in a *single attempt* you can merge mine on multiple different forks, i don't think that's the case but would be interesting if it was
15:04:27	pigeons:	the "effort" or computation/energy is greater with pow than stake fork simulation though?
15:16:26	Eliel:	bsm117532: I'm not absolutely certain of this but I got the impression that there were some kind of a rule in the merged mining process that allows only one merge mined block to be valid for a particular chain.
16:01:56	DoctorBTC:	DoctorBTC is now known as Guest59781
16:06:13	Dr-G2:	Dr-G2 is now known as Dr-G
16:23:43	Taek42:	Proving storage on an empty disk:
16:24:00	Taek42:	take some random seed hash
16:24:19	Taek42:	oh wait nvm
16:24:58	Taek42:	is there some simple scheme for filling a disk with random data, such that someone can do proof of storage on it, while being required to actually store the data?
16:25:06	Taek42:	like a proof-of-empty-disk-space?
16:26:13	Taek42:	if you use sequentially computed storage, everyone has to do the computation at least once to get the merkle root, which is too costly
16:27:54	grubles:	Taek42, https://bitcointalk.org/index.php?topic=731923.0 <- something like this?
16:28:57	Taek42:	Is their crypto trusted?
16:29:31	grubles:	* grubles shrugs
16:30:51	Taek42:	hmm. But yeah that's the general idea.
16:31:10	grubles:	yeah I thought it sounded like what you were talking about
16:59:47	Taek42:	http://pastebin.com/GJwhq1Mu
17:00:40	Taek42:	^ Potential approach for proof-of-capacity. I'm not convinced that burstcoin has a proper solution
17:03:35	devrando1:	devrando1 is now known as devrandom
17:07:16	bsm117532:	Taek42: won't it be the case that everyone interacting with this system has the stored data?
17:07:36	bsm117532:	If not, it becomes a problem of finding a function that is easy-to-verify, *without* having the storage.
17:07:50	Taek42:	no not at all
17:08:13	bsm117532:	I mean, I could make a challenge-response to see if a node had *my* data (because I have it too)
17:08:33	bsm117532:	Or nodes mirroring the same data could challenge each other.
17:08:52	Taek42:	so, thanks to merkle trees, you can make a challenge on storage without ever knowing what it is
17:09:22	Taek42:	you only need some way of knowing that the data underneath the merkle tree follows the rules set up for storing it
17:09:38	bsm117532:	Certain challenges, yes. But if I wanted to test if a node had my data, I'd ask for a hash of a subset that's not in the Merkle tree.
17:10:00	bsm117532:	(Otherwise it might just be storing the Merkle tree but not the data)
17:10:29	Taek42:	?? I think you misunderstand
17:10:43	Taek42:	For the merkle tree, you take every 32 bytes of the original data and hash it
17:11:03	Taek42:	and you take neighboring hashes and append them and hash them to get a new hash
17:11:07	Taek42:	forming a tree with a root
17:11:19	bsm117532:	Sure
17:11:25	Taek42:	Then you can request that a host prove they have some random index within your data
17:11:42	Taek42:	if they can provide that, then they must have at least that index
17:11:43	bsm117532:	Yes but how do you know they didn't just store the tree and dump the data?
17:12:05	Taek42:	so, if you request a number of random indexes
17:12:08	jtimon:	maybe we should link to https://botbot.me/freenode/bitcoin-wizards for the logs?
17:12:10	bsm117532:	If I wanted to know if they had it, I'd request them to concatenate several subsets of the data and hash them.
17:12:28	bsm117532:	(e.g. anything that can't be derived from the Merkle tree)
17:12:38	Taek42:	but then you also have to have the data
17:12:48	Taek42:	IE you have to be able to compute the result yourself
17:12:48	bsm117532:	I'm not sure if this is relevant at all for your concerns though.
17:12:52	bsm117532:	Yes.
17:13:09	Taek42:	with the merkle tree approach, if someone can provide proofs on say, 10 random indexes in a row
17:13:13	bsm117532:	Do you have a function that requires the data to compute, but can be verified *without* the data?
17:13:19	Taek42:	then there's a very low chance that they've thrown out your data
17:13:32	bsm117532:	No, they could just compute the tree and dump all the data.
17:13:36	bsm117532:	It's called a bittorrent file...
17:13:59	Taek42:	with the initial index being 32 bytes, the whole tree would be the same size as the file
17:14:19	Taek42:	but you are also still requiring that they provide a small portion of the original data with each request
17:14:28	Taek42:	if they dumped the data, they couldn't provide the small portion of original data
17:14:33	bsm117532:	So then me (as client) would need to pick a subset of hashes to store, that I'll use to interrogate the storage system...
17:14:50	bsm117532:	(Because me as client doesn't want to store the whole dataset)
17:15:35	bsm117532:	So then this random subset of the hashes that the client stores becomes a kind of "private key" for verifying if the servers are storing data.
17:15:45	bsm117532:	But in order to interrogate the system you have to reveal your private key. :-(
17:15:46	Taek42:	There's a paper called 'Compact Proofs of Retrievability' that might be relevant, but I haven't read it yet.
17:16:24	Taek42:	I believe that they've found a better way to do things than either merkle trees or single use proofs (which is what your solution is)
17:25:13	midnightmagic:	I thought you can't mine two identical chainid at once. the downstream won't accept it..?
17:26:55	bsm117532:	38 pages. Hmm...
17:33:04	gmaxwell:	Taek42: that pastebin is too underspecified for me. "A random 32 bytes is chosen" how? by whom? Why can't I grind this stuff?
17:37:49	bsm117532:	Taek42: Why not have the client request a Bloom filter of their data?
17:38:22	bsm117532:	Then the client could store a handful of hashes and verify that the Bloom filter contains them...
17:39:38	bsm117532:	I think the Shachaum/Waters paper is a variation on this...the client is still storing a subset of hashes, but blinds them using some magic on Z_p instead.
17:57:31	Taek42:	bsm I don't think that bloom filters are cryptographic
17:58:37	Taek42:	gmaxwell 'random 32 bytes' would be assigned by the network. If you have access to POW in some way (or just by borrowing Bitcoin), you could use the hash of a future block, which would prevent grinding
17:59:18	Taek42:	Actually
17:59:35	Taek42:	you could just use the hash of the previous state under any set of consensus
17:59:49	Taek42:	because the random number doesn't need to be "random", it just needs to not have a collison with already known data
18:00:19	Taek42:	hashes are good at that. As long as there is some small volume of uncontrolled data in the previous block, then you can't grind it to get a desirable result
18:00:23	bsm117532:	Taek42: Bloom filters are not cryptographic. But they allow the user to query any hash to see if it's in the set.
18:01:13	bsm117532:	(without revealing what they're querying)
18:03:34	gmaxwell:	Taek42: assuming you're using this for consensus you cannot use the state under consensus and avoid grinding.
18:04:21	bsm117532:	Taek42, gmaxwell: exactly. Grinding is constructing an alternate history. If you use the previous block I just need to grind two blocks instead of one.
18:07:09	Taek42:	The intent is not to use the POC for consensus, just to have some reassurance that there's empty space on a disk which could be later used for hosting a file.
18:07:52	Taek42:	I think that we're going to end up securing consensus by using a POW blockchain containing hashes of whatever the current network state is
18:08:22	Taek42:	that way constructing alternate histories requires rewriting the POW history too
18:10:35	bsm117532:	So Taek42: what benefit does blockchain bring to storage technology?
18:10:45	gmaxwell:	Taek42: what does "forms the basis" mean?
18:10:49	bsm117532:	There are lots of distributed/replicated/federated storage solutions out there (that are centralized).
18:13:30	Taek42:	So, you have a 32 byte seed, which we assume is not a collision of any other seed used by other machines. (this is pretty easy, you just combine entropy sources, as long is one is good, no collision is possible). Then you take that seed and hash it repeatedly. Each hash is stored as the next 32 bytes on disk. While saving these to disk, you create a merkle tree. You present the root of the merkle tree to the network, giving a proof that the 32
18:13:30	Taek42:	byte seed (which was generated for them) is a part of the root.
18:14:02	gmaxwell:	oh now I understand what you're actually trying to do.
18:14:57	bsm117532:	aaaaahhh
18:15:00	Taek42:	ok cool. The problem with this is since you generated the data by hashing, you can regenrate it by hashing when asked for a proof. So you have to make sure the proof would result in an unreasonable amount of hashing
18:15:06	bsm117532:	That's for *empty* space.
18:15:23	Taek42:	yeah lol we're trying to prove that someone has empty space
18:15:35	bsm117532:	I was trying to prove someone has my porn collection.
18:15:46	gmaxwell:	So before I point you to where it's already described; ... how do you know that the random data returned in a query came from that seed?
18:15:54	gmaxwell:	without doing the linear work to regenerate all that data.
18:16:17	bsm117532:	Taek42 needs a new algorithm. I don't think you can do it with that one.
18:16:56	Taek42:	well I just took a probabilistic approach. If they can provide 2 indices in a row that both fit in the merkle root that you calculated earlier, and one is the hash of the previous, then for at least that little piece you followed the rules
18:17:18	Taek42:	of course, now you need an actual source of non-grindable random numbers
18:17:20	gmaxwell:	https://bitcointalk.org/index.php?topic=310323.0
18:17:25	Taek42:	because we're picking indices at random
18:18:12	gmaxwell:	Taek42: but that means I could use any seed I want and meet that criteria, e.g. using someone elses storage.
18:19:14	Taek42:	how can you use any seed you want? The seed is forced upon you by the network. (thanks for the link btw)
18:23:10	Taek42:	Also (not sure if this is what you meant) we don't care where the storage comes from. If you can write to it and read from it without interference, that's good enough for us.
18:23:37	gmaxwell:	Taek42: it's not, you ask me to do a query, I return you two successive bytes ... They follow the succession rule, but I didn't store anything.
18:24:25	gmaxwell:	I just used someone else's data the followed the succession rule but started from a different seed.
18:24:28	Taek42:	they have to match the merkle-root you provided when you generated the data, you have to also supply the hashes for the merkle-proofs.
18:24:50	Taek42:	So, your input is a seed, and at some point later you return a merkle root, which can be whatever you want
18:25:05	gmaxwell:	Yea, great. so I just return you bob's merkle root.
18:25:47	gmaxwell:	and you give me a query, and I just return bob's data to you.
18:26:57	Taek42:	oh right. You have to initially prove that the seed you were given is a part of the merkle tree, but I guess you could just switch to Bob's data at some random point early in the data. As long as you aren't challenged on that exact point of transition, you'll be safe from detection
18:27:02	Taek42:	I see the issue
18:31:04	Taek42:	I don't understand how the system in your post works. Why does the client need to sort the data?
18:33:30	gmaxwell:	Taek42: To make it efficiently seekable (e.g. don't have to read all the data to find the requested element)
18:34:22	Taek42:	oh. So you say 'what index is has abcdef at?'
18:34:31	Taek42:	*hash abcdef
18:35:03	gmaxwell:	yes. the queryier picks an index, figures out what data shoul be there... asks you to find that data, and you return the index.
18:35:23	gmaxwell:	Though if you use it like you want to use it, it's forgable in that someone can MITM someone else to claim credit for their space.
18:36:29	Taek42:	I was planning on having a blockchain pick the index, which wouldn't work because then everyone knows the index.
18:44:33	hashtag:	Is this a good channel to discuss ideas regarding future uses of the blockchain and what systems might employ a distributed ledger such as the one existing with the Bitcoin protocol?
18:45:12	gmaxwell:	I don't believe it's possible to construct such a thing where there isn't a 'secret' that trapdoors it... not if the proof verification is cheaper than the proof creation.
18:45:44	gmaxwell:	hashtag: potentially, but take care to not wear out people's patience. There are many things where the technology seems inapplicable.
18:49:38	Taek42:	You're approach is essentially to take a bunch of random items and put them in a set that takes X storage to store. Then you have some way to pick an item at random from the set. To do this publically, you'd need some way to pick an item that's guaranteed to be in the set without knowing what process placed it into the set.
18:50:01	Taek42:	I guess that's not terribly promising
19:00:54	hashtag:	this may seem a bit abstract, but how applicable would the technology be in providing the basis for a system that can help resolve/facilitate loadbearing/traffic management in a dynamic system? Kind of like load balancing in a large wi-fi network, but where currency would pay for a better access
19:02:08	gmaxwell:	hashtag: systems like that don't usually need a global consensus for their actual balancing.
19:03:00	sipa:	also, loadbalancing is usually done between well-identified nodes that trust it eachother
19:03:03	gmaxwell:	Generally a problem that arises is that the cost of doing the transactions (however it works) dwarfs the rest.
19:03:13	Taek42:	hashtag are you familiar with microchannel payments? That could help.
19:03:29	sipa:	sure you can use a digital currency for payment for the service, but for the service itself it seems hardly useful
19:11:05	hashtag:	my specific imagining of it would be with physical traffic. This of course is several years down the road. The transactions would happen between vehicles. With automatic cars on the way and V2V communication being a huge part of that, say someone would want to pay a premium to get somewhere faster, so the traffic balancing would allow a slight priority for that vehicle, and maybe someone is willing to get somewhere slower...
19:11:05	hashtag:	they could be 'tipped' by the high-priority vehicle for letting them through... so it involves real currency and real value (time), in microtransactions. The current max. transactions/second cap would have to increase, but maybe this could be an off-chain system? With transactions being communicated to the main network when the vehicles connect to a wi-fi network?
19:11:44	hashtag:	feel free to shoot holes in the idea, it's just a tought I had in the shower a while back
19:12:59	Taek42:	so if you have each car establish a microchannel payment system with the highway, and each lane costs a different amount to use (perhaps the 'fast lane' is the most expensive), and you have the highway have some way to enforce that a car stays in the lane it has paid for
19:13:28	Taek42:	it's a slightly different system than the one described by you, and requires trusted the highway as a central source
19:14:01	Taek42:	but the result is that those more willing to pay get access to better traffic conditions
19:17:10	hashtag:	I don't think the highway needs to enforce. The vehicle is self-driving. It enforces itself, if you try to manually drive to a faster lane, it incurs charges based on the information provided to the vehicle by its surroundings and existing road database. The vehicle can tell when you've changed lanes. maybe you would end up tipping other vehicles that you just cut off
19:18:39	hashtag:	but I wasn't thinking necessarily having "fast lanes", rather that reacting to surrounding traffic and interacting with those vehicles would provide the "shape" of the priority...
19:18:45	hashtag:	jsut spitballing here
19:19:07	hashtag:	sorry if this isn't the place to discuss such things
19:21:26	Adohgg:	Adohgg is now known as twobltbot
19:21:36	twobltbot:	twobltbot is now known as twobLtbot
19:21:41	twobLtbot:	twobLtbot is now known as twobltbot
19:22:03	Taek42:	it's an interesting concept but it sounds like the foundation is just having some universally recognized payment system
19:22:10	Taek42:	*universally recognized by the cars
19:22:36	hashtag:	such as bitcoin?
19:22:36	Taek42:	it they're already self-enforcing based on your driving habits, then you don't need to trust the driver and you can just install centralized software on the car
19:22:52	itod:	itod has left #bitcoin-wizards
19:24:36	twobltbot:	twobltbot is now known as DEA_Agent
20:12:11	Taek42:	gmaxwell: http://pastebin.com/EDTuqVFv
20:12:23	Taek42:	tell me what you think
20:15:42	Taek42:	you could tweak it so that instead of being reward based, it's penatly based.
20:16:08	Taek42:	if you store everything, in the long term the penalty is 0, but occasionally you might get a reward or penalty
20:16:25	Taek42:	and if you store less than everything, in the long term you incur prohibitive penalty
20:16:31	Taek42:	or just get kicked
22:45:50	phantomcircuit:	for namecoin style merged mining does the data actually have to be in the coinbase?
22:47:43	jgarzik:	phantomcircuit, well it all depends on what namecoin will validate doesn't it?
22:47:47	jgarzik:	in theory no
22:48:29	phantomcircuit:	jgarzik, sadly i think theory doesn't match reality on this one
22:49:57	gmaxwell:	phantomcircuit: it's very easy to crate vulnerabilities if you don't carefully confine where the data can be located.
22:50:33	phantomcircuit:	gmaxwell, because a normal tx could contain the data also
22:51:19	phantomcircuit:	seems like it should be easy enough to come up with a consensus rule for that, something as simple as the last such value wins and require a magic value
22:51:32	phantomcircuit:	then the pool can simply filter out transactions which contain the magic value
22:51:40	gmaxwell:	perhaps but you have to.
22:52:30	jgarzik:	phantomcircuit, oh, I'm certain namecoin does not support that today. Thought you were asking about possibilities for the future...
22:52:56	jgarzik:	so
22:53:04	jgarzik:	what's the latest paper or reference on 2-way pegging?
22:53:14	gmaxwell:	phantomcircuit: namecoin actually had a minor vulnerability of this type in the past, where you could mergemine namecoin with namecoin.
22:53:15	jgarzik:	I want to run a test in picocoin
22:53:16	phantomcircuit:	jgarzik, was hoping that i could move it into an OP_RETURN to make it possible to calculate the coinbase hash with a midstate for mining purposes
22:54:03	phantomcircuit:	it's not ideally located but it's not that big of a deal
22:54:22	phantomcircuit:	gmaxwell, wait what
22:54:29	phantomcircuit:	mergemine namecoin with namecoin
22:54:34	jgarzik:	I have this post from Adam Back,
22:54:35	jgarzik:	http://sourceforge.net/p/bitcoin/mailman/message/32108143/
22:54:40	jgarzik:	is that the best 2-way ref?
22:59:04	jtimon:	this conversation seems related to https://github.com/bitcoin/bitcoin/pull/3977
23:06:47	Luke-Jr:	[22:45:50] for namecoin style merged mining does the data actually have to be in the coinbase? <-- I believe so
23:08:17	gmaxwell:	phantomcircuit: yea, namecoin on namecoin e.g. mine namecoin and a fork at the same time! :)
23:09:06	Luke-Jr:	gmaxwell: can't you still do that?
23:09:14	gmaxwell:	I think they fixed that.
23:09:18	Luke-Jr:	or do solo blocks require a proof-of-not-merge-mining?
23:09:20	gmaxwell:	Maybe not.
23:09:37	gmaxwell:	I thought they just stopped allowing solo blocks (you could just put junk in the template)
23:09:40	Luke-Jr:	ah
23:16:45	gmaxwell:	jgarzik: andytoshi, myself, and some others have been working on an omnibus whitepaper on sidechains... but we're trying to avoid doing the thing where a bunch of half cooked crap gets released and then they tweak constantly in response to criticism (and thus somewhat devaluing the criticism, since the result becomes unreviewable).
23:18:53	gmaxwell:	I'd be happy to share privately with you progress so far, though ... at the same time somewhat regretful since I think it'll reduce the value of later review on the actual cooked work.
23:21:21	adam3us:	jgarzik: yeah other than wizards irc from dec last year thats about it, other than paper coming rsn gmaxwell mentioned.
23:24:42	phantomcircuit:	gmaxwell, as in you could put two of the values in the coinbase
23:24:47	phantomcircuit:	?
23:26:14	gmaxwell:	phantomcircuit: you could mine a 'solo' namecoin block (not merged mined) which was also merged mined.
23:26:30	gmaxwell:	e.g. merge mine namecoin with namecoin.
23:30:52	grubles:	i guess that is different than selfish mining (pool mining but withholding found blocks from the pool) ?
23:33:24	phantomcircuit:	gmaxwell, oh i see
23:33:30	phantomcircuit:	why the hell would anybody do that though
23:33:39	Luke-Jr:	grubles: "selfish mining" is NOT "pool mining but withholding found blocks from the pool"
23:33:53	Luke-Jr:	phantomcircuit: it's a convenient way to attack it?
23:34:02	phantomcircuit:	Luke-Jr, expensive way to do it
23:34:06	Luke-Jr:	:p
23:34:52	Luke-Jr:	phantomcircuit: they almost deployed MM with the ability to put a nice long chain of sequential namecoin blocks in a single bitcoin block header :D
23:34:54	phantomcircuit:	namecoin diff is ~50% of bitcoin diff
23:35:03	phantomcircuit:	but a namecoin block is worth ~2% of a bitcoin block
23:35:08	Luke-Jr:	more like 90% these days I thought?
23:35:12	phantomcircuit:	such an attack would be economically insane
23:35:21	phantomcircuit:	Luke-Jr, no it's back to 50% since namecoind was horribly broken
23:35:25	Luke-Jr:	ah
23:36:00	phantomcircuit:	that reminds me
23:36:10	phantomcircuit:	probably should stop mining empty namecoin blocks now
23:36:14	Luke-Jr:	no
23:36:20	Luke-Jr:	that's still the only solution AFAIK
23:36:20	phantomcircuit:	no?
23:36:27	Luke-Jr:	their "fixes" don't work
23:36:31	phantomcircuit:	iirc the default fees were increased substantially
23:38:26	gmaxwell:	phantomcircuit: to attack it
23:39:24	phantomcircuit:	gmaxwell, that just gets you a 2x right?
23:39:34	phantomcircuit:	or does that break things in some other way
23:39:54	grubles:	grubles has left #bitcoin-wizards
23:39:59	gmaxwell:	just 2x... but it means you can mine honestly and an attack at the same time... or a block and its successor (I think)
23:40:19	phantomcircuit:	gmaxwell, right but that would be economically irrational
23:40:34	gmaxwell:	a block and its successor would be profitable.
23:40:42	phantomcircuit:	no it wouldn't
23:40:51	gmaxwell:	why not? two blocks for the price of one.
23:40:55	phantomcircuit:	the opportunity cost of not mining for bitcoin
23:41:00	gmaxwell:	oh you mean becase of that, sure.
23:41:18	gmaxwell:	more a certificational weakness just because bitcoin income loss.
23:41:21	phantomcircuit:	and im pretty sure at the difficulty it's at solo mining even getting 2x would be irrational
23:44:28	gmaxwell:	sure sure
23:46:57	phantomcircuit:	it would be nice if the aux data could be changed without changing the midstate values
23:47:23	phantomcircuit:	with the data in the coinbase the savings from the is pretty low (read zero)