00:34:09	dsnrk:	andytoshi: I think gmax mentioned the answer to the second question earlier (no, you can't trim anything so there's scaling issues)
00:36:45	tacotime_:	utxo is next to impossible as long as some or all users are using mixin>0, unfortunately.
00:40:13	andytoshi:	ok, well these outputs have this nice property of being identifiable through these "key images" which is how double-spends are detected. suppose every block commits to (a) a merkle root of the txo set (b) a merkle root of the spent-key-image set. both are append-only
00:41:06	andytoshi:	then nobody needs to have an explicit view of the utxoset, they just need to be aware of their own outputs as well as some random ones for anonymity's sake
00:41:32	tacotime_:	right, i suppose that might work.
00:42:47	tacotime_:	and it'd free up a lost of the nasty slowness upon wallet syncing that currently plagues the software, because it seems to check outputs in every block to see if they belong to you.
00:43:59	andytoshi:	hmm..you'd hope the wallet would know the first blockheight at which it ever might've received funds and be able to skip that for earlier ones
00:44:04	tacotime_:	(part of which is also our fault, because the pool software is implemented a little naively and generates a lot more dust than it should.)
00:44:13	tacotime_:	andytoshi, yeah, i've been meaning to integrate that too.
00:45:18	andytoshi:	but there's still a ton of slowness, these ringsigs are not very cheap (mainly, they make you look up every single input they reference) and if we're also tracking these merklized appends that's a lot
00:45:35	tacotime_:	right now it syncs from 0, which is unfortunate; the simplewallet refresh command should allow an optional argument to choose the height at which to begin looking for outputs.
00:45:40	tacotime_:	* tacotime_ makes an issue
00:45:53	tacotime_:	yeah.
00:46:29	tacotime_:	it'll get _really_ ugly when we move to a non-RAM database soon. probably users will need ssds.
00:49:24	andytoshi:	can you expand on that comment? what database and why should it be non-RAM?
00:50:08	tacotime_:	andytoshi, there is no database implementation in the cryptonote reference code. it just stores the blockchain in memory.
00:50:39	andytoshi:	oh, you mean RAM memory, i read it as "non-random access database" and was wondering what kind of weird optimization you might get by forcing reading every record..
00:50:52	tacotime_:	oh, no, sorry X)
00:51:24	andytoshi:	:P no my bad, i don't want to start a thing where we have to say "RAM memory" around here..
00:53:01	dsnrk:	helps distinguish from those using mercury delay line memory.
00:53:04	tacotime_:	right now, because of the tx dust generated by pools, it's taking almost an hour just to sync a new wallet on a modern pc with the blockchain in ram. it'll probably be at least a bit worse when you offload it to an hdd/ssd.
00:53:20	dsnrk:	yipe, that's slow.
01:07:08	tromp_:	how is that hour divided between verifying sigs and pows?
01:07:34	tacotime_:	tromp_, this is all sigs
01:07:48	tacotime_:	pow verification is separate (daemon behaviour)
01:08:37	tacotime_:	i think we're using reference code for the ecdh for stealth addressing though
01:08:45	tacotime_:	so there's probably room for some optimization
01:10:07	tacotime_:	well really there's room everywhere for optimization, we just need to sit down and profile where the code is dragging its heels. unfortunately there's lot to deal with fixing, so we're trying to prioritize trying to fix what's most broken in the implementation (that doesn't require a hardfork) first.
01:10:33	tacotime_:	(anyway, sorry if this is OT dev-related stuff)
02:10:51	ghtdak:	ghtdak has left #bitcoin-wizards
03:49:35	alferzz:	alferzz is now known as alferz
06:36:57	cym:	cym is now known as pen_
08:23:22	Guest40907:	Guest40907 is now known as maaku
12:16:37	pangpang:	pangpang is now known as pen_
13:42:24	maaku:	maaku is now known as Guest14473
14:08:56	Guyver2:	Guyver2 has left #bitcoin-wizards
14:40:49	Eliel:	I wonder, if the mining reward system was tweaked to give some slight bonus mining reward for including all transactions from an earlier block attempt that didn't quite match the target but got reasonably close. Perhaps scale the bonus reward so that if the earlier block attempt got to 10% of the target, the extra reward is 10% of the maximum. If 50%, then 50% of the maximum.
14:41:42	Eliel:	Would that be enough to make it sensible to treat those earlier blocks as weaker confirmations than 1 confirmation.
14:44:50	Eliel:	Also, if it required referencing the same previous block, wouldn't it also lead to faster consensus in the event of a fork?
14:48:53	sipa:	Eliel: there is no consensus on what was to be included in an earlier block attempt
14:49:17	sipa:	so you can't have this as a consensus rule
14:49:28	sipa:	which means no consensus about the reward...
14:50:02	Eliel:	sipa: it would of course require referencing the earlier attempt and publicizing it.
14:50:14	Eliel:	is there something that prevents this?
14:50:45	tromp__:	a lot of complexity for highly questionable benefits
14:50:49	sipa:	how do you prevent the miner from making something up about the previous attempt?
14:51:07	Eliel:	make something up == almost no benefit
14:51:17	Eliel:	it'd require considerable hashing on average to produce one
14:51:31	Eliel:	that gives meaningfully high bonus
14:51:41	sipa:	i misread part
14:51:44	sipa:	never ind
14:53:03	Eliel:	tromp__: I believe it could be implemented such that including just the block headers of the earlier attempt is sufficient to check that the rules have been followed.
14:53:42	Eliel:	as long as the merkle root in the attempt is present in the merkle tree of the block you found.
14:54:40	Eliel:	this might require separating coinbase from the merkle tree to work properly though.
14:55:02	andytoshi:	one problem is that it's hard to say what "reasonably close" means.. if you are within some range [1, N] you've got 1/2 chance of being in [1, N/2], 1/4 chance of [1, N/4], etc.
14:55:54	Eliel:	andytoshi: I don't see any especialy reason for a hard limit. The scaling reward is enough, no?
14:57:07	andytoshi:	no, because a person could mine a block in secret spending coins to himself. then whenever he lucks out and gets a valuable block, he can broadcast some conflicting tx knowing that he has a good chance of overwhelming any other partial blocks
14:59:18	Eliel:	is that fundamentally worse than having to find a full block before you can do that? The point here would be to speed up the consensus.
14:59:48	andytoshi:	it is worse because it makes analysis that much harder
15:00:09	andytoshi:	it doesn't speed up consensus because it's still a gamble until you're several blocks deep
15:00:11	Eliel:	would be beneficial for small payments. Even one confirmation is overkill for small amounts.
15:01:10	andytoshi:	small payments don't need fast global consensus, they can use the same trust mechanism that they do today... which is "people are mostly honest"
15:01:45	andytoshi:	or they could use debit cards from trusted banks, or casascius coins, or ....
15:02:16	Eliel:	well, the core of my idea was to incentivice miners to publicize what set they're mining.
15:02:55	andytoshi:	the set could change at any time tho because mining is progress-free
15:03:20	Eliel:	yes, but that's what the bonus is for. It encourages miners to publicize _and_ keep to it.
15:07:12	andytoshi:	ok, i see. i'll have to think about it, i think it is an improvement but i can't say how much
15:13:37	andytoshi:	does this make mining non-progress-free? how badly?
15:15:03	andytoshi:	i think it might really benefit huge pools since they'd be practically guaranteed to find partial blocks
15:20:27	Eliel:	ah, right, it's missing a strong incentive to actually publicize the partial blocks.
15:22:18	Eliel:	perhaps the bonus should go to both the finder of the actual block as well as the finder of the partial block.
15:22:19	andytoshi:	yeah, it's kinda weak actually because you'd expect most miners to have and use their own partial blocks
15:22:57	Eliel:	andytoshi: if you stick to your own partial blocks, most of the time the bonus you get would be less due to scaling.
15:23:01	andytoshi:	yeah, you said that above, maybe a 10/90 split or something. but (a) i'm not sure it makes the incentive strong enough to publicize, and (b) i'm pretty sure it'll incentivize people to join big pools
15:23:11	andytoshi:	oh, i see
15:24:18	Eliel:	... could this actually make it costly for a 51% attacker to selectively leave transactions out of their blocks...
15:25:58	andytoshi:	yeah, you'd want to ensure that the partial block is only legit iff its transaction set is a subset of the real block's, otherwise you don't really get your "commit to a txset" property
15:26:22	andytoshi:	but the centralization incentive i think is serious
15:28:32	Eliel:	perhaps, but I also get the feeling that this idea could lead to a mining system where 51% attack is less serious and potentially removes the possibility for a 51% attacker to make mining completely unattractive to anyone else.
15:29:53	dsnrk:	andytoshi: it's a harder question to answer once you go back to the core idea. do you really want one vote per cpu, per person? there's all these ideas of limiting but I still can't work out what the limiting factor is supposed to do.
15:30:40	andytoshi:	Eliel: can you describe how your suggestion differs from "let's use a sequential PoW that only allows growing the txoset, then miners won't be able to remove transactions" except in scale?
15:30:59	dsnrk:	the core idea usually seems to be "one vote per person" without actually trying to identify miners.
15:31:04	andytoshi:	(a sequential PoW is a totally non-progress-free one, so mining is actually a race and everybody wants to join the biggest pool)
15:31:27	andytoshi:	dsnrk: well, the idea is there are no votes really, there is no majority rule, it is just consensus
15:31:37	Eliel:	andytoshi: it sounds pretty similar, except that it doesn't require redesigning the PoW function.
15:32:23	andytoshi:	Eliel: right. but a sequential PoW would completely destroy bitcoin's mining model, so if it's an extreme form of what you're suggesting maybe it's easier to see what my concern is
15:32:27	Eliel:	and you might still get lucky and find a block before you find a partial block
15:32:51	dsnrk:	andytoshi: still not sure I see the point. anything that can be done by one miner can be done better in bulk.
15:33:37	andytoshi:	dsnrk: that's not true, there is no benefit to two miners at 1PH vs one miner at 2PH... except the single guy will have more cooling problems
15:33:38	Eliel:	andytoshi: I tend to value censorship resistance over other concerns.
15:33:57	andytoshi:	Eliel: what you're suggesting will lead to total centralization and no censorship resistance
15:35:04	andytoshi:	the whole point of progress-freeness is that you don't have anything "better in bulk", otherwise the biggest pool would just take over the network
15:35:46	dsnrk:	andytoshi: there's always savings in bulk. shipping is cheaper, getting power is cheaper, setup time verses income is better
15:35:51	Eliel:	the mining system already fails the "nothing better in bulk" requireent if you ask me.
15:37:53	andytoshi:	sure, those are incentives toward centralization, but the thermodynamic limit stuff counters it so there is a limit to how centralized you can get
15:38:20	andytoshi:	as asics become commodity things will improve relative to where they are now, setup/shipping costs are basically nil compared to running costs
15:39:13	andytoshi:	you can't design your PoW so it's unconditionally better to be centralized, that can't support a distributed consensus
15:39:43	Eliel:	There's the pool centralization thing too. Although, I think that's mostly due to missing framework to allow automated config-free cooperation between miners.
15:40:28	andytoshi:	yeah, a lot of it is an accident of history. amiller's non-outsourceable puzzle work can also counter it, so there's something that a better bitcoin would support
15:40:50	Eliel:	I still can't quite see why my proposal would incentivice centralization though.
15:42:21	andytoshi:	can you see why a sequential PoW would incentivize centralization?
15:42:48	Eliel:	actually, no. Do you have a link about it?
15:44:00	andytoshi:	one sec, i have a link for what sequential PoW actually is.. for centralization you'd just have to think about it, i don't think it's written out
15:46:12	andytoshi:	http://www.cs.virginia.edu/~mohammad/files/papers/15%20TimeStamp.pdf
15:48:29	andytoshi:	oh, also q2.5 of https://download.wpsoftware.net/bitcoin/asic-faq.pdf talks about progress freeness
15:49:26	Eliel:	one difference that I can think of is that in the model I'm suggesting, you only lose the bonus part of the block reward by ignoring work done by others. In sequential, you have to keep up or you'll get nothing.
15:50:28	Eliel:	I was envisioning the bonus as something like 5% of the total reward.
15:53:50	Eliel:	also, the partial block that increases the reward, why would that be so different from the necessity of being up to date on what's the latest block in the mining system currently?
15:58:15	Eliel:	I think that the centralization incentive due to this can be largely dealt with by providing a proper framework for miners to communicate without too much delay.
16:01:24	andytoshi:	so the current mining community has an advantage over new miners?
16:01:37	andytoshi:	so you can't mine anonymously?
16:02:09	Eliel:	well, obviously, you have an advantage if you can get new blocks faster than other miners, no?
16:05:48	Eliel:	although, I guess the major factor in pool centralization is that it takes more effort to mine at several pools than it takes to mine in a single pool.
16:06:15	Eliel:	effort in this case being the miner's attention
16:06:57	Eliel:	I think a framework to automate this process could help a lot.
16:18:36	hearn:	is this new? http://bitcoin.stanford.edu/
16:24:49	Pan0ram1x:	hearn: since dec 8, 2013 (https://web.archive.org/web/20131208074631/http://bitcoin.stanford.edu/)
16:25:02	hearn:	hmm
16:25:05	hearn:	i never heard about it before
16:25:32	Pan0ram1x:	me neither.. reading it now
16:32:46	Pan0ram1x:	coinsafe uses bockscore.com. interesting.
16:42:56	lechuga_:	the group leader is also a general partner @ a16z
17:05:39	OneFixt_:	OneFixt_ is now known as OneFixt
17:40:37	Pasha:	Pasha is now known as Cory
18:12:07	pangpang:	pangpang is now known as pen_
18:12:08	Emcy_:	http://p2pool-nodes.info/ is that what really happened to p2pool
18:12:28	Emcy_:	the rentiers moved in?
18:13:24	Emcy_:	not a case of convenience for a fee, some people seem genuinely unaware that p2pool is something youre supposed to do on your own
18:27:11	hearn_:	yes that seems a very common problem
18:27:14	hearn_:	hearn_ is now known as hearn
18:27:37	hearn:	as gmaxwell says, we have lost our ability to transmit cultural knowledge. a lot of people seem to think that Bitcoin Core exists only to run the p2p network
18:27:45	hearn:	they don't seem to realise it has any relevance to mining at all: a very remarkable outcome
18:27:54	hearn:	i am thinking we need to build a miners section of the website
18:28:09	hearn:	it may be a bit too late now, but explaining to people what mining is supposed to be like can't hurt
18:34:19	ielo:	ielo has left #bitcoin-wizards
18:37:47	Emcy_:	hearn i do my crappy little bit
18:37:57	Emcy_:	by referring to enforcement nodes and whatnot
19:09:07	nsh:	nsh has left #bitcoin-wizards
19:11:45	phantomcircuit:	hearn, just tell them to use the cloudhashing pool
19:11:54	phantomcircuit:	i prettttty promise not to do anything weird
19:17:05	Guest81385:	i want to get a bankloan to offer swaps at bitfinex, is there a better way to explain this to a bank than saying its bitcoin related
19:17:46	phantomcircuit:	Guest81385, lololol
19:18:05	Guest81385:	are there other forex sites like bitfinex that allow users to offer swaps?
19:18:56	Dizzle:	Guest81385: what you'd effectively be asking for is margin. If you explain the position to them and they have a maintenance margin calculation strategy to employ for determining what collateral would required of you, then you might have a chance. You generally have to "know people" for such a thing though.
19:19:21	Dizzle:	You'd have better luck securing a loan from prosper.com or another p2p lending site.
19:19:25	phantomcircuit:	Dizzle, he has no chance, bitfinex is operated illegally
19:19:39	Guest81385:	right i wouldn't want to tell them its for bitfinex
19:19:43	phantomcircuit:	that much will be obvious to anybody at a bank almost instantly
19:20:15	phantomcircuit:	Guest81385, do you plan on personally backing the loan?
19:20:25	phantomcircuit:	do you have assets in excess of the amount you wish to borrow?
19:20:36	phantomcircuit:	unless you can say yes to both of those you're wasting your time
19:21:42	pigeons:	what made you decide to ask this particular channel?
19:21:44	Guest81385:	yeah we do
19:22:11	Guest81385:	but they are locked up in CD's, but i can use them as collateral to get large loans i'd want to put on bitfinex swap offers
19:25:04	Guest81385:	which looks to me like an extremely high paying CD
19:29:16	phantomcircuit:	Guest81385, did you miss the part about bitfinex operating entirely in contradiction to law?
19:30:01	Guest81385:	is it really? i thought it was just unregulated
19:31:44	phantomcircuit:	no
19:31:50	phantomcircuit:	its illegal
19:32:29	Guest81385:	why exactly? the high interest rates?
19:32:42	phantomcircuit:	Guest81385, they are acting as issuer, broker, dealer, and clearinghouse for unregistered securities offered to the general public
19:33:05	phantomcircuit:	they operate out of france but claim to be a hong kong corporation
19:33:30	phantomcircuit:	the entire operation is based on source code used without license from bitcoinica
19:33:59	phantomcircuit:	that's at least a dozen felonies
19:34:04	Guest81385:	so u think bitfinex is going to collapse
19:34:30	phantomcircuit:	i think the owner will spent a very long time in prison in various countries
19:34:40	phantomcircuit:	the stupid mans way of traveling the world
19:35:27	Guest81385:	woudln't he just be subject to hong kong laws
19:35:43	phantomcircuit:	that isn't how the world actually works
19:37:13	Guest81385:	is there a reddit thread about this
19:37:50	andytoshi:	Guest81385: this is really funny, but it's also OT here..
20:46:18	shazow:	shazow has left #bitcoin-wizards
21:45:56	justanotheruser:	Would it be ideal to have a power that involved making ZKPs of the rest of the chain (along with finding a small hash)?
23:53:34	abc56889:	Isn't the p2pool 30sec chain itself vulnerable to a 51% attack?
23:56:31	Eliel:	abc56889: as far as I know, yes.