1 2015-05-29 00:50:06 <cfields> BlueMatt: i suppose we could switch to fPIC by default, and use fPIC for releases
  2 2015-05-29 00:50:21 <cfields> since we build our own static qt
  3 2015-05-29 00:50:52 <cfields> *use fPIE for releases
  4 2015-05-29 00:51:33 <BlueMatt> sounds good to me
  5 2015-05-29 00:53:00 <cfields> fwiw, you should be able to immediately work-around via --disable-hardening CXXFLAGS="-O2 -g -fPIC"
  6 2015-05-29 00:53:10 <cfields> (not tested)
  7 2015-05-29 00:54:56 <BlueMatt> or just force fPIC (which I did)
  8 2015-05-29 00:56:10 <cfields> gmaxwell: looks like both Ubuntu and Gentoo go for PIE when possible
  9 2015-05-29 00:56:25 <cfields> from a quick look around
 10 2015-05-29 00:58:24 <cfields> seems odd to me that distros would use qt's -reduce-relocations in the first place. I wonder if that'll change once gcc5 gets some traction
 11 2015-05-29 02:08:49 <Rozal> what is nick szabo's IRC handle?
 12 2015-05-29 04:55:56 <earlz> Was the gitian setup changed in 10.2 or something? I'm getting errors where it's requesting /home/ubuntu for everything rather than /home/debian
 13 2015-05-29 04:56:06 <earlz> 0.10.2*
 14 2015-05-29 07:01:39 <sythaeryn> Anyone know SGornick?
 15 2015-05-29 07:06:55 <sword_smith> Can anyone give me a guesstimate as to when this transaction will be confirmed? 990a7302f4b0ee84cbf3a5683dc1ed31c700858bd99b7543b9768cd16cfa70b9
 16 2015-05-29 07:08:09 <sword_smith> https://blockchain.info/tx/990a7302f4b0ee84cbf3a5683dc1ed31c700858bd99b7543b9768cd16cfa70b9
 17 2015-05-29 07:32:54 <wumpus> using PIC for executables should not be necessary
 18 2015-05-29 07:33:43 <wumpus> PIE = Position Independent Executable, PIC is for building shared libraries
 19 2015-05-29 07:34:01 <wumpus> (or static libraries that are linked into a shared library)
 20 2015-05-29 07:36:50 <Luke-Jr> eh? I thought PIE was just a PIC executable?
 21 2015-05-29 07:38:12 <wumpus> "So, to allow a randomization of the program binary itself, the PIE mode was created. It works very much like what PIC does for dynamic libraries. The difference is that a PLT is not created, instead PC-relative relocation is used."
 22 2015-05-29 07:38:28 <wumpus> it's close, but not the same
 23 2015-05-29 07:40:09 <wumpus> just a trade-off in overhead (PLT versus additional relocations)
 24 2015-05-29 07:40:34 <Luke-Jr> hm
 25 2015-05-29 07:42:07 <wumpus> http://www.openbsd.org/papers/nycbsdcon08-pie/mgp00004.html
 26 2015-05-29 07:45:47 <K1773R> sword_smith: crystal ball says: sometime
 27 2015-05-29 07:47:45 <wumpus> please take the confirmation discussion to #bitcoin
 28 2015-05-29 07:48:33 <jonasschnelli> Right. This is #bitcoin stuff. sword_smith: i'm there if you need to discuss that in detail
 29 2015-05-29 07:48:47 <wumpus> but yes, it could take some time, all those inputs, low priority, and only a very little fee
 30 2015-05-29 09:29:07 <ren0v0> Hi, what's the "recommended" SPV client ?
 31 2015-05-29 09:33:37 <b_lumenkraft> ren0v0: https://bitcoin.org/en/choose-your-wallet
 32 2015-05-29 09:34:46 <ren0v0> yup i'm there, can't decide if armory/electrum is a better choice so i'm an opinion there really
 33 2015-05-29 09:35:24 <stonecoldpat> the #bitcoin channel may be better for this type of discussion
 34 2015-05-29 09:35:26 <b_lumenkraft> armory is not a SPV wallet
 35 2015-05-29 10:00:05 <aschildbach_> ren0v0: I suggest Bitcoin Wallet: https://market.android.com/details?id=de.schildbach.wallet
 36 2015-05-29 10:06:50 <wumpus> electrum is not a 'SPV' wallet either, in the strict definition (it is a light wallet client, though)
 37 2015-05-29 10:07:55 <wumpus> +1 for aschildbach_'s android wallet. For desktop, there is not really a SPV wallet I can recommend
 38 2015-05-29 11:07:02 <wumpus> almost every pull is failing on that now... I wonder why, what changed, do some tests take a lot longer?
 39 2015-05-29 11:12:40 <jonasschnelli> wumpus: Thanks!
 40 2015-05-29 11:13:22 <jonasschnelli> wumpus: this was somehow annoying because you could not longer tell if travis is failing becuase or a PR issue or because of a general testing issue
 41 2015-05-29 11:13:46 <jonasschnelli> s/not longer/no longer
 42 2015-05-29 11:16:03 <wumpus> jonasschnelli: it looks to me that the servers are extremely busy and overloaded, so hitting intermittent timeouts, and it happens in the java-based tool probably because that's the cpu-heaviest part of the test suite
 43 2015-05-29 11:16:42 <jonasschnelli> wumpus: hmm.. your probably right. this could be the case.
 44 2015-05-29 11:29:36 <jonasschnelli> wumpus: yes. i think gpg should be held external
 45 2015-05-29 11:29:37 <wumpus> jonasschnelli: I'm all for such a tool, but wouldn't want it integrated in bitcoin core
 46 2015-05-29 11:30:06 <wumpus> a gitian-downloader as a project would be nice tho
 47 2015-05-29 11:30:16 <jonasschnelli> wumpus: so you would say it's better to keep this in a seperate app?
 48 2015-05-29 11:30:19 <wumpus> yes
 49 2015-05-29 11:30:43 <wumpus> it could be packaged along, I don't care, but I don't want anything and the kitchen sink in bitcoin core
 50 2015-05-29 11:30:55 <jonasschnelli> wumpus: it would require some kind of packaging format. Mapping of binaries and signatures and pgp keys
 51 2015-05-29 11:31:55 <wumpus> yes, a start was made on it once (there are some remnants in the repository of signature->score mappings and such), but it's a long time ago
 52 2015-05-29 11:33:45 <jonasschnelli> okay... will see what i can do
 53 2015-05-29 11:35:05 <jonasschnelli> is there a reason why the signers pgp keys are within bitcoin.git instead of gitian.sigs.git?
 54 2015-05-29 11:35:08 <wumpus> another option would be to switch to (or add) ecdsa-based gitian signatures, those will be easier to verify in our context
 55 2015-05-29 11:36:33 <wumpus> I don't think switching over completely is a good idea as this loses the GPG web of trust and keyservers and such, though, but as an extra layer for simple verification in the software it could maybe work
 56 2015-05-29 11:37:40 <wumpus> jonasschnelli: gitian.sigs is suppose to contain only signatures; there's arguments for and against keeping everything together. In general the bitcoin repository is perceived to be harder to tamper with.
 57 2015-05-29 11:38:07 <wumpus> (all commits are signed, the source code is there so there is more scrutiny, etc)
 58 2015-05-29 11:38:16 <jonasschnelli> okay.. makes sense.
 59 2015-05-29 11:39:49 <wumpus> and the contents of the bitcoin repository could be shipped with releases (although it creates a chicken-egg problem, you'd only use them for verifying the *next* release)
 60 2015-05-29 11:44:26 <wumpus> which makes sense, as the gpg keys for the last release will have been verified along with that release, that creates continuity in the auditing (unlike retrieving the gpg keys from an external repo on demand)
 61 2015-05-29 13:44:47 <kanzure> those threats of a fork are just not amusing. why would i want to work with someone that thinks analysis is debate?
 62 2015-05-29 14:30:54 <sitco> i feel enough people want to increase the blocksize, i would like to see debate on the specification of it
 63 2015-05-29 14:33:50 <akstunt600> how about we just put out 2 versions 1 with dyn block height + hard cap at 20mb the other stays at 1mb and see which branch gets more love?
 64 2015-05-29 14:33:53 <akstunt600> :p
 65 2015-05-29 14:34:34 <sitco> putting in another hard cap is just going to cause a replay of this in however long it takes to get there
 66 2015-05-29 14:34:39 <akstunt600> yup
 67 2015-05-29 14:34:41 <akstunt600> i want that
 68 2015-05-29 14:35:31 <sitco> my impression has been that hard forks become more difficult the larger the user base, why would you want the same discussion but with more noise?
 69 2015-05-29 14:35:34 <akstunt600> the consensus is key here we gotta get comfortable with it sooner or later. We must learn how to deal with this
 70 2015-05-29 14:35:55 <akstunt600> its test, a good one
 71 2015-05-29 14:37:25 <akstunt600> btc consensus *could* be the new democracy if it can be made to work
 72 2015-05-29 14:37:27 <sitco> hard forks aren't good, unavoidable sometimes but design shouldn't be to create more of them in the future
 73 2015-05-29 14:37:59 <akstunt600> the intention is not create hard forks its to draw more interest and development IMO
 74 2015-05-29 14:38:05 <akstunt600> to*
 75 2015-05-29 14:38:43 <sitco> retaining a hard cap is going to just create another situation requiring another hard fork
 76 2015-05-29 14:39:13 <akstunt600> Plus if it properly educated on the tech it only make sense to guard the long chain otherwise it *could* be crashed in a hard fork leaving many in ruin
 77 2015-05-29 14:39:34 <gavinandresen> I still like the 20MB doubling every couple of years plan, that's the patch I'll submit to -Xt I think.
 78 2015-05-29 14:39:40 <akstunt600> there is incentive on the side to stay mathematically legit
 79 2015-05-29 14:39:42 <akstunt600> IMO
 80 2015-05-29 14:40:03 <instagibbs> gavin are you asking or telling on the email list?
 81 2015-05-29 14:40:08 <akstunt600> i think that sounds reasonable
 82 2015-05-29 14:40:17 <gavinandresen> instagibbs: asking or telling what?
 83 2015-05-29 14:40:40 <gavinandresen> instagibbs: are you GibbsSamplePlatter on reddit? I was just writing:  "I've been pushing them to make a counter-proposal, or, at least, a specific plan for how to move forward since February."
 84 2015-05-29 14:40:50 <sitco> why not scale by usage the way difficulty does instead of trying to guess usage with some numbers like 20 every 2 years?
 85 2015-05-29 14:41:00 <instagibbs> does "What do other people think?" mean "I'll go ahead regardless and this is just saying it nicely?"
 86 2015-05-29 14:41:06 <instagibbs> or "you can change my mind"
 87 2015-05-29 14:41:09 <hearn> guess i should get the XT house in order. i'm not really happy with the current workflow/branch organisation
 88 2015-05-29 14:41:12 <dgenr8> average size can be low even with frequent over-max. hiking max sculd be based on frequency max is hit.
 89 2015-05-29 14:41:13 <akstunt600> difficulty is not a good metric for that
 90 2015-05-29 14:41:16 <instagibbs> i mean modulo them saying what you want to hear aout block sizes
 91 2015-05-29 14:41:24 <gavinandresen> sitco: because greg and sipa dont' want bitcoin to become "only google-scale data centers can handle the traffic"
 92 2015-05-29 14:42:49 <midnightmagic> sitco: i do not think that means what you think it means
 93 2015-05-29 14:43:21 <sitco> i have no idea what you think i think i mean
 94 2015-05-29 14:43:55 <gavinandresen> sitco: a dynamic max size based on historical block sizes with no upper limit is fine with me, too, but then there's endless arguing over parameters.....
 95 2015-05-29 14:44:13 <midnightmagic> i think you both think there's some thinking that hasn't been thought
 96 2015-05-29 14:44:22 <akstunt600> well i worry about the BS bloating too quickly too, and core wallets on "regular" HW not being able to keep up. it needs to follow moores law in reguards to cpu/bandwidth
 97 2015-05-29 14:44:27 <akstunt600> ^ i think that is about it
 98 2015-05-29 14:44:27 <sitco> define endless?
 99 2015-05-29 14:44:39 <akstunt600> if dyn BS is done well this shouldnt be too much of a worry i think
100 2015-05-29 14:45:55 <GAit> gavinandresen: would you enable your hard forking changes even if the majority of nodes and miners are still on bitcoin core with the majority of core devs?
101 2015-05-29 14:46:15 <sitco> if bitcoin becomes so widely successfully so quickly that so many transaction are hitting the chain that only full nodes at a well connected data center can keep up that seems like 1) a great thing and 2) unlikely
102 2015-05-29 14:46:56 <akstunt600> however with Intel and 21 right around the corner lurking it might be best to throw caution into the wind with BS but it would need to stay in check untill there is some market saturation of this new tech
103 2015-05-29 14:47:07 <gavinandresen> GAit: majority of nodes is weird-- it would be easy for either side to spin up tens of thousands of nodes to make it look like there's a majority for their side.
104 2015-05-29 14:47:30 <gavinandresen> GAit: that's why I'll judge consensus based on public statements of big merchants/exchanges/etc
105 2015-05-29 14:47:43 <instagibbs> does "What do other people think?" mean "I'll go ahead regardless and this is just saying it nicely?"
106 2015-05-29 14:47:47 <gavinandresen> GAit: there certainly has to be a supermajority of hashpower willing to support the change.
107 2015-05-29 14:48:36 <stonecoldpat> gavinandresen: i think the statistic of people who havent upgraded is a better metric, if 100 nodes say they havent upgraded, then this may be a better way to convince yourself that the majority accepts it
108 2015-05-29 14:48:49 <gavinandresen> instagibbs: no, I really do want to hear what other people think. I want to hear specific plans for how to handle increasing transaction volume....
109 2015-05-29 14:48:58 <akstunt600> Right now we are a tad centralized in terms of hash, and the demand is go big or go home from the big players.
110 2015-05-29 14:49:04 <gavinandresen> ... or I want to hear people say "more transaction volume is bad because...."
111 2015-05-29 14:49:45 <akstunt600> the question on many peopls mind is can it go faster than 4-7 TPS and can it do it reliably
112 2015-05-29 14:49:49 <instagibbs> as you note there has been endless debate about that question. I'm talking about your specific plan outlined in your e-mail
113 2015-05-29 14:50:01 <akstunt600> just answering that question could drive everything up
114 2015-05-29 14:50:11 <GAit> ok, my public statement as founder of  GreenAddress.com is that I am very worried and I would prefer if the majority of core devs agreed on one or the other and so far it seems like the decision is to not move to 20MB anytime soon
115 2015-05-29 14:51:01 <hearn> obviously, everyone would prefer it if there was agreement
116 2015-05-29 14:51:09 <instagibbs> The most charitable reading I'm getting out of this is you've given up on getting consensus, and are asking if it's ok to ignore other dev's views on your specific 20MB proposal.
117 2015-05-29 14:51:18 <GAit> it's at best something that could slow down a lot of development on bitcoin and disruption and at worse it could fork and cause a split of people on different chains with all the caos that comes with it
118 2015-05-29 14:51:19 <hearn> however it's become clear that some of the developers, especially the ones at blockstream, will not agree to any proposal.
119 2015-05-29 14:51:21 <instagibbs> prepend "developer" with consensus here clearly
120 2015-05-29 14:51:25 <akstunt600> hmm, i was under the impression that we are leaning towards dyn blocks in the few months
121 2015-05-29 14:51:25 <hearn> so most likely you will have to pick
122 2015-05-29 14:51:33 <akstunt600> next*
123 2015-05-29 14:51:41 <instagibbs> err "core developer"
124 2015-05-29 14:52:56 <GAit> I listened to motivations on all sides and i have been following the debate forever. I am really not convinced about the urgency of the change yet and I am not convinced we should increase it so much in one go
125 2015-05-29 14:53:00 <gavinandresen> GAit: development of Bitcoin Core is already painfully slow, in my opinion....
126 2015-05-29 14:53:08 <instagibbs> The least charitable is " you give me 2/3 of what I want or I'll do what I want"
127 2015-05-29 14:54:25 <LeMiner> I believe that Gavin has already spoken about most arguments against a block size increase, and altough it sucks that some people with bad internet connections wont be able to handle 20MB blocks, when we do actually reach that blocksize it'll mean that we reached a whole new level of adoption and general Bitcoin acceptance
128 2015-05-29 14:54:28 <GAit> hearn: i think the devs at blockstream have held the same opinion prior to becoming founders of blockstream and I don't think they are the only ones, there's me and there's Peter Todd and a few others that are not convinced
129 2015-05-29 14:54:42 <midnightmagic> hearn: I wish you would stop doing that. The casting aspersions nonsense.
130 2015-05-29 14:54:56 <LeMiner> And I think that that is a lot more important than a few nodes on bad connections
131 2015-05-29 14:55:12 <hearn> it was meant as a shorthand to save typing, not to imply that people are being paid to have certain opinions
132 2015-05-29 14:55:13 <hearn> jeez
133 2015-05-29 14:55:25 <midnightmagic> You're doing it again.
134 2015-05-29 14:55:34 <hearn> doing what?
135 2015-05-29 14:56:06 <LeMiner> And for anyone saying that blocks aren't getting near full yet there are some very interesting graphs on that, currently we wouldn't survive the next big price rally....
136 2015-05-29 14:56:32 <akstunt600> thats not entirely accurate at all
137 2015-05-29 14:56:48 <GAit> LeMiner: not everyone has the same urgency and people can decide how much they want to wait
138 2015-05-29 14:57:02 <akstunt600> the fees would just flux and there would be a back log trying to get into a block. most stuff happens on exchanges anyway
139 2015-05-29 14:57:17 <LeMiner> Precicely, if you do not agree with the new rules, then by all means don't update your node when it happens....
140 2015-05-29 14:57:22 <instagibbs> Unless otherwise stated, I'll just assume it's the less generous interpretation. Cheers.
141 2015-05-29 14:57:30 <LeMiner> akstun600, that is inaccurate
142 2015-05-29 14:57:35 <GAit> block are a lot full with transaction that could easily and trivially move to payment channels of some sort or Lightening once the soft fork for malleability is done
143 2015-05-29 14:57:59 <LeMiner> Gait, are you ready to implement lightning? Cause even they need bigger blocks
144 2015-05-29 14:58:09 <GAit> they need bigger blocks to scale globally
145 2015-05-29 14:58:13 <LeMiner> https://i.imgur.com/LtOQ0zh.gif
146 2015-05-29 14:58:19 <GAit> but buys us a lot of time and saves us from bloat
147 2015-05-29 14:58:24 <hearn> this must be some new use of the phrase "easily and trivially" i have not encountered before
148 2015-05-29 14:58:26 <LeMiner> do believe lightning will be implimented before 2016?
149 2015-05-29 14:58:30 <hearn> as just one example, that requires abandoning bitcoin addresses
150 2015-05-29 14:58:31 <LeMiner> or before the next big price rally?
151 2015-05-29 14:58:39 <hearn> which i'd love to see happen but despite my efforts, people do love to use them still ....
152 2015-05-29 14:59:29 <GAit> LeMiner: yes I am considering to adopt some ligthening like standard if there's consensus/support for the idea
153 2015-05-29 14:59:38 <gavinandresen> Any solution that requires every SPV wallet to make major changes is impractical for the short-term (next three years), in my opinion.
154 2015-05-29 14:59:44 <hearn> GAit: did you see my article about it?
155 2015-05-29 15:00:04 <GAit> yes, i saw all articles from both you and Gavin as well as the mailing list
156 2015-05-29 15:00:04 <sitco> is there anywhere to read gavin's specific xt proposal? is it just new hard cap at 20mb?
157 2015-05-29 15:00:29 <LeMiner> Gait, at the rate that the core project is advancing currently increasing the block size to prepare ourselfs for more transactions is the way to go
158 2015-05-29 15:00:30 <hearn> GAit: do you disagree with the complexity arguments in my article about lightning?
159 2015-05-29 15:00:49 <GAit> i think is the most viable solution right now in sight
160 2015-05-29 15:01:01 <hearn> because?
161 2015-05-29 15:01:09 <akstunt600> yeah lightning is a bit "big"
162 2015-05-29 15:01:19 <LeMiner> because he will impliment it himself?
163 2015-05-29 15:01:20 <dgenr8> anyone have a link to a plotted distribution of block sizes?
164 2015-05-29 15:01:26 <GAit> blocks can't scale to global levels any time soon, lightening for *some* application seems fantastic, and payment channels are great for all gambling and sites like that
165 2015-05-29 15:01:33 <LeMiner> implement*
166 2015-05-29 15:02:25 <GAit> LeMiner: not myself, just support the standard, use common libraries and contribute to them if we can
167 2015-05-29 15:03:12 <LeMiner> Great, so we know that you will support and help where needed. Now let's see if you can get a team together to implement the rest of it before the blocks are actually full
168 2015-05-29 15:04:13 <gavinandresen> dgenr8: I made a histogram of blocksizes yesterday  http://bitcoincore.org/~gavin/sizes_last1000.html
169 2015-05-29 15:04:37 <GAit> i'm supportive of having a tiny increase ready in case of proven emergency
170 2015-05-29 15:04:46 <dgenr8> gavinandresen: ah! okay so the size of that bump at 1mb is of interest
171 2015-05-29 15:04:47 <LeMiner> It's great to dream about lightning and it truely is great once implemented, but seeing how slow all these projects move we will NOT have it anywhere near finished before we have a huge transaction backlog and things start breaking
172 2015-05-29 15:05:06 <dgenr8> 50/1000 are hitting the limit
173 2015-05-29 15:05:23 <GAit> LeMiner: i'm far more convinced you can move faster on top of the blockchain than make changes to bitcoin core, and for good reason!
174 2015-05-29 15:05:40 <hearn> dgenr8: the hard limit. far more are hitting the default soft limit
175 2015-05-29 15:05:58 <gavinandresen> yes, that's the big spike at 750K
176 2015-05-29 15:05:59 <LeMiner> Gait, just look how slow blockstream is moving....
177 2015-05-29 15:06:17 <hearn> GAit: i believe you should think through the implications of trying to implement a Lightning/Stroem network approach and possibly talk it over with the strawpay guys
178 2015-05-29 15:06:36 <dgenr8> hearn: so you think some of the soft limit blocks would actually liked to be bigger than hard limit...
179 2015-05-29 15:06:38 <hearn> GAit: assuming that libraries will magically appear to do everything seems optimistic. the Stroem guys have built such a library (for java/bitcoinj) but they still say it takes a LOT of changes to a wallet, to support it
180 2015-05-29 15:06:56 <hearn> dgenr8: well they'd like to be 1mb, if the software default wasn't throttling them yeah
181 2015-05-29 15:07:01 <GAit> hearn: working payment channels is a good start for a bunch of applications even without lightening
182 2015-05-29 15:07:14 <sitco> is it possible to also raise the minimum blocksize? that would force miners to include more transactions
183 2015-05-29 15:07:28 <hearn> GAit: and yet there's only one implementation that's mature, and that's java/bitcoinj only. the bitcore version that Streamium is using, it turns out, doesn't support some fairly important features.
184 2015-05-29 15:07:30 <GAit> sitco, nope
185 2015-05-29 15:07:38 <hearn> GAit: for instance reloading the Streamium tab destroys private keys and thus money! :(
186 2015-05-29 15:07:46 <gavinandresen> sitco: possible, yes, but that's not a good idea-- miners would just stuff blocks full of bogus pay-to-self transactions.
187 2015-05-29 15:07:53 <hearn> anyway
188 2015-05-29 15:07:56 <Luke-Jr> sitco: that would be bad; there's already serious spam problems
189 2015-05-29 15:08:02 <hearn> time to go and spend some time in the sun with a non-bitcoiner ..... ciao
190 2015-05-29 15:08:04 <GAit> hearn: yes it is mature but can't be used without trust yet because of malleability
191 2015-05-29 15:08:14 <GAit> regardless of library
192 2015-05-29 15:09:50 <LeMiner> One way or another, we are going to need bigger blocks regardless of what happens
193 2015-05-29 15:09:52 <LeMiner> might as well do it now
194 2015-05-29 15:10:47 <GAit> now it may be much more risky than later
195 2015-05-29 15:11:19 <LeMiner> tell me about the risks, ones that gavin hasen't spoken about in his blog posts
196 2015-05-29 15:11:41 <LeMiner> and I don't want to hear about rural US internet connection speed either....
197 2015-05-29 15:11:47 <midnightmagic> Is this kind of pointless aggravation and cheerleading really appropriate for #bitcoin-dev?
198 2015-05-29 15:12:07 <dgenr8> hearn: the lower bar at 800K argues that less than half of the 750K blocks would have been over 900K.  Overall i'd guess between 3-10% of blocks are full today.
199 2015-05-29 15:15:50 <sitco> so the current proposal is a new hard cap at 20?
200 2015-05-29 15:15:55 <gavinandresen> dgenr8: no, many miners choose to create smaller blocks, and, therefore, they are "full"
201 2015-05-29 15:16:19 <gavinandresen> dgenr8: see http://gavinandresen.ninja/the-myth-of-not-full-blocks
202 2015-05-29 15:17:04 <gavinandresen> dgenr8: ... or take a look at http://bitcoincore.org/~gavin/sizes_357511.html  which plots what miners did at a time when the memory pool was getting larger and larger
203 2015-05-29 15:19:00 <dgenr8> gavinandresen: ok, but isn't that a second-order effect as it relates to desired MAX block size?
204 2015-05-29 15:19:06 <akstunt600> yeah solving the block fast is the game, the fees arent enough to ensure that pools would fill blocks over solving the block faster
205 2015-05-29 15:19:08 <sitco> graph of average number of transaction per block, 14 day average: https://blockchain.info/charts/n-transactions-per-block?timespan=all&showDataPoints=false&daysAverageString=14&show_header=true&scale=0&address=
206 2015-05-29 15:19:46 <midnightmagic> blockchain.info is not an accurate source of information, and refuses to correct in timely fashion pretty much any of the issues reported to it.
207 2015-05-29 15:21:15 <gavinandresen> dgenr8: I think it depends on what point you're trying to make.  If you're saying "we have plenty of space and don't need to do anything"... well, average block size is about 400K, so yes, we can about double (if miners agree to produce bigger blocks)...
208 2015-05-29 15:21:56 <dgenr8> my point is averages are the wrong measure.  we should be looking at frequency of maxing out (and 10% seems too frequent to me)
209 2015-05-29 15:22:24 <akstunt600> well keep in mind the spam issue
210 2015-05-29 15:23:39 <sitco> if most miners use the default settings why not just change the default to mine 1mb blocks, it'll at least make miners consider what they want
211 2015-05-29 15:24:01 <akstunt600> Whoa
212 2015-05-29 15:24:08 <akstunt600> i think there is a misunderstanding there
213 2015-05-29 15:27:03 <Luke-Jr> sitco: not necessarily; a default of empty blocks or random size would accomplish that better IMO
214 2015-05-29 15:28:43 <dgenr8> bikeshed alert.  set max blocksize = f(current max blocksize, last-2016-maxout%, previous-2016-maxout%)
215 2015-05-29 15:28:44 <gavinandresen> Luke-Jr: I'm thinking of submitting a patch that makes the default target size for miners "whatever the rest of the network has been producing over the last N blocks"
216 2015-05-29 15:28:54 <gavinandresen> ... so miners that don't care just go along with the herd.
217 2015-05-29 15:30:01 <akstunt600> that would be a nice change for p2pool and solo miners
218 2015-05-29 15:30:01 <Luke-Jr> gavinandresen: that's an interesting approach
219 2015-05-29 15:30:10 <gavinandresen> dgenr8: I don't think that's compatible with nodes that are pruning, you need the entire chain (with sizes) to compute that function....
220 2015-05-29 15:30:15 <akstunt600> i like that idea :)
221 2015-05-29 15:32:06 <temujin> gavinandresen: max(blocksize) or avg(blocksize) over the last N blocks? probably max is smarter as 1-transaction blocks can seriously mess with the average, and median is a bit awkward...
222 2015-05-29 15:32:07 <dgenr8> setting MAX = AVERAGE creates a downward bias.  <--
223 2015-05-29 15:32:30 <Luke-Jr> max makes sense since it's a max
224 2015-05-29 15:32:40 <Luke-Jr> but then it's too easy for one miner to change it
225 2015-05-29 15:33:03 <Luke-Jr> so perhaps "median" 2/3 or something?
226 2015-05-29 15:33:17 <gavinandresen> Well, target would really be average + half the average transaction size so there's no bias....
227 2015-05-29 15:33:59 <Luke-Jr> but in the end, this default only makes sense alone - there are other aspects to policy miners ought to be making a positive decision on
228 2015-05-29 15:35:42 <dgenr8> gavinandresesn: i don't follow
229 2015-05-29 15:36:35 <gavinandresen> dgenr8: CreateNewBlock() adds transactions to the block until adding one more transaction would make it bigger than the target size (default 750K right now).
230 2015-05-29 15:37:09 <gavinandresen> dgenr8: if we want "i don't care" miners to have no effect on the average block size, then setting the target to the average over the last N blocks plus half the average transaction size should accomplish that.
231 2015-05-29 15:37:44 <gavinandresen> ... assuming there are always enough transactions waiting around to fill up the average block size....
232 2015-05-29 15:37:56 <dgenr8> gavinandresesn: that's the rub. the bias comes from all the smaller blocks
233 2015-05-29 15:38:55 <gavinandresen> dgenr8: mmm.  Want to run some number to figure out what algorithm WOULD result in neutrality?
234 2015-05-29 15:39:31 <sitco> we wouldn't we want 'i don't care' miners to include as many transactions as feasible?
235 2015-05-29 15:39:32 <temujin> gavinandresen: what is "transaction size"?
236 2015-05-29 15:39:49 <temujin> just the size in bytes of all transactions included in the last N blocks?
237 2015-05-29 15:39:53 <gavinandresen> temujin: number of bytes in a transaction when it is serialized for transmitting across the network
238 2015-05-29 15:41:03 <dgenr8> gavinandresen: strictly speaking, since a max can only reduce the size otherwise produced, it can only reduce the future average.  so it would be more than just a max.
239 2015-05-29 15:42:10 <dgenr8> reminde me why we have a soft limit again?
240 2015-05-29 15:44:35 <gavinandresen> dgenr8: the soft limit is from when "real" transaction volume was tiny and we had a lot of send-to-self transaction spam.
241 2015-05-29 15:53:39 <kanzure> it is somewhat unethical to claim to large exchanges that a hard fork is totally safe for them. they can lose out on a bunch of money from being on the wrong end of a fork.
242 2015-05-29 15:55:12 <sitco> or lose a bunch more if the hashing power of their chain becomes trivial
243 2015-05-29 15:55:49 <LeMiner> kanzure, it'll be easy to see which fork has more support before the actual forking happens
244 2015-05-29 15:56:10 <kanzure> that's not quite true
245 2015-05-29 15:56:39 <kanzure> those version numbers or whatever are not what you think they are. yes they communicate that someone had that value set, but that doesn't tell you who or the quantity of support.
246 2015-05-29 15:57:11 <kanzure> well anyway; i encourage you to be more careful about assumptions about what you can guestimate from various sources of data
247 2015-05-29 15:57:17 <LeMiner> ofc, but since most pools/miners will actually say hey guys, we're running xxx
248 2015-05-29 15:57:22 <LeMiner> and support xxx
249 2015-05-29 15:57:28 <LeMiner> it will be
250 2015-05-29 16:07:20 <XiaronFlux> bitcoin is a great idea thanks for your hard work :-D
251 2015-05-29 16:10:43 <sitco> another bikeshed proposal for block size. ever 2016 blocks new block size = avg transactions over 2016 : new max block size :: 750 transaction : 1mb block size
252 2015-05-29 17:00:10 <sitco> as for raising the minimum block size, while it's true miners could just stuff bogus transactions wouldn't they still rather at least include transactions with fees attached first?
253 2015-05-29 17:01:27 <gmaxwell> sitco: You might have more responses in #bitcoin with that line of thought.
254 2015-05-29 17:10:47 <wallet42> gavinandresen: have you read https://cryptonote.org/whitepaper.pdf 6.2.2 Size limits? (and maybe 6.2.3) whats your opinion on that?
255 2015-05-29 17:13:45 <gavinandresen> wallet42: gmaxwell has a better scheme than 6.2.3, but it only works when the subsidy goes to zero.
256 2015-05-29 17:15:05 <gavinandresen> wallet42: ... and I posted on the bitcoin-dev mailing list a straw-man dynamic algorithm similar to 6.2.2 (except I like average instead of median, because otherwise 51% of miners have complete control over the max size)
257 2015-05-29 17:16:11 <gavinandresen> wallet42: (gmaxwell and maaku have a scheme that works even with subsidy, but they said it's pretty complex, and complexity is bad in consensus code)
258 2015-05-29 17:17:05 <wallet42> I totally agree on that last part.
259 2015-05-29 17:28:27 <gmaxwell> It's not really that its code-complex; it's that it changes the subsidy amount; so one would have to convince the public that it was actually non-inflationary and such. (not that its _technically_ hard, or that it would be difficult to convince an engineer of this).
260 2015-05-29 17:30:06 <gmaxwell> gavinandresen: Hm. 51% always have control over the size in any miner controlled setting, ultimately-- as they can just disallow blocks that go a way that they don't like.  The dislike of the majority control was why I suggested a lower percentile (e.g. 25% or 33%)
261 2015-05-29 17:31:00 <gmaxwell> wallet42: the particular scheme there does potentially nothing when the subsidy is very low, because one can simply pay fees out of band. In Monero where the subsidy is never zero it's perhaps a little more defensible.
262 2015-05-29 17:39:40 <langerhans\n> Hey, am trying to add some print support to the build system. Cross compiling for windows with the dependency builder still gives me an undefined reference to `qt_static_plugin_QWindowsPrinterSupportPlugin()'. Any idea?
263 2015-05-29 17:41:07 <langerhans\n> plugin is imported like this, in bitcoin.cpp: http://pastebin.com/WhCq6gZX
264 2015-05-29 17:41:55 <langerhans\n> libwindowsprintersupport.a exists
265 2015-05-29 17:54:28 <dgenr8> there are natural cycles of varying lengths in economic activity; some of the cycles are short (intra-day, and weekly). penalizing deviation from median activity would have to be careful to avoid that.
266 2015-05-29 17:59:02 <dgenr8> have any recent investigations found evidence of problems with miners artificially inflating blocks?  propagation time is natural disincentive and fortunately miner can't publish those txes ahead of time or the fees may go to someone else
267 2015-05-29 18:00:34 <jonasschnelli> langerhans\n: did you had a look at http://doc.qt.io/qt-5/qtprintsupport-index.html?
268 2015-05-29 18:01:01 <jonasschnelli> langerhans\n: i'm not sure if you still need Q_IMPORT_PLUGIN(QWindowsPrinterSupportPlugin); with qt5.4
269 2015-05-29 18:01:10 <jonasschnelli> but never tried. just guessing.
270 2015-05-29 18:01:32 <langerhans\n> Linux build works pretty good, but I'll have a look if it's still needed. Thanks for the tip!
271 2015-05-29 18:02:32 <jonasschnelli> langerhans\n depends on your deployment targets; but i definitively would try to go with qt5.4 (especially if you like to link static).
272 2015-05-29 18:02:47 <langerhans\n> makes sense, yeah
273 2015-05-29 18:03:32 <jonasschnelli> langerhans\n: the QPrinter class looks that it works fine under windows
274 2015-05-29 18:03:46 <langerhans\n> interesting, I'll have a look
275 2015-05-29 18:12:20 <jonasschnelli> langerhans\n: what are you trying to achieve? Paperwallet?
276 2015-05-29 18:12:35 <langerhans\n> yeah
277 2015-05-29 18:13:02 <jonasschnelli> within bitcoin-core?
278 2015-05-29 18:13:18 <jonasschnelli> (or bitcoin-qt)
279 2015-05-29 19:25:38 <kryo_> where can i find a description of the blockchain file format?
280 2015-05-29 19:26:39 <Jouke> kryo_: https://en.bitcoin.it/wiki/Block
281 2015-05-29 19:27:40 <kryo_> hmm ok thanks
282 2015-05-29 20:02:08 <langerhans\n> jonasschnelli, I finally fixed it by adding the required plugins to the bitcoin-qt.m4 :) Thanks again. I gotta go
283 2015-05-29 22:09:52 <Billdr> Is there any protocol tier reason for me to rely on my own infrastructure to do the initial broadcast a transaction?
284 2015-05-29 22:10:49 <dhill> you should inv first to see who wants it
285 2015-05-29 23:40:06 <BTCSpam5-29> this test is melting down chrome trying to render https://blockchain.info/unconfirmed-transactions