1 2015-06-14 00:10:40 <jgarzik> phantomcircuit, Mainly it needs to mirror relay logic, thus "superblock" analogy, mirroring the logic building a block:  First take the highest fees, but there is a secondary sort and inclusion based on priority
  2 2015-06-14 00:11:24 <jgarzik> phantomcircuit, RE size, the consensus was 24-48 hours worth of traffic
  3 2015-06-14 00:11:41 <jgarzik> phantomcircuit, priority alone is insufficient, and 16mb is way too small
  4 2015-06-14 00:11:55 <gmaxwell> I think you cannot immitate the mining logic without two queues, I think the relay logic cannot be immitated with any finite datastructure.
  5 2015-06-14 00:12:20 <gmaxwell> jgarzik: the dpriority he's using is the one in the mining logic, I thought
  6 2015-06-14 00:12:26 <Rickyy> who can help me building windows and linux wallets for my new coin ... i pay to learn .. pm me
  7 2015-06-14 00:13:18 <hidden> Rickyy ask in bitcointalk. this is for bitcoin development.
  8 2015-06-14 00:13:36 <Rickyy> thx
  9 2015-06-14 00:14:17 <phantomcircuit> gmaxwell, Luke-Jr mentioned something about the priority being calculated different ways in different places
 10 2015-06-14 00:16:38 <phantomcircuit> jgarzik, the block creation logic is iirc fairly slow actually
 11 2015-06-14 00:17:12 <phantomcircuit> if the mempool max size is substantially larger than the maximum block size
 12 2015-06-14 00:17:21 <phantomcircuit> im not sure it'll make that much of a difference
 13 2015-06-14 00:17:47 <phantomcircuit> and there certainly will be nodes that operate with gigabyte limits
 14 2015-06-14 00:17:52 <jgarzik> phantomcircuit, nod
 15 2015-06-14 00:17:54 <phantomcircuit> (at the very least i'll be running one)
 16 2015-06-14 00:18:34 <gmaxwell> phantomcircuit: I explained how it will make a big difference. If you can't even relay because your txn won't be includable for a few hours, you're kinda stuck.
 17 2015-06-14 00:18:51 <jgarzik> phantomcircuit, Never said the problem was easy ;-)   The goal is "what will likely confirm within the next X hours" (X=24-48)   The next step is to approximate that.
 18 2015-06-14 00:19:04 <jgarzik> pure priority does a poor job of capturing low priority + high fee
 19 2015-06-14 00:19:07 <gmaxwell> meaning you can't take advantage of low off peak rates, without waiting to broadcast, which seems silly.
 20 2015-06-14 00:20:16 <phantomcircuit> well there's 144 blocks/day
 21 2015-06-14 00:20:37 <phantomcircuit> if we assume that the peak to peak low fees happen within a 24 hour window
 22 2015-06-14 00:20:50 <phantomcircuit> then 288 would be enough to hit that and clear anything that's reasonably going to be mined
 23 2015-06-14 00:20:57 <gmaxwell> yes.
 24 2015-06-14 00:21:54 <gmaxwell> likewise, if we assume that there is 20kb of each block used for low fee high priority then 288 * 20kb would be enough for a by-priority queue for low fee txn.
 25 2015-06-14 00:22:08 <phantomcircuit> gmaxwell, what about DEFAULT_BLOCK_MAX_SIZE * 288;
 26 2015-06-14 00:23:54 <gmaxwell> phantomcircuit: that would be good except if relay logic also depends on this, more consistent would be helpful.
 27 2015-06-14 00:28:44 <phantomcircuit> https://github.com/bitcoin/bitcoin/pull/6281
 28 2015-06-14 00:41:27 <jgarzik> phantomcircuit, looks reasonable
 29 2015-06-14 00:42:02 <jgarzik> phantomcircuit, the main issue with solutions like this is that you add a full additional mempool walk with each insertion
 30 2015-06-14 00:42:09 <phantomcircuit> the priority calculation logic should probably be unified
 31 2015-06-14 00:42:12 <jgarzik> phantomcircuit, not saying it's wrong - it's simple and reasonable
 32 2015-06-14 00:42:21 <phantomcircuit> i assume it probably causes all kinds of problems that nobody has noticed
 33 2015-06-14 00:42:31 <jgarzik> phantomcircuit, ideal would be to integrate with existing mempool and Already Know
 34 2015-06-14 00:43:40 <phantomcircuit> jgarzik, i could track the the lowest priority already in the mempool which would avoid that on transactions that will be removed immediately
 35 2015-06-14 00:44:21 <phantomcircuit> but i doubt it's worth it since at this point we've already done script checks on the transaction so this is a relatively small cost
 36 2015-06-14 00:44:40 <phantomcircuit> (checking the scripts is necessary for setting the misbehaving flags)
 37 2015-06-14 03:07:58 <jgarzik> Updated BIP 100 draft: http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
 38 2015-06-14 03:08:29 <jgarzik> hard fork at 32MB made explicit (implicit 32MB cap becomes explicit)
 39 2015-06-14 03:08:45 <jgarzik> BlueMatt, ^
 40 2015-06-14 03:09:12 <BlueMatt> thanks for noting that
 41 2015-06-14 03:09:55 <Luke-Jr> jgarzik: are you going to ever clarify the part that erroneously talks about a "simultaneous" soft fork?
 42 2015-06-14 03:14:49 <jgarzik> Luke-Jr, what is your preferred choice of language?
 43 2015-06-14 03:17:12 <Luke-Jr> jgarzik: I guess "variable hard limit" based on my current understanding. I haven't read the newer drafts entirely yet, though, so I'm not 100% sure on the details.
 44 2015-06-14 03:17:58 <Luke-Jr> part of the reason I think it ought to change, is because it poses an actual barrier to my ability to comprehend it.
 45 2015-06-14 03:22:31 <jgarzik> Luke-Jr, OK fixed click reload
 46 2015-06-14 03:22:48 <Luke-Jr> jgarzik: btw, is there a .md version anywhere?
 47 2015-06-14 03:23:04 <jgarzik> not yet
 48 2015-06-14 03:23:41 <phantomcircuit> jgarzik, a text version on github would probably be useful, change tracking helps people to understand why things were done
 49 2015-06-14 03:23:46 <Luke-Jr> ok; I'll read through it tomorrow or Monday probably
 50 2015-06-14 03:24:15 <jgarzik> phantomcircuit, yah I'll do it once major arrows have been thrown
 51 2015-06-14 03:24:37 <jgarzik> I think it's pretty close
 52 2015-06-14 03:25:11 <jgarzik> some of the checks & balances take time to think through
 53 2015-06-14 11:26:00 <C-Otto_> I wrote an article about consequences of the (a) hard fork, in German. anyone willing to proof-read?
 54 2015-06-14 14:00:04 <wallet42> C-Otto_: pass over the link
 55 2015-06-14 14:30:20 <ren0v0> hi according to this readme, syncing should be quicker from scratch post 0.10.x over using bootstrap file. However it gives no reason and from what i've tried is completely false?
 56 2015-06-14 14:30:23 <ren0v0> https://bitcoin.org/bin/block-chain/README.txt
 57 2015-06-14 14:31:08 <ren0v0> what does *slower* mean, why is it in asterisks like that?
 58 2015-06-14 14:31:36 <harding> ren0v0: it means emphesis, as in *this* is important.
 59 2015-06-14 14:32:36 <ren0v0> harding, in that case why is there no explanation, i can't see how its possibly faster
 60 2015-06-14 14:32:48 <ren0v0> it seems more that there is a caveat or something
 61 2015-06-14 14:33:48 <ren0v0> it took me around 15minutes to get synced to like 2500 blocks
 62 2015-06-14 14:34:14 <ren0v0> whereas i can get 22gb of the chain in about double that amount of time
 63 2015-06-14 14:34:24 <harding> ren0v0: sorry about that, I wrote the that text and most people I communicate understand what it means.  I hadn't realized it could be confusing to people who don't regularly communicate using plain ASCII.
 64 2015-06-14 14:35:15 <ren0v0> harding, maybe you should consider your audience a bit more before writing in future :)
 65 2015-06-14 14:35:38 <C-Otto> wallet42: will do, just a sec
 66 2015-06-14 14:35:45 <ren0v0> that aside, it still doesn't help making that statement with no explanation, especially if its wrong?
 67 2015-06-14 14:35:55 <harding> ren0v0: you can possibly download faster using BitTorrent, but to actually import that data into Bitconi Core will take just as long whether it comes from torrent or directly over the network.
 68 2015-06-14 14:36:33 <harding> Since Bitcoin Core can download and validate at the same time, while with torrent you need to download first and then import, syncing with Bitcoin Core will be faster.
 69 2015-06-14 14:36:49 <C-Otto> wallet42: http://ftp2.de.debian.org/~cotto/bitcoin.pdf
 70 2015-06-14 14:36:50 <harding> However, you're correct that the message confuses download time with sync time.  I'll suggest we change that.
 71 2015-06-14 14:37:07 <ren0v0> harding, ok, and this was confirmed with the same spec machine and networking?
 72 2015-06-14 14:37:44 <harding> ren0v0: this was confirmed with logic: time_to_download + time_to_validate
 73 2015-06-14 14:37:50 <ren0v0> ahhhh logic
 74 2015-06-14 14:37:52 <harding> Whoops, hit enter too soon.
 75 2015-06-14 14:38:17 <harding> ren0v0: this was confirmed with logic: time_to_download + time_to_validate > time_to_download_and_validate_simultaneously
 76 2015-06-14 14:38:37 <ren0v0> harding, well i started 8 minutes ago via torrent method, i'll time it and may try a standard sync as well and test your logic
 77 2015-06-14 14:38:47 <ren0v0> kk
 78 2015-06-14 14:39:04 <ren0v0> i know code changes have been made, but this has never been the case for me in many years
 79 2015-06-14 14:39:17 <harding> ren0v0: Do you have a GitHub account?  I'll be happy to @ mention you when I propose a change to that message.
 80 2015-06-14 14:39:36 <ren0v0> what i actually was wondering is what changed in 0.10, it'll likely mean nothing to me but it would be nice to back the logic up with some theory
 81 2015-06-14 14:40:18 <harding> ren0v0: 0.10 uses a different method of Initial Blockchain Download (IBD) called headers first.  I have some documentation of how that works and why it's faster; give me a sec and I'll find the link.
 82 2015-06-14 14:40:40 <wallet42> C-Otto: Danke, busy now but will review a few hours later
 83 2015-06-14 14:40:56 <ren0v0> ah yes i'm aware of headers first not the finer details though
 84 2015-06-14 14:41:17 <harding> ren0v0: https://bitcoin.org/en/developer-guide#initial-block-download and specifically https://bitcoin.org/en/developer-guide#headers-first
 85 2015-06-14 14:41:27 <ren0v0> i was under the impression this would allow spending quicker but would still download the full chain eventually
 86 2015-06-14 14:41:42 <ren0v0> again, maybe the statement in the readme confuses this issue as well
 87 2015-06-14 14:42:19 <ren0v0> so assume this is the reason for the statement, would it still be true if it was referring to gaining two complete chains?
 88 2015-06-14 14:42:48 <harding> ren0v0: no, I think you're confusing headers first with a proposal to have Bitcoin Core start with SPV security (this has not been implemented, or work started on it AFAIK).
 89 2015-06-14 14:43:07 <harding> ren0v0: Would you mind if we switch to #bitcoin, this is getting more and more non -dev?
 90 2015-06-14 14:44:29 <ren0v0> harding, no need, i'll practically test the  logic and PM you if the result don't match the statement if thats ok?
 91 2015-06-14 14:44:41 <harding> Sure.  Thanks.
 92 2015-06-14 17:43:35 <afk11> is there a lightning dev room?
 93 2015-06-14 17:53:43 <harding> afk11: not that I know of, but I believe there's a #sidechains-dev that might be relevant, as well as #bitcoin-wizards
 94 2015-06-14 17:56:01 <afk11> harding: ah cool, I'll try there!
 95 2015-06-14 19:45:31 <tommo> hi guys trying to install bitcoind here, I installed openssl with brew, but having trouble with its version
 96 2015-06-14 19:45:53 <tommo> im following the doc/build-osx.md
 97 2015-06-14 19:46:44 <tommo> it says if the version is incorrect and 'brew link openssl --force' doesnt fix it then check the path
 98 2015-06-14 19:48:18 <tommo> where do i check the path?
 99 2015-06-14 19:50:19 <tommo> specifically it says 'make sure `/usr/local/bin` comes before `/usr/bin` in your PATH. '
100 2015-06-14 20:29:40 <theymos> Sorry for the somewhat off-topic question, but I wonder: Do Bitcoin Core devs perceive the creation/management of bitcoin.org content as being a sub-project of the main Bitcoin Core project, or is bitcoin.org more-or-less independent?
101 2015-06-14 20:30:44 <C-Otto> wallet42: ping
102 2015-06-14 20:31:18 <wumpus> theymos: more or less independent, I think, bitcoin.org doesn't aim to be a site about bitcoin core but about the whole ecosystem, hence the wallet chooser etc
103 2015-06-14 20:33:45 <theymos> ok, thanks. That's also what I thought.
104 2015-06-14 22:09:51 <warren> https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08217.html  Apparently it's easy to achieve quick consensus in the Bitcoin Project. =)
105 2015-06-14 22:20:42 <Anunnak1> sounds like a good idea