01:21:28alexwaters:alexwaters has left #bitcoin-wizards
07:22:01mm_0:mm_0 is now known as mm_1
08:05:15orwell.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:15orwell.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:15orwell.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:15orwell.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:15orwell.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:15orwell.freenode.net:Users on #bitcoin-wizards: Oizopower epscy gwillen kinlo coryfields_ Muis sl01 michagogo STRML
08:27:09jeremyrubin: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:09jeremyrubin: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:06sipa:why do you think miners switching matters?
08:28:19sipa:for a hardfork, you need to convince everyone else
08:28:45sipa:if you don't, miners must switch too, or become obsolete (their blocks would be ignored by the rest of the network)
08:29:02jeremyrubin: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:21sipa:but you are talking about a hard fork, and miners
08:29:25sipa:miners do not matter for a hardfork
08:29:58jeremyrubin:hardfork to 0 block reward?
08:30:42jeremyrubin:(in the extreme case, just demonstrating miners do matter)
08:30:44sipa: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:08sipa:a soft fork is any change to the consensus rules that does not do that
08:31:20stonecoldpat: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:26sipa:for soft forks you need minor majority
08:31:33sipa:*miner majority
08:31:52sipa:for hard forks you need everyone (including miners, but also including non-miners, and not just a majority, everyone)
08:32:21sipa:swapping OP_AND with OP_OR would be a hard fork
08:32:31sipa:setting the block payout value to 0 is a soft fork
08:36:31jeremyrubin: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:45jeremyrubin:stonecoldpat: thanks for link
08:36:48sipa: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:27sipa: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:44sipa:so for a hard fork, miners agreement doesn't matter at all
08:38:02sipa:either you have support from "everyone else", and miners are forced to upgraded
08:38:14sipa:or you don't have support from "everyone else", and you risk crippling the network
08:44:42jeremyrubin:sipa: I guess what I'm trying to say I'm interested in
08:45:04jeremyrubin:is that outside of the bounds of an actual proposal for a forking protocol
08:45:18sipa:i think my point is that there is no "forking protocol"
08:45:35sipa:you just convince the world to upgrade, and if you don't end up convincing everyone, things break
08:46:02jeremyrubin:that's a protocol? And there could be ways of convincing people.
08:46:14sipa:war is one
08:46:43sipa:if you extend "protocol" to mean things outside of IT infrastrcture, i fully agree
08:47:06stonecoldpat: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:18jeremyrubin: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:33sipa:why do you keep talking about miners?
08:47:34jeremyrubin:and a user base behind it
08:47:45smooth:what part of miners being totally irrelevant wasn't clear?
08:47:52sipa:i couldn't care less if miners change their code or not
08:47:55stonecoldpat:you could convince miners, but you need to convince people running full nodes as well (otherwise they wont pass on the blocks)
08:48:05sipa:if they don't run the same code as me, i ignore them
08:48:22sipa:more income for the miners that don't voluntarily leave the consensus
08:48:52sipa:stonecoldpat: s/pass on/accept/
08:48:59sipa:stonecoldpat: relay doesn't evne matter
08:49:13sipa:the point of running a full node is being capable of verying the rules it implements *yourself*
08:50:02sipa:jeremyrubin: assume that today, 60% of miners chance their software to give themselves a perpetual 100 BTC sunsidy per block
08:50:08sipa:jeremyrubin: tell me what would happen
08:51:08jeremyrubin:sipa: I'm not sure.
08:51:23sipa:jeremyrubin: in particular, what would your own full node do?
08:51:47jeremyrubin:sipa: my full node would not recognize their blocks
08:52:24smooth:sipa: what would you call a fork that lowered the reward schedule?
08:52:37sipa:jeremyrubin: what would happen is that the world would see a 2.5x hashrate decrease, and that's all
08:52:53sipa:jeremyrubin: those 60% of miners just voluntarily left the bitcoin consensus
08:52:59jeremyrubin: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:59sipa:and made themselves irrelevant
08:53:34sipa: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:43sipa:smooth: that's a soft fork
08:54:04jeremyrubin: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:17smooth:sipa: im not sure, don't you need everyone to upgrade in order to enforce such a schedule?
08:54:24sipa:smooth: nope
08:54:30sipa:smooth: just a hashpower majority
08:54:41smooth:sipa: but that's temporary, it can't enforce a future scheule
08:54:47sipa:smooth: so?
08:55:02smooth:so to change the schedule i would say you need to get all the users to upgrade
08:55:14jeremyrubin:smooth: the point is that nothing invalid in past becomes valid.
08:55:25sipa:smooth: yes, i see
08:55:33smooth:jeremyrubin: yes and im questioning whether this deffinition of hard fork is actually the most useful one
08:55:45sipa:smooth: but at any point undoing the change can result in a fork again, if some users did upgrade
08:55:49jeremyrubin:smooth: gotcha
08:56:19sipa:smooth: note that you can enforce every softforking-change as a hard fork
08:56:19smooth:sipa: is this not worse, now you have a majority of miners who can break the network any time they want?
08:56:31sipa:smooth: they can always do that :)
08:56:48sipa:smooth: just have two groups of near equal hash power that don't like each other's blocks
08:57:13smooth:sipa: i suppose by excluding transactions, but even that is only temporary, while creating a permanent fork is different
08:57:39sipa:fair enough, the risk of a permanent fork is only there if part of the userbase upgrades
08:59:35smooth: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:14sipa:smooth: yeah
09:00:42sipa:i guess we should talk about two types of enforcement (miner collusion being one, userbase enforcement is another)
09:01:18sipa:softforks are done by first having miners colluding as soon as enough of them indicate support, then doing userbase enforcement
09:01:40smooth:but its very hard to get all users to ever upgrade anything...
09:02:14smooth:it seems in practice this relies on miners never having an incentive to change their minds
09:02:35sipa:well as soon as you have miners that are doing the collusion, users can upgrade at their leisure
09:02:43sipa:this gives miners a power to fork the network
09:02:50sipa:but they always have this power
09:03:04sipa:well, no, that's not true
09:03:16smooth:the power to fork is much weaker, it requires an exact 50-50 split
09:03:28smooth:miners can block transactions though
09:03:34smooth:essentially breaking the network
09:04:10smooth:although perhaps with some feedback mechanism you could engineer a persistent 50-50 (etc) split
10:59:31mm_1:mm_1 is now known as mm_0
11:49:07mm_0:mm_0 is now known as mm_1
13:00:29mm_1:mm_1 is now known as mm_0
13:15:13kanzure:maybe there's a way where you can use your consensus rules to help sign your verifications
13:15:44kanzure: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:09mm_0:mm_0 is now known as mm_1
14:46:15midnightmagic:* 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:09dEBRUYNE__:dEBRUYNE__ is now known as dEBRUYNE
19:48:21mm_1:mm_1 is now known as mm_0
21:51:52blazes816:blazes816 is now known as tcrypt
22:02:14lmatteis:what protocol does bitcoin use to propagate messages across the network, and how are peers discovered?
22:03:44fluffypony:lmatteis: more a question for #bitcoin-dev, no?