12017-12-30T00:04:51 *** YellowSphere has joined #bitcoin-core-dev
22017-12-30T00:06:57 *** cheese_ has quit IRC
32017-12-30T00:14:35 *** YellowSphere has quit IRC
42017-12-30T00:17:21 *** jb55 has joined #bitcoin-core-dev
52017-12-30T00:24:15 *** PaulCapestany has quit IRC
62017-12-30T00:26:26 *** PaulCapestany has joined #bitcoin-core-dev
72017-12-30T00:27:28 *** jb55 has quit IRC
82017-12-30T00:29:08 *** PaulCapestany has quit IRC
92017-12-30T00:32:03 *** PaulCapestany has joined #bitcoin-core-dev
102017-12-30T00:35:07 *** promag has joined #bitcoin-core-dev
112017-12-30T00:42:04 *** qwertzlcoatl has joined #bitcoin-core-dev
122017-12-30T00:44:33 *** jb55 has joined #bitcoin-core-dev
132017-12-30T00:54:08 *** Chris_Stewart_5 has joined #bitcoin-core-dev
142017-12-30T00:55:25 *** Victorsueca has quit IRC
152017-12-30T00:56:57 *** Victorsueca has joined #bitcoin-core-dev
162017-12-30T01:02:54 *** promag has quit IRC
172017-12-30T01:16:47 *** synthetic11000 has joined #bitcoin-core-dev
182017-12-30T01:25:14 *** jb55 has quit IRC
192017-12-30T02:02:00 *** belcher has quit IRC
202017-12-30T02:18:08 *** justanotheruser has quit IRC
212017-12-30T02:20:17 *** justanotheruser has joined #bitcoin-core-dev
222017-12-30T02:25:57 *** qwertzlcoatl has quit IRC
232017-12-30T02:30:27 *** Chris_Stewart_5 has quit IRC
242017-12-30T02:30:59 *** dgenr8 has quit IRC
252017-12-30T02:51:32 *** jb55 has joined #bitcoin-core-dev
262017-12-30T03:01:13 *** xiedeacc has joined #bitcoin-core-dev
272017-12-30T03:03:11 *** synthetic11000 has left #bitcoin-core-dev
282017-12-30T03:10:02 *** Randolf has joined #bitcoin-core-dev
292017-12-30T03:21:09 *** ^darkfire^ is now known as ^shartshow^
302017-12-30T03:41:25 *** xiedeacc has quit IRC
312017-12-30T04:33:20 *** Kozuch has quit IRC
322017-12-30T04:41:18 *** ^shartshow^ is now known as ^kleptocoin^
332017-12-30T04:45:30 *** ^kleptocoin^ is now known as alternativeminer
342017-12-30T04:49:44 *** alternativeminer is now known as netpilot
352017-12-30T05:05:45 *** netpilot is now known as ^ice9
362017-12-30T05:08:29 *** justan0theruser has joined #bitcoin-core-dev
372017-12-30T05:10:35 *** justanotheruser has quit IRC
382017-12-30T05:13:44 *** CubicEarths has quit IRC
392017-12-30T05:14:04 *** ^ice9 is now known as autopilot
402017-12-30T05:14:19 *** CubicEarths has joined #bitcoin-core-dev
412017-12-30T05:18:27 *** CubicEarths has quit IRC
422017-12-30T05:22:14 *** CubicEarths has joined #bitcoin-core-dev
432017-12-30T05:26:44 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d9fdac130a5e...a332a7d5a152
442017-12-30T05:26:44 <bitcoin-git> bitcoin/master a3ac767 dongsamb: Fix string concatenation to os.path.join and add exception case
452017-12-30T05:26:45 <bitcoin-git> bitcoin/master a332a7d MarcoFalke: Merge #11291: Fix string concatenation to os.path.join and add exception case...
462017-12-30T05:27:05 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #11291: Fix string concatenation to os.path.join and add exception case (master...Fix-PEP8-warnings) https://github.com/bitcoin/bitcoin/pull/11291
472017-12-30T05:48:28 *** boblee has joined #bitcoin-core-dev
482017-12-30T05:52:07 *** boblee has quit IRC
492017-12-30T05:52:08 *** boblee has joined #bitcoin-core-dev
502017-12-30T06:08:34 *** go1111111 has joined #bitcoin-core-dev
512017-12-30T06:24:54 *** juscamarena has joined #bitcoin-core-dev
522017-12-30T06:28:55 *** xiedeacc has joined #bitcoin-core-dev
532017-12-30T06:30:39 *** juscamar1 has joined #bitcoin-core-dev
542017-12-30T06:30:57 *** juscamarena has quit IRC
552017-12-30T06:32:56 *** meshcollider has quit IRC
562017-12-30T06:46:06 *** juscamar1 has quit IRC
572017-12-30T06:54:35 *** juscamar1 has joined #bitcoin-core-dev
582017-12-30T07:05:09 *** jb55 has quit IRC
592017-12-30T07:20:17 *** soffi has joined #bitcoin-core-dev
602017-12-30T07:49:48 *** CubicEarths has quit IRC
612017-12-30T08:13:35 *** t0adst00l has joined #bitcoin-core-dev
622017-12-30T08:37:04 *** t0adst00l has quit IRC
632017-12-30T08:40:14 *** ghost43 has quit IRC
642017-12-30T08:40:26 *** juscamar1 has quit IRC
652017-12-30T08:40:30 *** ghost43 has joined #bitcoin-core-dev
662017-12-30T08:40:36 *** juscamar1 has joined #bitcoin-core-dev
672017-12-30T08:52:50 *** qrestlove has quit IRC
682017-12-30T08:56:49 *** qrestlove has joined #bitcoin-core-dev
692017-12-30T09:01:53 *** juscamar1 has quit IRC
702017-12-30T09:05:12 *** t0adst00l has joined #bitcoin-core-dev
712017-12-30T09:23:43 *** meshcollider has joined #bitcoin-core-dev
722017-12-30T09:24:11 *** davec has quit IRC
732017-12-30T09:32:10 *** t0adst00l has quit IRC
742017-12-30T09:32:34 *** davec has joined #bitcoin-core-dev
752017-12-30T09:37:07 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a332a7d5a152...efae3663a772
762017-12-30T09:37:07 <bitcoin-git> bitcoin/master 6915f93 Wladimir J. van der Laan: doc: Update OpenBSD build instructions for 6.2...
772017-12-30T09:37:08 <bitcoin-git> bitcoin/master efae366 Wladimir J. van der Laan: Merge #11984: doc: Update OpenBSD build instructions for 6.2 (cont'd)...
782017-12-30T09:37:38 <bitcoin-git> [bitcoin] laanwj closed pull request #11984: doc: Update OpenBSD build instructions for 6.2 (cont'd) (master...2017_12_openbsd_build_update) https://github.com/bitcoin/bitcoin/pull/11984
792017-12-30T09:38:13 *** fanquake has joined #bitcoin-core-dev
802017-12-30T09:40:41 <fanquake> wumpus Good idea. The other two were more gui based anyways.
812017-12-30T09:44:35 *** AaronvanW has quit IRC
822017-12-30T09:51:05 <wumpus> MarcoFalke: oh no you didn't just #12026
832017-12-30T09:51:06 <gribble> https://github.com/bitcoin/bitcoin/issues/12026 | Prepare version scheme for 17.0 release by MarcoFalke · Pull Request #12026 · bitcoin/bitcoin · GitHub
842017-12-30T09:51:32 <wumpus> as if there aren't enough virtually irrelevant issues to fight about yet
852017-12-30T09:52:34 <fanquake> I tried, and failed, to redirect traffic back to where the actual discussion has already happened.
862017-12-30T09:52:48 <wumpus> yes now all the armchair devs are coming out of the woodwork
872017-12-30T09:53:04 <wumpus> my versionining scheme is better than your versioining scheme!
882017-12-30T09:53:22 <luke-jr> seems pointless to have a PR for such a trivial thing without consensus to do it
892017-12-30T09:53:25 <fanquake> Red, white or blue paint?
902017-12-30T09:53:34 <wumpus> and people reading way too much in it
912017-12-30T09:53:39 <wumpus> OH SO BITCOIN ISN'T BETA ANYMORE?
922017-12-30T09:53:41 <wumpus> whieeeee
932017-12-30T09:53:59 <fanquake> I assume this is the point everyone has been waiting for so that can actually deploy to production...
942017-12-30T09:54:12 <wumpus> unleash the monster
952017-12-30T09:54:20 <sipa> i tried to clarify things on twitter a bit... but i may have made things worse :(
962017-12-30T09:54:40 <aj> that got linked on reddit even https://www.reddit.com/r/Bitcoin/comments/7mp7md/bitcoin_core_is_preparing_planning_the_version/
972017-12-30T09:54:58 <wumpus> yes he added a disclaimer "EDIT: Obviously, this does not mean Bitcoin Core is all of a sudden less experimental than before.". Of course, such people don't read disclaimers.
982017-12-30T09:55:05 <fanquake> "While these types of posts do not get the attention they deserve" . No, they get far more attention than they deserve.
992017-12-30T09:55:16 <wumpus> they get attention
1002017-12-30T09:55:20 <wumpus> while we still don't have segwit wallet
1012017-12-30T09:55:29 <sipa> https://twitter.com/pwuille/status/946689982034477056
1022017-12-30T09:55:44 <fanquake> sipa clearly you
1032017-12-30T09:56:04 <fanquake> 've done something wrong, thats the first tweet of yours I've seen with < 1000 hearts..
1042017-12-30T09:56:18 <sipa> fanquake: it's buried deep in a thread
1052017-12-30T09:56:26 <sipa> but hey i got some nice in-person review from BlueMatt yesterday on #11304
1062017-12-30T09:56:27 <gribble> https://github.com/bitcoin/bitcoin/issues/11304 | ÐообÑе не Ð¿Ð¾Ð½Ð¸Ð¼Ð°Ñ ÐºÐ°Ðº ÑÑÑановиÑÑ Ð½Ð° linux kali · Issue #11304 · bitcoin/bitcoin · GitHub
1072017-12-30T09:56:32 <sipa> no, not on that
1082017-12-30T09:56:35 <luke-jr> hmm, I kinda like that comment suggesting we aim for 1.0 at the 10 year anniversary :p
1092017-12-30T09:56:40 <wumpus> I mean all these people are clamoring for TRADE SIGNALS
1102017-12-30T09:56:44 <wumpus> this has nothing to do with development
1112017-12-30T09:56:59 <wumpus> this is more like with alts, where the devs make a big announcement and the price is pumped
1122017-12-30T09:57:07 <sipa> but hey i got some nice in-person review from BlueMatt yesterday on #11403
1132017-12-30T09:57:12 <gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
1142017-12-30T09:57:28 <wumpus> that's why they want the version number to bump. THey won't even be running bitcoin core, most probably.
1152017-12-30T09:57:59 <fanquake> Better send some anti signal
1162017-12-30T09:58:18 <sipa> how about we change the versioning scheme to 0.0.17?
1172017-12-30T09:58:21 * sipa hides
1182017-12-30T09:58:22 <luke-jr> lol
1192017-12-30T09:58:35 <aj> release 18.0 without telling anyone whether it's year based or not
1202017-12-30T09:58:40 <sipa> i can make the same argument
1212017-12-30T09:59:01 <sipa> "I support dropping the final 0 in 0.17.0.0, as it's clearly redundant"
1222017-12-30T09:59:16 <fanquake> The only thing I don't want to see are named releases.
1232017-12-30T09:59:19 <wumpus> it's just pointless to argue about, sucking up developer time in arguments
1242017-12-30T09:59:23 <aj> sipa: any summary on the in-person review?
1252017-12-30T09:59:31 <wumpus> fanquake: lol
1262017-12-30T09:59:31 *** qrestlove has quit IRC
1272017-12-30T09:59:51 *** jezeba has joined #bitcoin-core-dev
1282017-12-30T09:59:51 <fanquake> I thought everyone at that conference was too busy hitting that red button
1292017-12-30T09:59:54 <wumpus> fanquake: nonono I think I"ve read at least one post proposing those, even
1302017-12-30T09:59:56 <sipa> aj: i learned that some of BlueMatt's concerns were legitimate; BlueMatt learned that some of his concerns weren't :)
1312017-12-30T10:00:06 <luke-jr> let's name the next release "fanquake"
1322017-12-30T10:00:13 <fanquake> please no
1332017-12-30T10:00:18 <luke-jr> :p
1342017-12-30T10:00:24 <sipa> (all relating to import/downgrade/restore scenarios, and nothing that a rescan with a later version can't fix)
1352017-12-30T10:00:41 <midnightmagic> "complaints to fanquake"
1362017-12-30T10:01:05 <sipa> wumpus: i think we should just do it, or not. i don't care either way - but letting it linger won't help
1372017-12-30T10:01:16 <midnightmagic> and then just replace the name with someone random in this channel each point release
1382017-12-30T10:01:31 <wumpus> sipa: I won't touch it with a 10 foot pole
1392017-12-30T10:01:44 <sipa> fair
1402017-12-30T10:01:52 * sipa hands wumpus the 11 foot pole
1412017-12-30T10:02:04 <wumpus> I'm not going to NACK it, but let me be clear I think it's ill-advised
1422017-12-30T10:02:08 <aj> wumpus: btw, i've been poking at #11862 more. if we make it so 'port=1234' only affects mainnet and you have to say '[regtest]\nport=1234' to change the regtest port (or rpcport, etc) i thought it might make sense to allow you to just say 'regtest=1 \n port=1234' without having to have the [regtest] section header. but there's a whole bunch of corner cases there that make it seem not worthwhile (and
1432017-12-30T10:02:08 <aj> possibly too hard to document accurately)
1442017-12-30T10:02:09 <gribble> https://github.com/bitcoin/bitcoin/issues/11862 | [concept] Network specific conf sections by ajtowns · Pull Request #11862 · bitcoin/bitcoin · GitHub
1452017-12-30T10:02:22 <fanquake> Then lets just close everything, and worry about segwit wallet
1462017-12-30T10:02:45 *** Giszmo has quit IRC
1472017-12-30T10:02:48 <wumpus> aj: I don't think that's worth it, no
1482017-12-30T10:02:54 <aj> sipa: that sounds positive!
1492017-12-30T10:03:13 <wumpus> aj: I'd prefer to make the logic simple but flexible
1502017-12-30T10:03:25 <wumpus> aj: adding [regtest] header is simple to understand and parse
1512017-12-30T10:03:31 <sipa> aj: i'll comment on the PR when i adress the things
1522017-12-30T10:03:59 <sipa> aj: wasn't there also support for regtest.port=1234 ?
1532017-12-30T10:04:16 <aj> sipa: yes, [regtest] foo=bar and regtest.foo=bar are equivalent in boost config parsing
1542017-12-30T10:04:28 <wumpus> aj: most people won't even be using the test network and regtest, adding corner cases here just adds corner cases for corner cases' sake
1552017-12-30T10:04:38 <wumpus> aj: if it comes for free with boost, fair enough
1562017-12-30T10:05:58 <fanquake> wumpus re boost #12027 is a pretty trivial merge that removes some confusion errors from the brew install log
1572017-12-30T10:05:59 <gribble> https://github.com/bitcoin/bitcoin/issues/12027 | [Docs] Remove boost --c++ flag from osx build instructions by fernandezpablo85 · Pull Request #12027 · bitcoin/bitcoin · GitHub
1582017-12-30T10:06:11 <fanquake> commit message just need ammending
1592017-12-30T10:06:22 <aj> wumpus: the other issue that i'm hitting now is that regtest.datadir doesn't work -- datadir is decided before the chain is selected. would be a bit more invasive (but ultimately simplify things a bit) to change that
1602017-12-30T10:07:02 <wumpus> aj: yes there are tons of edge cases around precedence and order of options, with regard to the -datadir and -conf and -regtest/-testnet options
1612017-12-30T10:07:12 <wumpus> aj: let's try to keep the order there the same
1622017-12-30T10:07:50 <wumpus> aj: at least don't add that to the scope of the PR
1632017-12-30T10:08:17 <aj> wumpus: okay, less invasive it is
1642017-12-30T10:08:18 <wumpus> the current order works pretty well, you can use -conf to select a configuration and set a datadir in there, as well as a netwerk
1652017-12-30T10:08:36 <wumpus> you can use -datadir to select a datadir and use the bitcoin.conf inside, which can also set a network
1662017-12-30T10:08:42 <wumpus> (this is used for the tests)
1672017-12-30T10:09:02 *** d9b4bef9 has quit IRC
1682017-12-30T10:09:38 <wumpus> less invasive is better certainly as long as we don't have full test coverage for these edge cases
1692017-12-30T10:10:07 <wumpus> also it would mean all kinds of scenarios would need to be re-thought
1702017-12-30T10:10:48 <aj> wumpus: oh, any idea which options to make network-specific? i've got -wallet and -addnode, and https://github.com/bitcoin/bitcoin/pull/11741#issuecomment-347458820 suggested -port -bind -rpcport and -rpcbind ?
1712017-12-30T10:11:01 <wumpus> fanquake: hehe closing all PRs but segwit wallet (and related things) would make a point, at least
1722017-12-30T10:11:39 *** qrestlove has joined #bitcoin-core-dev
1732017-12-30T10:11:47 <wumpus> aj: I think that's a good set to start with. THe general credo would be: all options that have different default based on network.
1742017-12-30T10:12:01 <aj> oh good point
1752017-12-30T10:12:04 <fanquake> If GitHub had better tools for managing project "workflow" we could actually make something like that happen.
1762017-12-30T10:13:01 *** jezeba has quit IRC
1772017-12-30T10:18:54 *** finkan has joined #bitcoin-core-dev
1782017-12-30T10:19:12 *** Giszmo has joined #bitcoin-core-dev
1792017-12-30T10:21:27 <luke-jr> wumpus: not a positive point, IMO
1802017-12-30T10:21:56 <wumpus> luke-jr: hm?
1812017-12-30T10:23:02 <luke-jr> wumpus: the only point I could see from closing all PRs besides a few, would be that some people are trying to force the priority for other people.
1822017-12-30T10:23:31 <aj> fanquake: it's got tools you can use to make tools to manage workflows at least? did you see https://gist.github.com/ajtowns/bdc91590471559b5c73682fdfa712b15 ?
1832017-12-30T10:23:53 <wumpus> luke-jr: I was just kidding
1842017-12-30T10:25:01 <fanquake> aj No, will read through it
1852017-12-30T10:26:13 *** m0d has joined #bitcoin-core-dev
1862017-12-30T10:27:39 <wumpus> luke-jr: I think it'd be an awful idea too
1872017-12-30T10:35:58 *** Jaybaby has joined #bitcoin-core-dev
1882017-12-30T10:44:35 <midnightmagic> you could hire a temporary transition person whose primary job would be to close all PRs, then act as a strawman you could punch the crap out of while pretending to get rid of them..
1892017-12-30T10:47:22 <wumpus> at some point the project will outgrow the github PR way of working in any case
1902017-12-30T10:47:41 <wumpus> e.g. stuff like http://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html
1912017-12-30T10:47:47 <wumpus> but we're not there yet
1922017-12-30T10:48:02 <wumpus> I think
1932017-12-30T10:51:39 <bitcoin-git> [bitcoin] vajdaz opened pull request #12054: Minimize to tray functionality only on Windows (master...win-only-tray) https://github.com/bitcoin/bitcoin/pull/12054
1942017-12-30T10:57:04 <MarcoFalke> wumpus: Yeah, sorry about that. Someone brought it to twitter, which lead to the fights. I assumed that step was uncontroversial. But meh, better close it.
1952017-12-30T10:57:15 <wumpus> MarcoFalke: no, let's merge it
1962017-12-30T10:57:33 <wumpus> MarcoFalke: just get it over with
1972017-12-30T10:57:52 <meshcollider> then people can stop arguing about it yeah
1982017-12-30T10:58:02 <wumpus> I'm sorry for contributing to the pain around it
1992017-12-30T10:58:24 <luke-jr> merge what?
2002017-12-30T10:58:41 <wumpus> #12026
2012017-12-30T10:58:43 <gribble> https://github.com/bitcoin/bitcoin/issues/12026 | Prepare version scheme for 17.0 release by MarcoFalke · Pull Request #12026 · bitcoin/bitcoin · GitHub
2022017-12-30T10:58:46 <luke-jr> no, that's stupid
2032017-12-30T10:59:15 *** Ylbam has joined #bitcoin-core-dev
2042017-12-30T11:00:29 <wumpus> I mean it's clear that no one likes the current versioning scheme, and people want to change it, we're never going to agree on what to change it to, so let's go with this simple change.
2052017-12-30T11:00:50 *** finkan has quit IRC
2062017-12-30T11:00:57 <luke-jr> the current one is fine, and certainly much better than that
2072017-12-30T11:01:11 <wumpus> sigh
2082017-12-30T11:01:48 <meshcollider> its really just a number, who cares, its not symbolic of any major change, its just to save the stupid 0 at the front all the time
2092017-12-30T11:02:01 <wumpus> yep
2102017-12-30T11:02:30 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/efae3663a772...db7eba6169b6
2112017-12-30T11:02:30 <bitcoin-git> bitcoin/master faa7ecf MarcoFalke: Prepare version scheme for 17.0 release
2122017-12-30T11:02:31 <bitcoin-git> bitcoin/master db7eba6 Wladimir J. van der Laan: Merge #12026: Prepare version scheme for 17.0 release...
2132017-12-30T11:02:34 <luke-jr> meshcollider: the 0 at the front indicates the current immaturity of the project
2142017-12-30T11:02:49 <luke-jr> when things get to a sensible state, it should become a 1.x.y.z
2152017-12-30T11:02:57 <meshcollider> btw luke-jr I liked your consensus versions page on the wiki
2162017-12-30T11:02:58 <wumpus> luke-jr: no one is making that decision
2172017-12-30T11:03:05 <bitcoin-git> [bitcoin] laanwj closed pull request #12026: Prepare version scheme for 17.0 release (master...Mf1712-version17) https://github.com/bitcoin/bitcoin/pull/12026
2182017-12-30T11:03:13 <wumpus> luke-jr: no one will ever agree whether 'bitcoin is ready'
2192017-12-30T11:03:20 <wumpus> luke-jr: we already get too many fights about that
2202017-12-30T11:03:21 <luke-jr> wumpus: why not?
2212017-12-30T11:03:44 <wumpus> with some people calling it completely useless in current state and others saying it's done don't change it anymore
2222017-12-30T11:03:49 <wumpus> and a whole spectrum in between
2232017-12-30T11:03:56 <meshcollider> wumpus: shouldnt that have waited til after 0.16 branches off
2242017-12-30T11:04:01 <luke-jr> and even if it were true, that's certainly no reason to set it to a 16-past-readiness stage when it clearly isn't
2252017-12-30T11:04:23 <sipa> wumpus: that wasn't intended to be merged now...
2262017-12-30T11:05:18 <sipa> (the PR also changes the number from 15 to 16)
2272017-12-30T11:05:20 <wumpus> there is no readyness stage, there won't be no readyness stage
2282017-12-30T11:05:28 <fanquake> "trades intensify"
2292017-12-30T11:05:48 <wumpus> sipa: oh shit
2302017-12-30T11:06:01 <meshcollider> wumpus: heh but now master will build as 16.99 instead of 0.15.99
2312017-12-30T11:06:21 <meshcollider> we skipped 0.16 release, segwit wallet is now 0.17 ;)
2322017-12-30T11:06:38 <sipa> meshcollider: no, 17.0
2332017-12-30T11:07:11 *** lvmbdv has quit IRC
2342017-12-30T11:07:18 <luke-jr> wumpus: the only reason to drop the 0 is for the same marketting/pumping nonsense you were denouncing earlier
2352017-12-30T11:07:22 <meshcollider> sipa: oops, yes lol
2362017-12-30T11:07:49 <wumpus> luke-jr: which no one agreed to at the time
2372017-12-30T11:08:21 <wumpus> going to force-push to previous master
2382017-12-30T11:08:24 <luke-jr> â
2392017-12-30T11:09:11 <MarcoFalke> s/16/15/ && git commit
2402017-12-30T11:09:43 <luke-jr> wumpus: so why merge pumping nonsense just because nobody explicitly agreed in the last 2 hours?
2412017-12-30T11:10:15 <sipa> it's just dropping a stupid zero that has no meaning
2422017-12-30T11:10:58 <sipa> yes, some people will misinterpreted as sign
2432017-12-30T11:10:59 <bitcoin-git> [bitcoin] laanwj force-pushed master from db7eba6 to efae366: https://github.com/bitcoin/bitcoin/commits/master
2442017-12-30T11:11:04 <luke-jr> sipa: it has meaning
2452017-12-30T11:11:12 <sipa> the alternative is that we never get rid of the 0
2462017-12-30T11:11:28 <wumpus> MarcoFalke: sorry for the inconvenience, please open a new PR
2472017-12-30T11:11:30 *** sengehest has joined #bitcoin-core-dev
2482017-12-30T11:11:33 <luke-jr> we get rid of the 0 when it's reasonable to bump to 1.0..
2492017-12-30T11:11:48 <MarcoFalke> wumpus: No rush. Can wait until next year
2502017-12-30T11:11:51 <luke-jr> like any other sane versioning
2512017-12-30T11:11:55 <sipa> luke-jr: the whole point is that there is no "reasonable" time for that
2522017-12-30T11:11:58 <meshcollider> luke-jr: there will be arguments whenever anyone suggests that though
2532017-12-30T11:12:00 <luke-jr> sipa: but there is
2542017-12-30T11:12:01 <wumpus> MarcoFalke: I think it has to be done now
2552017-12-30T11:12:01 <sipa> we have date based releades
2562017-12-30T11:12:21 <wumpus> MarcoFalke: either we do it, or we never do it, I think there's a good point to not let this linger
2572017-12-30T11:12:30 <meshcollider> MarcoFalke: next year is in less than 24 hours in NZ ;)
2582017-12-30T11:12:38 <sipa> i just had a twitter fight with someone who assumed that bitcoin core could not be "ready" until it integrated lightning
2592017-12-30T11:12:49 <luke-jr> even if there may be arguments when it's reasonable, it clearly ISN'T reasonable TODAY
2602017-12-30T11:12:50 <meshcollider> sipa: heh yep I saw that
2612017-12-30T11:13:04 <sipa> luke-jr: it's as reasonable today as it will ever b
2622017-12-30T11:13:20 <sipa> everyone has different requirements for ready, and no software is ever finished
2632017-12-30T11:13:28 <luke-jr> sipa: today it's often that users get transactions stuck and beyond simple recovery; that's not 1.0 quality
2642017-12-30T11:13:39 <luke-jr> today we have no way to restore wallet backups
2652017-12-30T11:13:42 *** juscamar1 has joined #bitcoin-core-dev
2662017-12-30T11:13:42 <wumpus> luke-jr: that will not improve from one day to another
2672017-12-30T11:13:50 <luke-jr> today we have no simple way to automate safe backups
2682017-12-30T11:13:50 <wumpus> luke-jr: there is not one *point* at which that will all be true
2692017-12-30T11:13:58 <sipa> and then there will be another issue
2702017-12-30T11:14:05 <sipa> no software is ever perfect
2712017-12-30T11:14:15 <wumpus> and no one will decide on that, no one wil stake their reputation on 'bitcoin is 1.0 quality now'
2722017-12-30T11:14:19 <luke-jr> point is that today, Core is not usable by a normal person
2732017-12-30T11:14:20 <wumpus> sipa: indeed
2742017-12-30T11:14:26 <wumpus> define 'normal person'
2752017-12-30T11:14:30 <sipa> luke-jr: sure
2762017-12-30T11:14:35 <sipa> totally agree
2772017-12-30T11:14:45 <sipa> it's also not the right choice for many
2782017-12-30T11:14:45 <wumpus> will it ever be usable by everyone? I don't think so
2792017-12-30T11:14:46 <luke-jr> wumpus: pick a random person off the street
2802017-12-30T11:14:52 <wumpus> that's not a requirement
2812017-12-30T11:15:24 <wumpus> you're just making up things now. Can a random person from the street program the linux kernel directly?
2822017-12-30T11:15:35 <luke-jr> we're not talking about programming
2832017-12-30T11:15:38 <luke-jr> we're talking about usage
2842017-12-30T11:15:39 <wumpus> bitcoin core is just the infrastructre
2852017-12-30T11:15:46 <sipa> would you argue that FPFA designer software cannot be 1.0 before a random person on the street can use it?
2862017-12-30T11:15:49 <luke-jr> random person off the street can certainly boot and use a Linux LiveCD
2872017-12-30T11:15:51 <wumpus> there is tons of software aimed at providing better ui and whatnot
2882017-12-30T11:15:59 <wumpus> sipa: exactly.
2892017-12-30T11:16:01 <sipa> i think it's more than infrastructure
2902017-12-30T11:16:12 <luke-jr> Bitcoin Core is an end-user application, not a developer application
2912017-12-30T11:16:17 <sipa> but it's not for everyone
2922017-12-30T11:16:20 <wumpus> luke-jr: then what is RPC for?
2932017-12-30T11:16:27 <luke-jr> if nearly everyone doesn't use a full node, Bitcoin doesn't work
2942017-12-30T11:16:32 <luke-jr> wumpus: RPC isn't all of Core
2952017-12-30T11:16:48 <luke-jr> I'd have no problem with calling bitcoind >=1.0
2962017-12-30T11:16:50 <sipa> yes, so?
2972017-12-30T11:16:51 <wumpus> I'm really so tired of this
2982017-12-30T11:17:26 <wumpus> sure, let's version bitcoind separately... that will make things easier
2992017-12-30T11:18:01 <luke-jr> there's always the "don't fix what isn't broken" option
3002017-12-30T11:18:21 *** juscamar1 has quit IRC
3012017-12-30T11:18:52 <sipa> the 0 in front is redundant at best, and confusing at worst
3022017-12-30T11:20:34 <luke-jr> strongly disagree. it has a meaning and a purpose
3032017-12-30T11:20:44 <wumpus> no, it has no purpose
3042017-12-30T11:21:06 <wumpus> it will never be increased
3052017-12-30T11:21:16 <meshcollider> and the only ones who would really understand the "meaning and purpose" of a version number in general are other developers... no end user will read this deeply into it
3062017-12-30T11:21:25 <luke-jr> you're talking about increasing it NOW, so that argument makes no sense
3072017-12-30T11:21:32 <wumpus> we're just removing the initial 0
3082017-12-30T11:21:37 <wumpus> not *increasing* anything
3092017-12-30T11:22:24 <meshcollider> because we actually refer to the second number as the "major" version number, what is the 0 even called?
3102017-12-30T11:22:37 <meshcollider> the supermajor version number
3112017-12-30T11:22:43 <sipa> "the zero"
3122017-12-30T11:23:08 <wumpus> +1 for "the zero"
3132017-12-30T11:23:18 <luke-jr> who refers to the second as "major"? that'd be incorrect terminology
3142017-12-30T11:23:23 <wumpus> we all do
3152017-12-30T11:23:24 <sipa> everyone
3162017-12-30T11:23:26 <wumpus> except for you, maybe
3172017-12-30T11:23:28 <sipa> seriously.
3182017-12-30T11:23:35 <sipa> we have major releases every 6 months
3192017-12-30T11:23:41 <wumpus> yes
3202017-12-30T11:23:45 <sipa> minor releases for bigfixes and softforks
3212017-12-30T11:24:12 <sipa> i like bigfixes and i cannot lie
3222017-12-30T11:24:21 <meshcollider> e.g. quote from #11449 "Like for previous major releases I've added 6 months to the previous release schedule"
3232017-12-30T11:24:22 <gribble> https://github.com/bitcoin/bitcoin/issues/11449 | Release schedule for 0.16.0 · Issue #11449 · bitcoin/bitcoin · GitHub
3242017-12-30T11:24:57 <luke-jr> bugfixes aren't minor releases in normal versioning
3252017-12-30T11:24:59 *** cplusboi has joined #bitcoin-core-dev
3262017-12-30T11:25:18 <meshcollider> sipa: lol
3272017-12-30T11:25:47 <wumpus> we've always used that terminology
3282017-12-30T11:26:03 <sipa> luke-jr: yet that is how we've all been referring to it
3292017-12-30T11:26:06 <wumpus> so that matches better withremoving the 0
3302017-12-30T11:27:17 <meshcollider> we'll stick with the 6-monthly release schedule though won't we, rather than converting fully to semver?
3312017-12-30T11:28:01 <wumpus> what, you want to change the release schedule too now?
3322017-12-30T11:28:18 <meshcollider> heh no that's what I'm checking
3332017-12-30T11:28:38 <wumpus> oh right, sorry
3342017-12-30T11:28:52 <wumpus> yes, I think it makes sense to stick to that, it has worked pretty well
3352017-12-30T11:29:52 <wumpus> we don't need to change everything around just because a few people (most not even involved with the project) are screaming
3362017-12-30T11:30:20 <meshcollider> Agreed, it's just that semver has come up in discussion over these version numbers quite a lot, so people might expect us to stick to it more strongly now
3372017-12-30T11:30:39 <wumpus> what in 'semver' rules out a 6 month release schedule anyway?
3382017-12-30T11:30:45 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #12055: Prepare version scheme for upcoming release [take 2] (master...Mf1712-versionDropRedundantZero) https://github.com/bitcoin/bitcoin/pull/12055
3392017-12-30T11:31:28 <meshcollider> semver would only require a major release each time a breaking API change occurred, so you'd be limited to merging a breaking change once every 6 months ;)
3402017-12-30T11:31:44 <wumpus> don't most open source projects have a more or less tick-tock release schedule?
3412017-12-30T11:32:07 <wumpus> what is 'breaking' in this context?
3422017-12-30T11:32:12 <fanquake> I don't think we really gain much by trying to stick to some arbitrary requirements. It would seem like core isn't exactly like "other" projects.
3432017-12-30T11:32:18 <wumpus> changing RPC interface?
3442017-12-30T11:32:25 <wumpus> well, every major version wil qualify for that one :)
3452017-12-30T11:32:27 <meshcollider> wumpus: yes, external API
3462017-12-30T11:32:48 <wumpus> even if there are no P2P and consensus changes
3472017-12-30T11:33:08 <meshcollider> wumpus: internal changes do not matter for semver, they are patch releases. Minor changes are backwards compatible extensions of the API, and major are breaking changes to the API (no matter how small, technically)
3482017-12-30T11:33:30 <wumpus> ok...
3492017-12-30T11:33:34 <fanquake> To think about this a bit differently. What would the release schedule look like if core github had 2 or 3x the contributors for review and code that it currently has?
3502017-12-30T11:33:54 <wumpus> it might be possible to do more frequent releases
3512017-12-30T11:34:02 <wumpus> e.g. 3 month schedule instead of 6
3522017-12-30T11:34:39 <luke-jr> meshcollider: SemVer is not exclusively about interfaces.. any new functionality warrants a minor bump
3532017-12-30T11:35:19 <wumpus> but still I think the only sane way to do releases is to have them time based
3542017-12-30T11:35:32 <luke-jr> wumpus: I think everyone likes thaat
3552017-12-30T11:36:01 <fanquake> I agree, and I think that will become even more "likeable" over time
3562017-12-30T11:36:03 <luke-jr> wumpus: doing SemVer right would simply mean we'd go from 1.0 to 1.1 if we were backward compatible, and to 2.0 if breaking compatibility
3572017-12-30T11:36:14 <luke-jr> nothing to do with the schedule
3582017-12-30T11:36:16 <meshcollider> luke-jr: It *may* increase minor but not *must*
3592017-12-30T11:36:30 <luke-jr> meshcollider: patch-level increases must only be fixes, though\
3602017-12-30T11:36:35 <wumpus> luke-jr: but breaking *what* interface? we have many interfaces to contend with, for semver we'd have to define what interfaces count and which do not
3612017-12-30T11:36:37 <fanquake> Longer term releases only somethimes "suck" now because big new features can get delayed.
3622017-12-30T11:37:01 <luke-jr> wumpus: the root of this problem is that we haven't modularised yet (which is yet another reason to stick to 0.x)
3632017-12-30T11:37:03 <MarcoFalke> In the longer term, we need versions for RPC, wallet, gui, etc anyway
3642017-12-30T11:37:08 <meshcollider> yeah trying to version core as a whole is too unwieldy tbh
3652017-12-30T11:37:11 <MarcoFalke> That has nothing to do with Bitcoin Core version
3662017-12-30T11:37:15 <luke-jr> wumpus: once modularised, each component can have its own version, which makes things a lot more obvious
3672017-12-30T11:37:19 <wumpus> fanquake: yes, indeed, that's the drawback of the long duration between releases, on the other hand it makes sure things are pretty well tested on mater usually before they end up in a relesae
3682017-12-30T11:37:20 <meshcollider> indeed
3692017-12-30T11:37:29 <luke-jr> MarcoFalke: it's harder to go backward
3702017-12-30T11:37:58 <wumpus> we have a wallet version, and network protocol version, but yes no RPC api version. I agree those are separate from the software proejct version.
3712017-12-30T11:38:08 <aj> sipa: hmm. "i like bugfixes and i cannot lie: your other branches don't compile. 'cause when a patch comes in and claims it make it run fast and the travis checks pass, it gets merged"
3722017-12-30T11:38:09 <wumpus> this is also why I closed the PR adding the bitcoin core version to libconsensus pc
3732017-12-30T11:38:32 <wumpus> libconsensus should probably be versioned differently
3742017-12-30T11:38:53 <meshcollider> yes libconsensus should definitely follow semver because it is a library
3752017-12-30T11:39:03 <wumpus> yep
3762017-12-30T11:39:08 <wumpus> for libraries it makes perfect sense
3772017-12-30T11:39:21 <wumpus> for the rest it's just useless splitting hairs
3782017-12-30T11:40:19 <sipa> aj: haha
3792017-12-30T11:45:07 <luke-jr> at least the "drop the leading zero" approach enables me to just ignore it and keep using a leading zero. ;)
3802017-12-30T11:46:33 <meshcollider> Instead of dropping the zero, let's just rename _CLIENT_VERSION_MAJOR to _CLIENT_VERSION_THE_ZERO then ;)
3812017-12-30T11:46:39 <luke-jr> (and eventually the project can revert it when we're ready to get to a real 1.0)
3822017-12-30T11:54:01 <zelest> o/
3832017-12-30T11:54:10 <echeveria> at some point soon there'll be pretty good justification for dislodging the wallet from bitcoin core.
3842017-12-30T11:54:28 <echeveria> it's almost unusable as a wallet now, and I'm pretty tolerant of bad user experiences.
3852017-12-30T11:54:40 <sipa> how so?
3862017-12-30T11:54:44 <wumpus> it's pretty usable as a wallet IMO
3872017-12-30T11:55:30 <luke-jr> I find it very usable, but I'm admittedly not an ordinary user and don't use it like an ordinary user probably would want to
3882017-12-30T11:55:34 <wumpus> and as said, a full node without a wallet is pretty useless, unless you have other, better wallet to interface with it, which doesn't exist at the moment
3892017-12-30T11:56:10 <echeveria> it's by far the slowest, highest resource usage piece of software around. I can either suffer it destroying my battery life and bandwidth, or wait for it to catch up a week or two of blocks every time I want to use it.
3902017-12-30T11:56:11 <wumpus> there are certainly wallets with better UI, but the privacy/flexibility of bitcoin core's wallet is one of the best
3912017-12-30T11:56:21 <wumpus> that's because you're running a full node
3922017-12-30T11:56:27 <wumpus> that has nothing to do with the wallet
3932017-12-30T11:56:28 <luke-jr> wumpus: lots of other wallets exist
3942017-12-30T11:56:32 <echeveria> note that I said dislodge, not remove.
3952017-12-30T11:56:35 <wumpus> luke-jr: yes, but I don't think they're better
3962017-12-30T11:56:35 <sipa> echeveria: those are inherent to running a full node
3972017-12-30T11:56:42 <wumpus> luke-jr: apart from UI-niceness
3982017-12-30T11:56:43 <luke-jr> I agree
3992017-12-30T11:56:46 <sipa> echeveria: dislodging the wallet from the node won't change that
4002017-12-30T11:56:53 <luke-jr> I also think B-Qt's UI is the nicest ;P
4012017-12-30T11:57:28 <luke-jr> echeveria: that's what it means to use Bitcoin though
4022017-12-30T11:57:54 <wumpus> echeveria: so how would the user experience *concretely* become better with a 'dislodged' wallet?
4032017-12-30T11:58:22 <wumpus> echeveria: apart from the drawback of having to install two programs to have a full node with wallet
4042017-12-30T11:58:41 <wumpus> echeveria: I like modularization but that doesn't really solve the problem of anything being slow or such things
4052017-12-30T11:59:00 <wumpus> echeveria: if you want to improve the UI, just improve the uI
4062017-12-30T11:59:21 <wumpus> that can be done without compounding the issue and extending the scope to reorganizaing the whole project
4072017-12-30T11:59:37 <wumpus> which will never happen in one go
4082017-12-30T11:59:42 <echeveria> there's a lot of scope for being able to remotely connect to a trusted node, without giving it any key responsibility.
4092017-12-30T12:00:05 <sipa> echeveria: fair point
4102017-12-30T12:00:26 <wumpus> you could already do that though, by running a full node and connecting a SPV node to that
4112017-12-30T12:00:27 <luke-jr> need BIPs 150 & 151 to do that reasonably safe
4122017-12-30T12:00:35 <luke-jr> or Tor
4132017-12-30T12:00:37 <wumpus> there are SPV wallets where you can specify a trusted node
4142017-12-30T12:00:42 <echeveria> damn, was chewing as missed my 'inb4 bip37'.
4152017-12-30T12:01:06 <wumpus> in any case, this has been discussed since 2012, patches welcome
4162017-12-30T12:01:11 <echeveria> it takes like, 45 minutes to sync over bip37 now and it shreds the node you're connected to.
4172017-12-30T12:01:20 <echeveria> wumpus: I'm not demanding anything of you, or anyone.
4182017-12-30T12:01:24 <wumpus> more arguing doesn't change anything
4192017-12-30T12:01:26 <wumpus> it never did
4202017-12-30T12:02:05 <wumpus> no one is writing software for you for free, if you want something you need to commit to writing it, or having someone write it, or at least to reviewing the end product (there's a few PRs open that move in that direction)
4212017-12-30T12:02:58 <echeveria> I never asked you to.
4222017-12-30T12:03:25 <echeveria> I was busy making sure bip37 was disabled on my nodes, that's all.
4232017-12-30T12:04:31 <sipa> in any casez i agree it would be a useful evolution to running a full node separately from the wallet
4242017-12-30T12:04:51 <wumpus> yes, exposing bip37 to random nodes was probably not the best idea
4252017-12-30T12:05:01 <wumpus> it's okay for your own whitelisted wallet
4262017-12-30T12:05:03 <sipa> though avoiding the bandwidth issue of syncing isn't magically solved by that
4272017-12-30T12:05:10 <sipa> neutrino is one possibility
4282017-12-30T12:05:15 <wumpus> certainly not....
4292017-12-30T12:05:38 <wumpus> it'd just split the load over two hosts, which could be useful in some cases for some people
4302017-12-30T12:05:55 <wumpus> which was my point that 'dislodging' the wallet is not a panacea
4312017-12-30T12:06:15 <sipa> right
4322017-12-30T12:11:54 <wumpus> for completelness: joinmarket's wallet uses a different approach, it imports its addresses as watch-only addresses into bitcoind
4332017-12-30T12:13:52 <wumpus> this avoids the bandwidth issue between the bitcoind and wallet by doing the scanning server-side
4342017-12-30T12:14:11 *** nibor has quit IRC
4352017-12-30T12:15:26 *** provoostenator has quit IRC
4362017-12-30T12:15:26 <wumpus> after all, if the node is trusted, it doesn't matter that you're leaking your public addresses to it
4372017-12-30T12:15:44 <wumpus> -public
4382017-12-30T12:16:13 *** dabura667 has joined #bitcoin-core-dev
4392017-12-30T12:16:46 *** provoostenator has joined #bitcoin-core-dev
4402017-12-30T12:17:28 <wumpus> that approach also works with a pruning node, without risk that blocks that the client wallet needs have been deleted
4412017-12-30T12:19:13 <wumpus> (which bip37-based, or even full block SPV approaches would suffer from)
4422017-12-30T12:21:15 *** dabura667 has quit IRC
4432017-12-30T12:21:25 <wumpus> SPV wallets of any kind only have to sync from their birthday, so I don't see why '45 minutes to sync over bip37' unless it's an old wallet that hasn't been synced for a long time
4442017-12-30T12:21:58 <wumpus> there is certainly no such requirement for new wallets
4452017-12-30T12:22:23 <echeveria> wumpus: some of them sync from zero, not the birthday.
4462017-12-30T12:23:03 <wumpus> that's unnecessary
4472017-12-30T12:23:30 <echeveria> of course.
4482017-12-30T12:23:52 <wumpus> haven't seen that for a long time anyhow, most of the wallets in active use don't have that problem
4492017-12-30T12:24:48 *** nibor has joined #bitcoin-core-dev
4502017-12-30T12:25:23 <wumpus> anyhow see #10794
4512017-12-30T12:25:26 <gribble> https://github.com/bitcoin/bitcoin/issues/10794 | Add simple light-client mode (RPC only) by jonasschnelli · Pull Request #10794 · bitcoin/bitcoin · GitHub
4522017-12-30T12:25:40 <wumpus> or #9483
4532017-12-30T12:25:43 <gribble> https://github.com/bitcoin/bitcoin/issues/9483 | Complete hybrid full block SPV mode by jonasschnelli · Pull Request #9483 · bitcoin/bitcoin · GitHub
4542017-12-30T12:35:12 *** Evel-Knievel has quit IRC
4552017-12-30T12:45:06 <xiedeacc> can someone provide some information describe segwit in detail and clear?
4562017-12-30T12:45:20 <xiedeacc> website or book
4572017-12-30T12:48:11 *** xiedeacc has quit IRC
4582017-12-30T12:52:39 *** xiedeacc has joined #bitcoin-core-dev
4592017-12-30T12:53:12 <xiedeacc> sorry, computer crashed
4602017-12-30T12:53:42 <sipa> xiedeacc: bip141, bip143, bip144
4612017-12-30T12:53:55 <sipa> for questions, https://bitcoin.stackexchange.com
4622017-12-30T12:54:46 <xiedeacc> thanks~
4632017-12-30T12:55:53 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/efae3663a772...63a4dc10876b
4642017-12-30T12:55:53 <bitcoin-git> bitcoin/master 5ec3eae Pablo Fernandez: remove brew c++ flag...
4652017-12-30T12:55:54 <bitcoin-git> bitcoin/master 63a4dc1 Wladimir J. van der Laan: Merge #12027: [Docs] Remove boost --c++ flag from osx build instructions...
4662017-12-30T12:56:31 <bitcoin-git> [bitcoin] laanwj closed pull request #12027: [Docs] Remove boost --c++ flag from osx build instructions (master...patch-1) https://github.com/bitcoin/bitcoin/pull/12027
4672017-12-30T12:59:50 *** xiedeacc has quit IRC
4682017-12-30T13:09:26 <echeveria> uh
4692017-12-30T13:09:32 <echeveria> 9bf8853b3a823bbfa1e54017ae11a9e1f4d08a854dcce9f24e08114f2c921182
4702017-12-30T13:09:45 <echeveria> well someone just fucked up badly and mined a zero value block.
4712017-12-30T13:11:10 <wumpus> nice, not even the block reward
4722017-12-30T13:12:26 <sturles> Not seen by my node. :-/
4732017-12-30T13:12:40 <echeveria> uh.
4742017-12-30T13:12:46 <echeveria> so blockchain.info is stuck on it.
4752017-12-30T13:13:00 <echeveria> the block hash is 0000000000000000004b27f9ee7ba33d6f048f684aaeb0eea4befd80f1701126.
4762017-12-30T13:13:24 <sturles> Ah, yes. I've got that one.
4772017-12-30T13:13:56 <sturles> Mined by AntPool.
4782017-12-30T13:14:07 <echeveria> why do you say that?
4792017-12-30T13:14:22 <echeveria> there's nothing identifying in the coinbase nonce, and no output address.
4802017-12-30T13:14:33 <sturles> According to https://tradeblock.com/bitcoin
4812017-12-30T13:14:49 <sturles> Could be wrong. I have no idea where they get the information.
4822017-12-30T13:14:59 <sturles> Some pools publish the blocks they find.
4832017-12-30T13:15:30 <sturles> Claims to have found.
4842017-12-30T13:15:52 <echeveria> https://www.antpool.com/poolStats.htm < they're not claiming it
4852017-12-30T13:18:47 <wumpus> the vout script is weird, invalid "RSKBLOCK:\xdd\xbfQz\xdf\x8f\xfdK\xcawQP[9\xc9\x01:\r\x1f\xd4y\xfcN\x90\x1b9\xddW\xb3G\xc6$"
4862017-12-30T13:19:06 <sipa> rootstock?
4872017-12-30T13:20:38 <echeveria> https://github.com/rsksmart/rskj/blob/e03421af1e361114f9e63838b92b008c518c0638/rskj-core/src/main/java/co/rsk/validators/ProofOfWorkRule.java#L94
4882017-12-30T13:20:49 <wumpus> gah, would have been proper to put that in a OP_RETURN instead of just using an invalid script
4892017-12-30T13:20:54 <echeveria> yeah, looks like a rootstock commitment. that was an expensive mistake.
4902017-12-30T13:24:09 <echeveria> they vaporized about $240,000. who the hell writes custom software and doesn't check that they have the payout set to something sane?
4912017-12-30T13:42:51 <provoostenator> Our own little DAO :-)
4922017-12-30T13:43:21 <provoostenator> Wasn't the previous record of not claiming a coinbase reward 1 satoshi?
4932017-12-30T13:44:01 <echeveria> provoostenator: no. https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki
4942017-12-30T13:45:56 <provoostenator> echeveria: do you mean someone didn't implement that BIP in time and lost funds?
4952017-12-30T13:46:33 <echeveria> provoostenator: read the BIP, two duplicate block rewards (2x 50 BTC) don't exist.
4962017-12-30T13:46:50 <provoostenator> I thought they were grandfathered in?
4972017-12-30T13:47:19 <echeveria> they were clobbered. they have the same hash, so spending one spends "both".
4982017-12-30T13:48:00 <provoostenator> Ok, I see, so those blocks are valid, but their coinbases were already worthless. So the BIP prevents miners from wasting money this way (among the other benefits explictly mentioned).
4992017-12-30T13:49:02 <echeveria> BIP34 specifies a soft fork that makes them unique by adding a nonce to the coinbase.
5002017-12-30T13:51:17 <sipa> https://bitcoin.stackexchange.com/a/38998/208
5012017-12-30T13:51:29 <sipa> ^ all known cases of known losses
5022017-12-30T13:51:48 <echeveria> needs updating for the latest 12.5 BTC loss.
5032017-12-30T13:52:22 <sipa> yeah.
5042017-12-30T13:53:13 <provoostenator> Ah yes, wonderful how block explorers have to deal with that special case: https://www.blocktrail.com/BTC/tx/d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599
5052017-12-30T13:55:16 *** blackbaba has joined #bitcoin-core-dev
5062017-12-30T13:57:27 <provoostenator> sipa while you're at it, maybe link to an explanation for "the coins created in the genesis block cannot be spent"?
5072017-12-30T13:58:28 *** fanquake has quit IRC
5082017-12-30T13:59:52 <sipa> provoostenator: they just can't
5092017-12-30T14:00:56 <sipa> every version of the bitcoin full node software would have considered a spend of the genesis output as invalid; hence, it is invalid
5102017-12-30T14:01:26 <sipa> it may have been intentional or an oversight, but that doesn't matter
5112017-12-30T14:02:12 <Varunram> sipa: so, satoshi didn't add the genesis block coins to the tx db?
5122017-12-30T14:02:39 <provoostenator> My understanding is that it was hardcoded into the client in some later version, though by that time it was too late, because even older versions would consider spending that a hardfork, so presumably new versions also don't allow it.
5132017-12-30T14:03:21 <provoostenator> And about the least important thing you could possibly want to change.
5142017-12-30T14:03:25 <Varunram> oh, ok
5152017-12-30T14:04:07 <sipa> provoostenator: in early versions it was because the genesis block was never processed, so its output was never added to the txdb (precursor of the utxo set)
5162017-12-30T14:04:27 <sipa> in recent versions it's an explicit special case
5172017-12-30T14:04:53 <sipa> (introduced to prevent creating a hardfork w.r.t. older versions)
5182017-12-30T14:04:54 <provoostenator> Do all altcoins based on this codebase have the same behavior?
5192017-12-30T14:04:58 *** blackbaba has quit IRC
5202017-12-30T14:05:07 *** Chris_Stewart_5 has joined #bitcoin-core-dev
5212017-12-30T14:05:54 <sipa> provoostenator: no idea
5222017-12-30T14:10:07 *** d9b4bef9 has joined #bitcoin-core-dev
5232017-12-30T14:13:20 *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
5242017-12-30T14:13:20 *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
5252017-12-30T14:13:25 *** meshcollider has quit IRC
5262017-12-30T14:38:37 *** Guyver2 has joined #bitcoin-core-dev
5272017-12-30T14:38:56 *** dyboj has joined #bitcoin-core-dev
5282017-12-30T14:40:50 *** CubicEarths has joined #bitcoin-core-dev
5292017-12-30T14:42:42 *** dyboj has quit IRC
5302017-12-30T15:14:45 *** juscamar1 has joined #bitcoin-core-dev
5312017-12-30T15:18:57 *** juscamar1 has quit IRC
5322017-12-30T15:18:59 *** Chris_Stewart_5 has quit IRC
5332017-12-30T15:36:44 *** cplusboi has quit IRC
5342017-12-30T15:42:22 *** ula has joined #bitcoin-core-dev
5352017-12-30T15:56:27 *** Murch has quit IRC
5362017-12-30T16:00:57 *** Kozuch has joined #bitcoin-core-dev
5372017-12-30T16:12:39 *** Murch has joined #bitcoin-core-dev
5382017-12-30T16:16:35 *** finkan has joined #bitcoin-core-dev
5392017-12-30T16:35:53 *** finkan has quit IRC
5402017-12-30T16:38:25 *** CubicEarths has quit IRC
5412017-12-30T16:38:44 *** CubicEarths has joined #bitcoin-core-dev
5422017-12-30T16:41:19 *** imnothreat has joined #bitcoin-core-dev
5432017-12-30T16:42:50 *** finkan has joined #bitcoin-core-dev
5442017-12-30T16:49:53 *** Chris_Stewart_5 has joined #bitcoin-core-dev
5452017-12-30T16:55:45 *** juscamar1 has joined #bitcoin-core-dev
5462017-12-30T17:00:25 *** juscamar1 has quit IRC
5472017-12-30T17:01:42 *** owowo has quit IRC
5482017-12-30T17:02:08 *** ghost43 has quit IRC
5492017-12-30T17:02:19 *** ghost43 has joined #bitcoin-core-dev
5502017-12-30T17:02:58 *** HoloIRCUser4 has joined #bitcoin-core-dev
5512017-12-30T17:03:59 *** Chris_Stewart_5 has quit IRC
5522017-12-30T17:04:43 *** finkan has quit IRC
5532017-12-30T17:06:24 *** owowo has joined #bitcoin-core-dev
5542017-12-30T17:11:01 *** Cogito_Ergo_Sum has quit IRC
5552017-12-30T17:22:15 *** HoloIRCUser4 has quit IRC
5562017-12-30T17:23:49 *** Evel-Knievel has joined #bitcoin-core-dev
5572017-12-30T17:27:52 <achow101> provoostenator: no, some changed it to explicitly add the genesis block output to the txdb
5582017-12-30T17:33:26 *** CubicEarths has quit IRC
5592017-12-30T17:33:55 *** CubicEarths has joined #bitcoin-core-dev
5602017-12-30T17:37:49 *** CubicEar_ has joined #bitcoin-core-dev
5612017-12-30T17:38:12 *** CubicEarths has quit IRC
5622017-12-30T17:39:40 *** laurentmt has joined #bitcoin-core-dev
5632017-12-30T17:46:50 *** lvmbdv has joined #bitcoin-core-dev
5642017-12-30T17:47:13 *** CubicEar_ has quit IRC
5652017-12-30T17:49:06 *** CubicEarths has joined #bitcoin-core-dev
5662017-12-30T17:49:45 *** CubicEarths has joined #bitcoin-core-dev
5672017-12-30T17:51:25 *** CubicEar_ has joined #bitcoin-core-dev
5682017-12-30T17:52:34 *** CubicEarths has quit IRC
5692017-12-30T17:55:08 <lvmbdv> hello, if P2PKH was the only mechanism of payment, would keeping witness data make more sense?
5702017-12-30T17:55:38 <sipa> ?
5712017-12-30T17:56:30 <Randolf> lvmbdv: You'd probably find that the #bitcoin channel is a really great place to ask that question.
5722017-12-30T17:56:47 <lvmbdv> sorry, i will
5732017-12-30T17:57:24 <Randolf> :)
5742017-12-30T17:57:38 <Sentineo> but it certainly needs rephrasing ;)
5752017-12-30T17:59:57 <midnightmagic> sipa: sorry about that. I can put in an exception if you like
5762017-12-30T18:00:26 *** arubi has quit IRC
5772017-12-30T18:01:02 *** arubi has joined #bitcoin-core-dev
5782017-12-30T18:01:14 <sipa> midnightmagic: heh, no
5792017-12-30T18:01:22 <sipa> i should just identify
5802017-12-30T18:06:01 *** d9b4bef9 has quit IRC
5812017-12-30T18:07:07 *** d9b4bef9 has joined #bitcoin-core-dev
5822017-12-30T18:08:02 *** d9b4bef9 has quit IRC
5832017-12-30T18:09:03 *** rabidus has quit IRC
5842017-12-30T18:09:16 *** d9b4bef9 has joined #bitcoin-core-dev
5852017-12-30T18:10:02 *** d9b4bef9 has quit IRC
5862017-12-30T18:11:08 *** d9b4bef9 has joined #bitcoin-core-dev
5872017-12-30T18:20:53 <midnightmagic> k
5882017-12-30T18:28:28 *** sengehest has quit IRC
5892017-12-30T18:28:55 *** sengehest has joined #bitcoin-core-dev
5902017-12-30T18:31:42 *** juscamar1 has joined #bitcoin-core-dev
5912017-12-30T18:41:20 *** laurentmt has quit IRC
5922017-12-30T18:41:49 *** jb55 has joined #bitcoin-core-dev
5932017-12-30T18:55:08 *** jb55 has quit IRC
5942017-12-30T19:05:34 *** CubicEarths has joined #bitcoin-core-dev
5952017-12-30T19:05:54 *** CubicEar_ has quit IRC
5962017-12-30T19:07:43 *** d0xffea has joined #bitcoin-core-dev
5972017-12-30T19:13:35 *** mmmmmm has joined #bitcoin-core-dev
5982017-12-30T19:20:33 *** CubicEarths has quit IRC
5992017-12-30T19:20:50 *** CubicEarths has joined #bitcoin-core-dev
6002017-12-30T19:21:49 *** CubicEarths has quit IRC
6012017-12-30T19:22:24 *** CubicEarths has joined #bitcoin-core-dev
6022017-12-30T19:24:56 *** CubicEar_ has joined #bitcoin-core-dev
6032017-12-30T19:28:08 *** CubicEarths has quit IRC
6042017-12-30T19:32:01 *** twistedline has quit IRC
6052017-12-30T19:32:09 *** twistedline_ has joined #bitcoin-core-dev
6062017-12-30T19:35:02 *** Giszmo has quit IRC
6072017-12-30T19:40:47 *** Giszmo has joined #bitcoin-core-dev
6082017-12-30T19:43:32 *** promag has joined #bitcoin-core-dev
6092017-12-30T19:44:09 *** promag has quit IRC
6102017-12-30T20:00:15 *** meshcollider has joined #bitcoin-core-dev
6112017-12-30T20:08:39 *** jb55 has joined #bitcoin-core-dev
6122017-12-30T20:10:09 *** andytoshi has quit IRC
6132017-12-30T20:10:09 *** andytoshi has joined #bitcoin-core-dev
6142017-12-30T20:18:06 *** mmmmmm has quit IRC
6152017-12-30T20:22:02 *** jb55 has quit IRC
6162017-12-30T20:31:28 *** juscamar1 has quit IRC
6172017-12-30T20:31:58 *** juscamar1 has joined #bitcoin-core-dev
6182017-12-30T20:40:35 *** juscamar1 has quit IRC
6192017-12-30T20:43:52 *** imnothreat has quit IRC
6202017-12-30T20:45:00 *** juscamar1 has joined #bitcoin-core-dev
6212017-12-30T20:49:58 *** mrfrasha has joined #bitcoin-core-dev
6222017-12-30T21:09:07 *** promag has joined #bitcoin-core-dev
6232017-12-30T21:12:35 *** juscamar1 has quit IRC
6242017-12-30T21:13:01 *** juscamar1 has joined #bitcoin-core-dev
6252017-12-30T21:16:28 *** CubicEar_ has quit IRC
6262017-12-30T21:18:04 *** jb55 has joined #bitcoin-core-dev
6272017-12-30T21:18:58 *** Guyver2 has quit IRC
6282017-12-30T21:21:03 *** juscamar1 has quit IRC
6292017-12-30T21:27:34 *** juscamar1 has joined #bitcoin-core-dev
6302017-12-30T21:42:27 *** Randolf has quit IRC
6312017-12-30T21:44:33 *** harrymm has quit IRC
6322017-12-30T21:46:50 *** ek33191 has joined #bitcoin-core-dev
6332017-12-30T21:52:27 *** ek33191 has quit IRC
6342017-12-30T21:57:40 *** harrymm has joined #bitcoin-core-dev
6352017-12-30T21:58:32 *** promag has quit IRC
6362017-12-30T21:59:09 *** SevenTimes has joined #bitcoin-core-dev
6372017-12-30T21:59:43 *** sdupre has joined #bitcoin-core-dev
6382017-12-30T22:00:04 <sdupre> I having a C++ error making static builds. Looking for some guidance. Willing to pay.
6392017-12-30T22:12:02 *** d9b4bef9 has quit IRC
6402017-12-30T22:12:11 *** d0xffea has quit IRC
6412017-12-30T22:13:09 *** d9b4bef9 has joined #bitcoin-core-dev
6422017-12-30T22:19:58 *** meshcollider has quit IRC
6432017-12-30T22:21:48 *** gribble has quit IRC
6442017-12-30T22:23:41 *** Chris_Stewart_5 has joined #bitcoin-core-dev
6452017-12-30T22:27:47 *** gribble has joined #bitcoin-core-dev
6462017-12-30T22:28:26 *** sengehest has quit IRC
6472017-12-30T22:55:42 *** justanotheruser has joined #bitcoin-core-dev
6482017-12-30T22:57:08 *** axlalkdkjfkjdefk has joined #bitcoin-core-dev
6492017-12-30T22:57:57 *** justan0theruser has quit IRC
6502017-12-30T22:58:29 *** axlalkdkjfkjdefk has quit IRC
6512017-12-30T23:00:12 *** meshcollider has joined #bitcoin-core-dev
6522017-12-30T23:05:04 *** ada_ has joined #bitcoin-core-dev
6532017-12-30T23:05:22 *** ada_ is now known as Adarvc
6542017-12-30T23:20:13 *** Cache_Money has joined #bitcoin-core-dev
6552017-12-30T23:24:22 *** arubi has quit IRC
6562017-12-30T23:27:24 *** arubi has joined #bitcoin-core-dev
6572017-12-30T23:30:48 *** Tennis has joined #bitcoin-core-dev
6582017-12-30T23:32:15 *** Chris_Stewart_5 has quit IRC
6592017-12-30T23:33:36 *** blaster has quit IRC
6602017-12-30T23:42:21 *** Cache_Money has quit IRC
6612017-12-30T23:42:38 *** chaus has joined #bitcoin-core-dev
6622017-12-30T23:42:42 *** Murch has quit IRC
6632017-12-30T23:42:45 *** Cache_Money has joined #bitcoin-core-dev
6642017-12-30T23:43:25 *** Murch has joined #bitcoin-core-dev
6652017-12-30T23:43:47 *** Murch has quit IRC
6662017-12-30T23:47:35 *** jb55 has quit IRC
6672017-12-30T23:52:31 *** jb55 has joined #bitcoin-core-dev
6682017-12-30T23:56:26 *** Cache_Money has quit IRC