00:08:27 <jarpiain> jarpiain is now known as Guest74504
01:20:23 <jarpiain> jarpiain is now known as Guest83509
04:18:52 <amiller_> amiller_ is now known as amiller
04:53:01 <lifeofcray2> lifeofcray2 is now known as lifeofcray
06:53:13 <maaku> maaku is now known as Guest93342
09:28:40 <Guest93342> Guest93342 is now known as maaku
12:33:06 <petertodd> jtimon: re: inputs only, my thinking is for every tx to be accompanied by PoW
12:33:28 <jtimon> yeah, that solves spam
12:33:35 <jtimon> but who is going to mine?
12:33:41 <michagogo|cloud> petertodd: Like bitmessage?
12:36:09 <petertodd> jtimon: every user - I also want mining to be non-outsourcable and asic hard
12:36:30 <petertodd> jtimon: also, ponies
12:36:43 <petertodd> michagogo|cloud: basically yes
12:36:51 <pigeons> i think if you add unicorn blood it works
12:37:09 <petertodd> pigeons: or pigeon blood
12:37:44 <petertodd> asic hard seems like a reasonable goal, though the end result is more likely to be gpu-minable
12:37:59 <petertodd> or maybe "fpga soft" so to speak
12:41:04 <jtimon> petertodd, but if users add pow to txs, who adds pow to blocks?
12:45:19 <petertodd> jtimon: potentially the tx's do - I proposed something very similar to that tx scalability paper for proof-of-sacrifice where you would do tx's as a dag
12:45:55 <jtimon> so each tx would commit to the same previous block
12:46:20 <jtimon> what happens when two tx with the same input appear in the same block?
12:46:50 <jtimon> which one came first
12:46:51 <jtimon> ?
12:47:32 <petertodd> jtimon: potentially you do a tie-breaker via pow, or just make the rules that they can't for the dag path to be valid
12:47:53 <petertodd> my zookeyv proposal was for the latter
12:48:09 <jtimon> what's dag?
12:48:53 <petertodd> directed acyclic graph
12:49:40 <jtimon> ok, I still don't understand what you mean by " just make the rules that they can't for the dag path to be valid"
12:50:23 <petertodd> ok, so every node in the dag is essentially a path from the genesis block right? well, multiple paths? so define the path as valid only if no input is ever spent twice
12:50:31 <jtimon> in the first "pow tie-brake" solution...when isa transaction final? how the "time between blocks" is determined?
12:51:42 <petertodd> I've proposed before that time between blocks be based on some short block interval with eventual merging... IE min PoW for a tx would be some amount
12:52:04 <petertodd> or, alternatively, group txs together and make a min PoW for the group
12:52:27 <petertodd> all very in the air because we don't yet understnd the impact of latency on centralization well yet
12:52:27 <jtimon> yeah ryan fugger and me speculated about pow chains merging but didn't get anywhere
12:53:16 <petertodd> I'm meaning to write up a reply to those tx paper guys showing why they're probably going to wreck decentralization via bad incentives
12:53:39 <jtimon> we had chains where a block was basically a transaction and parallel chains could be merged
12:53:55 <petertodd> yup, very similar ideas
12:54:17 <jtimon> by we didn't solve how conflicts are resolved
12:54:19 <petertodd> with proof-of-sacrifice, specially using an embedded consensus system, the logic is really simple, not so simple when latency matters
12:54:31 <petertodd> *especially
12:54:39 <jtimon> basically we had only tx_ids, not even inputs
12:55:00 <jtimon> but we didn't
12:55:12 <petertodd> ah cool
12:56:39 <petertodd> I think implementing zookeyv might be a good educational exercise myself - learn more about such blockchain structures without the complexity of latency
12:57:03 <jtimon> sorry, zookeyv?
12:57:44 <jtimon> as said, we gave up because we weren't able to properly resolve merges, what do you have in mind?
12:58:27 <petertodd> jtimon: largest total sacrifice wins is the logic in zookeyv
12:58:44 <petertodd> as for what it is: key-value consensus system based on sacrificing bitcoins
12:59:02 <petertodd> very roughly sketched out on -wizards a few months ago
13:00:57 <jtimon> oh, kind of a replacement for namecoin
13:01:10 <petertodd> exactly
13:01:30 <MoALTz> if you include PoW in transactions then make it so that the PoW nonce is NOT included in the signature check. that way SPV clients can have their transactions "hardened" by a 3rd party
13:01:33 <jtimon> maaku and I were discussing "freiname" the other days, treating names as land
13:01:44 <petertodd> nice security properties too in some senses, as you know the BTC value of the re-write security
13:01:57 <petertodd> MoALTz: absolutely
13:02:04 <jtimon> he started with a gesellian freiland but we ended up with something more similar to Henry George land tax
13:02:46 <petertodd> MoALTz: although, equally it is worth considering non-outsourcable schemes where PoW reward - whatever it is - can be stolen by whomever mined it
13:02:50 <jtimon> I think we reached a good incentive strcture for anti-squatting
13:03:37 <petertodd> jtimon: oh yeah?
13:03:48 <jtimon> but back to the chain merging, please, tell me when you think you've solved that problem
13:04:38 <jtimon> yes, and we could implement it with a soft-fork
13:04:47 <jtimon> on top of bitcoin/freicoin
13:05:35 <jtimon> I can mail you the discussion log if you're interested in "freiname"
13:05:36 <petertodd> jtimon: heh, well, first let me get to a part of the world without 1s latency to the US :p
13:05:40 <petertodd> sure
13:22:54 <jtimon> sorry, there's many other things in the log, and we also discuss land reform (that may actually help understand the motivation)
13:22:59 <jtimon> petertodd http://pastebin.com/ZFHG2LvV
13:23:41 <nsh> * nsh would like 16 landcoin please
13:23:48 <jtimon> about the "chain marging problem", do you think you could solve it assuming zero latency for everyone?
13:25:01 <jtimon> because we failed without even considering network latency
13:25:13 <jtimon> not in much detail at least
13:26:35 <jtimon> by the way, I'm not so sure it is a soft-fork since we would need at least a new OP
13:27:19 <jtimon> we also talk about integrating it better with freimarket's unique tokens, but that's not really necessary
13:27:28 <jtimon> new OP_CODE
14:37:49 <gigavps> gigavps is now known as teravps
14:42:37 <gmaxwell> A consequence of inadequate privacy in payment systems: http://i.imgur.com/Obl8xRW.jpg
14:48:45 <sipa> :o
14:52:24 <gmaxwell> Aparrently he'd done about a dozen payments to coinbase in about a month, totaling under $10k.  (amusingly, coinbase replicates their high transaction volume bad practices on the ACH side too— people make many payments because coinbase won't let them hold USD in their coinbase account. I bet this makes them no friends with banks.)
14:56:15 <warren> gmaxwell: he is a merchant receiving payments?
14:56:29 <gmaxwell> No he's just some guy that was buying bitcoin using coinbase.
14:56:42 <gmaxwell> it was all out from him to coinbase
14:56:56 <warren> and this made his bank nervous...
14:59:09 <gmaxwell> banks are like persian cats, fluffy and afraid of everything.
15:00:21 <warren> and a flat smushed face
15:01:44 <gmaxwell> the only unusual thing here is that they warned him a lot of people have just randomly had their accounts closed when their bank notices btc related txn.
15:03:24 <warren> "they"?
15:13:59 <gmaxwell> the bank
15:51:43 <andytoshi> i had wells fargo disable my account because i was connected through tor ... when i called them up the security guy asked "are you using tor?"
15:51:51 <andytoshi> i said yeah, he said "okay, i'll make a note of it"
15:51:55 <andytoshi> i was really surprised
15:58:17 <andytoshi> i stopped using tor anyway, i think the "note" he made was to NSA rather than anything that'd keep my account open..
15:59:44 <teravps> teravps is now known as gigavps
15:59:53 <gmaxwell> andytoshi: on your manualcoinjoin you're doing, ... you'd mentioned txindex to me, but you can actually look up any spendable coin with gettxout.
16:00:34 <andytoshi> even without txindex?
16:00:37 <gmaxwell> yes.
16:00:51 <gmaxwell> it usees the utxo set— obviously since the same operation is needed to validate!
16:01:21 <gmaxwell> thats also what any CJ tool should use for checking the availability of txins.
16:01:31 <andytoshi> oh, thanks
16:01:57 <andytoshi> i thought so, but gettransaction wasn't working...i guess i txindex'd for nothing
16:02:05 <andytoshi> and i guess gettransaction does not work with txouts
16:02:51 <gmaxwell> gettransaction would never return a non-wallet txn. Getrawtransaction would, depending on if its spent or not, but we've talked about changing that (e.g. by providing a new call) since its surprising to people.
16:03:29 <gmaxwell> (getrawtransaction has a nice verbose argument to get the verbose details)
16:03:43 <gmaxwell> You're the sort of person who should have a txindex=1 node anyways. :)
16:04:05 <gmaxwell> sorry, it was late last night or I would have thought to mention it then.
16:05:07 <andytoshi> no worries, i was off to bed anyway, i probably would have missed it anyway
16:06:00 <andytoshi> and i was asleep for the entire reindex, so it didn't bother me
16:06:39 <andytoshi> (linux bogs down horrifically during reindexing...there was a recent LWN article about fiddling some flush-rate parameters, but i didn't get around to doing that)
16:07:47 <gmaxwell> andytoshi: hm. never noticed it, but maybe I'm on overpowerful hardware relative to you. if you have a lot of ram you can make it a lost faster if you run with -dbcache=<big value>
16:08:49 <andytoshi> nope, i'm on a 2008 thinkpad which is maxxed out at 4gb :P
16:09:17 <gmaxwell> its annoying that its hard to get more than 16 gb in a laptop.
16:09:34 <andytoshi> yeah, i've spent forever on this hardware because i can't upgrade as much as i want
16:10:06 <andytoshi> i was also promised OLED screens every year since 2010..
16:11:22 <gmaxwell> yea, display tech stinking kept me on my older thinkpad until it basically fell apart.
17:18:16 <phantomcircuit_> phantomcircuit_ is now known as phantomcircuit
17:47:24 <maaku> gmaxwell: i think the latest workstation lenovos can do 32gb
17:47:29 <maaku> i would love a thinkpad with 96gb though
17:48:16 <maaku> petertodd: do you have a link or log of the sacrfiicial key-value store discussion?
17:48:25 <maaku> it sounds similar to what we came up with
17:50:03 <maaku> in our system there's on-chain offers stored in a merklized prioritiy heap
17:50:54 <maaku> and the owner needs to pay rent equal to a percentage of the largest offer
17:51:01 <maaku> rent being paid by sacrifice
17:51:45 <warren> adam3us: blah blah, boring talk
17:52:17 <maaku> (if rent owed goes negative, the offerer can claim the property from the owner by paying the offer amount, but he doesn't need the owner's permission)
17:53:10 <maaku> This is basically using georgist land tax to solve the squatting problem
17:53:32 <maaku> Also, with the system we put together it has the nice advantage of being entirely in merklized structures that the validators don't have to keep
18:20:36 <helo> is there any writing about the idea of an altcoin that gets its coin only from bitcoin sent to unspendable addresses?
18:22:16 <maaku> helo: that's what mastercoin is supposed to be, no?
18:22:22 <maaku> s/unspendable/owned by JR/
18:23:22 <maaku> helo: in freimarkets we have primitives for issuance and cross-chain transfer
18:23:45 <maaku> it's meant for gateways, but you could probably use it for unidirectional sacrifice-transfer
18:24:03 <helo> neat, i'll look into those
20:25:14 <spinza_> spinza_ is now known as spinza
20:30:26 <Guest83509> Guest83509 is now known as jarpiain
21:07:28 <MoALTz> transaction fees proportional to the block subsidy?
21:14:08 <MoALTz> *minimum
21:24:37 <maaku> MoALTz: ?
21:25:32 <maaku> the block subsidy currently has more to do with initial distribution than an ideal steady state
21:25:38 <MoALTz> wondering what the effect of setting the minimum transaction fee to be proportional to the block subsidy would be. it would make fees replacing the subsidy take longer, but would it matter?
21:31:35 <sipa> i doubt any minimum fee policy isn't going to mean much in the future
21:32:06 <sipa> it exists to protect the network from spammy-looking transactions
21:32:23 <maaku> 1) what sipa said, and 2) the minimum tx fee and block subsidy are not corrolated
21:32:35 <sipa> but if the actual fee to have your transaction mined in reasonable time exceeds that anti-dos fee policy, it becomes useless
21:32:57 <helo> it would make the value of bitcoin go down, as future value would be reduced by exorbitant fees
21:33:23 <helo> but that is very long...
21:39:24 <MoALTz> the last question i have for now: would new altcoins with new (truly novel, not like all those forks) features be welcomed? or would they only serve as a distraction from bitcoin?
21:40:57 <sipa> i've been thinking (just thinking... i don't have nearly enough time to do so) to create an altcoin with many of the nice ideas that have been proposed over the years
21:41:20 <MoALTz> i think many of us have ideas that we'd like to embody into a new coin
21:41:28 <sipa> i'd consider it an experiment, though - not a currency
21:41:34 <sipa> like testnet
21:43:25 <MoALTz> one issue with a truly novel new altcoin being run as an experiment: people WILL try and keep the original experiment running, even if the creator tries to shut it down or change elements of it
21:43:42 <MoALTz> it's a genie out of the bottle sort of thing
21:43:57 <MoALTz> at best you'd be able to change it's direction gradually
21:59:02 <gavinandresen> Just build an alt-coin with an expiration date:  "There Will Be a New Block One Every January 1."
21:59:13 <gavinandresen> Call it JubileeCoin maybe
22:00:31 <sipa> or announce from the start that you've added a vulnerability that allows you to exploit the system in a serious way
22:00:42 <sipa> remaining vague enough
22:01:30 <MoALTz> that makes implementing it tricker though
22:01:39 <MoALTz> unless you mean issuing a fake threat
22:02:15 <sipa> that's *maybe* what i mean :p
22:02:27 <MoALTz> :)
22:03:40 <MoALTz> i overlooked the obvious though: just not releasing the source code
22:03:52 <sipa> that makes it pretty useless as experiment
22:04:23 <MoALTz> not at all, since you (the author) can still learn
22:04:26 <gavinandresen> sipa: the real problem is you don't really know you're secure until you have value. Because people won't spend lots of time attacking (or spend money defending) things unless they're valuable
22:04:30 <maaku> a lot of the stuff that's talked about here is getting added to freicoin ... eventually
22:04:36 <sipa> gavinandresen: i know
22:06:32 <sipa> i don't think you need actual economic value though, before people are interested in studying it
22:06:41 <sipa> anyway, all hypotehtical anyway
23:05:58 <helo> maaku: so i take it that freicoin is staunchly against increasing the bitcoin block size limit?
23:07:02 <helo> since presumably freicoin nodes would want to be able to sync the bitcoin blockchain as easily as possible
23:08:14 <maaku> i'm not sure I follow
23:08:32 <pigeons> freicoin uses its own blockchain
23:08:35 <maaku> and no, we're for increasing as quickly and as much as is safely possible to do
23:08:49 <maaku> without risking decentralization
23:08:59 <maaku> er, centralization
23:09:47 <damethos> hey guys. Just thought to share this with u here since u might find some use. Just finished integrating testnet to our blockexplorer. https://www.biteasy.com/testnet/blocks
23:09:50 <helo> maaku: oh. i haven't had time to read about freicoin yet, but i was thinking it will enable one-way bitcoin-to-otherchaincoin transfers
23:09:53 <damethos> still fixing bugs etc but we will get there
23:10:08 <helo> so to know how much coin otherchaincoin has, you'd have to stay current with the bitcoin blockchain
23:10:39 <helo> and would therefore want bitcoin blockchain to be as small as possible
23:11:15 <pigeons> ah freimarkets will be yet another chain
23:11:37 <maaku> freimarkets private accounting servers is what you're thinking of
23:11:38 <helo> oh -markets
23:11:56 <maaku> same developers, different project
23:12:10 <maaku> but freimarkets will be deployed to freicoin
23:12:27 <maaku> but only the private servers track public chains - bitcoin, or freicoin
23:12:37 <maaku> freicoin stays independent of bitcoin, except merged mined pow
23:45:52 <eristisk> maaku: Freicoin does not have a merge minable POW blockchain, or at least they did not create it to be merge minable with Bitcoin's POW chain
23:47:23 <gmaxwell> eristisk: Freicoin will be changing in the future.
23:47:51 <gmaxwell> (also maaku is an expert on what Freicoin does and will do. :) )
23:48:12 <eristisk> Ah, ok, I thought it was commentary on the current state of things.
23:50:22 <maaku> eristisk: Freicoin will get merged mining with the introduction of Freimarkets, or if that fails to happen then at the end of the initial issuance (2 years from now)