00:00:28HostFat:"suppose no blocksize limit, and naughty miner makes a 10TB block this afternoon. what would happen?"
00:00:44HostFat:someone will make a smaller block that will spread faster then the one of 10 TB
00:00:49HostFat:and it will be the winner
00:01:14HostFat:even if it was discovered after the one of 10TB
00:02:16HostFat:miners will not release heavier blocks that can't spread faster on the network
00:02:40dgenr8:okay, I will rephrase: "what very bad thing will happen?"
00:05:00HostFat:maybe there aren't so much bad things as some are saying
00:06:26HostFat: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:25HostFat: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:26HostFat:I think that the limit of 20 MB is useless
00:08:53Taek: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:11Taek:As long as it reaches 50-70% of miners in time, it will be accepted on the main chain
00:09:17HostFat:it's the same for the nodes
00:09:24Taek:those miners who are in the minority, have worse infrastructure, etc, will get left out
00:09:40HostFat:I don't think so
00:09:42Taek:and as a result they will have a much higher rate of stale blocks
00:10:03HostFat:a smaller block will be faster to spread then the bigger one, even if the bigger was discovered then the smaller
00:10:18Taek:yes, but not every miner has the same infrastructure
00:10:24Taek:some can download a big block faster than others
00:10:50HostFat:you have to think how the block spread to the nodes more then the miners
00:11:02Taek: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:23Taek:what are you arguing?
00:11:46HostFat:how can you isolate other miners? if you are the only one that has received the big block
00:12:01HostFat:the others have reaceived the smaller one, and they are mining it
00:12:05Taek:you aren't the only one who has received the big block, 50+% of the network got the big block
00:12:08HostFat:heavy block will be orfan
00:12:12Taek:it's just the other 50% that got left behind
00:12:28Taek:I'm not making a 10TB block, I'm making one that's just big enough to isolate a minority of miners
00:12:37Taek:but a large minority
00:12:39HostFat:if the block is eavier, it has less probability to spread faster then the smaller one
00:12:48Taek:right, that's the entire goal
00:13:14Taek:the big is going to have a head start most of the time because blocks on average only appear every 10 minutes
00:13:29Taek:if a big + small appear at the exact same moment, the small will win
00:13:55HostFat:so it's better to release smaller blocks
00:13:58Taek: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:00HostFat:even if there is no limit
00:14:17Taek:it's better to isolate your competition
00:14:32Taek:if my competition has a higher rate of stale blocks than I do, they will not be in business for very long
00:14:41Taek:and since mining is a 0-sum game, that benefits me
00:15:39HostFat:the bandwidth and the power of miners aren't directly related
00:16:55Taek:that doesn't matter
00:17:06Taek:what matters is that some miners have better bandwidth/connectivity than others
00:17:29Taek:that disparity is much easier to exploit when you get to choose your own block size
00:17:31HostFat:so, more then then power, it will be important to have a good connection
00:17:51Taek:no matter what your power is, it's important to have a good connection
00:18:08Taek:your stale rate is directly related to your connection
00:18:36Taek: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:41Taek:a cheap connection is pretty much good enough
00:18:43HostFat:but we are still talking about the miners, and not the nodes
00:18:51Taek:why do the nodes matter/
00:19:02HostFat:nodes are more important than the miners
00:19:27Taek:for what?
00:19:27HostFat:they have the controll of the rules of the network
00:19:57Taek:are you arguing that nodes would arbitrarily enforce limits on the block size?
00:20:10HostFat:yes, wait .. :)
00:20:23HostFat: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:47Taek:the nodes will choose to accept the set of blocks that have the most pow
00:20:53HostFat: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:17Taek:which blocks the nodes have *right now* has no bearing on what choices the miners will make
00:21:25Taek:miners only care about getting their block onto the longest chain
00:21:39HostFat:miner want to be first than the other miner to find the next block
00:21:42Taek:and they care about the longest chain being accepted *eventually* by the nodes
00:22:20Taek:so they won't make invalid blocks, but that doesn't mean they are compelled to make small blocks
00:22:28HostFat: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:52HostFat:because the block of 1 mb spread faster
00:23:15Taek:you're missing something in your logic
00:24:11Taek:the miner is going to choose to mine on the block that's most likely to be extended
00:24:27Taek:and the block that's most likely to be extended is the block that most other miners have seen first
00:24:35Taek:nodes have nothing to do with it
00:25:12Taek: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:16HostFat:miners need to be sure that the block of 20mb has been recevied from the majority of the nodes
00:26:30HostFat:if they are sure about this, than it's ok
00:27:25Taek:the speed at which the nodes receive blocks is not related to which blocks the miners choose to mine
00:27:31Taek:it's okay if the nodes are several minutes behind the miners
00:29:47HostFat: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:31HostFat:he will probably mine a block smaller than 1mb :D
00:31:32Taek:HostFat: that's simply not how validation works
00:31:50HostFat:the validation comes from nodes
00:32:40Taek: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:45gwillen:HostFat: the only thing that affects what's in the longest chain is the miners
00:32:52gwillen:non-mining nodes have no way to control what chain ends up longest
00:33:06gwillen: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:22gwillen:so they _will_ briefly use it, but it won't matter in the end
00:34:39HostFat: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:27HostFat: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:36HostFat:because, the smaller block spread faster
00:37:30gwillen:you haven't explained why you think the miner would care what nodes get his block
00:37:37gwillen:the only thing he cares is whether his block ends up in the longest chain
00:37:44gwillen:and that is only affected by what other miners get his block
00:37:52HostFat: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:55gwillen:the non-mining nodes have no effect on whether his block ends up in the longest chain
00:39:06HostFat:the chain of the smaller blocks is faster of an heavy chain of bigger blocks
00:39:21GGuyZ_:GGuyZ_ is now known as GGuyZ
00:39:34HostFat:it's faster because smaller blocks spread faster, just this
00:40:25HostFat: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:23gwillen:HostFat: that _could_ be true but it's only affected by how long it takes block to get to _other miners_
00:41:32gwillen:if those 51% all have very fast connections to each other, they will always win
00:41:38gwillen:if they don't, they could have problems
00:41:56HostFat:to get to the nodes, nodes are more important than the miners
00:42:09HostFat:they are chosing the chain
00:42:17Taek:why are you so certain that the nodes are more important?
00:43:41HostFat:because this is how it works bitcoin, nodes are where the bitcoins are spent, where tx are checked
00:43:56HostFat:they check the blocks and the chain
00:44:15gwillen:but they will always choose the longest chain no matter what
00:44:23HostFat:it is impossible to make an hard fork without changing the nodes
00:44:28gwillen:so if one group of miners can produce a longer chain, the nodes will always choose that chain
00:44:43gwillen:so what you have to figure out is who creates the longest chain
00:44:54HostFat:the longeest that they get, and if the nodes have a modem of 56k, they will get the chain of smaller blocks
00:45:01gwillen: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:02HostFat:it seems easy to me ..
00:45:08smooth:dgenr8: the bad thing that will happen is that miners will be able to control who is able to access the network
00:45:27gwillen:HostFat: that would only be true if their connection were so slow that they _never_ get the bigger blocks
00:45:41gwillen:HostFat: as long as they _ever_ get the bigger blocks _eventually_, and that chain is longer, they will switch to it
00:46:02Taek:and in that regard there's a consensus risk
00:46:12Taek:because faster nodes may end up picking a different chain
00:46:17gwillen:right, if fast nodes use one chain and slow nodes use another, then you get in real trouble
00:46:20HostFat: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:25HostFat:than it will be ok
00:47:15HostFat: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:36HostFat:miner will "always" chose to relase the "right" block for the majority of the nodes
00:48:15HostFat: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:26HostFat:because, nodes are more important than the miners
00:54:54smooth:there is to be fair some logic in that
00:55:56smooth: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:03amiller:BlueMatt, how is the mining backbone going?
00:56:30BlueMatt:amiller: seems most miners use it, software has stabilized mostly
00:56:43amiller:any stats on it?
00:56:49amiller:which miners?
00:57:27HostFat:"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:14HostFat: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:25HostFat:nodes aren't getting any income to be nodes ...
00:58:46smooth:HostFat: they will get income if you cant operate your own node but still want to transact
00:58:49smooth:e.g. coinbase
00:59:51HostFat: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:53BlueMatt: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:04smooth:HostFat: nodes don't have to provide SPV service for free either
01:00:20BlueMatt:amiller: afaik pretty much all miners with big chunks of hashpower use it +/- one or two
01:01:20HostFat: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:56amiller: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:34HostFat:it's late here, good night!
01:05:51BlueMatt:amiller: yea, I want to reset everything and see what happens
01:06:34amiller:ok :) (though resetting is unrelated to publishing more about it anyway)
01:07:09BlueMatt: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:19gmaxwell: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:42gmaxwell:(basically I want exactly the ncurses tool, but in web form. :)) ... bit handicapped with bitcointalk and the wiki being down.
01:56:38kanzure:gmaxwell: well it's in php but... https://github.com/stolendata/rpc-ace
01:56:58kanzure:and https://github.com/JornC/bitcoin-transaction-explorer
01:58:34gmaxwell:woot, just found the first; hadn't found the second yet.
02:00:34Adlai:is http://webbtc.com as simple as you need?
02:01:12Adlai:might have a bit too many frills
02:01:49kanzure:he needs rpc
02:01:58gmaxwell:Need something that works even if the transaction format is wildly different. :)
02:02:14gmaxwell:its nice though I wish the rpc things were that nice.
02:02:31kanzure:tbh it would be faster to write a quick python wrapper around rpc output
02:03:00kanzure:gmaxwell: like https://github.com/typicode/json-server
02:03:28Adlai:* Adlai has been using https://gist.github.com/adlai/0afc53e42db9caae8c75#file-cjhunt-lisp-L3-L14
02:03:51gmaxwell:yea probably, would be interesting to just display the json output and do minimal parsing to add hyperlinks.
03:44:24frankenm_:frankenm_ is now known as frankenmint
04:49:39leakypat_:leakypat_ is now known as leakypat
07:27:18bosma:bosma is now known as bosnia
07:38:47bosnia:bosnia is now known as InlandBosnia
07:39:40InlandBosnia:InlandBosnia is now known as Bosnia
08:05:17holmes.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:17holmes.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:17holmes.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:17holmes.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:17holmes.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:17holmes.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:01felipelalli1:felipelalli1 is now known as felipelalli
10:34:02zz_lnovy:zz_lnovy is now known as lnovy
10:35:33Aesthetic:Aesthetic is now known as Logicwax
10:39:24lnovy:lnovy is now known as zz_lnovy
10:40:03zz_lnovy:zz_lnovy is now known as lnovy
10:46:25LeMiner2:LeMiner2 is now known as LeMiner
11:03:46lnovy:lnovy is now known as zz_lnovy
16:07:25www:hey, one quick q. can a bitcoin tx contain multiple OP_RETURN outputs?
16:09:42Luke-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:08Luke-Jr:www: why do you think OP_RETURN is useful?
16:10:41www:trying to fit a signature of a msg into a bitcoin tx. signature seems to be 88 bytes
16:11:21Luke-Jr:hash it
16:11:40www:i hash the message
16:11:48Luke-Jr:no, hash the signature
16:11:56www:and then where to publish the sig?
16:12:02Luke-Jr:with the message
16:12:12www:the message is on chain
16:12:20Luke-Jr:then the recipient verifies the sig matches the message, and the H(sig) matches the commitment
16:12:21www:and less than 80 bytes
16:12:39Luke-Jr:well, then you're just doing it wrong :P
16:12:41Luke-Jr:you might also find https://github.com/Blockstream/contracthashtool useful
16:13:00www:using bitcore for message signing and verification
16:13:03www:is bad?
16:13:15Luke-Jr:www: using the blockchain for messaging is bad
16:13:24www:ah, no, it is useful
16:13:35Luke-Jr:no, it isn't. it is clueless.
16:13:48www:ok mr overlord
16:13:54www:i obey
16:14:56www:i will try to keep your blockchain clean and pretty
16:20:06Luke-Jr:you asked how to do X, so I advised you how to do X. your hostility is not appropriate.
16:20:46www:i don't feel advised, i feel commanded
16:22:42www:maybe there is a way to make the sig shorter..?
16:30:39www: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:17fluffypony:www: take it somewhere else, thanks.
16:31:32www:is this the same Luke-Jr here who put CATHOLIC prayers into bitcoins chain?
16:33:54Luke-Jr:fluffypony: I'm biased. Ought he be +q'd?
16:34:53fluffypony:if he shuts up or leaves of his own accord then no, but if he carries on blathering then yes
16:35:01fluffypony:now let's make that a smart contract and put it on the blockchain
16:35:56www:have fun guys
16:36:01www:www has left #bitcoin-wizards
18:28:11jae:jae is now known as Guest79919
21:30:19dEBRUYNE__:dEBRUYNE__ is now known as dEBRUYNE
22:55:04c0rw1n:c0rw1n is now known as c0rw|sleep
23:37:58jae:jae is now known as Guest1212
23:45:24akrmn: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:06nsh:(you can wonder about that in #bitcoin)
23:50:38akrmn:nsh: I thought it was on topic, because of the large proportion of Bitcoin devs here, but ok...
23:51:31akrmn:also, no mods here :)
23:52:18akrmn:o ok
23:58:59nsh: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:43nsh:*perhaps via