04:12:09 | card.freenode.net: | topic is: This channel is not about Bitcoin today | "Bitcoin research, hardfork wishlist, ideas for the future - see also: https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas. This channel is logged at http://download.wpsoftware.net/bitcoin/wizards/. For questions about the logs talk to andytoshi." |
04:12:09 | card.freenode.net: | Users on #bitcoin-wizards: andytoshi-logbot justanot1eruser TheSeven justanotheruser otoburb licnep_ SoftwareMechanic andytoshi tacotime fanquake lnovy_ rdponticelli Luke-Jr rdymac akstunt600 Elriel draino_ spinza roconnor Logicwax execut3 acejudas dansmith_btc naxin shinypaavo postpre num1 LarsLarsen justusranvier eristisk go1111111 Krellan imjonathan mkarrer ewust Graet nikitab LaptopZZ kazcw mhanne Ryan52 jron BCB amiller adam3us tucenaber stqism gmaxwell mmozeiko |
04:12:09 | card.freenode.net: | Users on #bitcoin-wizards: phantomcircuit Alanius wumpus nezZario EasyAt sploush mr_burdell gavinandresen roidster HM2 trn jrmithdobbs d34th kaptah quackgyver zacm michagogo|cloud coryfields [\\\] Sorcier_FXK realazthat Coin4ce shadders pajarillo gribble nanotube optimator Hunger- airbreather nsh kanzure stonecoldpat lechuga_ maaku azariah4 Mikalv Snowleaksange hno johntramp ryan-c ageis c0rw|away forrestv jcorgan copumpkin mumu tromp__ Guest38638 iddo espes__ helo |
04:12:09 | card.freenode.net: | Users on #bitcoin-wizards: bobke Dyaheon poggy edulix samson_ mike4 rs0 Sangheili midnightmagic petertodd weex cajg keus asoltys flammit roasbeef harrow Guest58923 typex CodeShark K1773R jchp BlueMatt OneFixt pigeons artifexd paperbot comboy sl01 heakins @ChanServ Anduck Fistful_of_Coins lianj Muis kinlo sipa sbp epscy ascent_ a5m0 waxwing UukGoblin |
08:47:26 | execut3: | execut3 is now known as shesek |
08:53:37 | adam3us: | gmaxwell: alts need a hook, new approach to alts: kitchen sink - any conceivable / arguable advantage, claim it as your own. ghost, "asic hard" PoW, much script, analogies about tcp, web 2.0, silver, oil; talk up use cases. profit. my experience talking with, pointing out flaws: without attribution coin morphs to include arguments/defenses. kitchen-sink-coin. logic: maybe that'll make the scarcity race stick, because "more". r |
08:53:50 | adam3us: | gmaxwell: hmm was that harsh? |
08:56:03 | gmaxwell: | well another way to look at it is as post selection. Imagine instead alts do things at random. The ones that happen to do those things get more visiblity, the ones that don't fizzle out. Doesn't mean that the people who started them had any particular intent. |
08:58:29 | adam3us: | jtimon: quick thought about demurrage/freicoin-variant on 2-way peg (which has rational economic system-level arguments, but is hard to sell beside deflationary commodity) what-if demurrage is converted to resellable feecoin, usable for fees only. encourages transactions & velocity of money which is the economic argument for demurrage. but doesnt directly erode capital (as you can sell or use the feecoins) |
09:01:46 | adam3us: | gmaxwell: its a curious thing. its surprisingly difficult to explain even to intelligent & economics/biz/finance savvy crypto currency observers why alt-shares funded by premines are a bad thing and self-defeating. i think the so far winning counter-argument is hypothetically they technically succeed, they get forked & 2-way peg, destroying the "investors" unrealistically definitional profit motive; or if no rational investor wo |
09:14:39 | jtimon: | adam3us yes, somebody should claim he will fork ethereum replacing the dagger nonsense with merged mining |
09:15:40 | jtimon: | about the feecoins...I assume they cannot be redeemed back to mainchain (since the demurrage went to miners) |
09:15:49 | gmaxwell: | they now have a yet another differnt pow, as discussed this morning. |
09:17:33 | jtimon: | gmaxwell, whatever, replacing the "anti-ASIC" stuff with merged mining and explaining, again, that there's no such thing as "anti-specialized hardware algorithms" |
09:18:59 | jtimon: | adam3us re feecoin, isn't this creating the altcoin you were trying to avoid with 2-way peg? |
09:19:12 | gmaxwell: | jtimon: BUT BUT IF YOU MAKE SPECIALIZED HARDWARE THEN COMPUTERS ADVANCE 5 YEARS INTO THE FUTURE!! |
09:19:20 | adam3us: | gmaxwell: maybe it could be somewhat ASIC resistant if they kept unpredictably changing it every week :) but that seems subject to moral hazard itself |
09:19:46 | jtimon: | I guess is somehow capped in price since people can always hold peggedcoins to obtain feecoins at a fixed rate |
09:20:29 | gmaxwell: | adam3us: yes, I pointed this out to ltc folks... that changing it periodically (week isn't required, just faster than a special one could be fabbed and pay for itself!) is a probably effective way.... assuming you don't mind a duo-oply hardware situation. :P |
09:22:08 | jtimon: | gmaxwell: yeah is interesting how litecoiners want "anti-ASIC but GPU-friendly" I guess because ati and nvidia are the asic manufacturers you always wanted... |
09:22:09 | adam3us: | jtimon: werent you part of the discussion about adding friction to the reverse peg? demurrage could technicall work on a pegged side chain via reverse peg friction. well they can hold btc for long term storage. hypothetically deploy the system level advantages of demurrage as feecoin variant by making it the currency on a side-chain with useful features |
09:23:35 | adam3us: | jtimon: well they tried to do GPU hard, but failed; then they so oh well its ASIC hard, that failed too. you'd think repeated technical failing would affect confidence in a coin |
09:23:39 | jtimon: | yes, I was part of the discussion, that's what the chiemgauer does (redemption friction) |
09:24:27 | adam3us: | jtimon: chiemgauer is the economist who made the argument for system-level advantages of demurrage? |
09:24:29 | jtimon: | I meant feecoins are somewhat capped because if they were to rise like crazy, people would move their btc to pegcoins to obtain as many feecoins as they can |
09:25:32 | jtimon: | no, that's silvio gesell, chiemgauer is a region in germany and a regional currency implementing demurrage http://en.wikipedia.org/wiki/Chiemgauer |
09:25:48 | adam3us: | gmaxwell: LOL. (computers advance 5 years... I also heard that very argument in one of he alt-shares videos) |
09:26:24 | jtimon: | adam3us I know they "tried" GPU hard, but current litecoiners don't want GPU-hard because now they own GPUs |
09:27:19 | gmaxwell: | adam3us: I think if the failing happens slowly enough it escapes the very narrow public memory. |
09:27:59 | adam3us: | jtimon: you think they want ASICs? i guess they're coming in volume RSN.. interesting to see what happens next. I was thinking maybe primecoin rises. (and its claim to scientific utility is a crock) |
09:28:45 | jtimon: | no, I think litecoiners don't want asics but want to keep gpu mining |
09:29:38 | jtimon: | they were asking here how they could have an anti-asic but gpu-friendly hashing algo |
09:30:01 | adam3us: | gmaxwell: even 3-month changing PoW (who choses new algo I wonder) still hw wins. they dont really think CPU or GPU are power/throughput optimized do they? there's a lot of thread latency optimization (CPU) and extraneous circuitry (GPU) in there |
09:30:37 | adam3us: | gmaxwell: i am thinking generic PoW optimized parallela (1000 risc core chip) |
09:34:17 | gmaxwell: | andytoshi: ::sigh:: https://github.com/inuitwallet/inuit/blob/master/num/rand.py#L50 |
09:34:31 | gmaxwell: | (more gonzo crypto in software being promoted to people) |
09:34:34 | adam3us: | jtimon: i was thinking feecoin, if there is not much velocity, feecoins fall in value (glut of them) making transactions cheaper - which encourages transactions as demurrage effectively rises. so maybe its a kind of floating rate demurrage encouraging trade |
09:36:17 | jtimon: | gmaxwell why would you use some proven random key generation when you can code your own? |
09:37:00 | gmaxwell: | jtimon: especially when you can make your own difficult to distinguish from backdoored software. |
09:37:05 | sipa: | what is inuitwallet? |
09:37:35 | adam3us: | gmaxwell: also GPU are typically simd; then ASIC-hard algo try to frustrate SIMD and wide GPU memory access size. winning hw is power/throughput optimized high core count CPU like parallela but diff optimization |
09:37:39 | jtimon: | adam3us I was assuming fixed demurrage, why do feecoins fall in value again? |
09:38:04 | adam3us: | jtimon: if there are surplus of them, and their primary use is fees. |
09:38:28 | adam3us: | jtimon: maybe have to sell them at a discount if the surplus is growing and looks to continue that tren. |
09:38:50 | jtimon: | adam3us technically GPUs arenow SIMT rather than SIMD |
09:39:12 | sipa: | t? |
09:39:46 | jtimon: | threads, you can make conditional branches |
09:40:42 | jtimon: | https://devtalk.nvidia.com/default/topic/412916/simd-versus-simt-what-is-the-difference-between-simt-vs-simd/ |
09:40:58 | sipa: | ok, i was aware, just not of the terminology |
09:40:59 | adam3us: | jtimon: isnt there a thread switching cost? or is this hw-level thread? |
09:41:39 | gmaxwell: | jtimon: you still cause nasty stalls if you have things like non-uniform memory accesses. |
09:41:49 | jtimon: | all threads run concurrently, if/elses are costly because one part is executed for some threads first and then the other one for the rest |
09:42:47 | jtimon: | gmaxwell sure memory accesses is probably the most important thing in algorithm optimization for GPU |
09:43:08 | jtimon: | using the shared memory, having coalescing reads/writes... |
09:44:13 | jtimon: | well, I'm not sure you can use the shared memory using openCL, but I guess so |
09:44:14 | adam3us: | jtimon: it seems likely to me that if anti-GPU / anti-ASIC PoW designs tried to incur random access, heavy branching & with small word size (GPU have wide word size) that the optimal generic PoW hardware is power/throughput optimized multicore MIMD (with simple & so low overhead instruction decode) |
09:45:15 | jtimon: | makes sense, not everything is well suited GPU |
09:45:18 | adam3us: | jtimon: that kind of hardware is hard to frustrate: its just a better (power & throughput optimized) CPU |
09:46:06 | jtimon: | yes, I've been always saying that although you can't make an anti-ASIC algo, you certainly can make an anti-GPU one |
09:47:10 | jtimon: | ironic for ltc's current situation |
09:55:18 | adam3us: | jtimon: there seems to be a battle raging on litecoin forum about changing the PoW. coblee (aka charlie lee) and warren argue its not a good idea as it forks the coin into two coins with same name: litecoin-old and litecoin-new. i imagine that could be worked with so it seems like an artificial argument. eg litecoin and litecoin2, LTC & LT2 etc. harder problem is two competing currencies both claiming legitimate transfer over p |
09:58:09 | adam3us: | jtimon: its kind of interesting regardless of specifics, because it comes down to "we failed, but lets not change it anyway or it becomes a new coin, and some will refuse to migrate, forking the coin into two, and we dont know how to support that, or we prefer that not to happen because we hold LTC" if they could get community consensus they could switch. that would seem like the right thing to do for the claimed objective, or ma |
09:58:45 | adam3us: | jtimon: but i think that could also be addressed by a 1 year phase in (to allow recoup of ASIC life cycle) |
09:59:16 | Luke-Jr: | adam3us: if they were going to change, they should have done it on day 1 |
09:59:42 | Luke-Jr: | adam3us: remember LTC was *not* supposed to be ASIC-resistent. it was supposed to be *GPU*-resistent ;) |
09:59:49 | adam3us: | Luke-Jr: yeah but they didnt realize they failed the first (CPU only) or second (GPU only) for months/years |
10:00:02 | adam3us: | Luke-Jr: alternatively they could admit failure, and stop :) |
10:00:03 | jtimon: | only LTC or LTC2 will survive, the other one will disappear |
10:00:07 | Luke-Jr: | adam3us: the guy behind scrypt was GPU mining it from the start ;) |
10:00:28 | Luke-Jr: | jtimon: and in the meantime, all the transactions are valid on both networks ;) |
10:00:29 | adam3us: | Luke-Jr: right, thats the rumor. "failure" was engineered. |
10:00:39 | Luke-Jr: | well, for ~100 blocks.. |
10:01:10 | jtimon: | Luke-Jr that's why it's not sustainable to have two networks |
10:01:23 | Luke-Jr: | it'd be a good experiment anyway |
10:01:29 | Luke-Jr: | see how it happens in practice |
10:01:30 | gmaxwell: | Luke-Jr: you can do a soft fork POW change. 0_o |
10:01:31 | adam3us: | Luke-Jr jtimon: i think it might be possible to have some kind of mutually aware protocol fork |
10:02:28 | Luke-Jr: | gmaxwell: you mean just adding an additional algo? |
10:02:31 | adam3us: | where both PoW are valid for the respective parallel forks. its like starting a new alt where you can provide a proof of burn to get new coins. both forks are 1-way pegged, right |
10:02:36 | jtimon: | adam3us I think you just want a hardfork and everybody to move to the new pow |
10:03:15 | jtimon: | or maybe a new chain with 1 way peg from the old one |
10:03:22 | adam3us: | jtimon: yes. but they argue they cant get community consensus so some users would just keep using the old (cant or would prefer not because they hold LTC) |
10:03:24 | gmaxwell: | Luke-Jr: you can add an additional one, and start it at a diff of 0, and prefer blocks that have it... (and then later mandate soft-fork-style that blocks have it) and then let the original pow difficulty fall to the minimum. :) |
10:04:11 | jtimon: | adam3us then those users get screwed because they're looking at a fake ledger |
10:04:15 | gmaxwell: | adam3us: well probably guaranteed now that there are scrypt asics (well perhaps less guarenteed since there are other non-MM alts) |
10:04:38 | gmaxwell: | I had suggested they consider this _before_ there were asics available, which would have made it more likely to be successful: https://bitcointalk.org/index.php?topic=359323.0 |
10:04:48 | adam3us: | gmaxwell: i think you maybe could splinter the coin into two new coins. one with same PoW and 1-way pegged; the other with new PoW and 1-wy pegged also |
10:05:15 | adam3us: | gmaxwell: (because the proof of burn is valid on only one network) |
10:05:51 | jtimon: | doesn't 1-way pegging from the new to the old require a hardfork on the old? |
10:08:54 | adam3us: | jtimon: 1-way peg from old to either splinter. original PoW reward only occurs on old, new PoW reward occurs on new PoW splinter. new reward coins from old after splinter cut-off not accepted on new PoW splinter. something like that. seems quite workable to me |
10:08:55 | jtimon: | I don't see how the presence of the asic changes anything |
10:09:11 | jtimon: | they will mine for the old chain for a while, so what? |
10:09:20 | adam3us: | jtimon: the asic vendors and their customers bought into the social contract. kind of rude to pull the rug. |
10:10:07 | adam3us: | jtimon: suspect however most of the argument is not technical but due to holding LTC or attachment to it (mining brings visceral emotive attachment same for BTC or LTC) |
10:10:33 | jtimon: | I guess it all comes to what that "social contract" means and if it implied so called anti-ASIC pow or just scrypt pow |
10:11:29 | jtimon: | if ghash.io gets to control 80% of the hash rate and we kick them out by moving to, say, SHA3, that would be "rude" too, should that stop us? |
10:12:40 | adam3us: | jtimon: the main problem is if they cant get unanimous agreement, both coins will co-exist unless they adopt the 1-way peg planned/safe splinter mechanism, they argue it will technically fail via double-spending on both defacto splinters |
10:13:20 | jtimon: | adam3us that's my argument: both coins CAN'T coexist because there's only one coin |
10:13:47 | jtimon: | the minority will have to accept the majority I think |
10:13:51 | adam3us: | jtimon: there are other problems. sudden switch with no asics coin security could be decimated by bot nets, double spends, ec2 flash rental etc |
10:14:31 | adam3us: | jtimon: probably cause a loss of confidence also. has to be slow, planned. maybe people dont like it regardless. so disruptive that it should only be considered worst case |
10:14:37 | jtimon: | adam3us that's what litecoin has normally been subject to, no? |
10:14:53 | adam3us: | jtimon: yes. (referring to your sha3 what-if re bitcoin) |
10:15:12 | jtimon: | yes, it should be programmed for months in the future at least, of course, it's a hardfork |
10:15:26 | jtimon: | oh, I see |
10:15:36 | adam3us: | i think its like central bank deliberations. should be slow, predictable, deliberated, unsurprising |
10:16:14 | jtimon: | hardforks are always complicated |
10:16:20 | adam3us: | jtimon: i think litecoin and litecoin2 could co-exist via the 1-way peg to both splinters mechanism above if they planned for it. |
10:17:15 | jtimon: | on your what-if SHA3 argument, sure, that's why we shouldn't do it right now but would that be worse than 1 party controlling 80% hashing? |
10:17:59 | jtimon: | adam3us sure if you plan it, sure, but I think charlee is saying that you will have 2 even if you deploy it as a regular hardfork |
10:19:01 | adam3us: | jtimon: yes. i do not think he thought of or understood the possibility to actively support two splinters. probably he doesnt want it to happen anyway so would not support this third alternative outcome. |
10:19:41 | jtimon: | hehehe, he may already own asics ;) |
10:20:19 | gmaxwell: | mean number of transactions per litecoin block ... 11. Does it need a 1-way peg if no one is transacting? :P |
10:20:28 | adam3us: | jtimon: even if he holds LTC. i am not sure of the LTC price implications of LTC splintering into LTC & LTC2 |
10:21:17 | jtimon: | price is not predictable in either case |
10:21:33 | adam3us: | gmaxwell: hey no fair pointing out alts have no intrinsic value (using the money supply x velocity metric) |
10:22:44 | jtimon: | 1) there's no such thing as intrinsic value: people value things |
10:22:44 | jtimon: | 2) velocity can always be faked (for free if you're a miner) |
10:22:52 | adam3us: | gmaxwell: i guess it would be an interesting coopetition idea for warren to play with to see if he could pull off a planned splinter that prevents double-spend of pre-splinter epoch coins |
10:23:31 | adam3us: | jtimon: maybe transactional utility value (vs speculative value) |
10:23:56 | jtimon: | certainly it would be itnerseting to see that "2 phase hardfork" implemented in practice |
10:24:56 | jtimon: | adam3us: my point is that even that value is not intrinsic |
10:27:24 | adam3us: | jtimon: yes i know hence rephrase as transactional utility value. if there is no real (and non fake) transactional value, so that the entire price is derived from speculation, and speculation is either zero sum betting game, or based on future potential. if there are no transactions nor often interest to obtain real transactions, then it seems like a waste of electricity to mine them. surely someone can setup a branding/meme fo |
10:28:52 | adam3us: | jtimon: (because if there is no attempt nor interest to obtain real transactions eg via merchant integration, wallets etc then the future potential seems nil other than its zero-sum betting game use) |
10:31:59 | adam3us: | jtimon: so i think most speculators know its zero-sum betting game, and the real reason there is mining at all on scam-coins is to pretend there a future potential (otherwise there are provably fair zero-sum games via auditable central servers via private-chain trust-but-verify model. almost feel like building it but the lack of pretend potential would most likely make them less attractive zero-sum games! |
10:36:41 | gmaxwell: | Its interesting that the accusation of bitcoin being a "ponzi scheme" has become much less common now... |
10:40:17 | Emcy: | tulips |
10:40:47 | jtimon: | adam3us: my point is that even that value is not intrinsic: destroying seigniorage through mining subsidies is ALWAYS a waste of energy IMO (even for btc), but that doesn't mean isn't profitable for the miner |
10:41:46 | jtimon: | tulipcoin should be the reverse of freicoin "the sooner you buy tulipcoins, the sooner you will receive interest, BUY NOW!!" |
10:42:40 | jtimon: | I think most early miners don't think the altcoins will be valueable, just that some fools will buy it higher next week |
10:48:06 | Emcy: | there is an endless precession of altcoins that function as penny stocks |
10:49:28 | Emcy: | we will just have to wait until we run out of 3 letter codes |
10:50:11 | jtimon: | Emcy some of them are using 4 letter codes now |
10:50:40 | Emcy: | those fiends |
11:11:39 | andytosh1: | andytosh1 is now known as andytoshi |
12:33:10 | shinypaavo: | shinypaavo is now known as shinybro_ |
13:21:32 | wallet42: | wallet42 is now known as Guest51392 |
13:21:32 | wallet421: | wallet421 is now known as wallet42 |
15:30:55 | kanzure: | adam3us: a lot of your messages are cutoff at the end. your irc client should be configured to send all content in a separate message. |
15:31:33 | adam3us: | kanzure: hmm pidgin, i am assuming there is a plugin one could download or configure, but not by default |
15:32:24 | kanzure: | https://developer.pidgin.im/ticket/4753 |
16:28:04 | lnovy_: | lnovy_ is now known as lnovy |
17:57:16 | _ingsoc: | _ingsoc has left #bitcoin-wizards |
18:36:58 | gmaxwell: | https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding < On alternative block relay methods to avoid transmiting data the peer already knows without adding round trips while also enabling parallel transmission. |
19:52:25 | sipa: | maaku: so the idea is that you currently need the full chainstate (UTXO set + some block headers) to be stored in trusted storage |
19:52:47 | sipa: | if someone can mess with your chainstate, they can make your node believe anything, without a way to notice (except by rolling back history) |
19:53:11 | maaku: | sipa: gotcha, okay |
19:53:26 | maaku: | so its the same thing, i just hadn't thought about it in terms of "trusted storage" |
19:53:40 | sipa: | O(1) trusted storage basically means the only thing you store on trusted storage is the UTXO commitment |
19:54:01 | sipa: | and you can keep the actual UTXO set and other metadata in untrusted cache |
19:54:07 | sipa: | you'll notice when it's been tampered with |
19:56:10 | maaku: | i was thinking about it more from the perspective of hardware implementations - you can allocate registers for the O(1) storage, and process blocks as they come through on the wire |
19:56:27 | maaku: | or transactions in the case of something feeding a miner |
20:13:03 | amiller: | maaku, yeah sure i like that case |
20:16:59 | amiller: | you could have a hardened little trusted thing all on one chip |
20:17:33 | amiller: | it's hard to make a tamper proof thing that also has a ton of nonvolatile storage |
20:17:39 | sipa: | right |
20:28:52 | iddo: | amiller: is your new prediction market paper interesting? |
20:29:09 | amiller: | lol iddo |
20:29:31 | iddo: | i saw twitter msg |
20:29:50 | iddo: | what's there more to say other than letting issuers operate in a decentralized way with something like colored coins? |
20:30:02 | amiller: | there are a few interesting things |
20:30:33 | amiller: | first just to say, the really interesting thing is about who "calls" the outcome of the bet |
20:30:46 | amiller: | and tbh we don't have any particularly good or unsurprising answer for that |
20:30:53 | iddo: | issuer reputation ? |
20:31:04 | amiller: | you basically get to choose your "oracle", like with realitykeys etc |
20:31:19 | amiller: | issuer is not necessarily the arbitrator |
20:32:01 | iddo: | so you trust the reputation of some arbitrator for the outcome, hmm seems a little reduntant because you still have to trust the issuer to actually pay? |
20:32:26 | amiller: | okay so yeah you'd find this interesting |
20:32:29 | amiller: | i'll clarify what's up |
20:32:34 | amiller: | there's an arbitrator but not an issuer |
20:32:57 | amiller: | the betting is "parimutuel" meaning that that you are only taking bets with other people who have put money in |
20:33:08 | amiller: | the arbitrator possibly/likely/hopefully has no stake in the outcome |
20:33:32 | amiller: | you can only bet with bitcoins (or "futurecoins" if implemented as an altcoin) that are actually deposited/escrowed/stashed away for this purpose |
20:33:56 | iddo: | so if you bet in favor of some event, you have to be matched with someone who bets against this event? |
20:34:01 | amiller: | so the arbitrator's reputation is on the line for signing a message "Dewey elected" or "Truman elected" and hopefully not both and hopefuly not the wrong one |
20:34:08 | amiller: | iddo yes that's right |
20:34:12 | amiller: | so the way we implement that is really clever |
20:34:33 | amiller: | basically the way to put money into the bet is to buy a "matched portfolio" |
20:34:46 | amiller: | that means you spend $10, and you get $5 for Truman and $5 for Dewey |
20:35:12 | amiller: | when the bet is called for Truman, the truman share can be redeemed for $10 and the dewey share is useless |
20:36:16 | iddo: | i didnt understand, you spend $10 and win only $5 ? |
20:36:23 | amiller: | let me rephrase it |
20:36:40 | iddo: | shouldn't there be some atomic transaction that matched the person who bets in favor with person who bets againt? |
20:36:44 | amiller: | you can spend $10 and get 1 token for Dewey and 1 token for Truman |
20:37:06 | amiller: | if the arbitrator says Truman won the election, you can exchange it for $10. |
20:37:15 | amiller: | and the dewey token is useless |
20:37:39 | amiller: | if you want to 1:1 bet with someone and you want to take opposite sides, then you can both pitch in $5, buy one share of each, and each take the one you want |
20:37:43 | amiller: | then one of you wins and gets $10 |
20:37:59 | amiller: | you can also buy both and then sell them on the market |
20:38:43 | iddo: | i see |
20:39:10 | iddo: | can the arbitrator steal the coins, or only decide who won and give the coins back to? |
20:39:25 | amiller: | the arbitrator can *only* decide wrong |
20:39:44 | amiller: | all the coin transactions are done just like in bitcoin or colored coins w/e |
20:40:55 | iddo: | maybe the arbitrator can be bribed to decide wrong? |
20:41:28 | maaku: | you could do threshold arbitration too |
20:41:53 | amiller: | yes yes you can always turn 1 trusted party into k/n trusted parties |
20:42:09 | amiller: | that's always possible and almost never very much improvement |
20:43:06 | maaku: | amiller: depends on the circumstances |
20:43:33 | amiller: | i wish we had spent more time in the paper talking about ways of making bets about other blockchain things |
20:43:39 | maaku: | while it provides no theoretical improvement, in practice it's often sufficient |
20:43:47 | iddo: | not exactly true to say that arbitrator can only decide wrong, because a corrupt arbitrator can keep the coins locked and ask the winning party to pay extra to unlock the coins? so there's still reputation involved here, i guess? |
20:44:00 | midnightmagic: | there are strictly provably winnable bets |
20:44:09 | amiller: | midnightmagic, yeah. |
20:44:14 | amiller: | midnightmagic, i think there are a lot of interesitng ones too |
20:44:46 | amiller: | midnightmagic, our perception is that most people reading this are mostly interested in the "betting on public interest 'real world' events" like elections etc. which are not usually of that nature |
20:44:47 | midnightmagic: | yeah. Basically anything you're writing up I'm happy about, the betting sites out there need to go away. |
20:45:02 | amiller: | iddo, i don't know what you mean by keep the coins locked |
20:45:14 | amiller: | iddo, we are proposing this as an altcoin or a set of colored coin / mastercoin rules |
20:45:39 | midnightmagic: | anything that gets written, I'd be glad to help test. |
20:45:40 | amiller: | iddo oh i see what you mena |
20:45:48 | iddo: | not decide who won, so the winner cannot collect what he should have won? unless winner gives some money on the side... |
20:45:49 | amiller: | iddo, you're saying the arbitrator could basically threaten to never resolve the bet |
20:46:18 | amiller: | iddo, okay then yeah |
20:46:33 | iddo: | unless you could use some timelock to prevent a corrupt arbitrator from misbehaving? |
20:47:01 | amiller: | the arbitrator for sure is then a matter of public record and if they refuse to make any decision then they'll be found out |
20:47:21 | amiller: | like their interactions (agreeing to arbitrarte, makingt he final call) are all done in public via blockchain broadcasts so yeah |
20:47:51 | iddo: | ok, i was trying to assess whether there's less trust needed with an arbitrator than with a centralized issuer |
20:48:22 | gmaxwell: | 13:16 < amiller> you could have a hardened little trusted thing all on one chip |
20:48:23 | midnightmagic: | if it's public, I wonder if they could be jailed for refusing to unlock a large enough sum. |
20:48:26 | gmaxwell: | tpm, I suppose. :P |
20:48:45 | amiller: | gmaxwell, /me explodes |
20:48:59 | amiller: | gmaxwell, yeah yeah locally trusted |
20:49:04 | maaku: | well tpm would be too slow, but TrustZone probably |
20:49:20 | amiller: | i swear i don't even have the words i need to emphasize that you should only trust your own little trip, no one else has to trust it |
20:50:21 | amiller: | yeah i guess i should have just said tpm |
20:50:33 | gmaxwell: | tpm wouldn't be too slow, since you only have to update ever once in a while— the cost is just repeating some validation. |
20:51:24 | gmaxwell: | trick is how do you prevent the tmp's value from being replaced while you're not looking? I think existing tpms are just not flexible enough. |
20:51:51 | amiller: | gmaxwell, if all you do is give the tpm blocks |
20:51:57 | amiller: | gmaxwell, and it always takes the longest valid chain |
20:52:09 | amiller: | gmaxwell, then no one can get your tpm in a state that good blocks can't make it recover from |
20:53:13 | gmaxwell: | right but the tpm would have to verify blocks. :) |
20:53:38 | amiller: | right, which is the topic of discussion? |
20:53:51 | maaku: | amiller: TPM being to slow to do that |
20:54:01 | maaku: | but you could verify merkle proofs for an SPV wallet in a TPM |
20:54:15 | amiller: | oh |
20:54:19 | maaku: | or do full verification in a TrustZone like system |
20:54:55 | amiller: | ok then full verification with trustzone is hopefully a reasonable application of utxo commitments. |
20:55:06 | maaku: | yes |
20:55:37 | gmaxwell: | I'm finding it a little hard to be too motivated about verification integrity in the face of an marginally untrusted hardware, simply because getting people to verify (and convincing even technical people that its important) is an open question. |
20:55:50 | gmaxwell: | So e.g. ideas that add complexity and cost to verification are just depressing. :) |
20:56:43 | gmaxwell: | saving a 'personal checkpoint' as in "I've verified up to this block in the past and it passed" sounds super useful though... and would work in existin tpms. (reason for using the tpm: to avoid people copying over speed up keys between systems. :) ) |
20:59:54 | amiller: | yeah, i do kinda get that. i think this is more important only for some other application where the utxo ends up getting used for bigger and bigger things, but so far it's small enough that storing the utxo is hardly the bottleneck |
21:08:06 | iddo: | amiller: ideas similar to yours (buying in pairs) were described here: https://github.com/bitcoinx/colored-coin-tools/wiki/predmarket |
21:08:55 | iddo: | but there the end-users don't buy in pairs |
21:09:38 | amiller: | iddo, right, here there's just a prediction market operator that creates the bonds |
21:09:50 | amiller: | and a guideline that he *should* at his discretion sell matched pairs to keep his position neutral |
21:10:25 | iddo: | there's "primary dealer" escrow idea near the end there |
21:10:49 | iddo: | to avoid end-users buying in pairs |
21:13:05 | amiller: | right, so yeah it is basically the same as this except we do away with the dealers and operator... |
21:13:09 | justanot1eruser: | Would it be safe to have a PoS altchain based on Bitcoin stake? |
21:13:45 | gmaxwell: | justanot1eruser: yes, probably, but you'll require a bitcoin transaction for every block to make sure the stake consumption is unique. |
21:14:09 | justanot1eruser: | gmaxwell: could the PoS just be based on coindays? |
21:14:37 | gmaxwell: | as in the thing being consumed? yes sure. |
21:15:07 | justanot1eruser: | Would this work on a 2way pegged altchain? |
21:15:45 | gmaxwell: | It could, in theory, be made to work. |
21:16:03 | justanot1eruser: | Is there any reason this wouldn't be ideal? |
21:17:07 | gmaxwell: | sure, it can't actually be more secure than bitcoin, for one, since bitcoin is ultimately determining the consensus of the stake spends. It would also be rather slow, needing a bitcoin block and a burying to advance the state. |
21:17:11 | justanot1eruser: | The only I can think of is that full nodes would be required to own the mainchain |
21:17:26 | gmaxwell: | Then there is a question of what the incentives are. |
21:18:54 | justanot1eruser: | The biggest problem I see with coinwitness is that it will make mining require a large datacenter to allow miners to profit (assuming Bitcoin grows a ton and there are tons of tx) |
21:19:24 | justanot1eruser: | Meaning p2pool will be pretty much done |
21:19:33 | gmaxwell: | justanot1eruser: I have no idea what you're talking about. |
21:20:02 | justanot1eruser: | gmaxwell: If there are 1000tx per second then the mining pools will have to handle it. Miners can't handle it themselves. |
21:21:02 | gmaxwell: | What does that have to do with coinwitness at all? part of the point is allowing transactions to securely go on externally so you don't need to make 1000 tx per second publically. |
21:21:31 | gmaxwell: | (incidentally my laptop can verify close to 40k transactions per second, as an aside) |
21:21:55 | iddo: | amiller: prediction market without centralized arbitrators: https://groups.google.com/forum/#!searchin/bitcoinX/prediction$20market/bitcoinx/RG0F-EoT67o/ZlHueFpIABwJ |
21:22:32 | justanot1eruser: | gmaxwell: yes, the full nodes will be fine and can be on however many altchains they can handle, however mining will increase in profitability because of all these transactions, increasing difficulty. To keep up with the difficulty increase and make a profit, miners will need to be on all of the networks, which isn't possible |
21:22:45 | justanot1eruser: | without a mining pool |
21:23:46 | iddo: | justanot1eruser: what do you mean by miners will need to be on all the networks? |
21:23:57 | justanot1eruser: | iddo: every altchain |
21:24:04 | iddo: | huh? |
21:24:45 | iddo: | when you say "miners" you mean PoW miners? |
21:25:41 | justanot1eruser: | If the profitability has reached an equilibrium where processing 10000tx/second is barely profitable, and an independent or p2pool miner can only process 500tx/second, then they will be at a disadvantage and will be unable to profit without a mining pool |
21:25:48 | gmaxwell: | justanot1eruser: I think you're talking about the two way peg and not coinwitness in general (half of the coinwitness post was about binding non-blockchain things). |
21:26:06 | justanot1eruser: | gmaxwell: you are correct. I should have specified |
21:27:11 | iddo: | justanot1eruser: you're asking how to scale to large txns-per-second while keeping the network decentralized? |
21:27:18 | justanot1eruser: | iddo: basically |
21:27:25 | gmaxwell: | iddo: it's a more complicated point. |
21:28:00 | justanot1eruser: | I am wondering if it's possible at all |
21:28:13 | gmaxwell: | In an imagined future where scaling is achieved via two-way-pegs with merged mined sidechains it is conceivable that validation costs for all the popular chains could become non-trivial. If so, this would create a centeralization advantage. |
21:28:20 | gmaxwell: | Because validation costs can be centeralized. |
21:29:04 | gmaxwell: | so while you could choose to validate only a fraction, your income would be less than someone to delegates their validation to a third party and thus validates all fractions. |
21:30:21 | justanot1eruser: | Hmm. P2Pool could have each miner handle a different altchain, so the entire set of pegged chains could be accounted for and profited on by P2Pool users without every user needing to be on every network. |
21:30:57 | iddo: | btw why are you afraid of txn-verifications-centralization and not PoW centralization ? |
21:31:05 | gmaxwell: | justanot1eruser: you can do things like fractional verification and fraud proofs to make verification scale better without needing centeralization. So I don't think your concern is a fundimental problem. |
21:31:32 | justanot1eruser: | gmaxwell: yes, I think P2Pool can solve these future problems. |
21:31:33 | gmaxwell: | iddo: because PoW shouldn't have too much _fundimental_ economies of scale, but validation currently does. |
21:31:59 | gmaxwell: | (in, fact, there is a nice argument that PoW has fundimental diseconomies of scale.. though how they balance out is an open question) |
21:32:11 | justanot1eruser: | How do we get users to use p2pool? |
21:32:46 | iddo: | gmaxwell: i suppose that you saw this video clip: https://www.youtube.com/watch?v=5CjldZLXiAU&t=3m about PoW farm in USA ? |
21:33:22 | iddo: | diseconomies of scale, how come? |
21:33:28 | gmaxwell: | justanot1eruser: Right now, I think p2pool is back to a point where hashrate is now the biggest barrier. |
21:34:01 | justanot1eruser: | gmaxwell: how is hashrate a barrier? |
21:34:23 | justanot1eruser: | Or are you talking about the low hashrate causing them to get a block every 2 days |
21:35:01 | gmaxwell: | justanot1eruser: yes, last p2pool block was 692 blocks ago. My expirence suggests that once a pool is over 1 day per block it starts to lose hashrate because people lose their nerves after a few day run with no blocks. |
21:35:53 | amiller: | iddo, thanks, i didn't have that cite |
21:36:09 | justanot1eruser: | There is incentive for mining pools to start DoSing each other. Maybe the pools will solve the centralization problem themselves. |
21:36:16 | amiller: | iddo i tried to find more writing about that starting out from that post, it seems like he was describing either github code or a whitepaper somewhere else but i couldn't find anything else |
21:39:18 | gmaxwell: | justanot1eruser: they do DOS each other. though this seems to have resulted in all pools being hosted on AWS. :P |
21:39:29 | iddo: | gmaxwell: why diseconomies of scale ? |
21:39:53 | amiller: | hi killerstorm |
21:40:01 | gmaxwell: | iddo: because it is fundimentally easier to dissapate heat over a larger area than a smaller one. e.g. a single miner in a typical home doesn't need heroic cooling at all, and in fact the low level waste heat can be useful. |
21:40:07 | killerstorm: | hi |
21:40:41 | iddo: | amiller: i invited killerstorm to chat, you're right that there's no well-organized writing on prediction market |
21:40:57 | justanot1eruser: | Maybe we will have siberian miners heating their homes for a discount :) |
21:41:30 | amiller: | killerstorm, so i helped (a minor bit) a bunch of other researchers write a paper that was just accepted to WEIS on a design for a decentralized prediction market as an altcoin |
21:41:31 | iddo: | gmaxwell: wouldn't all mining opeartion tend to move to more cold geographical areas, over time? |
21:41:39 | gmaxwell: | (don't have to be in siberia to use the waste heat) |
21:41:59 | amiller: | it seems pretty closely related to the design you described here in particular: https://groups.google.com/forum/#!searchin/bitcoinX/prediction$20market/bitcoinx/RG0F-EoT67o/ZlHueFpIABwJ |
21:42:00 | gmaxwell: | iddo: certantly its easier to use the waste heat more of the year in colder places. |
21:42:28 | amiller: | killerstorm, do you have anything else written up? if so i'll pick it apart and try to figure out how best to cite you :o |
21:43:06 | iddo: | gmaxwell: but also in hot places you have to spend more money to maintain your PoW equipment, so to get better profit margins everyone will migrate to more cold places, no? |
21:45:35 | gmaxwell: | iddo: There is indeed some climate advantage but that doesn't imply centeralization. so long as you can use the waste heat your as well off as someone who can use more of it in terms of marginal cost until you fill capacity. |
21:46:06 | gmaxwell: | https://www.sslshopper.com/certificate-key-matcher.html |
21:46:08 | killerstorm: | amiller: There is also a bitcointalk discussion, but I think it pre-dates the post mentioned above, so is a bit inferior. Starting from this post: https://bitcointalk.org/index.php?topic=152200.msg1620827#msg1620827 |
21:48:14 | justanot1eruser: | Is there a reason P2Pool couldn't just have block headers downloaded and let full nodes decide who transactions to include? |
21:49:40 | gmaxwell: | justanot1eruser: I'm not sure what you're saying. Thats how p2pool works, your full node decides whats transactions to include (and what chains to accept). |
21:51:26 | justanot1eruser: | gmaxwell: but is there a reason P2Pool users couldn't chose to just passively accept the merkle trees full nodes are giving them (would block verification in SPV be too time consuming)? |
21:51:36 | gmaxwell: | ... |
21:52:25 | gmaxwell: | because (1) doing so would completely undermine the bitcoin security model for spv nodes, when people would mine invalid blocks, and (2) it would be trivial and highly profitable to dos attack p2pool miners by giving them bad data to make them produce invalid blocks. |
21:52:29 | justanot1eruser: | For example, if I didn't have the blockchain, just the block headers, I would have to either trust that a full node is giving me a valid block header, or verify every tx in that |
21:53:19 | gmaxwell: | besides, actually validing blocks takes less bandwidth and cpu time than running p2pool itself does. |
21:53:29 | gmaxwell: | so I don't know what you're trying to optimize for. |
21:53:39 | justanot1eruser: | gmaxwell: storage space |
21:54:04 | gmaxwell: | ... |
21:54:10 | justanot1eruser: | ... |
21:54:36 | gmaxwell: | I'm getting a little fed up with people constantly invoking trust and centeralization for ABSOLUTELY NO FUCKING REASON. Sorry to yell, but this is shameful. |
21:54:57 | killerstorm: | killerstorm has left #bitcoin-wizards |
21:55:08 | gmaxwell: | justanot1eruser: if you are concerned about storage space, go implement pruning. UTXO set is 350 MBytes right now. |
21:55:29 | gmaxwell: | And then there is no change in the security model and no dos vulnerability created. |
21:55:44 | justanot1eruser: | gmaxwell: that's why I'm asking, I don't know if there is a way around it. |
21:56:13 | gmaxwell: | I mean, it's only described in the bitcoin white paper and 3/4 implemented (in a stronger form) in #bitcoin-qt. |
21:56:58 | gmaxwell: | section 7 IIRC of bitcoin.pdf |
21:57:31 | justanot1eruser: | That's good. Perhaps SPV client users will use this instead. |
21:58:38 | phantomcircuit: | justanot1eruser, no... they wont |
21:59:32 | justanot1eruser: | phantomcircuit: why not? It is more secure and doesn't require a 20gb blockchain. Isn't that why most of them are using SPV? |
21:59:43 | justanot1eruser: | (SPV over a centralized wallet I mean) |
22:00:02 | phantomcircuit: | because you're not going to wait days for the wallet on your phone to be ready... |
22:00:04 | gmaxwell: | sorry for yelling at you. I went through the first half of the conversation assuming you already knew this stuff. I sometimes feel like sisyphus pushing the trust stone up the centeralization mountain all day long. It's often not as easy as "oh you just do this" to convince people that they don't need to trust all the things. |
22:00:46 | gmaxwell: | phantomcircuit: perfectly possible to fast start with spv security and check in the background. This isn't to say that I think thats a good thing to do on a phone. |
22:00:50 | justanot1eruser: | gmaxwell: I just didn't know if there was a way to use P2Pool with only block headers safely. I assumed there might be since the miners incentives were aligned. |
22:01:43 | gmaxwell: | they're not though. I might mine p2pool with the motivation of undermining p2pool so that the rest of my mining hashpower is more profitable. |
22:02:27 | gmaxwell: | (or better, to direct p2pool users to a centeralized pool I run and collect fees on) |
22:02:47 | justanot1eruser: | Good point |
23:06:16 | phantomcircuit: | gmaxwell, tbh that seems like a pretty big issue since it's only 200Th?s |
23:07:11 | gmaxwell: | phantomcircuit: it's gone through this before where it has an unlucky run and then a bunch of hashrate drops off. then it continues to fall for a while when it gets lucky and a bunch of hashrate joins in. Irritating. |
23:07:50 | gmaxwell: | also doesn't help that a p2pool.info bug made the web luck screen miss a couple blocks and report luck considerably lower than it actually was. |
23:12:56 | phantomcircuit: | gmaxwell, it still seems pretty low |
23:17:20 | gmaxwell: | the p2pool.info data is still incorrect. It's missing 3 or 4 blocks. |
23:42:50 | phantomcircuit: | gmaxwell, did you ever get power readings on the ct machines at reduced load? |