--- Log opened Tue Dec 03 00:00:27 2013
00:08 < cork2> hey
00:15 < cork2> o________0
00:17 < Mike_B> gmaxwell: that's a very good post
00:25 < cork2> so how do I go about integrating a simple game to make a new alt coin
00:25 < Mike_B> has anyone in here looked carefully at the ripple architecture?
00:25 < Mike_B> i'm very interested in how consensus works vs proof of work
00:25 < Mike_B> i'm curious if it's possible to come up with the same sort of system but that doesn't require XRP and all that
00:29 < pigeons> Mike_B: probably not. The knock I've seen from people like amiller is that it may not work despite XRP
00:29 < pigeons> XRP is just a anti-abuse mechanism, not a part of the ripple consensus process
00:30 < Mike_B> well, a few things
00:30 < amiller> i've started trying to give ripple a thorough analysis with sample code experiments and such
00:30 < Mike_B> 1) i'm trying to figure out if XRP is really necessary to prevent abuse in the consensus process. i doubt it; seems likes they shoehorned it in
00:30 < Mike_B> 2) are you saying consensus itself is broken? if so, how?
00:31 < pigeons> its not to prevent abuse in the consensus process, its to prevent abuse of shared resources like ledger space and transaction capactiy
00:31 < amiller> i'm really sure the consensus system is broken and totally preposterous
00:32 < amiller> it's not so much that it's broken, but that it only works under exteremely optimistic conditions, which specifically amount in this case to "everyone uses the official validators list"
00:33 < gwillen> I am not sure sure the consensus system is preposterous
00:33 < gmaxwell> Mike_B: https://bitcointalk.org/index.php?topic=144471.0
00:33 < gwillen> but it's not clear they will ever switch to using the consensus system
00:33 < gwillen> from what they have right now, which is purely centralized
00:34 < amiller> they are "using" the consensus system
00:34 < amiller> it's implemented in their code, they're running the code
00:34 < gmaxwell> Mike_B: read more than just the intial message— I answered my own question and had a nice debate about their consensus system with one of their main developers.
00:34 < gwillen> can we just come up with a scheme to merge-mine an old-ripple-like consensus system into bitcoin
00:34 < gwillen> and then use that to kill off new-ripple by outcompeting it
00:34 < gmaxwell> gwillen: there is no need to have a consensus system for ripple!
00:34 < gwillen> er, old-ripple-like system, rather
00:34 < amiller> gwillen, that sounds reasonable to me
00:34 < gmaxwell> that was part of the attraction, the need for consensus was minimal to none.
00:34 < Mike_B> pigeons: how does bitcoin not have the same issue? transaction fees? i don't understand that
00:35 < amiller> gwillen, that's essentially what "Freimarkets" is
00:35 < gwillen> gmaxwell: well, the old ripple was purely centralized
00:35 < Mike_B> gmaxwell: thanks, i'll read
00:35 < gwillen> gmaxwell: I guess it's true that you do only need local knowledge of balances for the most part
00:35 < gwillen> gmaxwell: so you should be able to design a system that doesn't need centralization or consensus
00:35 < gmaxwell> gwillen: right, route finding doesn't need to be consistent, and the actual transaction only needs to involve the involved parties.
00:35 < gwillen> hmmm.
00:36 < gwillen> you do sort of want the actual transaciton to be atomic
00:36 < amiller> i don't think you're right about the transaction only involving the involved prties
00:36 < gwillen> that might require some sort of commitment mechanism
00:36 < pigeons> gwillen: the ideas like that were here http://archive.ripple-project.org/Protocol/Protocol?from=Protocol.Index
00:36 < gwillen> if you don't care about atomicity then it doesn't really need one
00:36 < amiller> the whole point is you can change the ledgers of people who aren't online
00:36 < gmaxwell> gwillen: yes, the atomic kill is the complicated part.
00:36 < gmaxwell> amiller: then you could still have distributed 'proxies' who can play your role when you are not online, but again— without requring a global consensus.
00:37 < amiller> i'm pretty sure there's a good use for global (or at least somewhat larger scale) consensus even with that but what you're suggesting is still reasonable for the most part
00:37 < gmaxwell> gwillen: the atomic part is being able to unwind a transaction which has only partially completed.
00:38 < gmaxwell> amiller: I'm not saying you couldn't add one, but adding one makes scaling fundimentally harder. Global consensus should be avoided where its at all possible to do so.
00:39 < gmaxwell> gwillen: e.g. you're flowing credit  alice -> bob -> carol -> sue  and before it's established carol goes offline. And now you need to unwind the alice -> bob  reservation in order to setup a new path to sue.
00:41 < gwillen> gmaxwell: I guess you don't really need any atomic primitives for that.
00:41 < gwillen> local atomicity of operations on the links is fine
00:43 < pigeons> aw too bad jtimon isnt on at the moment, he had an intersting proposal for ripple transaction processing "2 phase commit model" or something
00:43 < gmaxwell> gwillen: it's somewhat tricky. So you're tearing down alice -> bob but then carol comes back online
00:44 < gmaxwell> It's solvable, I mean if its solvable globally its certantly solvable locally.
00:44 < gwillen> gmaxwell: at any given moment there is some participant who is 'furthest along' in the chain, and they know whether they are currently setting up or aborting
00:44 < gwillen> so it seems pretty doable
00:44 < amiller> i think that's a really bad solution
00:44 < amiller> i guess someone should implement it that way first, at least it's decentralized
00:45 < gmaxwell> Having to back it out the opposite way is somewhat inefficient.
00:45 < amiller> you basically get all your liquidity tied up in trades that aren't likely to complete
00:45 < gmaxwell> But yea, workable.
00:45 < Mike_B> phew, this is a very large thread
00:45 < gwillen> but yeah, offline functioning would be nice
00:45 < amiller> you also get people able to lie when they offer exchanges
00:45 < Mike_B> i'll read the whole thing before asking more questions
00:45 < gwillen> and since we have this distributed consensus ledger right here
00:45 < gwillen> seems like we might as well use it ;-)
00:45 < amiller> in other words if i offer to exchange 1 of your IOUs for any 1.5 of someone else's, i shouldn't be able to cause those trades to abort
00:46 < gmaxwell> amiller: hm? you can be reasonably confident that it's likly to compelte.. and if someone lies you should be able to lrove it.
00:46 < amiller> that's the advantage of having the orders committed into the ledger where they can be executed automatically
00:46 < amiller> no way you definitely can't prove it
00:46 < gwillen> yeah, I was mostly thinking of old-ripple
00:46 < gwillen> the trades and stuff in new-ripple require more machinery
00:46 < amiller> old ripple always involved trades
00:46 < amiller> you would set up a willingness to exchange one IOU for another
00:46 < amiller> maybe old ripple never actually had that :/
00:46 < gmaxwell> amiller: yea great, except when there isn't room in the ledger.
00:47 < amiller> you don't necessarily need a huge ledger
00:47 < gmaxwell> amiller: did old ripple have you only do trades against XRP to avoid the N^2 problem? but also thereby letting anyone with a trillion xrp walk away with all the IOUs? :P
00:47 < gwillen> old ripple didn't have XRP, or trades, or currencies
00:48 < amiller> no it didn't, but current ripple actually has that functionality implemented corretly in their api
00:48 < gwillen> under old ripple, everybody issued their own IOUs that were all pegged to USD
00:48 < gwillen> old ripple was more or less entirely unlike new ripple, relaly
00:48 < pigeons> you don't have to trade against XRP in new ripple
00:48 < amiller> whether their web front end presents that to the user is kind of different, and i don't think they made the worng decision tehre necessarily
00:48 < amiller> they've done a thoroughly good job on the api, it's only the *whole underlying consensus mechanism* that doesn't work
00:48 < gmaxwell> pigeons: IIRC when I looked at some of their prerelease code all trade was really against xrp on the backend.
00:49 < pigeons> gmaxwell: it isnt
00:49 < pigeons> i construct my own paths
00:49 < gmaxwell> interesting. Is there actually enough usage of it that thats workable now?
00:50 < pigeons> recently they like to push that "hey you can just trade against XRP so you don't have to worry about all the combinations of pairs" but you can construct paths just as well that dont use XRP, and the pathfinding doesnt give preference to XRP
00:50 < pigeons> well enough usage is kind of subjective, but you can get rather large complicated paths now
00:51 < amiller> pigeons, you should make a walk through of this somehow, like a forum post
00:51 < pigeons> they've improved the server pathfinding engine a lot finsally but you can implenment your own and submit your own paths to be excuted
00:51 < amiller> i don't think anyone else is using it or knows how
00:51 < pigeons> right but then they would do the arbitrage trades i'm doing
00:52 < pigeons> but look at the ripple_path_find api, and kind of chain and brute force it to every issuer the destination accepts
00:52 < pigeons> and every currency code
00:52 < pigeons> let me ask if i can share my friend's custom client with you
00:54 < gmaxwell> pigeons: did your arb script screw you with tradeforetress?
00:55 < pigeons> not at all
00:55 < pigeons> i don't trust tradefortress
00:55 < pigeons> i dont trust anyone who trusts him either
00:55 < pigeons> i dont value anything he issues
00:56 < pigeons> sometimes my paths do go trhough things i dont value though
00:56 < gwillen> gmaxwell: what happened with tradefortress?
00:57 < pigeons> like the other day i discovered someone issuing MXN i didnt know because the cheapest path to send myself bitstamp USD from a certain issuers GBP i had was to buy MXN for XRP that i acquired for selling GBP and sell the MXN for BTC
00:57 < pigeons> trades on the oprder books are treated as a node in the path
00:57 < gmaxwell> gwillen: I'm clueless, something like:  he got lots of people to trust him, issued a bunch of tradeforetress btc, lots of trades flowed through him leaving people with tf btc and he said LOL SOL SUCKERS.
00:58 < gwillen> gmaxwell: heh.
00:58 < pigeons> so you can go through a trust line BTC/bob -> btc/alice or you can go BTC/bob ->market BTCbob/XRP _.btc/alic
00:58 < gwillen> gmaxwell: do I understand the ripple system correctly that if you do not manually trust tradefortress, it should not be possible for him to screw you?
00:58 < gwillen> gmaxwell: even if, for example, you trust someone who trust him?
00:58 < pigeons> he posted in the newbie section offering free btc if you trust him for 100 btc
00:58 < gwillen> sigh
00:58 < gwillen> people are idiots, aren't they
00:58 < gwillen> I guess this is why the ripple people put 'trust' under 'advanced'
00:59 < pigeons> then if the user also had btc assets that actually were redeemeable and also trusted TF, or someone with redeemable assets was trusted by the guy who trusted TF, TF or his cohorts would take the BTC they were trusted to be allowed to take
01:00 < pigeons> he calimed he was trying to teach a lesson on the dangers of IOUS, I guess he tought that lesson again with inputs.io and coinlenders
01:00 < gmaxwell> oh did he rip people off on coinlenders?
01:01 < gmaxwell> he should team up with realsolid and zhou... it would be like a cryptocurrency learning expirence dream team.
01:01 < gwillen> pigeons: just to be clear, if I trust X and X trusts TF, the ripple system will leave X holding the bag, and not me, right? I will never end up with TF IOUs?
01:01 < gwillen> pigeons: The only way I could get screwed is if X, who is holding worthless TF IOUs, decides to then default on their own IOUs?
01:01 < pigeons> you can never hold or receive an asset you don't explicitly agree to hold
01:01 < gwillen> (which they might well do, having issued those IOUs without understanding how they could get screwed)
01:01 < gmaxwell> pigeons: you could still trade through those assets you haven't agreed to hold, in passing so no risk from them, right?
01:02 < pigeons> you can acquire assets you havent granted a trust line for by making a trade offer
01:02 < pigeons> but making the trade offer implies agreement to accept
01:03 < pigeons> in the case i mentioned with the MXN, the buy and sell was in one transaction
01:03 < gmaxwell> gwillen: yea, of course there is always the systemic risk. You trust A, A trusts B. B bankrups A and in doing so that bankrups you, even though you never trusted B, only trusted A too much.
01:03 < gwillen> right
01:03 < gmaxwell> I dunno if there was any systemic risk fallout with TF
01:03 < gwillen> just checking my understanding
01:04 < pigeons> we marked the accounts that were not TF himself but took advantage of the situation in our address books as TF.X1 TF.X@ etc
01:04 < gwillen> took advantage how?
01:05 < gwillen> Did they also default on IOUs?
01:05 < pigeons> took advantage by sending the user TF IOUS that the user niavely agreed to accept, in exchange for more trustworthy ious like from bitstamp
01:05 < gmaxwell> used tf IOU's to acquire real assets.
01:06 < gwillen> hmm
01:06 < gwillen> is it possible to implicate people for doing that on purpose?
01:06 < gwillen> as opposed to just treating those things as equivalent, and having the system rearrange them as part of some other transaction?
01:06 < pigeons> well the client gives a red warning "YOU ARE TRUSTING MORE THAN ONE ISSUER FOR THE SAME ASSET, THIS ALLOWS THESE ASSETS TO BE EXCHANGED AT PAR WITH EACH OTHER" or something
01:07 < gwillen> oh, that's new since I used it
01:07 < gwillen> interesting
01:07 < pigeons> gwillen: yes there are ways to assign different values to different lines, called "quality settings" but they are not exposed in the default client
01:07 < gmaxwell> hm. really?
01:07 < pigeons> for example one issuer i have to email to get my btc, so i give it a quality in of 0.95
01:07 < gmaxwell> I have two issuers trusted for btc in my ripple wallet, I have no clue who they are. I don't see any warning.
01:07 < pigeons> so if payment ripples through me i recevie 5% more than the other issue i give out
01:08 < gmaxwell> I was about to ask if there was a way to program in automatic spreads.
01:08 < pigeons> the warning comes when you assign trust
01:08 < pigeons> try it
01:08 < gmaxwell> pigeons: gimme an address?
01:08 < pigeons> the corrolary is 'quality out" which means if liquidity form this line is used, you get more than you give
01:08 < pigeons> i maintain a list of addresses here https://bitcointalk.org/index.php?topic=155236.msg1646402#msg1646402
01:09 < pigeons> dividend rippler is rfYv1TXnwgDDK4WQNbFALykYuEBnrR4pDX
01:09 < pigeons> bitstamp is rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B
01:10 < pigeons> so you could set quality out of 1.01 on your trust line with BTC/Bitstamp since bitstamp is very liquid in ripple
01:10 < pigeons> so if you end up with dividend rippler at least you get 1% more
01:10 < gmaxwell> pigeons: hm. so you can turn a profit from acting as a liquidity provider ... interesting.
01:10 < pigeons> altough dividend rippler is immediately reedemable
01:10 < gwillen> what is 'dividend rippler'
01:10 < gmaxwell> rQay7bQ3XoZcT6E3c8uDopZdnWaMBxWea2 < any idea what that is?
01:11 < pigeons> one sec
01:11 < pigeons> i have that address as "jorgen"
01:11 < gmaxwell> "By pressing CONFIRM you are extending trust to multiple issuers for the same currency which may result in your account balances changing without your direct action. Make sure you understand these consequences, and that all your issuers are trustworthy." heh indeed.
01:11 < gwillen> is it not true that trusting a single issuer can cause your account balances to change without your direct action?
01:12 < gmaxwell> I have it, but trusted at 0.
01:12 < pigeons> gwillen: it cannot
01:12 < gwillen> hmm
01:12 < pigeons> trusted at 0 removes the trust line
01:12 < gmaxwell> yea, seems you can't label these darn things in the interfac.e
01:12 < pigeons> go to contacts and enter one and it will show in the trust tab
01:12 < pigeons> but yeah the client pretty much sucks
01:13 < pigeons> gwillen: dividendrippler.com is an automated way to send blockchain assets and get ripple assets issued and vice versa
01:13 < gwillen> hm, interesting
01:13 < gmaxwell> you'd think they'd make the quality stuff exposed, since I bet a lot of people would jump into this trying to make money as liquidity providers.
01:14 < pigeons> yes lots of people on the ripple forums complain that they would like to trust multiple issuers but dont want their balances changing
01:15 < amiller> in other words extend line of credit wihtout implicitly offering any exchange standing offers
01:15 < pigeons> i spoke with David Schwartz at a conference and was talking about my quality settings and he seemed to think that 1:1 acceptance was good for the network
01:16 < pigeons> you can also make explicit order book trades for USD/Foo vs USD/Bar
01:16 < gmaxwell> weird, I'd think that near but not quite 1:1 would be good for the network. Besides, taking a less trusted issuer exposes you to risk you should be compensated for.
01:16 < amiller> 1:1 accepts is basically the "i'm altruistic and trust everyone at my own avoidable loss" setting
01:16 < amiller> so yeah it's good for the network if everyone else does it
01:16 < pigeons> i do try to keep 1:1 if i can cashout easily and immediatly with little to no fee and the issuer has a good repuation
01:16 < pigeons> and then i discount from there
01:16 < gmaxwell> amiller: well not quite because if too many people lose their shirts thats bad for the network.
01:17 < pigeons> that's why i try to use quality in so i can charge a premium based on certain issues i receive instead of a quality out on a popular issue, cause that would affect the liquidty i offer to my friends in that issue
01:18 < pigeons> but the opposite is reccomended i dont know why
01:18 < gmaxwell> quality in sounds generally more reasonable. you have a cost in taking a non-prefered asset, not so much in giving out a preferred one.
01:19 < gwillen> just call it the "Gresham's Law multiplier" ;-)
01:19 < pigeons> sometimes if all my btc is immediatly flowing from bitstamp to say rippleisrael, but eventhough i know the guys at ripple israel and have an automated intefece to get real btc, i set the quality in on R.I. just cause it seems people are willing to pay it
01:19 < amiller> how many transactions go throuhg jeff cliff
01:20 < pigeons> amiller: not as many as in the old ripple system, but he's starting to catch up
01:20 < pigeons> "The Kevin Bacon of Ripple"
01:21 < gmaxwell> so what happens when fincen decides all ripple users are money transmitters? :P
01:21 < pigeons> well then we learn the consequences of the default UNL list issue, when those validators are asked to deny transactions from unlicensed folk
01:22 < gwillen> gmaxwell: http://www.quickmeme.com/Youre-gonna-have-a-bad-time/
01:22 < amiller> just the ones that make profit, rely on public reputations and the appearance of a "legal company", i.e., the only ones that ripple labs is encouraging to do this, aka gateways
01:22 < pigeons> and ripple is worse than bitcoin for pricavy
01:22 < pigeons> altough there is a feature for making subkeys that are suppsoedly not linked to your master key but can spend but i dont understand it
01:23 < pigeons> because an address needs a certain XRP "resever" to be activated and how would that appear for the subkeys? and i assume you could link them that way
01:23 < gmaxwell> thats annoying they could have made the privacy stronger than bitcoin, since if an issuer is online you could automatically ask them to replace your coins with unrelated coins.
01:24 < gmaxwell> how do the reserve settings and such get changed? it used to be like 300 ripples reserve, but now I see its 69.
01:24 < gmaxwell> oh sorry 75
01:25 < pigeons> the same consensus process that aggres on which transactions are part of the ledger agrees on current reserves
01:27 < pigeons> well the concept of "coins" isnt really the sames. with bitcoin you need to be able to trace every step of the input back to its generation, but with ripple you just look at the validated balance really
01:28 < gmaxwell> right. this is why I look forward to an altcoin attack.
01:29 < gmaxwell> What happens when the UNL stuff goes public and a majority of trusted parties decide that opencoin reserves ought to be more like 0 xrp?
01:30 < pigeons> you mean when more of the people running nodes start including more vlaidators in their UNL that may be likely to do that? we'll see
01:30 < pigeons> just clarifying by "going public" cause the daemon source is public but yes most use similar UNL
01:31 < pigeons> wait what do you mean by "opencoin reserves"?
01:31 < gmaxwell> thats what I mean by going public, sorry. Defacto public not dejure.
01:31 < pigeons> as opposed to reserves applying to any node/address
01:31 < gmaxwell> wherever the larger amounts of xrp consolidations are still left that haven't been given out.
01:32 < pigeons> you can't change balances by consensus
01:32 < pigeons> you need to have a signed transaction spending it
01:33 < gmaxwell> pigeons: I'm pretty sure you can. the other nodes won't ever accept the change, but a client will accept the majority ledger.
01:33 < pigeons> amiller: what do you say about that?
01:34 < gmaxwell> (IIRC, it would be like bitcoin if we only had a small number of miners (gulp) and everyone but miners was on spv nodes)
01:34 < gmaxwell> generally you couldn't do it without undermining trust in the system, but redistributing xrp— which a lot of people already consider insanely unfair, I bet could be done.
01:35 < amiller> yeah i agree with that unfortunately, i am pretty sure they cut a lot of steps in terms of what kinds of validation we can expect ordinary users to run
01:35 < amiller> full validating ripple nodes are pretty expensive to operate if i understand it right
01:35 < amiller> the web wallet that most people use is not a full validating client, for example
01:35 < amiller> it's effectively the same as SPV, yeah.
01:35 < pigeons> i operate one (yeah down atm) and verifying isnt that expensive but keeping history is
01:35 < amiller> how large is the state file/
01:36 < gmaxwell> heh. bitcoin's current state is about 250mbytes. :P
01:36 < pigeons> i dont know i was running on a smallish vps, and i dont understand the internals very well, which was why i was running it, but had some other projects and i've borrowed that box
01:37 < amiller> either way i don't think even that is an insurmountable problem
01:40 < Mike_B> well
01:40 < Mike_B> i just read the entire thread, as well as this irc convo
01:40 < Mike_B> gmaxwell: quite interesting
01:40 < Mike_B> this reinforces my impression of ripple as a cool service, but not really decentralized
01:40 < Mike_B> which, i guess, if they're trying to compete with paypal and visa, is fine
01:41 < Mike_B> but i agree with the analysis that the trust network concept can easily lead to topologies where the network gets screwed even if most nodes are honest
01:41 < gmaxwell> Yea, as amiller says. it's busted.
01:41 < Mike_B> i dunno how they intend to get other people running validator nodes anyway
01:42 < Mike_B> alright well, that was a very full answer to my question
01:42 < Mike_B> i'll have to bbl but thanks for pointing me to all of that
01:42 < gmaxwell> I think mostly the "decenteralized" thing on ripple is a regulatory dodge. I hope for them that it works... also for bitcoin, since if they decide that ripple's decenteralization is pretext, perhaps they'll suspect the same of bitcoin and go after .. say.. me.
01:42 < pigeons> ripple labs' nodes are very unreliable i guess they are under high load, so when mine isnt running i was looking for some others to use and one issue i thought of as far as trusting nodes you submit your signed transactions to is what if a "bad" server sends me a next sequence number far in the future, which causes my transaction to be rejected, but the bad server keeps my signed transaction and submits it when i reach that sequence number, a
01:43 < pigeons> far fetched i know, but i was running a few different clients at once and getting mixed up on sequence numbers and was thinking
01:43 < gmaxwell> Mike_B: we did come up with a somewhat elegant (IMO) way to get people to run archive nodes in a bitcoin like network, but it wouldn't apply to ripple.
01:44 < pigeons> gmaxwell: where is that discussed?
01:44 < gmaxwell> here.
01:44 < gmaxwell> :P
01:45 < pigeons> ok i'll scroll up, thanks :)
01:45 < gmaxwell> Mike_B: basically the idea is that we can (with massive protocol changes) effectively eliminate the utxo set, making validation nearly storageless, and require txn to provde proof that their inputs existed and are unspent.  Now the storage is required to produce those proofs. So if you're a storageless wallet, you can find an archive node and pay them a bit of fee in your txn to add the proof to it so you can get it mined.
01:47 < gmaxwell> though there is some bandwidth tradeoff to operate in this manner, and I dunno if anyone has worked out all the concrete numbers yet to see how it would work out in practice, asymptotically it looks good. and of you use SNARKS to compress the proofs then the bandwidth is similar to what is required today.
03:08 < _ingsoc> !seen swulf--
03:08 < _ingsoc> Does that work here? :(
04:19 < edulix> now, this channel has an awesome name (hi!)
04:22 < edulix> the coincovenant sounds like a really awesome-crazy-bad idea by the way gmaxwell
04:24 < edulix>  Alternative chains have been suggested as ways to implement DNS, P2P currency exchanges, SSL certificate authorities, timestamping, file storage and voting systems << which voting systems?
05:02 < Mike_B> 01:45 gmaxwell: Mike_B: basically the idea is that we can (with massive protocol changes) effectively eliminate the utxo set, making validation nearly storageless, and require txn to provde proof that their inputs existed and are unspent.  Now the storage is required to produce those proofs. So if you're a storageless wallet, you can find an archive node and pay them a bit of fee in your txn to add the proof to it s
05:02 < Mike_B> o you can get it mined.
05:03 < Mike_B> not sure i understand - when you talk about "storage" here, do you mean the blockchain? so when you say storageless validation, you mean no blockchain is required or something?
05:06 < edulix> Mike_B: I assume he means "local storage of the blockchain" i.e. in your HD
05:06 < edulix> which is currently quite large already, 12GB or something like that
05:08 < Mike_B> oh, i see what you mean
05:10 < gmaxwell> Mike_B: no blockchain storage is required for validation alread, but the utxo set is ...
05:11 < Mike_B> sorry, i'm a bit confused here. does this relate to how ripple does things somehow, or is this a different topic?
05:11 < gmaxwell> Mike_B: when bitcoin downloads the blocks it makes a summary of all the spendable coins. It never accesses the blocks again except for reorgs (which only needs the most recent few blocks, or we're doomed) ... and bootstrapping new nodes.
05:11 < Mike_B> i thought this was in the context of ripple and consensus
05:11 < gmaxwell> nah, not ripple. not sure how that tangent got picked up.
05:11 < phantomcircuit> lol ripple
05:11 < TD> this is the merkle mountain ranges thing?
05:11 < Mike_B> ok, got it
05:12 < phantomcircuit> Mike_B, let me help you, nothing works like ripple because ripple doesn't work
05:13 < Mike_B> gmaxwell: so the idea is that various miners basically advertise cryptographically that they have access to the valid utxo set, then you just query them for a fee?
05:14 < Mike_B> or well, not miners, but "archive nodes"
05:14 < Mike_B> maybe you could work it into mining somehow
05:14 < gmaxwell> Mike_B: sort of, the merkle mountain ranges basically eliminates the utxo but replaces by restructuring the blockchain data to make it easy to produce efficient provable queries.
05:14 < gmaxwell> so then transactions ship with the proofs, and verifiying nodes (including miners) don't strictly have to have the history themselves anymore.
05:14 < gmaxwell> Though someone has to have it, in order to produce the proofs.
05:15 < gmaxwell> But that could be users, miners, random nodes who sell their services (e.g. by requring a fee in transactions they provide proofs for)
05:15 < TD> very interesting
05:16  * TD re-reads gmaxwells post
05:17 < TD> the need to combine independent updates to the tree sounds a bit like the operational transform algorithm.
05:19 < gmaxwell> I think petertodd and maaku had some futher enhancements which might make it easier. E.g. having a write only "existing coins" MMR.  and a writable spent coins tree.  The write only tree doesn't require any online activity, once you have your coin proof once you have it forever.
05:19 < TD> that would be useful. the scheme in your post sounds like a wallet would have to sync with the network regularly just to keep money spendable, not only like today to learn about new inbound coins
05:20 < Mike_B> a "merkle mountain range" just looks like a set of merkle trees?
05:20 < Mike_B> where there's no single top node?
05:21 < gmaxwell> TD: kinda! in order to spend it would need some data this is kept updated by an online node, but it doesn't have to have this data itself, if there are other nodes providing this service.
05:21 < TD> right
05:22 < gmaxwell> Mike_B: it's an insertion ordered binary tree where you keep the right edge of the tree constantly. So you can keep inserting while only storing ~log2(n) data.
05:23 < gmaxwell> see also, https://github.com/opentimestamps/opentimestamps-server/blob/master/doc/merkle-mountain-range.md
05:30 < Mike_B> gmaxwell: what do you mean by keeping the right edge of the tree constantly? looks like in the example above that they append nodes to the right and the left is constant
05:30 < Mike_B> in that github link
05:32 < gmaxwell> Mike_B: "keeping constantly" mean keep that data all the time. sorry for the confusing language. :)
05:33 < TD> gmaxwell: did you see the multi-party lottery paper?
05:34 < TD> probably the most impressive piece of academic research into bitcoin yet, too bad the paper has a fair few spelling errors and is quite hard to follow
05:34 < gmaxwell> I did. and their transaction.
05:34 < gmaxwell> (I didn't comment in the thread.. instead I used my diabolical mod powers to copyedit amillers post :) )
05:36 < TD> hehe
05:37 < TD> i sort of understand why they invented their own notation for the scripts and transactions given the complexity of their programs, but ... i really wish they had avoided greek letters
05:37 < TD> english pseudocode is so much easier to follow
05:38 < gmaxwell> I was just talking to Iddo about it earlier, he's emailing them to point out the efficiency improvements Adam Back and he came up with in their cointoss thread.
05:39 < Mike_B> gmaxwell: sorry for being so slow here, i'm trying to get caught up to speed fast
05:39 < Mike_B> you guys have a tremendous amount of knowledge at the ready
05:39 < Mike_B> i'm totally new to the game
05:39 < TD> yes it reminded me i never wrote up adams/iddos coin toss protocol on the wiki
05:39 < TD> must do that
05:40 < Mike_B> so here's an absolute noob question: when you talk about the utxo set, you just basically mean the total set of coins that each wallet has, minus the wallets with 0 coins (e.g. almost all)?
05:40 < Mike_B> like it's a set of wallets with coins in them that are "unspent," meaning they're still in those wallets?
05:40 < gmaxwell> I wonder if any of those software packages for making illustrations from state machine descriptions could be put to use in illustrating some of these protocols.
05:41 < gmaxwell> Mike_B: Bitcoin doesn't track balances. It tracks transaction outputs, which we often tend to call coins.  Every transaction specifies a list of TxIns and a list of Txouts.
05:42 < gmaxwell> Mike_B: the TxIns are the transaction outputs from past transactions that it will be consuming— they're represented by encoding a txid and an index (which txout of that txid).
05:43 < gmaxwell> The txouts are the outputs from the transaction, which have a scriptPubKey (identify the rules for spending the output) and the value.
05:43 < sipa> it's very much like a wallet, where you track each individual coin
05:43 < sipa> except that coins can have arbitrary values
05:43 < sipa> to do a transaction, you give some coins, and get some coins back
05:43 < gmaxwell> The UTXO set is all the txouts that haven't been spent yet... keyed by txid:index.  with data being .. the scriptpubkey and value (and potentially a little bit of other data)
05:44 < gmaxwell> There are a bunch of reasons why this way of constructing the system actually turns out to be simpler than having balances. And if you're always using new public keys for privacy, its basically the same efficiency.
05:45 < Mike_B> ok, got it
05:45 < gmaxwell> https://people.xiph.org/~greg/tx.flow.png < a simple visualization I did for a post previously.
05:45 < Mike_B> ok, so instead of a set of "wallets with balances," which is what i thought naively, it's just a set of "wallets with individual coins," where each "coin" is a transaction that went to that wallet and is still in there
05:46 < gmaxwell> right, and a coin is spent atomically. If the coin has more value than you want to spend, you add an output to send some of the value back to you.
05:46 < gmaxwell> "Change"
05:46 < Mike_B> oh, i totally get this from satoshi's paper now
05:46 < Mike_B> when he talks about an individual coin being a chain of signatures and etc
05:47 < gmaxwell> Righ! yea, the whole system of transactions works without the blockchain at all— so long as no one double spends. :)
05:47 < Mike_B> i was always confused because it sounded like he meant literally one coin, like ฿1
05:47 < Mike_B> but a "coin" is just a transaction
05:47 < Mike_B> ha, that makes way more sense now
05:47 < gmaxwell> right you can imagine it as little metal coins that go off to the network to be melted down and reforged with new owners, and the network obeys conservation of mass.
05:47 < Mike_B> yeah that's exactly how i just visualized it in my head right now, haha
05:47 < Mike_B> different size coins
05:48 < Mike_B> beeeeautiful
05:48 < gmaxwell> (if the outputs are of lower value than the inputs, then the remainder is kept by the miner as a fee)
05:48 < gmaxwell> yea, it's a good mental model, though the overloading of "coin" and "bitcoin" creates confusion. :(
05:48 < Mike_B> i had this thought about mining and consensus and it's connection to something from political science called "arrow's impossibility theorem"
05:49 < Mike_B> it seems like the basic point of the blockchain, in a certain sense, is to come up with some way for the network to reach consensus on which transactions happened first
05:49 < gmaxwell> lol
05:49 < gmaxwell> Thats the purpose of it exactly.
05:49 < gmaxwell> I'm laughing becuase I spent a lot of time on IRC telling people that the only real purpose of mining is ordering transactions.
05:49 < Mike_B> say i'm in the US, and you're in japan, and we both control the same wallet with ฿1 in it, and we try to spend that ฿1 "at the same time"
05:50 < gmaxwell> yea, there is no _general_ autonoymous way to have a decenteralized order — see lamports clock paper. Relativity makes order position dependant, if you want to be uber wanky about it.
05:50 < Mike_B> but there's no such thing as "at the same time" actually, because even if information traveled as fast as possible (e.g. at the speed of light) it'd still take like 30ms or so for information to get from (say) new york and japan, right
05:50 < Mike_B> haha, you called the thing i was about to say "wanky" before i even got to wank :(
05:51 < gmaxwell> I'm allowed to call it wanky because its a position I've earnestly advocated. :)
05:51 < Mike_B> so anyway, *wank wank wank* relativity, no privileged reference frame, etc
05:51 < gmaxwell> But, you know, invoking relativity to explain ... its a little overpowered. :)
05:52 < Mike_B> i did find it useful though, because sometimes you're fooled into thinking that at bottom, there really was a "true" ordering of events
05:52 < Mike_B> and network latency just obscures that One True Ordering
05:52 < Mike_B> i found it useful to realize that i need to completely give up on that because it doesn't even exist
05:53 < gmaxwell> but right, for the most part the system is autonomous and trustless but relativity gets in the way— ultimately— making there be no true order unless you assume a privledged position. So we use a computational vote. Voting sucks. But it's pretty much only used for the ordering.
05:53 < Mike_B> yeah that's what i was thinking
05:53 < Mike_B> the network basically needs to "vote" on a reference frame, and bitcoin is like using the "random ballot" voting approach
05:53 < Mike_B> and the downside to that approach is the 51% vulnerability
05:54 < gmaxwell> right. but if you think about it any kind of "consensus" must have some kind of majority vulnerability... otherwise it has a minority vulnerability!
05:55 < Mike_B> if you used "first past the post" voting, which is kind of ripple's trying to do, you'd run into some other characteristic vulnerability
05:55 < gmaxwell> if there are orthorgonal states that honest nodes can disagree on, and you must pick one...  the weak part of bitcoin isn't 51% it's that it's a 51% of computation (well, really energy consumption it seems :) ) which may not map to anything fair.
05:55 < Mike_B> hm need to think about that re minority vulnerabilities
05:55 < gmaxwell> "fair"
05:56 < Mike_B> yes, that makes sense
05:56 < Mike_B> well i was curious if the 51% attack is a special case of that Arrow's impossibility theorem with the "random ballot" voting method
05:56 < gmaxwell> e.g. 51% of computing power could still be 1% of people, which would be a bit unfortunate. Though, if you want to be .. again. wanky.. given enough time 51% of energy means 51% of anything else. If bitcoin was based somehow on counting people, china (favorite boogyman) could use an energy majority to fund mining babies.
05:57 < gmaxwell> 'mining'
05:58 < Mike_B> what do you mean by that 51% of anything else part?
05:59 < gmaxwell> I was responding to my own point that 51% of energy expended on the system is not necessarily a fair representation of the wishes of the users. But at the same time if someone can really outspend the honest users, then upto-some-efficiency-constant-factors they can also out-whatever your metric is.
05:59 < UukGoblin> isn't "wizzard" spelled with two "z"s? ;-)
06:00 < gmaxwell> E.g. if your metric is voting with actual people (which we can't use because people aren't provable computationally) an attacker could use their excessive resources to make more people.
06:00 < Mike_B> oh, right
06:00 < gmaxwell> There is no finite resource, including humans, that you could count to decide a consensus which isn't potentially vulnerable to abuse by an overpowering attacker.
06:01 < Mike_B> i guess you could try some kind of reverse turing test of some sort
06:01 < gmaxwell> (though there are some constant factors: not everyone has a cpu, but everyone is already a people. :) so the honest side might have an initial advantage if we really could count people for the consensus)
06:01 < Mike_B> but yeah, if you have a ton of money you can just spend it on technology to beat that and then sybil your way to the top
06:02 < gmaxwell> right. This is why I roll my eyes on most "51% solution" proposals. they mostly either just shift around some constant factors, or replace one weakness with another.
06:03 < gmaxwell> (another .. usually worse one... like some clique of 10 people who can pick whatever state they want; e.g. in the case of solidcoin2.0)
06:03 < UukGoblin> well, they probably just do it to trick people into thinking their scamchain is "better"
06:03 < gmaxwell> or ripple's think which is ... hard to analyize.
06:04 < gmaxwell> UukGoblin: I'm sure most of the people doing that stuff believe it. Anyone can invent a consensus system which they don't personally think is flawed. And, hey, if I've got one of those signing keys: it's safe for me!
06:04 < Mike_B> maybe i'm ore interested in altcoins than the average person just because i find them to be interesting hotbeds for experimentation
06:05 < Mike_B> like something like litecoin i don't find interesting since it doesn't do much
06:05 < Mike_B> but some of these altcoins are pretty creative
06:05 < UukGoblin> I'm only interested in altchains to solve two issues: faster transaction confirmation and solving of the 7-transaction-per-second scalability limit
06:06 < UukGoblin> I have a feeling a solution with OpenTransactions may solve this stuff, but I don't yet know how
06:06 < gmaxwell> well most of them aren't there are a couple which have done some things, most of it is not so interesting.
06:06 < epscy> i would like to see a mining system that is more decentralized
06:06 < Mike_B> i thought primecoin was really interesting
06:06 < epscy> but so far litecoin and ppcoin have yet to convince
06:06 < UukGoblin> hence I'm looking forward to this thing you mentioned, gmaxwell - about OT people hacking something up
06:06 < Mike_B> i've been consumed with the problem of making POW useful, like coming up with a rePOW like there's a reCAPTCHA or something
06:07 < gmaxwell> Mike_B: yea, I don't think thats a useful thing in fact. If the POW has independant value that may lower the marginal cost of attacking.
06:07 < Mike_B> why?
06:07 < Mike_B> how so?
06:08 < gmaxwell> E.g. if 99% of your mining income comes from people buying cancer cures from you, and 1% from getting your block into the unique best chain... then you'll only lose 1% of your income by participating in attacks that put you on forks and lower your chances of getting in the unique best chain.
06:08 < gmaxwell> (and you can replace income with whatever utility-units power your motivation to mine. :) )
06:09 < Mike_B> that's a good point
06:09 < gmaxwell> Beyond that, cryptographic hashes have pretty good POW properties in general. You want the users to be very confident that the creator doesn't know some trapdoor that lets them mine fast for free.
06:09 < gmaxwell> You can potentially get that from other things but its surprisingly hard.
06:09 < Mike_B> that doesn't destroy the notion that POW could be useful though, it just argues against one system whereby computational time is purchased from you, and where that purchase works to double as POW for mining
06:09 < gmaxwell> You also want mining to have no progress... e.g. so being 2x faster than everyone else only gets you 2x more blocks, not all the blocks.
06:10 < Mike_B> but that's the exact system i had in mind, so, yeah, that's a good point.
06:10 < gmaxwell> Mike_B: yea, it's not a fatal argument. but it's a consideration.
06:11 < gmaxwell> I got past worrying that pow is "useless": it's quite useful, it makes bitcoin secure, and if you consider the cost of securing other currencies (which have enormous anti counterfeiting expenses, armored cars, guards, etc) perhaps its not so bad.
06:11 < Mike_B> well, i did think primecoin was fairly interesting in how it solves one piece of that problem. in a very broad philosophical sense, it treats the block it's working on as "found art" in a sense
06:11 < Mike_B> like any cryptocurrency has an enormous amount of data going through it
06:11 < gmaxwell> Though my alt idea list does have one not well fleshed out useful-pow that I'm kinda fond of.
06:11 < Mike_B> so primecoin is like, "check every single block to see if it divides the start of a cunningham chain"
06:11 < Mike_B> (or hash the block first or whatever it does, i don't remember the details but you get the gist)
06:12 < gmaxwell> ... which is the ticking of timelock encryption. ... which I'm fond of mostly because I don't think there is any other socially viable way to actually have functional trustless timelock encryption.
06:12 < gmaxwell> (Timelock encryption is encrypt data so that it can't be decrypted until ~xx years from now)
06:13 < Mike_B> hm, interesting
06:14 < Mike_B> well i don't think pow is "useless" in that sense
06:14 < gmaxwell> https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas incidentally, if your head isn't yet full enough. Though I admit its not very readable— has a lot of in-group lingo, I mostly made it as personal notes so I'd stop forgetting ideas.
06:14 < Mike_B> i know there's a lot of political tumult over whether hashcash is "useful"
06:14 < BlueMatt> ok smart people, if one has a lgn algorithm that only works on chunks of size power-of-two, and has arbitrary input, how does one go about efficiently breaking said input up into power-of-two chunks and running?
06:14 < Mike_B> i'm just talking from an engineering standpoint
06:15 < UukGoblin> can you use bitcoin for timelock encryption? :-O
06:15 < BlueMatt> UukGoblin: no?
06:15 < gmaxwell> UukGoblin: look at the altideas page.  not bitcoin as it is today, but I think it's possible with an alternative pow.
06:15 < UukGoblin> ah.
06:15 < Mike_B> gmaxwell: i read that page before but didn't understand some of the terms, i'll have to keep checking it as i get filled in on more of this lingo :)
06:16 < gmaxwell> UukGoblin: the ideas is basically that you make the pow into "take chunks of — say— pi  as a ecc public key, and try to crack it"
06:16 < gmaxwell> UukGoblin: everyone knows pi in advace and thus can encrypt to it.
06:16 < gmaxwell> UukGoblin: and you encrypt your message with all the pi problems between now and when you want it opened.
06:16 < BlueMatt> gmaxwell: heh, literally turn bitcoin into one giant decryption cluster
06:17 < Mike_B> gmaxwell: thinking more about it, doesn't your objection about "useful pow" mining also apply to bitcoin once the block reward goes to 0?
06:17 < gmaxwell> all kinds of problems making it pratical.
06:17 < UukGoblin> gmaxwell, ah... but you still don't really know the speed with which the things will get cracked
06:17 < Mike_B> then 0% of income comes from mining (other than tx fees)
06:17  * BlueMatt puts "make april-fools-altcoin witch decrypts arbitrary constant data as its pow" on his calendar for march
06:17 < gmaxwell> Mike_B: no— transaction fees. though bitcoin is toast, at least as it is currently designed, if there is no income for miners.
06:18 < gmaxwell> Mike_B: it works for txfees. You only get the txfees if your block successfully makes it into the longest chain.
06:18 < Mike_B> gmaxwell: why, just because miners will run away?
06:18 < gmaxwell> Mike_B: not just run away, but the difficulty will drop, and so it may become viable to buy up a lot of computing and overpower the network for short times to reverse transactions.
06:19 < gmaxwell> (I also propose on the alt coin page a tweak so that fees can only be collected if you are mining a chain the transaction author likes, so some successful reorg attacker can't get all the fees still)
06:19 < gmaxwell> (thats one I think we could perhaps someday do in bitcoin)
06:20 < Mike_B> gmaxwell: you could also have it so total coins asymptotically reaches something but never gets there
06:20  * BlueMatt wonders what would happen if all of #bitcoin-wizards were taken from their current dayjobs and hired to write an altcoin
06:21 < Mike_B> so a) there's always a block reward, and b) still a finite supply
06:21 < gmaxwell> BlueMatt: figuring out how to make an efficient discrete log solver progress free is one of the problems with that idea as I stated it. But the "Learning with errors" cryptosystem being used for fully homorphic encryption looks like it might be more agreeable... haven't thought about it too deeply though.
06:21 < gmaxwell> Mike_B: thats how bitcoin is already designed! except we eventually run out of precision!
06:22 < Mike_B> oh oh oh, that's why the block reward goes to zero? just because of precision?
06:22 < gmaxwell> Mike_B: its a geometric series with the limit after infinite time of 21 million, but the values are integers with 1e-8 being the smallest amount.
06:22 < gmaxwell> yea.
06:22 < Mike_B> oh, derp
06:22  * Mike_B pats self on back while saying derp three times
06:22 < gmaxwell> yea, hah, well you're not doing so bad when you're guessing how it already works.
06:23 < BlueMatt> gmaxwell: yes, that problem sounds exactly like something homomorphic encryption would be ideal for
06:23 < Mike_B> you could just have the precision automatically increase as the block reward decreases
06:23 < BlueMatt> not that Ive thought about it at all, but it seems to go together there
06:23 < gmaxwell> 32 years until the reward is imprecise.
06:23  * BlueMatt goes back to all-nighter coding parallel algorithms
06:24 < gmaxwell> Mike_B: software engineering nightmare.
06:24 < Mike_B> yeah that's no good
06:25 < Mike_B> i guess the only way around it would be to just get rid of the finite supply
06:25 < gmaxwell> already the range we have is close to what you can do before it's annoying.
06:26 < Mike_B> which is equivalent to everyone on the network paying a very small "tax" to miners
06:26 < gmaxwell> I do kinda wish bitcoin had been programed with some very slight inflation. But ... it sure makes the explination easier to say fixed supply.
06:26 < Mike_B> it would be weird for political reasons, people hate inflation
06:27 < BlueMatt> gmaxwell: i think most people do, but the "deflationary" statement made initial adoption all the more attractive
06:27 < Mike_B> but you could also program it to just suck some tiny percent out of everyone's wallet proportionally totaling ฿50 or whatever, and then give it to the miner who won as a "tax'
06:27 < BlueMatt> gmaxwell: and despite being little practical difference, there is huge psychological difference between "deflationary" and "barely inflationary"
06:28 < Mike_B> people would probably mind that less even though it's the same thing
06:28 < gmaxwell> Mike_B: there are problems, say you program the inflation rate at 1% and the lost rate is 2% ... after some very large amount of time the inflation is now some large percentage of the actual economy. And thats distorting.. people are like .. out capturing extra stars to implode them to power their miners.
06:29 < gmaxwell> maybe you could get away with some system estimate of the current surviving coin supply to keep that under control... but the solution is not unique. Every part of the bitcoin design which isn't largely unique seems to be subject to endless wasteful debate.
06:30 < epscy> i guess if you use days destroyed that's just a kind of proof of storage, but with the proceeds going to miners rather than the storers
06:30 < Mike_B> i agree having the system estimate the surviving coin supply is bad
06:30 < Mike_B> or likely to cause problems, at least
06:30 < gmaxwell> Mike_B: freicoin does the sucks out thing. ... but their sucks out and pumps in rate is 5% 0_o.
06:30 < jtimon> Mike_B gmaxwell infinite precision to have perpetual reward doesn't make much sense, will an anual reward of 0.00000000000000001% of the supply really make any difference?
06:31 < gmaxwell> jtimon: depends on how many coins are left. Careful with "supply"
06:31 < Mike_B> you could use "total number of transactions in a 2 week time period" or something to gauge how hot the bitcoin economy is
06:31 < Mike_B> the bitcoin GDP or whatever
06:31 < Mike_B> and tie inflation to that somehow
06:31 < Mike_B> dunno how that relates to miners anymore though
06:31 < gmaxwell> jtimon: if you've lost 99% of the coins (the great crypto wars of 2124 ...) then its a fair bit more.
06:31 < gmaxwell> Mike_B: easily manipulated by miners.
06:32 < gmaxwell> (who, of course, recieve the subsidy)
06:32 < jtimon> at some point the reward will be lower than the 0% of coins lost
06:32 < Mike_B> gmaxwell: i was thinking an inverse relationship
06:32 < Mike_B> more transactions = less reward
06:32 < Mike_B> though that's also bad
06:32 < jtimon> and with everrgowing supply but constant reward (aka timecoin) the problem is similar
06:32 < Mike_B> the real problem seems to be the length of time it takes difficulty to adjust
06:33 < gmaxwell> Mike_B: hm? I've never seen that as a problem.
06:33 < jtimon> if you one to have a perpetual reward proportional to the supply the only solutions are freicoin and expocoin (the reward is always growing too)
06:33 < Mike_B> oh nm i misunderstood what you were saying
06:34 < Mike_B> you're saying that if difficulty drops due to a block reward decrease, overpowered miners can come in and try to 51% the network?
06:34 < gmaxwell> Mike_B: yea.
06:34 < jtimon> Mike_B you cannot measure bitcoin's GDP from within the chain
06:34 < gmaxwell> Mike_B: if it drops and leaves the network stranded uhh we have bigger problems. (and it would be 'easy' to do a manual difficulty step to fix)
06:35 < Mike_B> gmaxwell: wouldn't all of these overpowered miners suddenly try to do that though? suddenly everyone's competing to be dishonest instead of honest
06:36 < Mike_B> now all overpowered miners now have an incentive to try to stay in to get 51%
06:36 < gmaxwell> Mike_B: maybe, depends on the form of the dishonesty. Some kinds are not that competitve. ... e.g. if there are very few full nodes they can cause inflation.
06:36 < Mike_B> jtimon: why not?
06:36 < gmaxwell> also, a war of dishonesty is bad for stability. e.g. big reorgs. even if the end result is mostly kinda sort honest.
06:37 < jtimon> because I can pay to myself
06:37 < gmaxwell> esp if jtimon is a miner.
06:37 < jtimon> and if I'm not I can pay fees to pay to myself
06:38 < gmaxwell> you can try some hack with coins days destroyed perhaps that works, but you get deep into hurestics, and I think adhoc solutions are not good inside a cryptocurrency.  All the users have to accept that it works right, and if there are 1001 ways to do something thats bad.
06:38 < jtimon> the point is there's no way to distinguish "real commerce" from just "wallet refactoring"
06:38 < Mike_B> ok, very true
06:39 < gmaxwell> you could potentially try a control loop that keeps difficulty forever increasing.
06:39 < Mike_B> though i'd still expect "more volume moved" still correlates very strongly with "bitcoin GDP" (whatever that would actually be)
06:39 < gmaxwell> Mike_B: it does until you add in an adaptive attacker.
06:39 < gmaxwell> as soon as there is an incentive to fake gdp (up or down) miners can block transactions or fill blocks with 'fake' ones.
06:40 < gmaxwell> might as well just have a field in the blocks miners can set: GDP: X :P
06:40 < jtimon> Mike_B that could be useful for an economic researcher that makes estimates about % real commerce, etc, but the chain algorithm shouldn't make those kind of estimates
06:40 < Mike_B> ok right
06:41 < jtimon> gmaxwell I've been thinking more about your "required security is not proportional to the value of the total supply more"
06:42 < jtimon> not taking post coins into account because those are recycled in freicoin
06:42 < jtimon> but I now disagreee
06:42 < jtimon> your example was that you could reverse a 1M tx with the work of one block
06:43 < jtimon> but it is the recipients fault to only wait 1 block (or 6) for a 1 million transaction
06:44 < jtimon> so really any demurrage rate is enough, it's just a matter of people having to wait more confirmations
06:44 < gmaxwell> jtimon: so what if they wait 6? 1M is cheap compared to 6 blocks, e.g. if you assume the attacker can bribe miners, or buy computing power. Bitcoin mining marketplaces offering 115% PPS got a substantial chunk of the hashrate when they existed. :P  perhaps enough, though enough might be a really large number. :)
06:45 < jtimon> I'm using 6 just as a number
06:46 < jtimon> the recipient should estimate how much he has to wait to considered himself paid
06:46 < jtimon> maybe he has to wit 4 or 100 blocks, I don't know
06:46 < jtimon> wait
06:47 < gmaxwell> all txn in the block could be attacks however. :(
06:47 < jtimon> what do you mean txs could be attacks?
06:47 < gmaxwell> yes, but if you assume current block volumes in bitcoin assuming an attack with 20% hashpower... you end up with crazy numbers like 35 blocks where attacking isn't provitable over subsidy.  (Well, current: I ran these number 9 months ago)
06:48 < gmaxwell> jtimon: an attacker is not limited to making one attack per block. Every transaction in their block could be a double spend attack on a different target.
06:48 < jtimon> oh, I see
06:48 < gmaxwell> so if you are to be conservative you must compare the value of the lost subsidies to the value of all transactions.
06:49 < jtimon> interesting, you would not only need to look at your transaction, but to all transactions near it
06:49 < gmaxwell> which is a bit extreme, I was hoping it would produce tidy numbers like 10 confirmations or whatever, but it turns out in bitcoin it didn't... not if you assume attackrs with 20% hashpower.
06:49 < jtimon> to know the full potential incentive of the attacker
06:50 < gmaxwell> (I was concerned about everyone still assuming 6 was golden and hoped the software could give better advice...)
06:50 < jtimon> but I still think that the rule "the more valuable the coins are, the more security you need" applies
06:51 < Mike_B> 06:28 gmaxwell: Mike_B: there are problems, say you program the inflation rate at 1% and the lost rate is 2% ... after some very large amount of time the inflation is now some large percentage of the actual economy. And thats distorting.. people are like .. out capturing extra stars to implode them to power their miners.
06:51 < Mike_B> i'm still kind of hung on this
06:51 < Mike_B> what would the problem be exactly?
06:52 < jtimon> yes, would be cool to have a configurable client that waits for more confirmations depending on values, maybe querying bitcoinwatch or something
06:52 < Mike_B> if there's an inflation rate of 1% and a lost rate of 2%, you end up with a net deflation rate of 1%, right?
06:52 < Mike_B> why does that lead to dyson spheres or what have you
06:52 < gmaxwell> Mike_B: but compute the proportion of the total remaining economy that is going to mining.
06:52 < Mike_B> oh, i see what you're saying
06:53 < Mike_B> since you never have a clue what the lost rate is
06:53 < gmaxwell> the 1% isn't of the economy, we can't measure that— it's 1% of the maximum potential economy.
06:53 < gmaxwell> right.
06:53 < Mike_B> so what you could do is just have it level off at some fixed reward per block
06:53 < Mike_B> so the inflation rate is basically a constantly decreasing percentage that never reaches 0%
06:53 < gmaxwell> yes but if there is a bunch of deflation then that number is too high and you're back to the dyson sphere.
06:53 < jtimon> yes, the problem we fear in freicoin is "over-mining" not "under-reward"
06:54 < jtimon> dyson sphere?
06:54 < gmaxwell> jtimon: https://en.wikipedia.org/wiki/Dyson_sphere
06:54 < jtimon> anyway gmaxwell, I don't think you need a control loop on the reward, it can be constant
06:55 < gmaxwell> I don't think any constant value is "safe" (in that it can't over-reward)
06:55 < jtimon> og, I see, starships
06:56 < jtimon> I claim that any value is safe in that it cannot under-reward
06:56 < gmaxwell> you can't know the value of a coin within the system, so whatever you set it to perhaps its way too much.. and if we're not smart enough to abandon the currency we do crazy things. :)
06:56 < jtimon> so we share the same concern
06:56 < Mike_B> gmaxwell: if overrewarding occurs then it balances itself out rather quickly as those new coins enter circulation
06:56 < jtimon> Mike_B the supply is constant
06:57 < jtimon> I'm using freicoin as example
06:57 < gmaxwell> 4am. too late to think. goodnight
06:57 < jtimon> constant supply, constant demurrage that goes to miners
06:57 < Mike_B> jtimon: the system i've been describing is one where supply always increasing, with block reward eventually leveling off at some fixed value (like say ฿1 or whatever) rather than to 0
06:57 < Mike_B> night gmaxwell
06:57 < jtimon> gmaxwell goodnight
06:58 < Mike_B> so the rate of inflation approaches 0 while the money supply approaches infinity
06:58 < jtimon> you can build a mining-reward-equivalent to freicoin with inflation, it's called expocoin
06:58 < jtimon> your system is timecoin
06:59 < jtimon> constant supply, but since the total supply is ever-growing you're paying proportionally less to miners each year
06:59 < Mike_B> what do you mean by "supply" here
06:59 < Mike_B> the total money supply?
06:59 < jtimon> 21 millions
06:59 < jtimon> yeah
07:00 < Mike_B> so what do you mean by the supply being constant yet ever-growing
07:00 < jtimon> the supply ever-growing, the reward constant
07:00 < jtimon> thus the rewardis always being reduced in proportion to total supply
07:00 < jtimon> the reward is the subsidy forminers
07:01 < Mike_B> ok right
07:01 < Mike_B> yeah that's what i was saying
07:01 < Mike_B> you're saying that's what - expocoin, freicoin, or timecoin?
07:01 < Mike_B> i'm not familiar with all these altcoins
07:01 < jtimon> timecoin
07:01 < Mike_B> the only one i know is freicoin
07:01 < jtimon> only freicoin exisists
07:01 < fagmuffinz> ;;ident fagmuffinz
07:01 < jtimon> the others are only theoretical
07:01 < jtimon> what you're saying is timecoin
07:02 < jtimon> and agaisnt it I previously said:
07:02 < jtimon> Mike_B gmaxwell infinite precision to have perpetual reward doesn't make much sense, will an anual reward of 0.00000000000000001% of the supply really make any difference?
07:03 < Mike_B> jtimon: the answer to that question is yes, because as gmaxwell said, coins are always getting taken out of circulation
07:03 < Mike_B> so it should oscillate or something
07:03 < Mike_B> the actual circulating money supply is less than the supply on paper because of lost private keys
07:04 < jtimon> but coins will be lost at a "fixed" rate, say 2% or 1%
07:04 < jtimon> your reward is proportionally decreasing
07:05 < Mike_B> what's the objection to that
07:05 < jtimon> unless the rate at which people lose coins constantly and forever also drecreases proportionally
07:05 < jtimon> the reward will become meaningless
07:06 < Mike_B> not if there's something nuts like 2% deflation per year it won't
07:06 < jtimon> let me think this again
07:06 < Mike_B> that's like 33% of the money supply being lost over 20 years
07:07 < Mike_B> so what happens is then, suddenly this ฿1 block reward becomes extremely valuable
07:07 < Mike_B> you overreward miners
07:07 < Mike_B> that was gmaxwell's objection
07:07 < Mike_B> but, my counter-argument is that if that happens, then this huge reward eventually enters circulation, causing inflation to counter the deflation
07:07 < Mike_B> so it evens out
07:08 < jtimon> in our example we have perpetual constant reward 1 per block
07:08 < Mike_B> yes
07:08 < jtimon> and people loss money at 2% of the total supply right?
07:09 < Mike_B> yeah, some fixed percentage per year
07:09 < Mike_B> so you have exponential decay and linear growth
07:09 < jtimon> ok, I need a cigarrete while I think about it, I'll be back in some minutes
07:16 < jtimon> so firt year the nominal supplygrows 365
07:16 < jtimon> but the real supply is 2% less
07:16 < jtimon> due to lost coins
07:17 < Mike_B> right
07:17 < jtimon> the number of lost coins starts below 365, but it grows over time
07:17 < Mike_B> right
07:18 < jtimon> at some point the total lost coins per year equals the new 365 created
07:18 < jtimon> and now the question is
07:18 < jtimon> the % of lost coins is from the total supply or the real supply
07:18 < Mike_B> real supply
07:19 < jtimon> if the former, you're right
07:19 < jtimon> since you have chosen real supply
07:19 < jtimon> at that point the real supply stabilizes forever
07:20 < jtimon> so timecoin ends up being reward-equivalent to freicoin too
07:20 < jtimon> but the reward is paid from unpredictable lost coins instead of constant demurrage
07:20 < Mike_B> wait, what was i right about if i said total supply?
07:20 < jtimon> I never thought about this in this way
07:20 < Mike_B> my goal was just that real supply stabilizes forever
07:21 < Mike_B> and miners are always rewarded
07:21 < jtimon> ok, if you had chosen total supply instead of real, gmaxwell would be right
07:22 < jtimon> if you don't take lost coins into account, you need expocoin or freicoin to achieve your goal
07:22 < jtimon> well, with expocoin you don't have constant supply
07:24 < jtimon> well, gmaxwell's objection can also apply to this (and freicoin) but in a less catastrophic way
07:24 < jtimon> I guess
07:25 < jtimon> what if 2% (or whatever rate people lose coins at) is too much subsidy?
07:25 < Mike_B> jtimon: it couldn't be total supply
07:25 < jtimon> mining won't grow like a cancer but still
07:25 < Mike_B> if 2% of the total supply is lost every year then in 50 years you have nothing left
07:26 < jtimon> will be always more miningthan needed
07:26 < jtimon> 1) if you reduce proportionally you always have somthing left
07:26 < Mike_B> i don't understand the total supply scenario
07:27 < Mike_B> if you lose 2% of the "on-paper" amount of bitcoins every year, you run out of bitcoins completely in 50 years and everyone has 0
07:27 < jtimon> 2) in both cases (timecoin and freicoin) you're introducing new coins at a constant rate
07:27 < jtimon> 50 years with what divisibility?
07:28 < jtimon> if coins are infintely devisible you never get out of them
07:29 < jtimon> so now that we've stalished that the supply will stabilize
07:30 < Mike_B> ok well i don't get the total supply thing but let's assume i mean real supply
07:30 < jtimon> in the case of timecoin not the total (on-paper) supply but the real supply will, in freicoin both
07:30 < jtimon> total supply = real supply + lost coins
07:30 < Mike_B> yeah, so just real supply
07:30 < jtimon> in timecoin
07:30 < jtimon> you end up with a fixed real supply
07:31 < jtimon> an equilibrium real supply
07:31 < jtimon> and you're giving miners 2% of that supply every year
07:31 < Mike_B> so the thing i'm describing is basically bitcoin but where the ฿50 block reward never halves. that's exactly what timecoin is?
07:31 < jtimon> what if 2% of the real supply is too much security?
07:31 < jtimon> Mike_B yes, that's timecoin
07:32 < Mike_B> and freicoin is what again?
07:32 < Mike_B> it's inflation + a wealth tax?
07:32 < jtimon> freicoin is 5% demurrage
07:32 < jtimon> demurrage is not a welath tax
07:32 < jtimon> is a fee for parking in the middle of the road
07:33 < jtimon> but economics apart
07:33 < jtimon> 5% demurrage and a reward that ends up constant
07:34 < jtimon> resulting in an equilibrium 100 millions supply
07:34 < Mike_B> but the idea of demurrage is just that it takes some percent out of everyone's wallet every so often, right?
07:34 < Mike_B> let me look up the numbers so i'm not so uninformed
07:34 < jtimon> yes 2^-20% of each output per block, to be exact
07:34 < Mike_B> 20%??
07:35 < jtimon> no 2^(-20)
07:35 < Mike_B> oh oh oh, ok
07:35 < jtimon> that results in 4.89 % anual or something close
07:36 < Mike_B> so what's the point of demurrage vs inflation if the economic impact is exactly the same?
07:36 < jtimon> the effect on interests rates is different
07:36 < jtimon> the effect on miners is equivalent
07:37 < Mike_B> does freicoin have a fixed supply?
07:37 < jtimon> well, inflation is also uglier than demurrage in my opinion since it's kind of hidden
07:37 < gmaxwell> demurrage @#$@#$@s up accounting.
07:37 < jtimon> not yet, but yes, 100 Million
07:38 < jtimon> gmaxwell, yeah, just like interest rates
07:38 < Mike_B> jtimon: so you get all of the properties of inflation except debt still deflates???
07:38 < jtimon> accountants have to account
07:38 < gmaxwell> easier to ignore by convention because it doesn't make your bookkeeping not add up.
07:39 < Mike_B> it seems to me that the net economic impact of demurrage = inflation + debt deflation
07:39 < Mike_B> which is like a double whammy
07:39 < Mike_B> but maybe i just don't understand
07:39 < jtimon> it's not that hard to accont
07:39 < jtimon> you just have to put a timestamp with every amount in your books
07:39 < Mike_B> jtimon: can you confirm that my understanding about debt deflation above is correct?
07:40 < jtimon> I don't undesrtand what makes you think that, and no, (natural) 0% interest rates prevent debt exponential gorwth
07:40 < jtimon> demurrage encourages debtors to pay their debts
07:42 < jtimon> Mike_B demurrage is inpired in this book (parts 3 to 5): https://www.community-exchange.org/docs/Gesell/en/neo/
07:42 < Mike_B> jtimon: so let's assume freicoin has a 0% loss rate to make it simple
07:42 < Mike_B> and let's assume this is in the future when all coins are mined
07:42 < jtimon> take a look at part IV point 5 How Free-Money will be judged
07:42 < Mike_B> now, let's make the (silly) assumption that nobody is lending anything to anyone - that no debt exists. this is silly, but bear with me for a second
07:43 < Mike_B> under the assumption that there's no debt at all, do you agree that a 5% demurrage rate is exactly equivalent to a 5% rate of inflation?
07:43 < jtimon> ok, but just a second
07:43 < jtimon> uff
07:43 < jtimon> I have never thought about a world without debt
07:44 < jtimon> debt is not intrinsically bad
07:44 < jtimon> there's 0% itnerest debt too
07:44 < Mike_B> i'm just doing this to simplify the math
07:45 < Mike_B> we'll bring debt back into it in a second
07:45 < Mike_B> i just want us to get on the same wavelength first re: assumptions
07:45 < jtimon> yes, I guess in a world without a finantial markets, investors that borrow money, without IOUs, without time banks, etc...
07:45 < jtimon> inflation would be equivalent to demurrage
07:46 < jtimon> but I also think that the assumption is totally irrealistic
07:46 < Mike_B> so assuming there's no debt, or let's say "only 0% interest debt", then do you agree the following two scenarios produce exactly identical results?
07:46 < Mike_B> 1) take 5% of money out of circulation proportional to everyone's holdings, give it to some guy (a miner, a bank, whatever)
07:46 < Mike_B> 2) increase the money supply by 5%, give it to some guy (a miner, a bank, whatever)
07:46 < Mike_B> ok
07:46 < Mike_B> so now let's bring debt back into it
07:47 < jtimon> yes, the re-distribution part is equivalent
07:47 < Mike_B> say I borrow $100,000 from you to buy a house
07:47 < jtimon> we're talking usd, really?
07:47 < jtimon> why not a simpler currency like gold or bitcoin?
07:47 < jtimon> usd is very hard to understand
07:48 < jtimon> shells or gold in an island, please?
07:48 < Mike_B> so i have to pay you back that $100,000 over x years or whatever, let's even say there's 0% interest
07:48 < Mike_B> i just have to pay you back $100k
07:48 < jtimon> what do you mean by "there's 0% interest"?
07:48 < Mike_B> however, now the two scenarios are different
07:48 < jtimon> you want to lend me 100k usd at 0% why?
07:49 < jtimon> you should just keep them yourself
07:49 < Mike_B> 1) demurrage scenario: i get 5% taken out of my paycheck per year due to demurrage, so i actually have to make something like $105,000 just to pay back the $100,000
07:49 < jtimon> you won't gain anything by lending usd to me at 0%
07:49 < jtimon> no
07:50 < jtimon> if they were freicoins, for example, it could make sense for you to lend me 100k of them at 0% interest
07:50 < Mike_B> assuming i try to pay it back in one year
07:50 < jtimon> but I owe you 100k frc, not 105k
07:51 < jtimon> so if I make 100k frc I will call you as soon as possible to pay you
07:51 < Mike_B> aw man, i dropped
07:51 < Mike_B> jtimon: what was the last thing you heard from me?
07:51 < Mike_B> i was typing into the ether for a while
07:53 < jtimon> I've pasted it privately
07:54 < Mike_B> ok yeah so my connection was weird
07:54 < Mike_B> you saw stuff i was saying but it didn't send me anything you were saying
07:54 < Mike_B> jtimon: yeah so now that i have the full log, i'll clarify
07:54 < Mike_B> say i'm borrowing $100,000 worth of freicoin
07:54 < Mike_B> from you
07:54 < Mike_B> and the loan is denominated in freicoin
07:54 < Mike_B> ok?
07:55 < jtimon> ok
07:55 < Mike_B> and i'm going to pay you back in one year, and you're going to charge me 0% interest
07:55 < jtimon> ok
07:55 < jtimon> assuming constant frc/usd price?
07:55 < Mike_B> yeah
07:55 < Mike_B> let's just say it's 100k freicoins, whatever
07:56 < Mike_B> i dunno how much that is
07:56 < jtimon> me neither
07:56 < Mike_B> so under that scenario i owe you 100k freicoins, but because I lose 5% a year, i actually have to earn 100k/.95 = 105263 freicoins to have 100k left over after demurrage to pay you back
07:56 < jtimon> 400k frc i think
07:56 < Mike_B> agree so far?
07:56 < jtimon> but wait, did you borrow the frc to hard them?
07:57 < jtimon> hoard
07:57 < Mike_B> yeah, you're a bank and you're lending me freicoins to buy a house
07:57 < Mike_B> no, it's a loan
07:57 < jtimon> ok, you could have probably done something more productive but whatever
07:57 < Mike_B> you lend me them to start a business, i dunno
07:57 < Mike_B> point is i don't have it anymore
07:58 < jtimon> when you buy the house you stop paying demurrage
07:58 < Mike_B> jtimon: i don't stop paying demurrage because now i have to pay you back, and those payments come from my salary, and my salary is subjected to demurrage
07:58 < jtimon> why would the borrower pay demurrage?
07:58 < jtimon> but you don't receive your salary yearly do you?
08:00 < jtimon> whatever you pay back from the loan each month, you will want to pay it as soon as you receive your salary
08:00 < Mike_B> jtimon: hm, maybe i don't understand. does demurrage only take money out of each transaction, or out of your holdings as well?
08:00 < jtimon> from all outputs all the time
08:00 < Mike_B> ok but if i just have a million freicoins in a wallet and leave them there for 10 years and never move them around, they aren't touched?
08:01 < jtimon> of course they're touched
08:01 < jtimon> when you want to spend them in a year you will have 950,000 frc
08:01 < jtimon> aprox
08:02 < Mike_B> ok so i thought you were saying it only comes from tx outputs
08:02 < Mike_B> and it's like 2^-20% per each output
08:02 < jtimon> the only way to dodge demurrage is spend, invest or lend
08:02 < jtimon> no, from every "account"
08:02 < jtimon> but there's really no accounts in bitcoin
08:02 < Mike_B> oh oh oh sorry
08:02 < jtimon> only public keys
08:03 < Mike_B> you meant it takes 2^-20% from the total set of utxo's
08:03 < Mike_B> i thought you just meant new utxo's from the current block
08:03 < jtimon> no, every block, the amounts in the utxo are reduced
08:04 < jtimon> well, we use a reference height for each transaction
08:04 < Mike_B> ok, so yeah, so then that's back to what i was saying before
08:04 < Mike_B> i owe you 100k and i have to pay it back over a year with 0% interest
08:04 < jtimon> and you calculate current_available_amount(refHeight, old_amount, current_block_height)
08:05 < jtimon> you have to pay me back the 100k in one payment or are you allowed to make 12 smaller payments?
08:05 < Mike_B> ok, i have to think about this
08:05 < jtimon> I recommend Gesell's book
08:06 < Mike_B> yeah, so if it's one large payment at the end of the year, i actually have to pay you 105263 freicoins
08:06 < jtimon> no
08:06 < Mike_B> like if i get paid all at once and save it for a year or something
08:06 < jtimon> say you get the loan and buy a house for 100 k
08:06 < jtimon> in one year, you sell the house for 100 k frc again and pay me back
08:07 < jtimon> but I think it will more typical that I allow you to pay me back gradually
08:07 < Mike_B> what's the block time for freicoin
08:07 < Mike_B> still 10m?
08:08 < jtimon> maybe I know I won't spend 120k frc I have soon and prefer to lend you
08:08 < jtimon> so that you pay me 10k frc a month back for the next year
08:09 < Mike_B> ok, i see what's happening now
08:09 < Mike_B> very interesting
08:10 < jtimon> that's what savers usually want, not spend now but spend in the future
08:11 < jtimon> https://www.community-exchange.org/docs/Gesell/en/neo/part4/5g.htm
08:19 < Mike_B> jtimon: ok, i'll think more about it
08:20 < Mike_B> intersting
08:27 < jtimon> cool, Mike_B I'm glad that you find the concept interesting
08:27 < jtimon> and I understand is hard to digest
13:14 < maaku> <Mike_B> under the assumption that there's no debt at all, do you agree that a 5% demurrage rate is exactly equivalent to a 5% rate of inflation?
13:15 < maaku> No they are not the same. Demurrage is reflected immediately whereas inflation takes time to move through the economy (price updating, etc.)
13:16 < maaku> Which has real-world economic consequences, causing those close to the source of inflation (large investment banks with fiat, miners with cryptocurrency) to have significant unearned advantages over the little guy
13:19 < maaku> The purpose of Freicoin is to eliminate advantages the holders and creators of money have due only to the nature of money
13:19 < maaku> Which in the inflationary case, includes the temporal advantage of being close to the source of inflation
13:20 < maaku> That could alternatively be neutralized by having everyone everywhere continuously update prices with electronic counters, based on current inflation rates
13:21 < maaku> Or, as Freicoin does, just make the clearing house software update wallet balances by protocol. We found that to be the easier solution - build the fix into the nature of money itself.
13:29 < amiller> i just found the strangest paper.
13:29 < amiller> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.1255&rep=rep1&type=pdf
13:29 < amiller> it's by "Naoshi Sakamoto"
13:29 < nsh> mmm
13:30 < nsh> is real person i think
13:30 < amiller> meh i'm pretty sure it's a red herring
13:30 < amiller> it's not that interesting a find. oh well
13:30 < maaku> japanese is a sound-poor language
13:30 < maaku> it's not surprising
13:36 < gmaxwell> amiller: Do take care that you don't cause some poor dude to get hounded by the press.
13:37 < gmaxwell> The press is actually really poor at this whole investigation thing, so it's actually pretty easy to send them off on a tangent
13:38 < gmaxwell> there are a couple other "is xxx satoshi?" questions that come up only from actually thoughtful people, and I always quitely advise them that such suggestions could only bring unhappyness to their targets.
13:40 < gigavps> amiller wow, crazy find
13:40 < amiller> it's pretty clearly unrelated
13:41  * nsh nods
13:41 < maaku> to someone who knows japanese, the names are not actually very related at all
13:41 < amiller> it's not even a proper anagram, it's missing a T
13:42 < pigeons> stop ruining my news story with facts
13:43 < gmaxwell> amiller: I like the OWAS paper posted to the forum with the awesome japanese sounding anagram name on it.
13:48 < maaku> "satoshi nakamoto" is something like "wisdom/cleverness middle/core-truth"
13:48 < maaku> so obviously a pseudonym given what we know of him/her/them
13:49 < maaku> whereas naoshi sakamoto has meaning related to honest intent & sloping hills
13:51 < maaku> only one kanji is shared, and not a very meaningful one
14:08 < jtimon> what kanji, maaku?
14:10 < jtimon> by the way, talking about eastern culture? Do any of you like chess? Go is older and better
14:10 < jtimon> machines still get humilliated by humans at go
14:11 < jtimon> I had a plan to fix that...but then I discovered bitcoin
14:12 < jtimon> neural networks trained by genentic algorithms will beat go pros
14:13 < jtimon> but programmers are still using monte-carlo
14:13 < jtimon> sorry guy for speaking alone...
14:23 < maaku> jtimon: the "moto", which means book, but in this context something more like truth
14:23 < maaku> jtimon: the problem with go is combinatorial explosion
14:24 < maaku> an evolutionary neural network approach alone won't solve that problem
14:31 < maaku> you'd need some sort of hiearchical planner that uses heuristics that could be genetically evolved
15:10 < jtimon> maau a neural network is normally trained with a training set with inputs and desired outputs
15:10 < jtimon> maaku
15:10 < jtimon> there's no expert that can feed that training set because of combinatorial explosion
15:11 < jtimon> but genetic algorithms can explore any space
15:12 < jtimon> it's just a matter of time
15:12 < jtimon> and well/
15:12 < jtimon> ...
15:12 < jtimon> the adversary
15:13 < jtimon> you could start with any montecarlo machine and when you beat it start using also your own individuals as benchmark
15:14 < jtimon> what kanji is moto and means book?
15:30 < maaku> well the search space is too big, even for a genetic algorithm
15:31 < maaku> which is why you'd need some sort of layering heuristic architecture (the hierarchical planner), which the evolutionary genetic search and then optimize
15:31 < maaku> hold on i don't have kanji input on this vm
15:31 < maaku> 本
15:33 < maaku> it's only "moto" in names though
15:33 < maaku> it's typically read "hon"
15:35 < Lifeofcray> go is for chumps
15:37 < jtimon> no, no planer, that won't work for go
15:38 < jtimon> Lifeofcray have you played?
15:38 < jtimon> genetic algorithms have all the eternity to play
15:39 < jtimon> and improve
15:39 < jtimon> humans have to eat and sleep
15:39 < maaku> jtimon: why's that? (be warned, this was the subject of my uncle's Ph.D thesis, so I know it pretty well)
15:39 < maaku> the planner i mean
15:39 < jtimon> well, there's like thre phases in go
15:40 < jtimon> initiation middle and ending
15:40 < jtimon> in the finishing deep blue would be good
15:41 < jtimon> in the other two phases humans train their intuition
15:41 < jtimon> what they study
15:41 < jtimon> are general patterns and heuristics
15:41 < pigeons> yeah i'm learning go, its fun
15:41 < gmaxwell> I like connect-6
15:41 < jtimon> but when you study them the're isolated, not in the middle of a real game
15:42 < jtimon> planers are based on expertise, that sucks
15:42 < jtimon> specially for go
15:43 < jtimon> what's your uncle's thesis?
15:58 < andytoshi> is there a list somewhere of the incentive problems in bitcoin?
15:58 < andytoshi> eg no incentive to IBD or relay transactions
15:59 < gmaxwell> except there are incentives, just not inside the system.— as evidence by the fact that people do do these things today.
16:00 < gmaxwell> maybe not _enough_, but thats a more subtle question.
16:39 < andytoshi> it occurs to me that if block relaying was not getting done, it would be a good candidate for probabilistic payments
16:39 < andytoshi> and there is no reason that wolud need to be built into the network
16:41 < petertodd> gpg-agent --daemon --enable-ssh-support --use-standard-socket --write-env-file /home/pete/.gpg-agent-info
16:41 < petertodd> gah, thinkpads have shit design...
16:42 < petertodd> who puts keys such that brushing the edge of the laptop presses them?
18:41 < midnightmagic> petertodd: Acer does that too. It's incredibly irritating, because some of the buttons are pure touch and it's not clear they're actually buttons.
18:42 < midnightmagic> "If you touch your hand over here, the dvd drive pops out and the whole machine turns into a media desktop."
18:42 < midnightmagic> "Unfortunately you have to touch your hand here to type.. so.. "
21:17 < phantomcircuit> gmaxwell, who is it that wrote bitrated.com ?
21:17 < phantomcircuit> they might want to put a note on the "Offer Arbitration" page that it's illegal to offer those services to people in CA/Idaho
22:41 < andytoshi> phantomcircuit: it is shesek
22:41 < phantomcircuit> i noticed he says it's not escrow
22:42 < phantomcircuit> so technically it might not be illegal in ca/idaho
22:42 < phantomcircuit> but that's a question for a lawyer
22:42 < phantomcircuit> (an expensive one)
22:50 < andytoshi> yeah, it's a really neat question actually
22:50 < andytoshi> legally
22:50 < andytoshi> it would probably be precedent-setting if it went to court under escrow laws
23:00 < phantomcircuit> andytoshi, the closest analogy i can think of would be a trust account held by an attorney in which m of n parties can authorize a transfer
23:01 < phantomcircuit> attorneys (hilariously) ignore escrow laws in ca which as far as i can tell is totally illegal
23:01 < andytoshi> if an actual account existed i can see that being an escrow..
23:01 < andytoshi> interesting
23:01 < phantomcircuit> when i've brought it up i got a very handwaivey response that amounted to "that's different"
23:01 < andytoshi> no kidding
23:03 < phantomcircuit> maybe i'll try it on someone who doesn't do trust accounts anymore due to them being a pain in his ass
--- Log closed Wed Dec 04 00:00:30 2013