1 2014-12-05 00:02:57 <eric___> If bitcoind gets a block, which is later orphaned -- for how long will bitcoind keep it around and know about it? (I ask, as i might end up using that block hash with other api calls like listsinceblock )
2 2014-12-05 00:07:11 <harding> eric___: currently, I believe that once a block is written to disk, it is never removed. I don't know about the indices, and future prunning code will likely remove stale blocks.
3 2014-12-05 00:08:28 <eric___> That would make listsinceblock a bit annoying, since it takes a hash and not a height
4 2014-12-05 00:08:58 <eric___> I guess i can always use getblockhash
5 2014-12-05 01:19:13 <BlueMatt> coryfields: cfields-away ping
6 2014-12-05 01:19:17 <BlueMatt> or anyone
7 2014-12-05 01:19:29 <BlueMatt> anyone have any idea wtf is up with this travis job: https://travis-ci.org/bitcoin/bitcoin/jobs/43050702 ?
8 2014-12-05 01:19:38 <BlueMatt> it just dies mid-build without any timeout notifications or anything
9 2014-12-05 06:29:05 <wumpus> BlueMatt: I have no idea either, and cory is away on holiday this week
10 2014-12-05 06:31:26 <wumpus> my guess would be a memory problem
11 2014-12-05 06:31:45 <wumpus> you could try reducing the -jX more in .travis.yml
12 2014-12-05 06:48:55 <wumpus> that was the issue last time
13 2014-12-05 06:52:09 <BlueMatt> wumpus: hmm, the memory issues I had been having were resulting in an oom kill, but I tested locally in a limited vm and it didnt eat much memory anymore
14 2014-12-05 06:53:02 <wumpus> it may also be a completely different issue this time. I'm not quite adept yet at the dark art of debugging travis problems, if there is no output well.. there is no clue for me
15 2014-12-05 06:53:38 <BlueMatt> ok, well I'm working on fixing the win32 issues, so maybe it will magically resolve itself as a part of that...
16 2014-12-05 06:54:34 <wumpus> I suppose it's like debugging an embedded device without serial console, just throw changes at it and it's hit and miss if it hasn't come up after a few minutes...
17 2014-12-05 06:54:48 <BlueMatt> yup, pretty much
18 2014-12-05 06:54:58 <BlueMatt> though I had gotten it to give me gdb logs previously on crash
19 2014-12-05 06:55:09 <BlueMatt> I suppose I should've left that change in, though its probably now lost to the annals of git history
20 2014-12-05 06:55:39 <wumpus> it also happened once that the cache was 'poisoned' due to an earlier problem building a dependency, but that would mean every build would fail
21 2014-12-05 06:56:10 <BlueMatt> I assume that issue might be travis auto-killing when other builds die...though the times dont quite line up, so maybe I'm crazy
22 2014-12-05 06:58:18 <wumpus> that'd be a possibility
23 2014-12-05 09:08:23 <jonasschnelli> is there a easy way to build against a static built BDB (libdb_cxx-4.8.a) lib?
24 2014-12-05 09:12:21 <wumpus> shouldn't be different from building against a non-static one?
25 2014-12-05 09:13:01 <wumpus> although you have to compile the static bdb with -fPIC if you want to keep using address space randomization
26 2014-12-05 09:13:27 <wumpus> build-unix has a part on building bdb yourself
27 2014-12-05 09:13:54 <jonasschnelli> wumpus: thanks. let me follow that....
28 2014-12-05 09:26:35 <BlueMatt> lol...push a bad build and travis will snarf it and start building...immediately realize this and force-push over it and travis will do the other platforms that havent yet started with the new code...double-building all of the platforms that start the new code....
29 2014-12-05 09:34:36 <sipa> BlueMatt: haha, yes, i wish it would realize that
30 2014-12-05 10:33:27 <Luke-Jr> BlueMatt: really? I thoguht Travis locked onto a specific commithash⦠at least when I forcepush quickly, the rest of the builds *fail* because they can't fetch it..
31 2014-12-05 10:33:37 <Luke-Jr> s/fail/error/
32 2014-12-05 10:34:12 <wumpus> indeed, github very quickly makes orphaned commits unfetchable
33 2014-12-05 10:35:05 <sipa> it still takes... hours, i think?
34 2014-12-05 10:35:18 <sipa> i don't think i have ever been able to not access an earlier commit when i tried
35 2014-12-05 10:35:33 <sipa> and that happens fairly frequently when those old commits had comments on them
36 2014-12-05 10:36:10 <wumpus> huh, one that is no longer accessible from the tip? I had to trick github through the API once to add a tag for a no-longer-reachable commit just to be able to fetch it again
37 2014-12-05 10:37:06 <wumpus> I really mean through git, not through the web interface, it stays around in the web interface longer
38 2014-12-05 10:37:26 <sipa> ah
39 2014-12-05 10:47:29 <Luke-Jr> yeah, git has the restrictions on unreachable commits being fetched, itself
40 2014-12-05 10:47:44 <Luke-Jr> as a security feature
41 2014-12-05 10:48:03 <wumpus> oh? I always assumed it was a github thing, as they use an erlang-based custom implementation of git
42 2014-12-05 10:48:19 <wumpus> but I must say I've never tried it with vanilla git so you could be right
43 2014-12-05 10:48:27 <Luke-Jr> interesting, I didn't know that
44 2014-12-05 10:49:01 <sipa> as long as you don't git gc (or have it run automatically to reduce storage), all former commits and trees should be accessible, afaik
45 2014-12-05 10:49:10 <Luke-Jr> over the network?
46 2014-12-05 10:49:15 <sipa> ah, no clue
47 2014-12-05 10:49:33 <Luke-Jr> pretty sure git prevents it over the network
48 2014-12-05 10:50:10 <Luke-Jr> obviously that's only git://, not SSH git ;)
49 2014-12-05 10:54:10 <wumpus> hmm I was wrong, they switched away from the erlang git again at some point and use a 'hacked git-daemon', as of 2009 already... https://twitter.com/mojombo/status/1661077910
50 2014-12-05 11:05:50 <b-itcoinssg> why doesn't bitcoind/bitcoin-qt adhere to the number of connections provided in the bitcoin.conf file specifically when the connections<8
51 2014-12-05 11:06:26 <b-itcoinssg> Do I have to override it somewhere else?
52 2014-12-05 11:11:37 <wumpus> it should adhere to that, if not it's probably a bug
53 2014-12-05 11:12:31 <wumpus> maybe try -nolisten so that you'll get no incoming connections
54 2014-12-05 11:12:47 <b-itcoinssg> k
55 2014-12-05 11:40:01 <jtimon> wumpus do you think #5430 can get in before 0.10 ? It is extremely simple
56 2014-12-05 11:43:54 <wumpus> I'll have a look later, going through the issue list now
57 2014-12-05 11:45:19 <Luke-Jr> jtimon: disagree re "if(info.amount != 0)" being more readable, not that it matters much
58 2014-12-05 11:45:30 <Luke-Jr> shouldn't we have a space between "if" and "(" though?
59 2014-12-05 11:51:16 <jtimon> well, the main reason actually is that a CAmount class cannot overload the conditional operator
60 2014-12-05 11:52:42 <jtimon> since a #4067-like patch will not be accepted soon and I plan to maintain it for eternity for several reasons, I'm trying to at least make the patch more readable and maintainable
61 2014-12-05 11:52:45 <Luke-Jr> hm! is that a bug?
62 2014-12-05 11:53:12 <jtimon> no, it is not a bug, it is about making the codebase more flexible
63 2014-12-05 11:53:30 <Luke-Jr> no, I mean that you can't overload it
64 2014-12-05 11:53:46 <wumpus> jtimon: ACK
65 2014-12-05 11:53:47 <jtimon> that's part of C++'s design I think
66 2014-12-05 11:54:13 <Luke-Jr> I would have expected if (a) to be the same as if ((bool)a)
67 2014-12-05 11:54:34 <wumpus> you should be able to overload the (bool) operator, but that's pretty ugly
68 2014-12-05 11:56:08 <Luke-Jr> wumpus: dunno, it seems like asking for bugs to have if (amt) NOT behave the same as if amt was an integer type
69 2014-12-05 11:56:36 <Luke-Jr> even if we prefer !=0 for readability
70 2014-12-05 11:56:44 <wumpus> well it won't even compile
71 2014-12-05 11:56:54 <Luke-Jr> oh
72 2014-12-05 11:57:07 <Luke-Jr> I'm too used to C I guess :p
73 2014-12-05 11:58:17 <jtimon> I like to use if (myObject) rather than if (myObject != NULL), like I do in python, but as said that's not possible in C++ (or I don't know how to do it)
74 2014-12-05 11:58:34 <wumpus> it's certainly possible
75 2014-12-05 12:01:34 <wumpus> something like: operator CAmount::bool() { return isamountzero; }
76 2014-12-05 12:02:51 <wumpus> if you prefer that, I'd rather keep the if(info.amount) as it is
77 2014-12-05 12:04:08 <wumpus> don't agree != 0 is better for readability as-such, and without a coding standard with regard to that it's hard to enforce anyway, and bound to result in lots of pulls that just fudge around how we do comparison
78 2014-12-05 12:05:29 <wumpus> before you know it, someone submits a pull that changes all if(x) to if(x!=0)... :')
79 2014-12-05 12:06:34 <wumpus> because READABILITY... yeah...
80 2014-12-05 12:07:09 <wumpus> the change to src/wallet.h makes sense though
81 2014-12-05 12:07:19 <alfacent> https://bitcointalk.org/index.php?topic=883694.0
82 2014-12-05 12:09:23 <wumpus> alfacent: that relies on encouraging address reuse, something we certianly want to avoid
83 2014-12-05 12:12:27 <jtimon> bool operator()(const TConstantAmount<T>& a) { return a.n != 0; } doesn't seem to be working, not even with if ((info.amount))
84 2014-12-05 12:13:04 <jtimon> another solution would be "if (!!info.amount)" but that's much uglier
85 2014-12-05 12:13:08 <wumpus> bleh
86 2014-12-05 12:13:48 <wumpus> it should simply be: operator bool() { ... }
87 2014-12-05 12:13:54 <wumpus> no need for the extra () or bool
88 2014-12-05 12:14:30 <wumpus> or operator bool() const {} even better
89 2014-12-05 12:14:53 <wumpus> see e.g. https://stackoverflow.com/questions/4600295/what-is-the-meaning-of-operator-bool-const-in-c
90 2014-12-05 12:17:59 <jtimon> ok, I'll update the PR later I have to go now, thanks!
91 2014-12-05 12:32:58 <Luke-Jr> alfacent: that doesn't even make sense, and as wumpus said, addresses are only meant to be used with a single transaction ever
92 2014-12-05 13:10:42 <wumpus> hehe @ #5424, sometimes I start to think apple users and devs rare some kind of religious cult trying to spread their word of praise...
93 2014-12-05 13:12:43 <jgarzik> heh
94 2014-12-05 13:27:59 <Luke-Jr> actually, why does the Mac menubar say "bitcoin-qt"? I'd think it should be "Bitcoin Core" or at least "Bitcoin-Qt"
95 2014-12-05 13:28:13 <wumpus> indeed
96 2014-12-05 13:28:24 <wumpus> no clue where that comes from
97 2014-12-05 14:41:04 <jonasschnelli> Luke-Jr: mac menubar title comes from the application name. Self-Built the binary is named "bitcoin-qt" ... when you run the "official" deployed dmg app it says "Bitcoin-Qt"
98 2014-12-05 14:41:25 <jonasschnelli> The OSX dmg app name should be changed to "Bitcoin Core"
99 2014-12-05 14:41:33 <Luke-Jr> jonasschnelli: why is self-built any differentâ O.o
100 2014-12-05 14:41:42 <Luke-Jr> should have the same result, byte-for-byte
101 2014-12-05 14:41:57 <jonasschnelli> on OS X an application has some metainfos next to the binary it self
102 2014-12-05 14:42:25 <jonasschnelli> Qt loads the application name which can be "overwritten" in the metainfos (info.plist)
103 2014-12-05 14:43:08 <Luke-Jr> oh, so more like .app vs the raw bin
104 2014-12-05 14:47:12 <sipa> wumpus: when do you plan to branch 0.10 off? i think all remaining 0.10 tagged issues are sort-of optional
105 2014-12-05 14:47:29 <wumpus> could be any time, though for the release I really want to wait until Cory is back
106 2014-12-05 14:48:31 <Luke-Jr> #5144 seems overlooked/simple?
107 2014-12-05 14:48:44 <sipa> branching doesn't need to mean rc1 immediately, though it probably makes sense to keep those close together (as you want the greatest possible exposure of the new code once it branches, to avoid having all testing on a new 0.11 master)
108 2014-12-05 14:48:47 <wumpus> though obviously the branch doesn't have to coincide with that
109 2014-12-05 14:48:50 <Luke-Jr> #5334 IMO should get merged too
110 2014-12-05 14:48:55 <wumpus> right
111 2014-12-05 14:48:57 <sipa> looking
112 2014-12-05 14:49:14 <Luke-Jr> #2340 is harmless and IIRC was just waiting on a rebase that occurred
113 2014-12-05 14:49:41 <Luke-Jr> Matt would probably appreciate #5298
114 2014-12-05 14:50:06 <Luke-Jr> #4964 is kinda "meh, why not?" IMO
115 2014-12-05 14:50:16 <wumpus> please don't ask to merge all kinds of last minute stuff
116 2014-12-05 14:50:45 <Luke-Jr> "nah" is a valid answer ;)
117 2014-12-05 14:51:12 <Luke-Jr> I was just going through the list
118 2014-12-05 14:53:50 <sipa> wumpus: i'd like to see 5267 (or alternatively 5368) in
119 2014-12-05 14:54:03 <wumpus> I'm not sure about the pkgtool thing, maybe it's not good yet to include that while things are experimental, but I' leave that to cory...
120 2014-12-05 14:58:32 <Luke-Jr> maybe. cfields did suggest it.
121 2014-12-05 14:58:50 <Luke-Jr> [Thursday, November 20, 2014] [8:38:53 PM] * Luke-Jr ponders whether libbitcoin_consensus should be a USE fla
122 2014-12-05 14:58:52 <Luke-Jr> g for bitcoind or independent
123 2014-12-05 14:58:53 <Luke-Jr> [Thursday, November 20, 2014] [8:39:14 PM] <cfields> Luke-Jr: probably want to hold off until there's a .pc
124 2014-12-05 14:58:55 <Luke-Jr> [Thursday, November 20, 2014] [8:39:17 PM] <cfields> (or add one ;)
125 2014-12-05 15:08:14 <wumpus> sipa: agreed
126 2014-12-05 15:08:43 <wumpus> if there only were'nt two evenly valid, competing implementations it would be much easier :p
127 2014-12-05 15:08:59 <wumpus> I see I've reviewed the other one
128 2014-12-05 15:09:36 <sipa> they've repeatedly cherry-picked commits from eachother
129 2014-12-05 15:09:54 <sipa> the only difference is that gavin's reads the block 100 back from disk, while matt iterates over the whole mempool
130 2014-12-05 15:12:20 <sipa> wumpus: nice issue closing frenzy earlier :)
131 2014-12-05 15:13:14 <andytoshi> was there a big rebase or something of libsecp256k1 recently?
132 2014-12-05 15:13:17 <andytoshi> or just a lot of pulls?
133 2014-12-05 15:13:28 <wumpus> sipa: so I guess gavin's has to do slightly less work, and matt's needs less blocks on disk
134 2014-12-05 15:13:34 <sipa> andytoshi: MANY PULLS :)
135 2014-12-05 15:13:35 <wumpus> sipa: yes, it was long overdue :)
136 2014-12-05 15:13:43 <andytoshi> sipa: hooray :D
137 2014-12-05 15:13:43 <wumpus> andytoshi: secp256k1 is extremely active
138 2014-12-05 15:15:47 <Luke-Jr> ACTION suggests secp256k1 add to #bitcoin-commits too
139 2014-12-05 15:16:13 <sipa> wumpus: i think that iterating over the mempool (which should be in order of magnitude the size of a block, maybe a small factor larger) is probably similar to just even parsing the block from disk
140 2014-12-05 15:16:20 <sipa> wumpus: but i have no numbers
141 2014-12-05 15:17:10 <sipa> andytoshi: several optimizations, several changes to make signing/keygen constant time, reducing dependency on GMP (it's really only used for modular inverses now)
142 2014-12-05 15:17:14 <wumpus> Luke-Jr: re: #2340 I find that one slightly scary, as it makes bitcoin-qt's wallet generate transactions so different from other wallets, re: #5298 as mentioned in that issue we need P2P proxy tests, re: #4964 fine with me, although I still think it is an utility call that can be handled just as well client-side
143 2014-12-05 15:18:58 <wumpus> sipa: well even if everything else is equal, I agree not having to read previous blocks would be better
144 2014-12-05 15:19:49 <Luke-Jr> wumpus: 2340: I'm not sure uniformity in locktime is something wallets really need? as far as reliability, I have had this in production use for everything of mine since 2012
145 2014-12-05 15:20:36 <Luke-Jr> (so "scary" doesn't quite make sense to me for describing it)
146 2014-12-05 15:20:59 <sipa> i think bitcoin-qt's transactions are already pretty distinguishable (fresh change script, low s values in signatures)
147 2014-12-05 15:21:11 <wumpus> Luke-Jr: yes, maybe it's nonsense to find it scary, but no one else merged it either! :p
148 2014-12-05 15:22:19 <Luke-Jr> I figured that was just due to low priority; if we're just talking about risk, IMO that is zero
149 2014-12-05 15:22:44 <wumpus> famous last words :-)
150 2014-12-05 15:22:52 <Luke-Jr> worst case, there's some weird locktime behaviour we're unaware of in the consensus code and the transaction never confirms
151 2014-12-05 15:23:40 <wumpus> but you said you've tested it since 2012? how many transactions have you generated, how did they confirm?
152 2014-12-05 15:23:41 <sipa> i think #2340 is mostly a proof-of-concept that actually doesn't get the benefits yet, but introduces the feature to expose problems with compatibility
153 2014-12-05 15:23:52 <sipa> it sets the locktime 10 blocks in the past
154 2014-12-05 15:23:58 <Luke-Jr> wumpus: and by "production use for everything", I *do* mean millions (possibly billions) of USD worth of Eligius manual payouts
155 2014-12-05 15:24:00 <wumpus> may be better to merge it as first thing after the .10 release
156 2014-12-05 15:24:01 <sipa> it shouldn't matter at all for any actual transactions
157 2014-12-05 15:24:31 <Luke-Jr> as far as transaction count, I'd need to script up something to count them.. I noticed no oddness in their confirmation
158 2014-12-05 15:24:39 <wumpus> Luke-Jr: ok, that's good
159 2014-12-05 15:25:33 <Luke-Jr> do you want me to write up a script to count txs? :p
160 2014-12-05 15:25:42 <wizkid057> your manual payout txns generally confirm immediately
161 2014-12-05 15:25:59 <sipa> if you do, count the average between blockheight and the locktime
162 2014-12-05 15:26:05 <wumpus> no, I don't need an exact count.. .'a lot' is enough
163 2014-12-05 15:27:51 <wumpus> Luke-Jr: ACK on adding secp256k1 commits to #bitcoin-commits
164 2014-12-05 15:29:15 <sipa> andytoshi: but feel free to review the unmerged (or merged!) recent changes
165 2014-12-05 15:29:19 <wizkid057> wumpus: there have been 203 manual payouts for Eligius since block 206485
166 2014-12-05 15:29:28 <wizkid057> if that helps
167 2014-12-05 15:29:57 <sipa> andytoshi: especially if you would know x86_64 assembly...
168 2014-12-05 15:30:28 <Luke-Jr> sipa: FYI, LLVM is more tolerant of inline asm with -no-integrated-as
169 2014-12-05 15:30:36 <Luke-Jr> but that might only work with GNU binutils systems
170 2014-12-05 15:31:52 <sipa> Luke-Jr: i had to convert it all to att syntax, because osx clang does not support intel syntax
171 2014-12-05 15:32:24 <Luke-Jr> sipa: yeah, I'm saying maybe that option would have helped
172 2014-12-05 15:34:00 <sipa> i doubt it; it seems to work fine now
173 2014-12-05 15:37:46 <Luke-Jr> if AT&T syntax is fine, ok. (I just confirmed BFGMiner is using Intel syntax for asm, which is one of the things fixed by -no-integrated-as for LLVM on Linux, but possibly untested on Mac)
174 2014-12-05 16:04:23 <andytoshi> sipa: i will review #123 at least
175 2014-12-05 16:08:13 <sipa> andytoshi: great
176 2014-12-05 16:10:37 <Luke-Jr> btw, is there any way to turn a normal address into a keypool address? <.<
177 2014-12-05 16:11:11 <Luke-Jr> back in 2011, I tried doing vanitygen via getnewaddress looping⦠would be nice to hide those all and let them get used gradually <.<
178 2014-12-05 16:19:27 <wumpus> no official way, but if you don't mind temporarily adding a RPC you could get there by removing the label/metadata (that will hide them) and putting them into the keypool db using WritePool using an index that won't overwrite any existing keypool entries
179 2014-12-05 16:20:10 <Luke-Jr> sounds complicated to the point of being risky :x
180 2014-12-05 16:20:58 <wumpus> it's not *that* risky as you don't touch the key data itself, just metadata, biggest risk is that you'll accidentally reuse an address
181 2014-12-05 16:21:11 <wumpus> but yeah I wouldn't do it unnecessarily either
182 2014-12-05 16:23:08 <Luke-Jr> wumpus: if only you had showed up sooner (the reason it didn't occur to me that it'd be annoying, was because I had no GUI to show the address list :P)
183 2014-12-05 16:24:36 <wumpus> just *hiding* them is easy, the complicated part is putting the keypool back together
184 2014-12-05 16:25:18 <Luke-Jr> yeah, at least if they're on the list, I can just relabel them and use them manually XD
185 2014-12-05 16:25:28 <gmaxwell> Luke-Jr: bleh: they'd all be uncompressed... forget about 'em.
186 2014-12-05 16:25:37 <Luke-Jr> gmaxwell: eek, you're right! :|
187 2014-12-05 16:25:44 <wumpus> CWalletDB::EraseName(...) should do it
188 2014-12-05 16:26:21 <wumpus> (or just CWallet::DelAddressBook, but I don't remember if it checks for receiving addresses)
189 2014-12-05 16:33:17 <gmaxwell> what is with the huge list of commits here: https://github.com/bitcoin/bitcoin/pull/5425 they weren't there before.
190 2014-12-05 16:33:58 <gmaxwell> I wish github changed out from under me in inexpliable ways less often. Does not inspire confidence.
191 2014-12-05 16:34:55 <paveljanik> Looks like sipa merged some commits into his branch?
192 2014-12-05 16:35:03 <paveljanik> or github issue
193 2014-12-05 16:35:24 <kanzure> gmaxwell: to get around that temporarily you may want to ACK specific commit ids (in your ACK message text)....
194 2014-12-05 16:36:14 <sipa> paveljanik: it's a github issue
195 2014-12-05 16:36:20 <sipa> it just pukes on subtree merges
196 2014-12-05 16:36:22 <gmaxwell> kanzure: yes, though without automation to actually check that it matches it's easy for that route to just be security theater. ... and harder to make that automation since the only place that data exists is on github.
197 2014-12-05 16:36:53 <kanzure> wasn't thinking about security, just informational... are ACKs being parsed by something automatically ?
198 2014-12-05 16:37:22 <sipa> no
199 2014-12-05 16:39:59 <gmaxwell> I mean the information isn't really useful if no one notices that its inconsistent. A communication no one reads is as good as not communicating.
200 2014-12-05 20:37:53 <paveljanik> sipa: did you report the issue to github?
201 2014-12-05 21:08:56 <wumpus> after merging a commit with subtree merges, github shows that strange list of commits, only afterwards though (the actual merge is fine, although we use sipa's script for that anyway) so it's harmless
202 2014-12-05 21:12:04 <paveljanik> and is support@github aware of the problem?
203 2014-12-05 21:13:50 <wumpus> no clue
204 2014-12-05 21:17:54 <maraoz> is there a reason we call output scripts "pubkey script" and input scripts "scriptSig" ? I mean, why not call them "input script" and "output script" ?
205 2014-12-05 21:26:42 <harding> maraoz: petertodd has an interesting way of describing the scripts as implementing a generic public-key crypto system. pubkey scripts are generic pubkeys that associate something with a psuedo-identity; signature scripts are generic signatures that prove you are that psuedo-identity.
206 2014-12-05 21:27:48 <harding> So, specifically, pubkey scripts associate bitcoins with a psuedo-identity and signature scripts allow that identity to spend those bitcoins.
207 2014-12-05 21:29:45 <Luke-Jr> harding: that's not really a petertodd thing - pretty sure all developers look at it that way
208 2014-12-05 21:32:24 <maraoz> ahhh, that's a nice explanation. thanks! (I still personally like input script and output script better, more newbie-friendly)
209 2014-12-05 21:33:11 <harding> Luke-Jr: that's quite likely. However, I came around to that line of thinking only after petertodd described it to me, and I don't want to take credit for someone else's ideas.
210 2014-12-05 21:38:02 <Luke-Jr> maraoz: pubkey/signature is IMO more newbie-friendly, in that once the newbie understands it, he understands how Bitcoin works better than otherwise
211 2014-12-05 22:23:36 <koeppelmann> default block reward is close to 0)
212 2014-12-05 22:23:36 <koeppelmann> Hi - I am new here and I just want to ask wether the empty mempool problem has already been discussed. This is a problem to keep in mind if the blocksize limit would be raised in such a way that on average all transaction with fees from the mempool could be included into a block. This would lead to a situation where it is always more profitable to try to fork because there is no incentive to mine on the longest chain (if
213 2014-12-05 22:24:02 <koeppelmann> at least in the first moments after the block is found
214 2014-12-05 22:55:54 <BlueMatt> FSCKing travis...why does it impose so many arbitrary limits?
215 2014-12-05 22:55:59 <BlueMatt> 4mb log file -> failed
216 2014-12-05 22:56:05 <BlueMatt> 10 minutes without log output -> failed
217 2014-12-05 22:56:10 <BlueMatt> 10000 lines of log output -> failed
218 2014-12-05 23:26:00 <lechuga_> sipa: does openssl produce signatures which violate the low S value constraint of BIP62?
219 2014-12-05 23:26:59 <runeks> In the Bitcoin P2P protocol, are new blocks and valid transactions broadcast, as they come in, or do nodes request new transactions and blocks periodically?
220 2014-12-05 23:29:53 <lechuga_> a packet informing peers that you have seen/validated the new tx/block is generally sent out immediately after doing so
221 2014-12-05 23:30:45 <lechuga_> peers can then come back and request the actual data if they need/want to