--- Log opened Tue Dec 10 00:00:45 2013
07:33 < petertodd> jtimon: re: inputs only, my thinking is for every tx to be accompanied by PoW
07:33 < jtimon> yeah, that solves spam
07:33 < jtimon> but who is going to mine?
07:33 < michagogo|cloud> petertodd: Like bitmessage?
07:36 < petertodd> jtimon: every user - I also want mining to be non-outsourcable and asic hard
07:36 < petertodd> jtimon: also, ponies
07:36 < petertodd> michagogo|cloud: basically yes
07:36 < pigeons> i think if you add unicorn blood it works
07:37 < petertodd> pigeons: or pigeon blood
07:37 < petertodd> asic hard seems like a reasonable goal, though the end result is more likely to be gpu-minable
07:37 < petertodd> or maybe "fpga soft" so to speak
07:41 < jtimon> petertodd, but if users add pow to txs, who adds pow to blocks?
07:45 < 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
07:45 < jtimon> so each tx would commit to the same previous block
07:46 < jtimon> what happens when two tx with the same input appear in the same block?
07:46 < jtimon> which one came first
07:46 < jtimon> ?
07:47 < 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
07:47 < petertodd> my zookeyv proposal was for the latter
07:48 < jtimon> what's dag?
07:48 < petertodd> directed acyclic graph
07:49 < 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"
07:50 < 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
07:50 < jtimon> in the first "pow tie-brake" solution...when isa transaction final? how the "time between blocks" is determined?
07:51 < 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
07:52 < petertodd> or, alternatively, group txs together and make a min PoW for the group
07:52 < petertodd> all very in the air because we don't yet understnd the impact of latency on centralization well yet
07:52 < jtimon> yeah ryan fugger and me speculated about pow chains merging but didn't get anywhere
07:53 < 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
07:53 < jtimon> we had chains where a block was basically a transaction and parallel chains could be merged
07:53 < petertodd> yup, very similar ideas
07:54 < jtimon> by we didn't solve how conflicts are resolved
07:54 < petertodd> with proof-of-sacrifice, specially using an embedded consensus system, the logic is really simple, not so simple when latency matters
07:54 < petertodd> *especially
07:54 < jtimon> basically we had only tx_ids, not even inputs
07:55 < jtimon> but we didn't
07:55 < petertodd> ah cool
07:56 < petertodd> I think implementing zookeyv might be a good educational exercise myself - learn more about such blockchain structures without the complexity of latency
07:57 < jtimon> sorry, zookeyv?
07:57 < jtimon> as said, we gave up because we weren't able to properly resolve merges, what do you have in mind?
07:58 < petertodd> jtimon: largest total sacrifice wins is the logic in zookeyv
07:58 < petertodd> as for what it is: key-value consensus system based on sacrificing bitcoins
07:59 < petertodd> very roughly sketched out on -wizards a few months ago
08:00 < jtimon> oh, kind of a replacement for namecoin
08:01 < petertodd> exactly
08:01 < 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
08:01 < jtimon> maaku and I were discussing "freiname" the other days, treating names as land
08:01 < petertodd> nice security properties too in some senses, as you know the BTC value of the re-write security
08:01 < petertodd> MoALTz: absolutely
08:02 < jtimon> he started with a gesellian freiland but we ended up with something more similar to Henry George land tax
08:02 < petertodd> MoALTz: although, equally it is worth considering non-outsourcable schemes where PoW reward - whatever it is - can be stolen by whomever mined it
08:02 < jtimon> I think we reached a good incentive strcture for anti-squatting
08:03 < petertodd> jtimon: oh yeah?
08:03 < jtimon> but back to the chain merging, please, tell me when you think you've solved that problem
08:04 < jtimon> yes, and we could implement it with a soft-fork
08:04 < jtimon> on top of bitcoin/freicoin
08:05 < jtimon> I can mail you the discussion log if you're interested in "freiname"
08:05 < petertodd> jtimon: heh, well, first let me get to a part of the world without 1s latency to the US :p
08:05 < petertodd> sure
08:22 < jtimon> sorry, there's many other things in the log, and we also discuss land reform (that may actually help understand the motivation)
08:22 < jtimon> petertodd http://pastebin.com/ZFHG2LvV
08:23  * nsh would like 16 landcoin please
08:23 < jtimon> about the "chain marging problem", do you think you could solve it assuming zero latency for everyone?
08:25 < jtimon> because we failed without even considering network latency
08:25 < jtimon> not in much detail at least
08:26 < jtimon> by the way, I'm not so sure it is a soft-fork since we would need at least a new OP
08:27 < jtimon> we also talk about integrating it better with freimarket's unique tokens, but that's not really necessary
08:27 < jtimon> new OP_CODE
09:42 < gmaxwell> A consequence of inadequate privacy in payment systems: http://i.imgur.com/Obl8xRW.jpg
09:48 < sipa> :o
09:52 < 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.)
09:56 < warren> gmaxwell: he is a merchant receiving payments?
09:56 < gmaxwell> No he's just some guy that was buying bitcoin using coinbase.
09:56 < gmaxwell> it was all out from him to coinbase
09:56 < warren> and this made his bank nervous...
09:59 < gmaxwell> banks are like persian cats, fluffy and afraid of everything.
10:00 < warren> and a flat smushed face
10:01 < 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.
10:03 < warren> "they"?
10:13 < gmaxwell> the bank
10:51 < 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?"
10:51 < andytoshi> i said yeah, he said "okay, i'll make a note of it"
10:51 < andytoshi> i was really surprised
10:58 < andytoshi> i stopped using tor anyway, i think the "note" he made was to NSA rather than anything that'd keep my account open..
10:59 < 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.
11:00 < andytoshi> even without txindex?
11:00 < gmaxwell> yes.
11:00 < gmaxwell> it usees the utxo set— obviously since the same operation is needed to validate!
11:01 < gmaxwell> thats also what any CJ tool should use for checking the availability of txins.
11:01 < andytoshi> oh, thanks
11:01 < andytoshi> i thought so, but gettransaction wasn't working...i guess i txindex'd for nothing
11:02 < andytoshi> and i guess gettransaction does not work with txouts
11:02 < 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.
11:03 < gmaxwell> (getrawtransaction has a nice verbose argument to get the verbose details)
11:03 < gmaxwell> You're the sort of person who should have a txindex=1 node anyways. :)
11:04 < gmaxwell> sorry, it was late last night or I would have thought to mention it then.
11:05 < andytoshi> no worries, i was off to bed anyway, i probably would have missed it anyway
11:06 < andytoshi> and i was asleep for the entire reindex, so it didn't bother me
11:06 < 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)
11:07 < 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>
11:08 < andytoshi> nope, i'm on a 2008 thinkpad which is maxxed out at 4gb :P
11:09 < gmaxwell> its annoying that its hard to get more than 16 gb in a laptop.
11:09 < andytoshi> yeah, i've spent forever on this hardware because i can't upgrade as much as i want
11:10 < andytoshi> i was also promised OLED screens every year since 2010..
11:11 < gmaxwell> yea, display tech stinking kept me on my older thinkpad until it basically fell apart.
12:47 < maaku> gmaxwell: i think the latest workstation lenovos can do 32gb
12:47 < maaku> i would love a thinkpad with 96gb though
12:48 < maaku> petertodd: do you have a link or log of the sacrfiicial key-value store discussion?
12:48 < maaku> it sounds similar to what we came up with
12:50 < maaku> in our system there's on-chain offers stored in a merklized prioritiy heap
12:50 < maaku> and the owner needs to pay rent equal to a percentage of the largest offer
12:51 < maaku> rent being paid by sacrifice
12:51 < warren> adam3us: blah blah, boring talk
12:52 < 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)
12:53 < maaku> This is basically using georgist land tax to solve the squatting problem
12:53 < 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
13:20 < helo> is there any writing about the idea of an altcoin that gets its coin only from bitcoin sent to unspendable addresses?
13:22 < maaku> helo: that's what mastercoin is supposed to be, no?
13:22 < maaku> s/unspendable/owned by JR/
13:23 < maaku> helo: in freimarkets we have primitives for issuance and cross-chain transfer
13:23 < maaku> it's meant for gateways, but you could probably use it for unidirectional sacrifice-transfer
13:24 < helo> neat, i'll look into those
16:07 < MoALTz> transaction fees proportional to the block subsidy?
16:14 < MoALTz> *minimum
16:24 < maaku> MoALTz: ?
16:25 < maaku> the block subsidy currently has more to do with initial distribution than an ideal steady state
16:25 < 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?
16:31 < sipa> i doubt any minimum fee policy isn't going to mean much in the future
16:32 < sipa> it exists to protect the network from spammy-looking transactions
16:32 < maaku> 1) what sipa said, and 2) the minimum tx fee and block subsidy are not corrolated
16:32 < sipa> but if the actual fee to have your transaction mined in reasonable time exceeds that anti-dos fee policy, it becomes useless
16:32 < helo> it would make the value of bitcoin go down, as future value would be reduced by exorbitant fees
16:33 < helo> but that is very long...
16:39 < 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?
16:40 < 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
16:41 < MoALTz> i think many of us have ideas that we'd like to embody into a new coin
16:41 < sipa> i'd consider it an experiment, though - not a currency
16:41 < sipa> like testnet
16:43 < 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
16:43 < MoALTz> it's a genie out of the bottle sort of thing
16:43 < MoALTz> at best you'd be able to change it's direction gradually
16:59 < gavinandresen> Just build an alt-coin with an expiration date:  "There Will Be a New Block One Every January 1."
16:59 < gavinandresen> Call it JubileeCoin maybe
17:00 < sipa> or announce from the start that you've added a vulnerability that allows you to exploit the system in a serious way
17:00 < sipa> remaining vague enough
17:01 < MoALTz> that makes implementing it tricker though
17:01 < MoALTz> unless you mean issuing a fake threat
17:02 < sipa> that's *maybe* what i mean :p
17:02 < MoALTz> :)
17:03 < MoALTz> i overlooked the obvious though: just not releasing the source code
17:03 < sipa> that makes it pretty useless as experiment
17:04 < MoALTz> not at all, since you (the author) can still learn
17:04 < 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
17:04 < maaku> a lot of the stuff that's talked about here is getting added to freicoin ... eventually
17:04 < sipa> gavinandresen: i know
17:06 < sipa> i don't think you need actual economic value though, before people are interested in studying it
17:06 < sipa> anyway, all hypotehtical anyway
18:05 < helo> maaku: so i take it that freicoin is staunchly against increasing the bitcoin block size limit?
18:07 < helo> since presumably freicoin nodes would want to be able to sync the bitcoin blockchain as easily as possible
18:08 < maaku> i'm not sure I follow
18:08 < pigeons> freicoin uses its own blockchain
18:08 < maaku> and no, we're for increasing as quickly and as much as is safely possible to do
18:08 < maaku> without risking decentralization
18:08 < maaku> er, centralization
18:09 < 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
18:09 < 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
18:09 < damethos> still fixing bugs etc but we will get there
18:10 < helo> so to know how much coin otherchaincoin has, you'd have to stay current with the bitcoin blockchain
18:10 < helo> and would therefore want bitcoin blockchain to be as small as possible
18:11 < pigeons> ah freimarkets will be yet another chain
18:11 < maaku> freimarkets private accounting servers is what you're thinking of
18:11 < helo> oh -markets
18:11 < maaku> same developers, different project
18:12 < maaku> but freimarkets will be deployed to freicoin
18:12 < maaku> but only the private servers track public chains - bitcoin, or freicoin
18:12 < maaku> freicoin stays independent of bitcoin, except merged mined pow
18:45 < 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
18:47 < gmaxwell> eristisk: Freicoin will be changing in the future.
18:47 < gmaxwell> (also maaku is an expert on what Freicoin does and will do. :) )
18:48 < eristisk> Ah, ok, I thought it was commentary on the current state of things.
18:50 < 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)
19:00 < Luke-Jr> maaku: why might it fail to happen?
19:03 < maaku> well it's not something we are actively working on at this exact moment, or funded to do, so I wouldn't want to say with 100% certainty that it would happen
19:03 < maaku> but it is a priority in the near term, just not this exact moment (unless someone stepped in to fund us)
19:03 < maaku> i assume you're talking about freimarkets
19:04 < maaku> "if Freimarkets fails to happen"
19:07 < Luke-Jr> I mean merged mining
19:07 < Luke-Jr> which tbh is more interesting to me than Freimarkets..
19:11 < maaku> ok so the story there is I've already gotten permission from the two major pools (>90% of the hash power) to add merged mining with the Freimarkets hard-fork
19:30 < Luke-Jr> maaku: hopefully an improved/fixed algo? :D
19:46 < maaku> Luke-Jr: yeah, basically a generic mechanism for committing arbitrary key/value data to the coinbase using Merklized indices
19:47 < maaku> also works for document timestamping, or other applications
20:21 < andytoshi> i'm going to delay the coinjoin another day because i'm close to having a tool which will merge the signed transactions for me
20:21 < andytoshi> so again i'm open to people joining in :)
21:36  * andytoshi-logbot is logging
22:25 < gmaxwell> andytoshi: if you've got a merging tool then you can probably go nag more people to join.
22:26 < gmaxwell> e.g. go post in the cj thread.
22:36 < andytoshi> gmaxwell: not yet
22:36 < andytoshi> i'm almost done the merger, but rust has no json-rpc support, so there'll be some more work
22:36 < andytoshi> it's no problem to just wrap a C lib, but those are hard to come by too :P
22:51 < gmaxwell> json rpc so that it yells if you try to add already spent coins? are you going to make it constrain outputs<inputs per user too?
22:52 < andytoshi> the latter
22:52 < gmaxwell> cool. make sure you shuffle the order.
22:52 < andytoshi> good call
22:53 < andytoshi> in about an hour i'll have something that can merge transactions and checks that they at least are all the same transaction
22:53 < andytoshi> i'd like to figure out RPC so i can check spending and value constraints
22:53 < andytoshi> and i'd also like to figure out CHECKSIG
22:54 < andytoshi> but those can wait for another day
22:54 < gmaxwell> I guess if you're fetching the inputs you can validate the sigs... but thats not super critical...
22:55 < gmaxwell> validating is a pita if you're not constraining the kinds of coins you spend.
22:57 < andytoshi> yeah, i read through the wiki pages and etotheipi's graphic..
23:18 < andytoshi> i think it's working (rust is incredible, first time it compiles it does the right thing)
23:18 < andytoshi> how can i verify that the signed transaction is valid?
23:35 < gmaxwell> andytoshi: there is no 'validatetransaction' rpc call, the best you can do is try it on testnet ... or an isolated node. (e.g. if the txn isn't relevant to your wallet, and you are -noconnect -nolisten ... it'll only ever be in memory on your node)
23:50 < andytoshi> done, will be on github in 5 minutes..
23:51 < gmaxwell> you may have the odd honor of having first publically posted rust bitcoin code.
23:56 < andytoshi> https://github.com/apoelstra/coinjoin
23:56  * andytoshi blushes
23:56 < jgarzik> gmaxwell, I'm pretty sure signtransaction will validate for you
23:56 < jgarzik> gmaxwell, it's not explicit, but there is a way
23:56 < jgarzik> one of the RPC calls will perform that function
23:59 < gmaxwell> maybe the complete flag there ... but I'm not sure, as I've run into it saying complete:false on a totally valid completed transaction in some case or another.
23:59 < gmaxwell> it won't tell you where it fails if it does, which I think is what andytoshi would want.
--- Log closed Wed Dec 11 00:00:11 2013