| 00:00:28 | HostFat: | "suppose no blocksize limit, and naughty miner makes a 10TB block this afternoon. what would happen?" |
| 00:00:44 | HostFat: | someone will make a smaller block that will spread faster then the one of 10 TB |
| 00:00:49 | HostFat: | and it will be the winner |
| 00:01:14 | HostFat: | even if it was discovered after the one of 10TB |
| 00:02:16 | HostFat: | miners will not release heavier blocks that can't spread faster on the network |
| 00:02:40 | dgenr8: | okay, I will rephrase: "what very bad thing will happen?" |
| 00:05:00 | HostFat: | maybe there aren't so much bad things as some are saying |
| 00:06:26 | HostFat: | if the bandwidth isn't enaught to spread faster blocks, and blocks aren't enaught large for every transactions, then there will be a marker of fees |
| 00:07:25 | HostFat: | if there is enaught bandwidth, there will be a "market of blocks". miners will try to have bigger blocks, but at the same time will try to have them smaller enaught to spread faster then other miners's blocks |
| 00:08:26 | HostFat: | I think that the limit of 20 MB is useless |
| 00:08:53 | Taek: | HostFat: if blocks had no size limit, miners could intentionally release blocks that are too large to spread to all other miners before the next one is mined |
| 00:09:11 | Taek: | As long as it reaches 50-70% of miners in time, it will be accepted on the main chain |
| 00:09:17 | HostFat: | it's the same for the nodes |
| 00:09:24 | Taek: | those miners who are in the minority, have worse infrastructure, etc, will get left out |
| 00:09:40 | HostFat: | I don't think so |
| 00:09:42 | Taek: | and as a result they will have a much higher rate of stale blocks |
| 00:10:03 | HostFat: | a smaller block will be faster to spread then the bigger one, even if the bigger was discovered then the smaller |
| 00:10:18 | Taek: | yes, but not every miner has the same infrastructure |
| 00:10:24 | Taek: | some can download a big block faster than others |
| 00:10:50 | HostFat: | you have to think how the block spread to the nodes more then the miners |
| 00:11:02 | Taek: | If I'm a malicious miner who can download big blocks very quickly, it's to my advantage to try and isolate the slowest 30-50% of the miners on the network by releasing blocks that they can't download inside of a few minutes |
| 00:11:23 | Taek: | what are you arguing? |
| 00:11:46 | HostFat: | how can you isolate other miners? if you are the only one that has received the big block |
| 00:12:01 | HostFat: | the others have reaceived the smaller one, and they are mining it |
| 00:12:05 | Taek: | you aren't the only one who has received the big block, 50+% of the network got the big block |
| 00:12:08 | HostFat: | heavy block will be orfan |
| 00:12:12 | Taek: | it's just the other 50% that got left behind |
| 00:12:28 | Taek: | I'm not making a 10TB block, I'm making one that's just big enough to isolate a minority of miners |
| 00:12:37 | Taek: | but a large minority |
| 00:12:39 | HostFat: | if the block is eavier, it has less probability to spread faster then the smaller one |
| 00:12:48 | Taek: | right, that's the entire goal |
| 00:13:14 | Taek: | the big is going to have a head start most of the time because blocks on average only appear every 10 minutes |
| 00:13:29 | Taek: | if a big + small appear at the exact same moment, the small will win |
| 00:13:55 | HostFat: | so it's better to release smaller blocks |
| 00:13:58 | Taek: | but if the big appears with a 5 minute propagation advantage, it's likely that it'll reach most of the faster miners before it reaches the slower miners |
| 00:14:00 | HostFat: | even if there is no limit |
| 00:14:09 | Taek: | no |
| 00:14:17 | Taek: | it's better to isolate your competition |
| 00:14:32 | Taek: | if my competition has a higher rate of stale blocks than I do, they will not be in business for very long |
| 00:14:41 | Taek: | and since mining is a 0-sum game, that benefits me |
| 00:15:39 | HostFat: | the bandwidth and the power of miners aren't directly related |
| 00:15:46 | Taek: | correct |
| 00:16:55 | Taek: | that doesn't matter |
| 00:17:06 | Taek: | what matters is that some miners have better bandwidth/connectivity than others |
| 00:17:29 | Taek: | that disparity is much easier to exploit when you get to choose your own block size |
| 00:17:31 | HostFat: | so, more then then power, it will be important to have a good connection |
| 00:17:40 | Taek: | no |
| 00:17:51 | Taek: | no matter what your power is, it's important to have a good connection |
| 00:18:08 | Taek: | your stale rate is directly related to your connection |
| 00:18:36 | Taek: | when there is a 1mb cap, it's not that big of a deal, because a cheap connection vs an expensive connection is going to affect you not very much |
| 00:18:41 | Taek: | a cheap connection is pretty much good enough |
| 00:18:43 | HostFat: | but we are still talking about the miners, and not the nodes |
| 00:18:51 | Taek: | why do the nodes matter/ |
| 00:18:53 | Taek: | *? |
| 00:19:02 | HostFat: | nodes are more important than the miners |
| 00:19:27 | Taek: | for what? |
| 00:19:27 | HostFat: | they have the controll of the rules of the network |
| 00:19:35 | Taek: | ok |
| 00:19:57 | Taek: | are you arguing that nodes would arbitrarily enforce limits on the block size? |
| 00:20:10 | HostFat: | yes, wait .. :) |
| 00:20:23 | HostFat: | what I'm saying is that, even if miners will find the bigger block at first, they will choice to use the smaller one |
| 00:20:47 | Taek: | the nodes will choose to accept the set of blocks that have the most pow |
| 00:20:53 | HostFat: | because they know that nodes will get it first, so it will be better for them (for the miners) to start mining on the next of the smaller |
| 00:21:17 | Taek: | which blocks the nodes have *right now* has no bearing on what choices the miners will make |
| 00:21:25 | Taek: | miners only care about getting their block onto the longest chain |
| 00:21:39 | HostFat: | miner want to be first than the other miner to find the next block |
| 00:21:42 | Taek: | and they care about the longest chain being accepted *eventually* by the nodes |
| 00:22:20 | Taek: | so they won't make invalid blocks, but that doesn't mean they are compelled to make small blocks |
| 00:22:28 | HostFat: | if there is a block of 1 mb, and one block of 20 mb, the miner will chose to mine after the block of 1 mb, because he know that nodes have already received it |
| 00:22:37 | Taek: | why? |
| 00:22:52 | HostFat: | because the block of 1 mb spread faster |
| 00:23:15 | Taek: | you're missing something in your logic |
| 00:24:11 | Taek: | the miner is going to choose to mine on the block that's most likely to be extended |
| 00:24:27 | Taek: | and the block that's most likely to be extended is the block that most other miners have seen first |
| 00:24:35 | Taek: | nodes have nothing to do with it |
| 00:25:12 | Taek: | if 51% of miners are already mining on the 20mb block, there's absolutely no reason to switch to mining the 1mb block |
| 00:26:16 | HostFat: | miners need to be sure that the block of 20mb has been recevied from the majority of the nodes |
| 00:26:30 | HostFat: | if they are sure about this, than it's ok |
| 00:26:34 | Taek: | _no_they_don't_ |
| 00:27:25 | Taek: | the speed at which the nodes receive blocks is not related to which blocks the miners choose to mine |
| 00:27:31 | Taek: | it's okay if the nodes are several minutes behind the miners |
| 00:29:47 | HostFat: | if 51% of miners are mining the 20mb, and only 10% of nodes has it, but the 90% has the 1mb blocks, than the miner that will mine after the 1mb has more possibility to get the next block (if it is smaller) validated from the network |
| 00:30:31 | HostFat: | he will probably mine a block smaller than 1mb :D |
| 00:31:32 | Taek: | HostFat: that's simply not how validation works |
| 00:31:50 | HostFat: | the validation comes from nodes |
| 00:32:40 | Taek: | the nodes have no input into *which* chain is the longest, they merely verify that the longest chain doesn't violate any consensus rules |
| 00:32:45 | gwillen: | HostFat: the only thing that affects what's in the longest chain is the miners |
| 00:32:52 | gwillen: | non-mining nodes have no way to control what chain ends up longest |
| 00:33:06 | gwillen: | if they get a block first, but that block doesn't end up in the longest chain, they will all eventually reorg that block away |
| 00:33:22 | gwillen: | so they _will_ briefly use it, but it won't matter in the end |
| 00:34:39 | HostFat: | yes, nodes doesn't know that the miners are mining actuly, they only get blocks, and these blocks need to be connected with the past one |
| 00:36:27 | HostFat: | so if the minority of nodes haven't the bigger block, but they know the smaller one, than a miner will try to give them (to the nodes) a new block connected with the smaller one, because he know that there is an higt probability that the majority of the nones know the smaller block than the bigger block |
| 00:36:36 | HostFat: | because, the smaller block spread faster |
| 00:37:30 | gwillen: | you haven't explained why you think the miner would care what nodes get his block |
| 00:37:37 | gwillen: | the only thing he cares is whether his block ends up in the longest chain |
| 00:37:44 | gwillen: | and that is only affected by what other miners get his block |
| 00:37:52 | HostFat: | as I said there will be a "market of blocks", where miners will try to find the bigger BUT faster block that can spread on the majority of the network |
| 00:37:55 | gwillen: | the non-mining nodes have no effect on whether his block ends up in the longest chain |
| 00:39:06 | HostFat: | the chain of the smaller blocks is faster of an heavy chain of bigger blocks |
| 00:39:21 | GGuyZ_: | GGuyZ_ is now known as GGuyZ |
| 00:39:34 | HostFat: | it's faster because smaller blocks spread faster, just this |
| 00:40:25 | HostFat: | if 51% or even more of miner will start to ming blocks of 1 GB, and the minority will mine blocks of 1 mb, the minority will probably win on the long run |
| 00:41:23 | gwillen: | HostFat: that _could_ be true but it's only affected by how long it takes block to get to _other miners_ |
| 00:41:32 | gwillen: | if those 51% all have very fast connections to each other, they will always win |
| 00:41:38 | gwillen: | if they don't, they could have problems |
| 00:41:56 | HostFat: | to get to the nodes, nodes are more important than the miners |
| 00:42:09 | HostFat: | they are chosing the chain |
| 00:42:17 | Taek: | why are you so certain that the nodes are more important? |
| 00:43:41 | HostFat: | because this is how it works bitcoin, nodes are where the bitcoins are spent, where tx are checked |
| 00:43:56 | HostFat: | they check the blocks and the chain |
| 00:44:15 | gwillen: | but they will always choose the longest chain no matter what |
| 00:44:23 | HostFat: | it is impossible to make an hard fork without changing the nodes |
| 00:44:28 | gwillen: | so if one group of miners can produce a longer chain, the nodes will always choose that chain |
| 00:44:31 | gwillen: | _always_ |
| 00:44:43 | gwillen: | so what you have to figure out is who creates the longest chain |
| 00:44:54 | HostFat: | the longeest that they get, and if the nodes have a modem of 56k, they will get the chain of smaller blocks |
| 00:45:01 | gwillen: | even if a node accepts one block over another, it will discard that block again if it's not in the longest chain |
| 00:45:02 | HostFat: | it seems easy to me .. |
| 00:45:08 | smooth: | dgenr8: the bad thing that will happen is that miners will be able to control who is able to access the network |
| 00:45:27 | gwillen: | HostFat: that would only be true if their connection were so slow that they _never_ get the bigger blocks |
| 00:45:41 | gwillen: | HostFat: as long as they _ever_ get the bigger blocks _eventually_, and that chain is longer, they will switch to it |
| 00:46:02 | Taek: | and in that regard there's a consensus risk |
| 00:46:12 | Taek: | because faster nodes may end up picking a different chain |
| 00:46:17 | gwillen: | right, if fast nodes use one chain and slow nodes use another, then you get in real trouble |
| 00:46:20 | HostFat: | if they will get the bigger block, than it's ok, the miners are chosing to relase a right block, of the right size, for the majority of the notes |
| 00:46:25 | HostFat: | than it will be ok |
| 00:47:15 | HostFat: | the miner want to relase a block for the majority of the nodes, because he wants to have a network that works, that gives money to him |
| 00:47:36 | HostFat: | miner will "always" chose to relase the "right" block for the majority of the nodes |
| 00:48:15 | HostFat: | if the majority have a 56k, then the majority of the miners will chose to relase smaller block, even if all of them have 1000 GB of connection |
| 00:48:26 | HostFat: | because, nodes are more important than the miners |
| 00:54:54 | smooth: | there is to be fair some logic in that |
| 00:55:56 | smooth: | i think it might be work short term, but longer term i think miners and big nodes will want to restrict access and charge those without the ability to operate nodes |
| 00:56:03 | amiller: | BlueMatt, how is the mining backbone going? |
| 00:56:30 | BlueMatt: | amiller: seems most miners use it, software has stabilized mostly |
| 00:56:43 | amiller: | any stats on it? |
| 00:56:49 | amiller: | which miners? |
| 00:57:27 | HostFat: | "i think it might be work short term, but longer term i think miners and big nodes will want to restrict access and charge those without the ability to operate nodes" |
| 00:58:14 | HostFat: | maybe, even if I understand that miners want to restring the network from other miners, but I can't find why some big nodes will want to do the same |
| 00:58:25 | HostFat: | nodes aren't getting any income to be nodes ... |
| 00:58:46 | smooth: | HostFat: they will get income if you cant operate your own node but still want to transact |
| 00:58:49 | smooth: | e.g. coinbase |
| 00:59:22 | HostFat: | hmm |
| 00:59:51 | HostFat: | yes ... this can be a problem if will be difficult to be nodes, or ... of users will prefer to use coinbase than SPV client |
| 00:59:53 | BlueMatt: | amiller: not readily at the moment...I need to fix one more bug then I want to reset and gather stats for a month |
| 01:00:04 | smooth: | HostFat: nodes don't have to provide SPV service for free either |
| 01:00:20 | BlueMatt: | amiller: afaik pretty much all miners with big chunks of hashpower use it +/- one or two |
| 01:01:20 | HostFat: | yes, true ... but they it doesn't cost so much, even less if there are many nodes (and pruning will help to get this) |
| 01:01:56 | amiller: | BlueMatt, ok. i'd be interesting in seeing any stats or info you have about how much it's used and like which miners use it |
| 01:02:34 | HostFat: | it's late here, good night! |
| 01:05:51 | BlueMatt: | amiller: yea, I want to reset everything and see what happens |
| 01:06:34 | amiller: | ok :) (though resetting is unrelated to publishing more about it anyway) |
| 01:07:09 | BlueMatt: | amiller: well, trying to parse out the stats right now would be a pita as there'd be a lot of false sources when nodes were acting up |
| 01:41:19 | gmaxwell: | Is anyone aware of a web block explorer front end for bitcoin that only uses the rpc? (like the ncurses tool)-- I mean something that lets you explore blocks using getblock / gettransaction verbose exclusively, not something that does its own block parsing. And I don't care if it doesn't have address indexing. |
| 01:41:42 | gmaxwell: | (basically I want exactly the ncurses tool, but in web form. :)) ... bit handicapped with bitcointalk and the wiki being down. |
| 01:56:38 | kanzure: | gmaxwell: well it's in php but... https://github.com/stolendata/rpc-ace |
| 01:56:58 | kanzure: | and https://github.com/JornC/bitcoin-transaction-explorer |
| 01:58:34 | gmaxwell: | woot, just found the first; hadn't found the second yet. |
| 02:00:34 | Adlai: | is http://webbtc.com as simple as you need? |
| 02:01:12 | Adlai: | might have a bit too many frills |
| 02:01:49 | kanzure: | he needs rpc |
| 02:01:58 | gmaxwell: | Need something that works even if the transaction format is wildly different. :) |
| 02:02:14 | gmaxwell: | its nice though I wish the rpc things were that nice. |
| 02:02:31 | kanzure: | tbh it would be faster to write a quick python wrapper around rpc output |
| 02:03:00 | kanzure: | gmaxwell: like https://github.com/typicode/json-server |
| 02:03:28 | Adlai: | * Adlai has been using https://gist.github.com/adlai/0afc53e42db9caae8c75#file-cjhunt-lisp-L3-L14 |
| 02:03:51 | gmaxwell: | yea probably, would be interesting to just display the json output and do minimal parsing to add hyperlinks. |
| 03:44:24 | frankenm_: | frankenm_ is now known as frankenmint |
| 04:49:39 | leakypat_: | leakypat_ is now known as leakypat |
| 07:27:18 | bosma: | bosma is now known as bosnia |
| 07:38:47 | bosnia: | bosnia is now known as InlandBosnia |
| 07:39:40 | InlandBosnia: | InlandBosnia is now known as Bosnia |
| 08:05:17 | holmes.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:17 | holmes.freenode.net: | Users on #bitcoin-wizards: andy-logbot dEBRUYNE ThomasV_ antanst Mably b_lumenkraft hktud0 d1ggy gielbier superobserver jtimon spinza jgarzik OneFixt [7] Logicwax Dr-G2 gmaxwell DrWat p15 DougieBot5000 metamarc vonzipper mappum NewLiberty hashtag_ akrmn isis sparetire_ MoALTz nubbins` dc17523be3 GAit gill3s PRab Jouke Tiraspol afk11 arubi_ Starduster_ Pan0ram1x thrasher` weex harrow gnusha Emcy alferz mkarrer Adlai tromp__ go1111111 nsh PaulCapestany luny triazo ttttemp |
| 08:05:17 | holmes.freenode.net: | Users on #bitcoin-wizards: jonasschnelli stonecoldpat LeMiner mountaingoat CryptoGoon wizkid057 Luke-Jr hulkhogan_ berndj leakypat pollux-bts Bosnia jrayhawk platinuum Oizopower jmcn_ jbenet HM dasource waxwing btcdrak tucenaber kyuupichan helo bassguitarman Taek ebfull hashtagg Madars zz_lnovy crowleyman bedeho iddo justanotheruser mengine GreenIsMyPepper amiller prodatalab_ sneak epscy adams__ wiz michagogo mikolalysenko artifexd grandmaster dansmith_btc SubCreative |
| 08:05:17 | holmes.freenode.net: | Users on #bitcoin-wizards: lmacken dgenr8 c0rw1n Cory larraboj brand0 nickler yrashk cfields Krellan_ stevenroose coryfields Meeh catlasshrugged cryptowest_ Alanius null_radix kanzure gavinand1esen bliljerk_ melvster azariah tromp_ scoria andytoshi warptangent harrigan sparetire davout comboy TD-Linux yorick crescend1 veox mm_1 theymos Zouppen huseby _whitelogger wumpus binaryatrocity heath BananaLotus maaku face_ Apocalyptic [d__d] optimator Eliel narwh4l lmatteis |
| 08:05:17 | holmes.freenode.net: | Users on #bitcoin-wizards: koshii mr_burdell throughnothing_ elastoma fluffypony Fistful_of_Coins yoleaux Jaamg se3000 xabbix mariorz catcow a5m0_ smooth dignork runeks Sqt poggy livegnik K1773R petertodd richardus nephyrin phedny so phantomcircuit afdudley pigeons SwedFTP guruvan ajweiss nanotube forrestv Muis warren Xzibit17 sdaftuar eric roasbeef BrainOverfl0w @ChanServ gwillen kinlo sl01 STRML espes AdrianG luigi1111 Anduck BlueMatt midnightmagic otoburb kumavis |
| 08:05:17 | holmes.freenode.net: | Users on #bitcoin-wizards: starsoccer d9b4bef9 gribble jessepollak ryan-c Keefe indolering Graet jaromil sturles [ace] merlincorey Iriez EasyAt morcos CryptOprah s1w |
| 10:01:01 | felipelalli1: | felipelalli1 is now known as felipelalli |
| 10:34:02 | zz_lnovy: | zz_lnovy is now known as lnovy |
| 10:35:33 | Aesthetic: | Aesthetic is now known as Logicwax |
| 10:39:24 | lnovy: | lnovy is now known as zz_lnovy |
| 10:40:03 | zz_lnovy: | zz_lnovy is now known as lnovy |
| 10:46:25 | LeMiner2: | LeMiner2 is now known as LeMiner |
| 11:03:46 | lnovy: | lnovy is now known as zz_lnovy |
| 16:07:25 | www: | hey, one quick q. can a bitcoin tx contain multiple OP_RETURN outputs? |
| 16:09:42 | Luke-Jr: | www: there is no such thing as "OP_RETURN outputs" at the protocol level; if you mean Core's reference spamfiltering, then no |
| 16:10:08 | Luke-Jr: | www: why do you think OP_RETURN is useful? |
| 16:10:41 | www: | trying to fit a signature of a msg into a bitcoin tx. signature seems to be 88 bytes |
| 16:11:21 | Luke-Jr: | hash it |
| 16:11:40 | www: | i hash the message |
| 16:11:48 | Luke-Jr: | no, hash the signature |
| 16:11:56 | www: | and then where to publish the sig? |
| 16:12:02 | Luke-Jr: | with the message |
| 16:12:12 | www: | the message is on chain |
| 16:12:20 | Luke-Jr: | then the recipient verifies the sig matches the message, and the H(sig) matches the commitment |
| 16:12:21 | www: | and less than 80 bytes |
| 16:12:39 | Luke-Jr: | well, then you're just doing it wrong :P |
| 16:12:41 | Luke-Jr: | you might also find https://github.com/Blockstream/contracthashtool useful |
| 16:13:00 | www: | using bitcore for message signing and verification |
| 16:13:03 | www: | is bad? |
| 16:13:15 | Luke-Jr: | www: using the blockchain for messaging is bad |
| 16:13:24 | www: | ah, no, it is useful |
| 16:13:35 | Luke-Jr: | no, it isn't. it is clueless. |
| 16:13:48 | www: | ok mr overlord |
| 16:13:54 | www: | i obey |
| 16:14:56 | www: | i will try to keep your blockchain clean and pretty |
| 16:20:06 | Luke-Jr: | you asked how to do X, so I advised you how to do X. your hostility is not appropriate. |
| 16:20:46 | www: | i don't feel advised, i feel commanded |
| 16:22:42 | www: | maybe there is a way to make the sig shorter..? |
| 16:30:39 | www: | WTF Early on, the miner Eligius started putting Catholic prayers in English and Latin in the coinbase field of blocks they mined. Here are some samples: http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html |
| 16:31:17 | fluffypony: | www: take it somewhere else, thanks. |
| 16:31:32 | www: | is this the same Luke-Jr here who put CATHOLIC prayers into bitcoins chain? |
| 16:33:54 | Luke-Jr: | fluffypony: I'm biased. Ought he be +q'd? |
| 16:34:53 | fluffypony: | if he shuts up or leaves of his own accord then no, but if he carries on blathering then yes |
| 16:35:01 | fluffypony: | now let's make that a smart contract and put it on the blockchain |
| 16:35:02 | fluffypony: | :-P |
| 16:35:07 | Luke-Jr: | :p |
| 16:35:56 | www: | have fun guys |
| 16:36:01 | www: | www has left #bitcoin-wizards |
| 18:28:11 | jae: | jae is now known as Guest79919 |
| 21:30:19 | dEBRUYNE__: | dEBRUYNE__ is now known as dEBRUYNE |
| 22:55:04 | c0rw1n: | c0rw1n is now known as c0rw|sleep |
| 23:37:58 | jae: | jae is now known as Guest1212 |
| 23:45:24 | akrmn: | I wonder if Bitcoin core devs restrict what they say publicly to avoid being targeted by a hitman hired by a powerful entity, or something like that |
| 23:49:06 | nsh: | (you can wonder about that in #bitcoin) |
| 23:50:38 | akrmn: | nsh: I thought it was on topic, because of the large proportion of Bitcoin devs here, but ok... |
| 23:51:31 | akrmn: | also, no mods here :) |
| 23:52:18 | akrmn: | o ok |
| 23:58:59 | nsh: | on-topic is vaguely defined, but if you wanted to enquire of the devs, perhaps the via the mailing-list. on-topicness seems to have a preference for conceptual/theoretical/technical aspects of blockchain and related technologies, over more social or hypothetical topics. but it's elastic, hence i made the suggestion parenthetical :) |
| 23:59:43 | nsh: | *perhaps via |