| 01:21:28 | alexwaters: | alexwaters has left #bitcoin-wizards |
| 07:22:01 | mm_0: | mm_0 is now known as mm_1 |
| 08:05:15 | orwell.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:15 | orwell.freenode.net: | Users on #bitcoin-wizards: andy-logbot wallet42 Mably xcthulhu hashtagg_ jeremyrubin spinza Krellan priidu hktud0 b_lumenkraft sipa p15x justanotheruser hulkhogan42o dc17523be3 jgarzik mm_1 kyuupichan unlord TheSeven Transisto p15 Dr-G Relos NeatBasis c0rw1n Emcy Cory adam3us LeMiner SDCDev antgreen maraoz crowleyman kyletorpey devrandom arubi_ hashtagg face veox sparetire_ sparetire bedeho2 nuke_ Luke-Jr bliljerk101 kanzure Meeh airbreather Taek MoALTz PaulCapestany |
| 08:05:15 | orwell.freenode.net: | Users on #bitcoin-wizards: waxwing OneFixt sneak catcow Starduster morcos lmatteis mappum helo isis Adlai pollux-bts Hunger- heath crescendo Guest50139 Tiraspol nickler Guest55444 prodatalab trstovall dansmith_btc dgenr8 sadoshi GAit melvster mkarrer Kwelstr [d__d] binaryatrocity gnusha luny BananaLotus guruvan lmacken rustyn harrigan Eliel K1773R warren Alanius brand0 poggy ajweiss Zouppen stonecoldpat phedny aakselrod HM s1w lechuga__ EasyAt_ yorick afdudley lnovy |
| 08:05:15 | orwell.freenode.net: | Users on #bitcoin-wizards: cdecker wiz leakypat platinuum koshii smooth SubCreative Madars tromp_ throughnothing_ amiller gmaxwell Xzibit17 adams_ forrestv richardus Fistful_of_coins sdaftuar andytoshi Iriez copumpkin nsh cfields_ wumpus jbenet dardasaba ebfull luigi1111w jonasschnelli merlincorey [ace] eric a5m0 nephyrin null_radix Sqt mikolalysenko sturles GreenIsMyPepper harrow vonzipper berndj manan19 comboy jaromil catlasshrugged_ Apocalyptic cryptowest_ runeks__ |
| 08:05:15 | orwell.freenode.net: | Users on #bitcoin-wizards: Graet indolering Keefe petertodd jcorgan larraboj ryan-c jessepollak gribble tromp mr_burdell d9b4bef9 starsoccer 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 BrainOverfl0w MRL-Relay azariah @ChanServ davout CryptOprah |
| 08:05:15 | orwell.freenode.net: | Users on #bitcoin-wizards: Oizopower epscy gwillen kinlo coryfields_ Muis sl01 michagogo STRML |
| 08:27:09 | jeremyrubin: | Small thought, which I think is interesting re: hardforks on opcode functionality. Staker constructs a txn which releases fee to miner that can be redeemed iff the opcode is changed to the proposed functionality. Once pool large enough, miner has incentive to switch. The thing that interests me about this is that I could go and do this incentive right now, ie let's say I wanted op_and to become op_or, I c |
| 08:27:09 | jeremyrubin: | ould do scripts like: op_dup <1> op_eq op_swap <4> op_eq op_and. If op_and becomes op_or, the txn can be spent. Obviously op_and/op_or would be dumb to swap, but on other opcodes maybe less so... Is there any literature on this kind of deal? Would be interested in the game theory, esp with multiple proposals. "obligatory hardforks are bad" |
| 08:28:06 | sipa: | why do you think miners switching matters? |
| 08:28:19 | sipa: | for a hardfork, you need to convince everyone else |
| 08:28:45 | sipa: | if you don't, miners must switch too, or become obsolete (their blocks would be ignored by the rest of the network) |
| 08:29:02 | jeremyrubin: | A part of this is that there has to be broad enough use demonstrated interest as well (ie to 'stake') the initial txs. |
| 08:29:13 | sipa: | yes |
| 08:29:21 | sipa: | but you are talking about a hard fork, and miners |
| 08:29:25 | sipa: | miners do not matter for a hardfork |
| 08:29:58 | jeremyrubin: | hardfork to 0 block reward? |
| 08:30:17 | sipa: | elaborate? |
| 08:30:42 | jeremyrubin: | (in the extreme case, just demonstrating miners do matter) |
| 08:30:44 | sipa: | a hard fork is any change to the consensus rules that causing something that was previously invalid in a block to become valid |
| 08:31:08 | sipa: | a soft fork is any change to the consensus rules that does not do that |
| 08:31:20 | stonecoldpat: | jeremyrubin: http://hackingdistributed.com/2014/06/19/bitcoin-and-voting-power/ has a good discussion about 51% power vs nodes voting power (I think this is relevant to what your talking about) |
| 08:31:26 | sipa: | for soft forks you need minor majority |
| 08:31:33 | sipa: | *miner majority |
| 08:31:52 | sipa: | for hard forks you need everyone (including miners, but also including non-miners, and not just a majority, everyone) |
| 08:32:21 | sipa: | swapping OP_AND with OP_OR would be a hard fork |
| 08:32:31 | sipa: | setting the block payout value to 0 is a soft fork |
| 08:36:31 | jeremyrubin: | ah sure my bad -- I think I should head to sleep, a little delirious right now as it is a bit late(/early) on EDT ;) |
| 08:36:45 | jeremyrubin: | stonecoldpat: thanks for link |
| 08:36:48 | sipa: | if you plan to do a hard fork, and you convince everyone but miners, all you would see is hashpower disappearing (because the existing miner's blocks would become ignored) |
| 08:37:27 | sipa: | if you do not convince everyone, you risk a permanent fork because upgraded and non-upgraded nodes (which may be horrible, leading to coins being spent once on each side of the fork) |
| 08:37:44 | sipa: | so for a hard fork, miners agreement doesn't matter at all |
| 08:38:02 | sipa: | either you have support from "everyone else", and miners are forced to upgraded |
| 08:38:14 | sipa: | or you don't have support from "everyone else", and you risk crippling the network |
| 08:44:42 | jeremyrubin: | sipa: I guess what I'm trying to say I'm interested in |
| 08:45:04 | jeremyrubin: | is that outside of the bounds of an actual proposal for a forking protocol |
| 08:45:18 | sipa: | i think my point is that there is no "forking protocol" |
| 08:45:35 | sipa: | you just convince the world to upgrade, and if you don't end up convincing everyone, things break |
| 08:46:02 | jeremyrubin: | that's a protocol? And there could be ways of convincing people. |
| 08:46:12 | sipa: | sure |
| 08:46:14 | sipa: | war is one |
| 08:46:18 | jeremyrubin: | ;) |
| 08:46:43 | sipa: | if you extend "protocol" to mean things outside of IT infrastrcture, i fully agree |
| 08:47:06 | stonecoldpat: | any type of forking like that without full consensus is quite dangerous *in my opinion*, e.g. you could have two parrallel forks in usa and china based on what each country find as acceptable for the protocol - both valid forks, but not really in our interest |
| 08:47:18 | jeremyrubin: | My point is, more broadly, at some level if i put a bunch of "hard fork request" txns on the chain there would be an incentive for miners to do this, even if it is dangerous |
| 08:47:33 | sipa: | why do you keep talking about miners? |
| 08:47:34 | jeremyrubin: | and a user base behind it |
| 08:47:45 | smooth: | what part of miners being totally irrelevant wasn't clear? |
| 08:47:52 | sipa: | i couldn't care less if miners change their code or not |
| 08:47:55 | stonecoldpat: | you could convince miners, but you need to convince people running full nodes as well (otherwise they wont pass on the blocks) |
| 08:48:05 | sipa: | if they don't run the same code as me, i ignore them |
| 08:48:22 | sipa: | more income for the miners that don't voluntarily leave the consensus |
| 08:48:52 | sipa: | stonecoldpat: s/pass on/accept/ |
| 08:48:59 | sipa: | stonecoldpat: relay doesn't evne matter |
| 08:49:13 | sipa: | the point of running a full node is being capable of verying the rules it implements *yourself* |
| 08:50:02 | sipa: | jeremyrubin: assume that today, 60% of miners chance their software to give themselves a perpetual 100 BTC sunsidy per block |
| 08:50:08 | sipa: | jeremyrubin: tell me what would happen |
| 08:51:08 | jeremyrubin: | sipa: I'm not sure. |
| 08:51:23 | sipa: | jeremyrubin: in particular, what would your own full node do? |
| 08:51:47 | jeremyrubin: | sipa: my full node would not recognize their blocks |
| 08:52:05 | sipa: | correct |
| 08:52:24 | smooth: | sipa: what would you call a fork that lowered the reward schedule? |
| 08:52:37 | sipa: | jeremyrubin: what would happen is that the world would see a 2.5x hashrate decrease, and that's all |
| 08:52:53 | sipa: | jeremyrubin: those 60% of miners just voluntarily left the bitcoin consensus |
| 08:52:59 | jeremyrubin: | but I'm trying to think about this from a game theory perspective, so what I'm wondering is if it would be rational for me to recognize the ++reward fork. |
| 08:52:59 | sipa: | and made themselves irrelevant |
| 08:53:34 | sipa: | jeremyrubin: the term you're looking for is economic majority (which is very misleading term, as there is no "majority" to speak of, just economic power) |
| 08:53:43 | sipa: | smooth: that's a soft fork |
| 08:54:04 | jeremyrubin: | sipa: the security model isn't great though. 60% leave consensus, while using 30% to attack the remaining 40 and 30% to mine with the new reward |
| 08:54:17 | smooth: | sipa: im not sure, don't you need everyone to upgrade in order to enforce such a schedule? |
| 08:54:24 | sipa: | smooth: nope |
| 08:54:30 | sipa: | smooth: just a hashpower majority |
| 08:54:41 | smooth: | sipa: but that's temporary, it can't enforce a future scheule |
| 08:54:47 | sipa: | smooth: so? |
| 08:55:02 | smooth: | so to change the schedule i would say you need to get all the users to upgrade |
| 08:55:14 | jeremyrubin: | smooth: the point is that nothing invalid in past becomes valid. |
| 08:55:25 | sipa: | smooth: yes, i see |
| 08:55:33 | smooth: | jeremyrubin: yes and im questioning whether this deffinition of hard fork is actually the most useful one |
| 08:55:45 | sipa: | smooth: but at any point undoing the change can result in a fork again, if some users did upgrade |
| 08:55:49 | jeremyrubin: | smooth: gotcha |
| 08:56:19 | sipa: | smooth: note that you can enforce every softforking-change as a hard fork |
| 08:56:19 | smooth: | sipa: is this not worse, now you have a majority of miners who can break the network any time they want? |
| 08:56:31 | sipa: | smooth: they can always do that :) |
| 08:56:48 | sipa: | smooth: just have two groups of near equal hash power that don't like each other's blocks |
| 08:57:13 | smooth: | sipa: i suppose by excluding transactions, but even that is only temporary, while creating a permanent fork is different |
| 08:57:39 | sipa: | fair enough, the risk of a permanent fork is only there if part of the userbase upgrades |
| 08:59:35 | smooth: | sipa: likewise it would be quite dangerous for part of the userbase to upgrade. so to make this change 'safely' it has to be done in the same manner as your defition of a hard fork, where 'everyone' upgrades |
| 09:00:14 | sipa: | smooth: yeah |
| 09:00:42 | sipa: | i guess we should talk about two types of enforcement (miner collusion being one, userbase enforcement is another) |
| 09:01:18 | sipa: | softforks are done by first having miners colluding as soon as enough of them indicate support, then doing userbase enforcement |
| 09:01:40 | smooth: | but its very hard to get all users to ever upgrade anything... |
| 09:02:14 | smooth: | it seems in practice this relies on miners never having an incentive to change their minds |
| 09:02:35 | sipa: | well as soon as you have miners that are doing the collusion, users can upgrade at their leisure |
| 09:02:43 | sipa: | this gives miners a power to fork the network |
| 09:02:50 | sipa: | but they always have this power |
| 09:03:04 | sipa: | well, no, that's not true |
| 09:03:15 | sipa: | sorry |
| 09:03:16 | smooth: | the power to fork is much weaker, it requires an exact 50-50 split |
| 09:03:28 | smooth: | miners can block transactions though |
| 09:03:34 | smooth: | essentially breaking the network |
| 09:04:10 | smooth: | although perhaps with some feedback mechanism you could engineer a persistent 50-50 (etc) split |
| 09:04:54 | sipa: | yes |
| 10:59:31 | mm_1: | mm_1 is now known as mm_0 |
| 11:49:07 | mm_0: | mm_0 is now known as mm_1 |
| 13:00:29 | mm_1: | mm_1 is now known as mm_0 |
| 13:15:13 | kanzure: | maybe there's a way where you can use your consensus rules to help sign your verifications |
| 13:15:44 | kanzure: | oh wait, you could always fake that i guess. but presumably if you use a fake signature, and your peer-provided data is invalid, then you're caught |
| 13:33:09 | mm_0: | mm_0 is now known as mm_1 |
| 14:46:15 | midnightmagic: | * midnightmagic sets mode +b $a:jgarzik$##fix_your_connection on #bitcoin-wizards |
| 15:34:45 | [1]LeMiner: | [1]LeMiner is now known as LeMiner |
| 18:36:09 | dEBRUYNE__: | dEBRUYNE__ is now known as dEBRUYNE |
| 19:48:21 | mm_1: | mm_1 is now known as mm_0 |
| 21:51:52 | blazes816: | blazes816 is now known as tcrypt |
| 22:02:14 | lmatteis: | what protocol does bitcoin use to propagate messages across the network, and how are peers discovered? |
| 22:03:44 | fluffypony: | lmatteis: more a question for #bitcoin-dev, no? |
| 22:03:50 | lmatteis: | ok |