01:52:36 | hulkhogan42o: | via flooding, i believe |
01:53:12 | hulkhogan42o: | oh, that was hours ago. |
04:14:26 | hulkhogan42o: | hulkhogan42o is now known as hulkhogan |
04:14:55 | hulkhogan: | hulkhogan is now known as Guest9087 |
07:46:34 | maaku: | maaku is now known as Guest73375 |
08:05:14 | weber.freenode.net: | topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja |
08:05:14 | weber.freenode.net: | Users on #bitcoin-wizards: andy-logbot Mably jtimon hashtagg priidu Guest73375 kyuupichan Guyver2 p15x dgenr8 hktud0 melvster1 super3 justanotheruser Krellan hashtag_ damethos ryanxcharles zooko bosma [7] unlord Cory jeremyrubin CodeShark cdecker Dr-G2 jhogan42 Relos go1111111 Burrito K1773R user7779078 dasource iddo spinza aakselrod crowleyman adam3us paveljanik sparetire PRab LeMiner b_lumenkraft realcr p15 sipa Guest9087 dc17523be3 mm_0 Transisto NeatBasis c0rw1n |
08:05:14 | weber.freenode.net: | Users on #bitcoin-wizards: SDCDev kyletorpey devrandom arubi_ face veox sparetire_ bedeho2 nuke_ Luke-Jr bliljerk101 kanzure Meeh airbreather Taek MoALTz PaulCapestany waxwing OneFixt sneak catcow Starduster morcos lmatteis mappum helo isis Adlai Hunger- heath crescendo Tiraspol nickler Guest55444 prodatalab trstovall dansmith_btc sadoshi GAit melvster mkarrer Kwelstr [d__d] binaryatrocity gnusha luny BananaLotus guruvan lmacken rustyn harrigan Eliel warren Alanius brand0 |
08:05:14 | weber.freenode.net: | Users on #bitcoin-wizards: poggy ajweiss Zouppen phedny HM s1w lechuga__ EasyAt_ yorick afdudley lnovy wiz leakypat platinuum koshii smooth weex SwedFTP yrashk artifexd kumavis otoburb huseby midnightmagic BlueMatt TD-Linux mariorz hguux___ wizkid057 Anduck Logicwax phantomcircuit luigi1111 nanotube yoleaux gavinandresen AdrianG livegnik optimator fluffypony cursive roasbeef_ espes__ pigeons warptangent STRML michagogo sl01 Muis coryfields_ kinlo gwillen epscy Oizopower |
08:05:14 | weber.freenode.net: | Users on #bitcoin-wizards: CryptOprah davout @ChanServ azariah MRL-Relay BrainOverfl0w starsoccer d9b4bef9 mr_burdell tromp gribble jessepollak ryan-c larraboj jcorgan petertodd Keefe indolering Graet runeks__ cryptowest_ Apocalyptic catlasshrugged_ jaromil comboy manan19 berndj vonzipper harrow GreenIsMyPepper sturles mikolalysenko Sqt null_radix nephyrin a5m0 eric [ace] merlincorey jonasschnelli ebfull dardasaba jbenet wumpus cfields_ nsh copumpkin Iriez andytoshi |
08:05:14 | weber.freenode.net: | Users on #bitcoin-wizards: sdaftuar Fistful_of_coins richardus forrestv adams_ Xzibit17 gmaxwell amiller throughnothing_ tromp_ Madars SubCreative |
12:39:17 | Guest9087: | Guest9087 is now known as hulkhogan42o |
13:04:08 | mm_0: | mm_0 is now known as mm_1 |
15:11:50 | dgenr8: | the nature of the fork matters. no strong reason for users to switch to a fork with higher (or lower) block reward. OTOH a fork that somehow resulted in a structurally lower fee market would be attractive to users. |
15:12:42 | sipa: | lower fee, and lower security :) |
15:12:47 | sipa: | nothing is for free |
15:13:42 | stonecoldpat: | if the fee is too low, the miners just wont accept them, which would still be valid in that type of fork |
15:18:48 | dgenr8: | suppose there is a technology improvement that allows lower fees without reducing security. |
15:19:13 | sipa: | well someone has to pay for the security |
15:19:26 | sipa: | now, it is mostly subsidy that pays |
15:19:31 | dgenr8: | does someone have to pay for SHA256 being better than SHA1? |
15:19:33 | sipa: | over time... who knows |
15:19:42 | sipa: | i don't ghink you understand |
15:20:16 | sipa: | bitcoin solves a theoretically unsolvable problem... by making it economically inattractive to cheat |
15:20:23 | sipa: | but it does not really solve it |
15:21:16 | dgenr8: | you claim such an improvement is impossible, yes? |
15:21:22 | sipa: | yes |
15:22:02 | sipa: | there may be other solutions of course, that equally result in a useful digital payment system |
15:22:10 | sipa: | but it will have different tradeoffs |
15:22:19 | sipa: | so you can't call it a strict improvement |
15:22:37 | dgenr8: | you claim a strict improvement is impossible. |
15:22:50 | sipa: | yes |
15:23:17 | adam3us: | dgenr8: so at some point i had a go at working out if you could do make a secure offline ecash system if you had fully homomorphic encryption. the answer seemed to be no. you could do it with trusted hardware, but then you have to trust the hardware maker so it still fails. |
15:23:37 | dgenr8: | so that's one thing that didn't work ;) |
15:46:49 | dgenr8: | different example. suppose a new opcode satisfies some enormous social need. a bitcoin fork is published, and 60% of hashing adopt it one day. still irrelevant? |
15:47:15 | sipa: | yes |
15:47:44 | sipa: | but if it satisfies enormous social need, probably non miners will adopt it too |
15:47:56 | sipa: | which matters |
15:48:04 | dgenr8: | thats what I mean |
15:48:26 | sipa: | but the miners adopting it per se is not relevant |
15:48:44 | sipa: | what matters is that people who *use* bitcoin validation choose to upgrade |
15:50:24 | sipa: | if they do, miners are forced to upgrade too |
15:50:37 | sipa: | if they don't, then miners upgrading has no effect |
15:51:13 | sipa: | the point is that miners opinion about it is not more rekevant than anyone else's opinion |
15:51:24 | sipa: | while it is for a softfork |
15:53:12 | stonecoldpat: | dgenr8: one way i've been thinking about it recently, miners basically own the means of production, their workers are machine and they are producing something that the general population want. (so means of production/workers/general population) - if the means of production produce something that nobody likes, then the general population will just ignore it. So it is in the means of |
15:53:12 | stonecoldpat: | productions interests to produce something that the people want - but only if they are making profit. |
15:53:35 | sipa: | exactly |
15:53:58 | sipa: | miners produce something that satisfies the constraints the full node network demands |
15:54:19 | sipa: | if the demands change, miners either upgrade or become irrelevant (this is a hardfork) |
15:54:44 | sipa: | miners of course can choose to enforce extra constraints on top of this (this is a softfork) |
15:56:22 | dgenr8: | in the example, users might decide to switch after they see what the miners have done |
15:56:43 | sipa: | miners don't "do" anything |
15:56:59 | sipa: | the validation rules enforced by miners have no effect |
15:57:07 | sipa: | unless full nodes adopt them too |
15:57:24 | sipa: | as you can't security rely on them being encofrced otherwise |
15:57:29 | dgenr8: | accepting a new opcode is doing something |
15:57:50 | dgenr8: | i don't claim rational miners would do things this way though. it's just a hypothetical. |
15:58:07 | sipa: | if they do that now, without full node support, miners leave the consensus! |
15:58:28 | sipa: | they cannot just start accepting a new opcode without making their blocks invalid |
15:58:41 | Taek: | I thought new opcodes were soft forks? |
15:58:56 | sipa: | if they are refinements of nops, yes |
15:59:10 | sipa: | in which case everything dgenr8 says is true |
15:59:59 | sipa: | but the orinal discussion was about whether or not miner support matters for a hardfork |
16:00:11 | sipa: | so i assume he was talking about a hardfork change |
16:01:48 | dgenr8: | i was, and i agree it is not rational for miners. but if it were done, users have a choice: stay on 40% for without whizbang feature, or switch |
16:02:02 | dgenr8: | s/for/fork |
16:02:22 | sipa: | dgenr8: they have that chojce whether miners adopt it or not! |
16:02:50 | sipa: | if there are suddenly full nodes that fork off and introduce a new opcode, users can already choose which fork to use |
16:03:08 | sipa: | each fork will have 100% miner support from its own perspective |
16:03:18 | sipa: | as the blocks produced by the other miners do not count |
16:03:48 | Taek: | I do imagine that people would be more likely to switch to a new hardfork if that hardfork had more mining power |
16:03:57 | dgenr8: | ^ |
16:03:58 | sipa: | why? |
16:04:20 | dgenr8: | more secure. global hash power is a scarce resource |
16:04:25 | Taek: | it's reasurring, and to the common person seems more secure |
16:04:43 | Taek: | also makes them more confident that everyone is doing it |
16:04:49 | sipa: | full node security is far stronger than the little power that mindrs have |
16:05:10 | Taek: | right but that's not how the average Bitcoin user understands it |
16:05:20 | sipa: | say tomorrow bitpay, coinbase and bitgo announce they will switch to a new fork |
16:05:24 | sipa: | which miners hate |
16:05:29 | sipa: | what would happen? |
16:05:48 | Taek: | /r/bitcoin would explode |
16:05:53 | sipa: | yes :p |
16:06:07 | sipa: | and likely bitcoin would be dead, due to lack of trust |
16:06:29 | sipa: | but assume people accept this... they would switch along |
16:06:39 | sipa: | and miners not switching would be totally irrelevant |
16:06:49 | Taek: | that's true |
16:06:59 | sipa: | it won't take long for some miners to pop up on the new chain |
16:07:08 | sipa: | and the difficulty would adapt to them |
16:08:10 | sipa: | if people already follow miner majority, they can just all run spv nodes |
16:08:18 | sipa: | and full nodes would be irrelevant |
16:08:28 | sipa: | much cheaper |
16:08:36 | Taek: | but if coinbase, bitpay, and bitgo all announced a hard fork, AND 70% of the mining power supported the hardfork, there would probably be less resistance. |
16:08:43 | Taek: | /r/bitcoin would still explode |
16:08:44 | sipa: | of course |
16:08:56 | sipa: | in practice, there is s huge incentive for compromise |
16:09:17 | sipa: | but still, in establishing that compromise, miners do not have a privileged position |
16:09:21 | sipa: | economic power does |
16:10:11 | sipa: | miners matter, as they are part of the ecosystem |
16:10:27 | sipa: | but, other than for a softfork, they are not the only ones who.matter |
16:10:41 | sipa: | and there is no reason to base decisions on % hashrate |
16:12:33 | dgenr8: | my point is not that miners are privileged. it is that innovations will have an effect regardless of the particulars of how they are introduced |
16:12:49 | sipa: | of course, no disagreement there |
16:27:33 | dgenr8: | sipa: would you be concerned to learn of the existence of a dark hashpower block, say 300% the size of live bitcoin mining? |
16:27:46 | sipa: | yes |
16:28:20 | dgenr8: | isn't that the same thing as living on a fork with 25% hashpower? |
16:28:24 | sipa: | but as much as being concerned that users would switch to the full node software that hashpower uses |
16:28:25 | petertodd: | dgenr8: +1 |
16:28:39 | sipa: | but not as much |
16:29:01 | sipa: | yes, it is identical |
16:29:35 | sipa: | but you're suggesting that is enough reason to switch to that fork |
16:29:47 | kanzure: | it is enough reason to suspect those miners might attack your fork |
16:29:47 | sipa: | which is disagree very strongly with |
16:30:31 | sipa: | it works the other way too: if miners know that users would not switch to their fork, they will have less incentive to start the fork in the first place |
16:30:47 | petertodd: | a very realistic possibility here is if the next reward halving reduces profitability to the point where mining is untenable - suppose the economic majority decides to go with a still-deflationary reward schedule to fix the issue, and the hashing power decides to go with 25BTC/block forever - there's a very high chance that the hashing power will get their way |
16:31:39 | petertodd: | it's a case where doing nothing will lead to bitcoin being destroyed anyway, so miners don't acrually have a strong downside - users might as well go with the fork that's secure |
16:32:34 | sipa: | petertodd: so you're saying full nodes don't actually have a say about what rules the network ends up using? |
16:32:39 | sipa: | that is very sad |
16:32:52 | sipa: | it's not black and white of course |
16:33:05 | petertodd: | sipa: that's exactly what I'm saying - or to be exact, of course they have a say, but it's not a black-and-white say like many people portray it as |
16:33:15 | sipa: | fair enough, i agree |
16:33:26 | sipa: | the incentive for compromise is huge |
16:33:39 | sipa: | and miners have a say in what that compromise ends up being |
16:33:46 | sipa: | but they're not the only ones |
16:33:57 | petertodd: | miners definitely hold a disproportiate amount of power in the bitcoin system, and they definitely can force changes through - albeit at risk to them. point is, the risk is disproportionately bourn by al users, rather than just miners |
16:34:13 | sipa: | right |
16:34:53 | petertodd: | another problem, is that mining has a built-in way to co-ordinate actions - user's *don't* have a clear way to coordinate actions |
16:35:12 | petertodd: | (or at least, they don't have any methods that miners don't - miners can organisee on reddit too) |
16:35:38 | sipa: | how do you mean, the CEO of Bitcoin decides? |
16:36:02 | petertodd: | I mean, miners can prove consent to changes with hashing power - users can't |
16:36:18 | sipa: | they csn indicate consent |
16:36:24 | sipa: | they can't prove consent |
16:36:33 | petertodd: | consent != they will actually accept :) |
16:36:38 | sipa: | right, ok |
16:36:54 | sipa: | users can too, by putting a vote in transactions! |
16:37:00 | sipa: | .... which miners can censor |
16:37:25 | sipa: | but then again, a miner majority can censor other miners too |
16:37:26 | petertodd: | exactly - the only solid publication medium available is the blockchain; everything else is fuzzy social consensus |
16:37:29 | cfields_: | users choose to deal with vendors/exchangers who back their horse |
16:37:59 | petertodd: | equally, proof-of-stake sort-of works, but has severe problems in practice, like unavailability of cold storage |
16:38:05 | cfields_: | (claim to, anyway) |
16:38:08 | petertodd: | cfields_: yes, but they can't prove that |
16:38:35 | kanzure: | the problem is more like, "even if users decide to ignore a certain fork because of consensus reasons, those miners can still provide hashrate to attack your consensus-unchanged network" because you can't filter out certain miners really |
16:39:23 | kanzure: | (and filtering out miners would be bad, anyway) |
16:39:26 | petertodd: | kanzure: better yet, miners could choose to switch to a fork that required you to prove you tried to attack the original as part of the mining process |
16:39:38 | sipa: | availability of hashpower not on your fork affects your means of judging your chdin's security |
16:39:48 | sipa: | petertodd: ugh! |
16:40:28 | petertodd: | sipa: heh |
16:40:38 | kanzure: | is there some sort of merge-mining help here |
16:40:59 | sipa: | merge-mining is just mining with 0 marginal cos |
16:41:03 | petertodd: | sipa: nor do you really need something that fancy if you have 95% miner opposittion to a change anyway - getting 5% from the 95% to attack the original is unlikely to be hard |
16:41:27 | petertodd: | kanzure: the proof you tried to attack the original would be implemented *with* merge-mining |
16:42:09 | kanzure: | alright the only solution i could think of is that satoshi arises from the grave and sells all of his bitcoin on the alternate fork |
16:42:17 | kanzure: | wait, that's not a solution. hm. |
16:42:17 | sipa: | lol |
16:43:40 | kanzure: | there's really no way to opt out of consensus changes like that |
16:43:57 | petertodd: | kanzure: sure there is! hav the Bitcoin Foundation sign blocks |
16:44:18 | kanzure: | even though the naive solution ("keep running your old consensus code") looks like an answer, it really isn't |
16:44:33 | petertodd: | kanzure: and in the case of SPV clients, it definitely isn't |
16:44:41 | dgenr8: | halvings are not an incentive problem as long as BTC keeps getting more valuable at a faster rate than the halvings. so we think about making it better, and making it better adopted |
16:44:43 | kanzure: | because if you have 0.1% hashrate then you'll just be reorged to infinity for a while |
16:44:49 | petertodd: | kanzure: pruning is fun too, if people start trusting UTXO commitments for old history... |
16:45:31 | kanzure: | i suppose one solace is that an attacker can't attack all possible forks at the same time |
16:45:44 | stonecoldpat: | assuming 95% miners did switch, and the population did not, even with the attacks - the currency would probably be dead anyway |
16:45:45 | sipa: | kanzure: except pos :) |
16:45:55 | stonecoldpat: | i dont think there would be a fix |
16:45:56 | kanzure: | so as long as the absolute number of attacks he has to participate in is greater than the amount of hashrate he has available to throw at the problem while also mining on his evil fokr, then the originals win |
16:46:12 | sipa: | stonecoldpat: indeed, it would mean consensus has failed |
16:46:12 | kanzure: | for example, he can't commit 0.1% a million times over to a million different chains to reorg-attack 'em |
16:46:28 | kanzure: | especially if he is busy trying to secure his own evil consensus fork |
16:46:56 | petertodd: | stonecoldpat: exactly my point. Miners have the choice to either go along with what the economic majority wants, or not, and option #2 always results in them either winning, or Bitcoin itself being destroyed. (so long as they stick to option #2!) |
16:47:21 | kanzure: | i agree that getting proofs from others about their participatin in attacks is likely to be problematic, but not when you consider the large number of forks that can arise compared to the amount of hashpower that the colluding group can muster |
16:47:26 | kanzure: | *participation |
16:48:26 | petertodd: | the economic majorities power is limited to trying to encourage miners by paying them - if they aren't paying enough miners have every reason to stick to a fork that's best for them and hope the economic majority gives in and starts paying them again |
16:48:48 | kanzure: | another thing that would help is if the mining incentives reset on the ones that are being potentially-attaced, so that low-scale miners could be incentivized to show up with the promise of bitcoin |
16:48:55 | petertodd: | hell, this all looks kinda like standard union negotiation scenarios... |
16:48:58 | kanzure: | but the 2 week lag or whatever is maybe problematic for that sort of incentive |
16:49:43 | kanzure: | petertodd: it's not just a majority hashchain vs minority hashchain, there will be many minority chains that might cumulatively add up to greater than the majority hashrate chain (possibly evil consensus chain). |
16:50:21 | petertodd: | kanzure: **will* be? in what scenario? |
16:50:24 | kanzure: | as long as the evil hashrate chain miner can't just switch to every existing alternative and insta-mine 1 billion blocks, i think an evil consensus attack will fail |
16:51:47 | petertodd: | kanzure: in my block reward scedule example it's highly likely there are just three forks - original, economic majority, and hashing power majority |
16:52:04 | kanzure: | the scenario was "a majority of hashrate is accumulated to mine on some fork that has invalid consensus rules, users are told to switch over, businesses switch because their partners have already switched, etc." and "it may be difficult to continue running with the actual rules since the majority hashrate can switch to your blockchain and pummel you" (and my above comments are explaining why this isn't as drastic as onen might thik) |
16:52:37 | kanzure: | hm why only 3 though. wouldn't everyone want to jump on board and try their hand at an original-rules fork to get their hands on some sweet mining rewards? |
16:52:54 | petertodd: | kanzure: because in that example the original rules aren't profitable |
16:53:11 | kanzure: | i'm not sure i buy that :-) |
16:53:27 | petertodd: | kanzure: we're looking at original, 12.5BTC/block, econ majority, say, 20BTC/block, declining every two years, and miner majority, 25BTC/block |
16:53:35 | petertodd: | *25BTC/block forever |
16:53:39 | kanzure: | i mean, sure, okay they switch to some other non-original rules but my point was "something other than the evil-consensus-rules" |
16:54:09 | kanzure: | bbl |
16:54:15 | petertodd: | don't use the word "evil" here - from the miners point of ivew, 25BTC/block forever is the right solution, economic majority thinks their version is right |
16:54:52 | kanzure: | evil does not mean wrong |
16:55:17 | petertodd: | * petertodd rolls eyes |
16:55:23 | kanzure: | heh |
16:55:26 | kanzure: | but really, bbl |
16:55:34 | petertodd: | later |
17:13:09 | Dizzle_: | Dizzle_ is now known as Dizzle |
17:34:08 | delitzer_: | delitzer_ is now known as delitzer |
19:12:24 | blazes816: | blazes816 is now known as tcrypt |
20:02:19 | bitstein: | bitstein has left #bitcoin-wizards |
22:43:40 | mm_1: | mm_1 is now known as mm_0 |
23:41:57 | delitzer_: | delitzer_ is now known as delitzer |