12016-01-12T00:00:42 *** jgarzik has quit IRC
22016-01-12T00:03:31 *** jgarzik has joined #bitcoin-core-dev
32016-01-12T00:03:31 *** jgarzik has joined #bitcoin-core-dev
42016-01-12T00:19:31 *** laurentmt has joined #bitcoin-core-dev
52016-01-12T00:20:38 *** laurentmt has quit IRC
62016-01-12T00:30:20 *** jgarzik has quit IRC
72016-01-12T00:33:00 *** jtimon has quit IRC
82016-01-12T00:40:37 *** brg444 has quit IRC
92016-01-12T01:03:25 *** brg444 has joined #bitcoin-core-dev
102016-01-12T01:06:44 *** xiangfu has joined #bitcoin-core-dev
112016-01-12T01:07:07 *** laurentmt has joined #bitcoin-core-dev
122016-01-12T01:08:41 *** laurentmt has quit IRC
132016-01-12T01:14:52 *** davec has quit IRC
142016-01-12T01:20:43 *** davec has joined #bitcoin-core-dev
152016-01-12T01:27:04 *** arowser has quit IRC
162016-01-12T01:27:38 *** arowser has joined #bitcoin-core-dev
172016-01-12T01:38:21 *** Ylbam has quit IRC
182016-01-12T02:10:34 *** jgarzik has joined #bitcoin-core-dev
192016-01-12T02:16:59 *** wallet42 has joined #bitcoin-core-dev
202016-01-12T02:27:49 *** Jimmy16 has quit IRC
212016-01-12T02:35:57 *** p15 has joined #bitcoin-core-dev
222016-01-12T03:05:53 *** wallet42 has quit IRC
232016-01-12T03:16:09 *** belcher has quit IRC
242016-01-12T03:17:48 *** SmiteMeSmith has quit IRC
252016-01-12T03:18:59 *** SmiteMeSmith has joined #bitcoin-core-dev
262016-01-12T03:33:13 *** guest21333 has joined #bitcoin-core-dev
272016-01-12T04:21:42 *** tripleslash_v has joined #bitcoin-core-dev
282016-01-12T05:09:00 *** guest21333 has quit IRC
292016-01-12T05:12:52 *** brg444 has quit IRC
302016-01-12T05:17:13 *** maaku has left #bitcoin-core-dev
312016-01-12T06:24:55 *** zookolap` has quit IRC
322016-01-12T06:32:22 <GitHub113> [bitcoin] btcdrak opened pull request #7328: Update README.md website link (master...website) https://github.com/bitcoin/bitcoin/pull/7328
332016-01-12T06:38:00 <Quent> the bitcoin-core website will be copyrighted?
342016-01-12T06:45:58 *** Ylbam has joined #bitcoin-core-dev
352016-01-12T07:07:20 <btcdrak> Quent #bitcoin
362016-01-12T07:13:31 *** Squidicuz has quit IRC
372016-01-12T07:28:22 *** wallet42 has joined #bitcoin-core-dev
382016-01-12T07:47:29 *** wallet42 has quit IRC
392016-01-12T08:03:01 *** Alopex has quit IRC
402016-01-12T08:04:06 *** Alopex has joined #bitcoin-core-dev
412016-01-12T08:31:02 *** Alopex has quit IRC
422016-01-12T08:32:07 *** Alopex has joined #bitcoin-core-dev
432016-01-12T08:41:12 *** Quent has quit IRC
442016-01-12T08:41:41 *** Quent has joined #bitcoin-core-dev
452016-01-12T08:47:03 *** BashCo has quit IRC
462016-01-12T08:57:12 *** randy-waterhouse has quit IRC
472016-01-12T09:05:00 *** BashCo has joined #bitcoin-core-dev
482016-01-12T09:10:15 *** dcousens has joined #bitcoin-core-dev
492016-01-12T09:10:15 *** dcousens has quit IRC
502016-01-12T09:10:31 *** dcousens has joined #bitcoin-core-dev
512016-01-12T09:18:56 *** paveljanik has quit IRC
522016-01-12T09:29:19 *** Amnez777 has quit IRC
532016-01-12T09:36:11 <GitHub168> [bitcoin] chriswheeler opened pull request #7329: Trivial: fix typo (master...typofix) https://github.com/bitcoin/bitcoin/pull/7329
542016-01-12T09:37:59 *** jtimon has joined #bitcoin-core-dev
552016-01-12T09:47:54 *** Guyver2 has joined #bitcoin-core-dev
562016-01-12T09:49:30 *** dgenr8 has quit IRC
572016-01-12T09:49:47 *** neilf_ has quit IRC
582016-01-12T09:50:11 *** neilf_ has joined #bitcoin-core-dev
592016-01-12T09:50:20 *** dgenr8 has joined #bitcoin-core-dev
602016-01-12T09:52:13 *** arowser has quit IRC
612016-01-12T09:52:35 *** arowser has joined #bitcoin-core-dev
622016-01-12T09:53:19 *** fkhan_ has quit IRC
632016-01-12T09:53:22 *** davec has quit IRC
642016-01-12T09:53:22 *** baldur_ has quit IRC
652016-01-12T09:55:06 *** davec has joined #bitcoin-core-dev
662016-01-12T10:06:52 *** fkhan_ has joined #bitcoin-core-dev
672016-01-12T10:10:56 *** adam3us has quit IRC
682016-01-12T10:15:15 *** davec has quit IRC
692016-01-12T10:16:18 *** Amnez777 has joined #bitcoin-core-dev
702016-01-12T10:16:19 *** Amnez777 has quit IRC
712016-01-12T10:16:47 *** Amnez777 has joined #bitcoin-core-dev
722016-01-12T10:18:04 *** fkhan_ has quit IRC
732016-01-12T10:18:44 *** Amnez777 has quit IRC
742016-01-12T10:18:44 *** Amnez777 has joined #bitcoin-core-dev
752016-01-12T10:21:46 *** davec has joined #bitcoin-core-dev
762016-01-12T10:31:28 *** fkhan_ has joined #bitcoin-core-dev
772016-01-12T10:47:15 *** adam3us has joined #bitcoin-core-dev
782016-01-12T10:53:44 *** dcousens has quit IRC
792016-01-12T10:53:56 *** p15 has quit IRC
802016-01-12T10:54:26 *** dcousens has joined #bitcoin-core-dev
812016-01-12T10:55:16 *** p15 has joined #bitcoin-core-dev
822016-01-12T10:55:29 *** arowser has quit IRC
832016-01-12T10:56:03 *** arowser has joined #bitcoin-core-dev
842016-01-12T10:58:45 *** adam3us has quit IRC
852016-01-12T10:58:55 *** MarcoFalke has joined #bitcoin-core-dev
862016-01-12T11:07:52 *** adam3us has joined #bitcoin-core-dev
872016-01-12T11:17:24 *** Thireus has joined #bitcoin-core-dev
882016-01-12T11:27:50 *** adam3us has quit IRC
892016-01-12T11:33:32 *** jcorgan is now known as jcorgan|away
902016-01-12T11:44:18 *** adam3us has joined #bitcoin-core-dev
912016-01-12T11:54:13 *** baldur_ has joined #bitcoin-core-dev
922016-01-12T12:35:56 *** midnightmagic has quit IRC
932016-01-12T12:36:50 *** midnightmagic has joined #bitcoin-core-dev
942016-01-12T12:52:56 *** adam3us has quit IRC
952016-01-12T12:56:56 *** xiangfu has quit IRC
962016-01-12T12:57:39 *** xiangfu has joined #bitcoin-core-dev
972016-01-12T13:03:33 *** MarcoFalke has quit IRC
982016-01-12T13:07:55 *** SmiteMeSmith_ has joined #bitcoin-core-dev
992016-01-12T13:11:24 *** SmiteMeSmith has quit IRC
1002016-01-12T13:11:49 *** p15 has quit IRC
1012016-01-12T13:12:26 *** fkhan_ has quit IRC
1022016-01-12T13:21:13 <GitHub118> [bitcoin] btcdrak closed pull request #7328: Update README.md website link (master...website) https://github.com/bitcoin/bitcoin/pull/7328
1032016-01-12T13:22:17 <GitHub36> [bitcoin] btcdrak reopened pull request #7328: Update README.md website link (master...website) https://github.com/bitcoin/bitcoin/pull/7328
1042016-01-12T13:29:30 *** fkhan_ has joined #bitcoin-core-dev
1052016-01-12T14:13:22 *** xiangfu has quit IRC
1062016-01-12T14:15:12 *** xiangfu has joined #bitcoin-core-dev
1072016-01-12T14:22:03 <morcos> wumpus: is the only hold up for RC1 my 2 PR's? (sorry) anything i can do to help move things along?
1082016-01-12T14:22:54 <morcos> i'm happy to try to get jonasschnelli's gui/rpc output improvements in if you think that makes it better for 0.12...
1092016-01-12T14:40:29 *** laurentmt has joined #bitcoin-core-dev
1102016-01-12T14:44:49 <jonasschnelli> morcos: you mean the listtransaction and GUI transaction detail improvements?
1112016-01-12T14:44:58 <jonasschnelli> Not sure if we need them for 0.12.
1122016-01-12T14:45:02 *** adam3us has joined #bitcoin-core-dev
1132016-01-12T14:45:18 <jonasschnelli> "listtransactions" abandoned-category maybe
1142016-01-12T14:45:20 <morcos> jonasschnelli: yes, thats what i meant, just wanted to let wumpus know if he preferred to have those for 0.12, that was fine by me
1152016-01-12T14:45:54 <morcos> jonasschnelli: did you see my question about it seemed like you were only allowing that for "send" txs, but any tx can be abandoned
1162016-01-12T14:45:55 <jonasschnelli> What I don't like in the GUI is, that abandoned transactions are still in the tx-list, but don't count for the balance (obviously).
1172016-01-12T14:46:35 <morcos> jonasschnelli: that is the same as it as always been. in 0.11 any tx not in the mempool counts as conflicted and in 0.11 and 0.12 all conflicted txs don't count towards balance
1182016-01-12T14:46:51 <morcos> so while i agree that maybe this could be improved, i think its a much bigger change
1192016-01-12T14:47:04 <jonasschnelli> Yes... somehow i think a transaction-list sum should be the balance.
1202016-01-12T14:47:13 <morcos> if anything abandoning a tx causes the behavior to be exactly the same as the 0.11 behavior
1212016-01-12T14:47:32 <jonasschnelli> okay... yes. Let's keep the listtransaction and GUI stuff for 0.13.
1222016-01-12T14:48:00 <jonasschnelli> And your right,... listtransaction abandoned category only gets detected for "sending" tx.
1232016-01-12T14:48:07 <jonasschnelli> (need to be fixed)
1242016-01-12T14:48:40 *** adam3us has quit IRC
1252016-01-12T15:05:42 *** guest21333 has joined #bitcoin-core-dev
1262016-01-12T15:07:19 *** arowser has quit IRC
1272016-01-12T15:07:37 *** arowser has joined #bitcoin-core-dev
1282016-01-12T15:24:46 *** Squidicuz has joined #bitcoin-core-dev
1292016-01-12T15:34:44 *** dcousens has quit IRC
1302016-01-12T15:43:53 *** xiangfu has quit IRC
1312016-01-12T15:45:12 *** laurentmt has quit IRC
1322016-01-12T15:47:29 *** guest21333 has quit IRC
1332016-01-12T15:51:14 *** MarcoFalke has joined #bitcoin-core-dev
1342016-01-12T15:53:32 *** USfV5 has joined #bitcoin-core-dev
1352016-01-12T15:55:22 *** deego has quit IRC
1362016-01-12T15:56:47 *** MarcoFalke has left #bitcoin-core-dev
1372016-01-12T15:56:50 *** MarcoFalke has joined #bitcoin-core-dev
1382016-01-12T15:59:07 *** USfV5 has quit IRC
1392016-01-12T16:10:13 *** tripleslash_d has joined #bitcoin-core-dev
1402016-01-12T16:12:06 *** tripleslash_v has quit IRC
1412016-01-12T16:18:10 *** laurentmt has joined #bitcoin-core-dev
1422016-01-12T16:19:07 *** MarcoFalke has left #bitcoin-core-dev
1432016-01-12T16:19:20 *** laurentmt has quit IRC
1442016-01-12T16:24:23 *** MarcoFalke has joined #bitcoin-core-dev
1452016-01-12T16:33:46 *** lecusemble has quit IRC
1462016-01-12T16:37:24 *** lecusemble has joined #bitcoin-core-dev
1472016-01-12T16:49:04 *** brg444 has joined #bitcoin-core-dev
1482016-01-12T16:56:16 *** murch has joined #bitcoin-core-dev
1492016-01-12T17:03:58 <wangchun> where is the "bitcoin" classic 2MB patch? I've checked their master branch but MAX_BLOCK_SIZE remains at 1000000 bytes
1502016-01-12T17:05:09 <morcos> wangchun: i'm not sure this is the right channel for that question, as this is for the Core implementation. But I think there are a couple of pull requests open on their github repo which have the changes.
1512016-01-12T17:07:35 <wangchun> morcos: I only see BIP101 style doubling every 2 years from pull reqs but only start from 2MB
1522016-01-12T17:07:57 <wangchun> From their intros on the website, it should be fixed 2MB right?
1532016-01-12T17:08:54 <morcos> wangchun: sorry i didn't look at their actual code. i don't know what they are doing. I've been helping the Core team with segregated witness as I think it gives us the effective increase of 2MB with a much safer rollout
1542016-01-12T17:09:06 <morcos> while at the same time fixing long standing issues and adding needed security toools
1552016-01-12T17:10:41 <morcos> happy to help with any questions you have about that! :)
1562016-01-12T17:11:02 <btcdrak> wangchun: they dont seem to have any code for it. However there is a 2MB patch in Core
1572016-01-12T17:11:06 <instagibbs> wangchun, http://bitcoinco.re/en/2015/12/23/capacity-increases-faq/
1582016-01-12T17:11:42 <btcdrak> wangchun: Here is a 2MB patch in Core https://github.com/bitcoin/bitcoin/pull/6451
1592016-01-12T17:12:24 <btcdrak> wangchun: there is Chinese version of the FAQ http://bitcoinco.re/zh_CN/2015/12/21/%E7%B3%BB%E7%BB%9F%E6%89%A9%E5%B1%95%E5%B8%B8%E8%A7%81%E9%97%AE%E9%A2%98%E8%A7%A3%E7%AD%94/
1602016-01-12T17:16:40 *** tripleslash_d has quit IRC
1612016-01-12T17:20:51 <wangchun> btcdrak: #6451 looks good to me. It would be nice if we mix this with segwit. May I have an update why many devs want to deploy segwit as a softfork?
1622016-01-12T17:21:19 <sipa> wangchun: because a softfork does not require the entire world to agree
1632016-01-12T17:21:23 <btcdrak> wangchun: a hard fork will take longer to deploy. Even if we do 2MB hard fork, segwit would deploy first
1642016-01-12T17:21:42 <sipa> because it allows us to make progress right now, without needing to force one choice or another
1652016-01-12T17:22:41 <wangchun> sipa: But Antpool/BW/BTCC already voted for 2MB, it shouldn't be hard to push that out right?
1662016-01-12T17:22:42 *** davec has quit IRC
1672016-01-12T17:23:00 *** davec has joined #bitcoin-core-dev
1682016-01-12T17:23:03 <sipa> wangchun: that's 3 people, not the whole world
1692016-01-12T17:23:21 <sipa> wangchun: for a hardfork not only miners have to agree
1702016-01-12T17:23:37 <btcdrak> wangchun: all 5000 fullnodes must also upgrade
1712016-01-12T17:23:48 <wangchun> Should we ACK Bitcoin Classic? I think it might be a good thing...
1722016-01-12T17:23:50 <sipa> wangchun: segwit SF gives 2 MB blocks, but without forcing anyone to change
1732016-01-12T17:24:05 <sipa> wangchun: what benefit does it have?
1742016-01-12T17:24:12 <wangchun> If the Classic get succeed, we have 2MB, and then we merge it back into core, we have segwit
1752016-01-12T17:24:15 <wangchun> win-win
1762016-01-12T17:24:23 <sipa> that makes no sense
1772016-01-12T17:24:54 <sipa> then you'll have 4 MB blocks, with all latency problems that causes, and still need to force the world to adopt a change
1782016-01-12T17:25:24 <wangchun> With 2MB, we'll have 8MB blocks, that is better
1792016-01-12T17:25:47 <wangchun> And it is not 8MB in fact. not every tx is p2sh
1802016-01-12T17:26:00 <wangchun> much like 5MB or so
1812016-01-12T17:26:55 <sipa> what block sizes are you confortable with?
1822016-01-12T17:27:25 *** BashCo has quit IRC
1832016-01-12T17:28:01 <wangchun> 2MB+segwit would be nice
1842016-01-12T17:28:21 <sipa> what effective block size are you comfortable wit
1852016-01-12T17:28:30 <sipa> the size of blocks going over the wire
1862016-01-12T17:28:45 <wangchun> 5MB is good
1872016-01-12T17:29:15 <sipa> well then you'll need a hard fork, and need to convince everyone to accept that
1882016-01-12T17:29:20 <wangchun> I think hardfork is much more desirable as it makes many things cleaner
1892016-01-12T17:29:40 <wangchun> I heard you guys want every coinbase tx to have an additional OP_RETURN vout, that is so ugly
1902016-01-12T17:29:58 <sipa> there are alternatives to that, i am very open to discuss
1912016-01-12T17:30:13 <btcdrak> wangchun: BTCC is selling advertising in the coinbase =__=
1922016-01-12T17:30:32 <wangchun> i also know many people who want to see a hardfork version of segwit
1932016-01-12T17:31:04 <wangchun> btcdrak: i know, if we enlarge coinbase string from 100 bytes to 256, they will be very happy
1942016-01-12T17:32:10 <wangchun> btcdrak: actually in the past we also sold a few coinbases, for 1 BTC each
1952016-01-12T17:32:28 *** zookolaptop has joined #bitcoin-core-dev
1962016-01-12T17:32:29 <btcdrak> wow
1972016-01-12T17:32:31 <wangchun> in 2013
1982016-01-12T17:32:53 <sipa> wangchun: the problem is that for a hard fork, everyone has to agree precisely on what the new rule will be
1992016-01-12T17:33:06 <sipa> wangchun: and that takes time
2002016-01-12T17:33:36 <JackH> it could get ugly, and in worst case scenario put us back months if not everyone upgrades
2012016-01-12T17:34:09 <sipa> a softfork is safe and possible with just miners accepting it
2022016-01-12T17:34:31 <sipa> which is why we strongly favor softforks where possible
2032016-01-12T17:34:40 <morcos> wangchun: Everyone in core would prefer to see segwit as a hard fork rather than a soft fork. but we take very seriously the notion that we should not be forcing the rules of bitcoin to change for people who might not agree
2042016-01-12T17:34:42 <sipa> it does not rule out doing a hardfork later
2052016-01-12T17:34:49 *** brg444 has quit IRC
2062016-01-12T17:35:25 <morcos> wangchun: so hopefully one day, there will be widespread consensus about a hardfork, whether its cleaning up segwit or whether its a block size increase, or both or other things.
2072016-01-12T17:36:14 <morcos> but given that we can get all the benefits of segwit without that, it seems clearly the right next step. it doesn't preclude everyone coming to agreement on some hard fork, but it allows progress to happen without waiting for that
2082016-01-12T17:36:53 <wangchun> then we may consider support the classic hope it get 2MB to be deployed sooner than segwit
2092016-01-12T17:37:23 <wangchun> but i think it is unlikely
2102016-01-12T17:37:36 <sipa> we already have a test version of segwit up and running
2112016-01-12T17:38:04 <wangchun> a race is better to everyone
2122016-01-12T17:38:10 <sipa> wangchun: you can support a 2 MB HF, but you can only run it when you know everyone agrees
2132016-01-12T17:38:32 <sipa> wangchun: you can run segwit immediately
2142016-01-12T17:38:33 <wangchun> there will be a 95% threshold i suppose
2152016-01-12T17:38:50 <morcos> wangchun: i think its great to announce you support 2MB HF blocks if thats what you want. but its risky to run code that will switch to that if only 75% of miners agree. it runs the risk of forkinig the network and creating two coins.
2162016-01-12T17:39:09 *** paveljanik has joined #bitcoin-core-dev
2172016-01-12T17:39:34 <morcos> wangchun: they are proposing i believe a 75% or lower threshold. and of course that only measures miner support, not support from the rest of the community
2182016-01-12T17:39:36 <wangchun> I agree 75% is not enough
2192016-01-12T17:39:55 <wangchun> if 95% miner support it, i believe others will follow
2202016-01-12T17:40:12 <sipa> wangchun: a hard fork requires everyone to agree, not just miners
2212016-01-12T17:40:25 <sipa> wangchun: even 100% of miners cannot decide a hard fork
2222016-01-12T17:40:26 <wangchun> if 95% miners support it, others have no choice :)
2232016-01-12T17:40:39 <helo> there should be no "hopefully others will follow"
2242016-01-12T17:40:54 <helo> others may not want to follow, and they may be right in not doing so
2252016-01-12T17:41:01 <wangchun> 5% hashrate cannot secure their own branch
2262016-01-12T17:41:30 <helo> that doesn't mean they are incorrect
2272016-01-12T17:41:53 <petertodd> wangchun: it's not a question about them securing that branch, it's a question of whether or not more blocks are added to it
2282016-01-12T17:42:12 <wangchun> anyway practically, if we got 95% hashrate in one branch, the other branch is over
2292016-01-12T17:42:27 <sipa> wangchun: not necessarily true for a hard fork
2302016-01-12T17:42:34 <sipa> for a softfork, yes
2312016-01-12T17:42:40 <petertodd> wangchun: 95% is probably high enough that's it's unlikely to end up with people being forked off, but that's not really certain in a hardfork case
2322016-01-12T17:42:49 <morcos> wangchun: regardless of whether you support the 2MB HF, I'd like to encourage you to help us with the segregated witness soft fork.
2332016-01-12T17:43:09 <wangchun> morcos: sure
2342016-01-12T17:43:33 <sipa> wangchun: and input on where you want the witness commitment is very welcome
2352016-01-12T17:44:10 <wangchun> witness commitment?
2362016-01-12T17:44:13 <petertodd> wangchun: now, if we had a 100% threshold that might put us in a better place. It also might be good to get a small % of hashing power willing to mine empty blocks on top of the old chain in the event that some miners still mine it. (aka, 51% attack it to ensure it stays dead)
2372016-01-12T17:44:39 <sipa> wangchun: segregated witness needs a 32-byte value somewhere in coinbase
2382016-01-12T17:44:39 <morcos> i'd like to avoid the outcome where neither happens because people are too entrenched in having their solution. it seems to me that the only objection to segregated witness as a soft fork is what you said about it being ugly compared to doing it as a hard fork.
2392016-01-12T17:44:55 <sipa> wangchun: this can go in an OP_RETURN output, or in the scriptSig
2402016-01-12T17:45:07 <wangchun> scriptSig of course
2412016-01-12T17:45:26 <sipa> wangchun: but others may not want to loose so much scriptSig space
2422016-01-12T17:45:31 <morcos> but i think t hats a very small price to pay for being able to get it implemented. if we tried to do it as a hard fork it would be hard to get it rolled out in any reasonable time period.
2432016-01-12T17:45:40 <wangchun> but the coinbase string max size limit should be lifted in the very next hard fork
2442016-01-12T17:45:58 <sipa> wangchun: ok, but we can't do that now
2452016-01-12T17:46:05 <wangchun> sipa: how many bytes? 32? 36?
2462016-01-12T17:46:10 <sipa> 32
2472016-01-12T17:46:14 <sipa> plus a header
2482016-01-12T17:46:18 <wangchun> header?
2492016-01-12T17:46:19 <sipa> 36 is ok
2502016-01-12T17:46:33 <sipa> magic bytes to say "here follows the witness commitment"
2512016-01-12T17:46:33 <jl2012> the "header" could be put in nLockTime
2522016-01-12T17:46:37 <wangchun> hmm
2532016-01-12T17:46:41 <jl2012> some 32 is the minimum
2542016-01-12T17:46:46 <wangchun> it's only 100 bytes... we cannot have a header
2552016-01-12T17:46:49 <jl2012> s/some/so/
2562016-01-12T17:46:59 <wangchun> put it immeidately follow the height bytes
2572016-01-12T17:46:59 <petertodd> wangchun: alternative to a header is to have it in a fixed position
2582016-01-12T17:47:14 <petertodd> wangchun: I think that makes sense
2592016-01-12T17:47:20 <sipa> wangchun: that is why i believe an OP_RETURN is easier to get accepted, even if it is uglier
2602016-01-12T17:47:23 *** BashCo has joined #bitcoin-core-dev
2612016-01-12T17:47:30 <sipa> immediately after the height is also possible
2622016-01-12T17:47:32 <wangchun> i've talked to jl2012 earlier
2632016-01-12T17:47:36 <sipa> ok
2642016-01-12T17:47:43 <wangchun> if people want more bytes, put extranonce to op_return
2652016-01-12T17:48:05 <jl2012> would it break some mining hardware?
2662016-01-12T17:48:24 <wangchun> or do like what we do, put extranonce to nsequence
2672016-01-12T17:48:54 <wangchun> jl2012: extranonce in nsequence is not breaking any hardware
2682016-01-12T17:49:05 <wangchun> i suppose extranonce in op_return should be fine too
2692016-01-12T17:49:46 <morcos> wangchun: i don't know how much all the miners talk to each other, but this seems a concern that affects them the most
2702016-01-12T17:50:06 <morcos> perhaps it would be useful for them to discuss among each other
2712016-01-12T17:50:11 <wangchun> so we have 4 bytes height + 32 bytes segwit + 44 bytes merged mining
2722016-01-12T17:50:26 <wangchun> 80 bytes
2732016-01-12T17:50:49 <wangchun> 20 bytes left for signature, no advertisement space for sell
2742016-01-12T17:50:50 <jl2012> what is the 44 bytes look like?
2752016-01-12T17:51:17 <wangchun> 4 bytes magic header + 32 bytes hash + 4 bytes merkle branch length + 4 bytes nonce
2762016-01-12T17:51:17 <sipa> wangchun: indeed, i thought the lack of ad space would be a problem
2772016-01-12T17:51:40 <wangchun> 4 bytes merkle branch length is a waste, 1 byte is enough, 4 bytes nonce is completely useless
2782016-01-12T17:52:03 <sipa> wangchun: we're working on a replacement for the MM header
2792016-01-12T17:52:12 <sipa> that can be used for more things
2802016-01-12T17:52:23 <jl2012> it's the mm of namecoin?
2812016-01-12T17:52:27 <sipa> yes
2822016-01-12T17:52:33 <wangchun> sipa: namecoin is planning the same thing, you may want to talk to them
2832016-01-12T17:52:40 <sipa> wangchun: i'm aware
2842016-01-12T17:52:50 <petertodd> wangchun: potentially, the witness commitment could be arranged to also work for MM, as well as any other future commitment
2852016-01-12T17:53:33 <wangchun> sipa: not just namecoin, we also have ixcoin, i0coin, groupcoin, 611, uno, huc, and some other dead ones
2862016-01-12T17:54:09 <jl2012> they should only commit 32 bytes in bitcoin, and leave the rest of meta data in their own header
2872016-01-12T17:54:44 <wangchun> anyway, it the size limit should be lifted in the next hard fork
2882016-01-12T17:54:51 *** brg444 has joined #bitcoin-core-dev
2892016-01-12T17:54:54 <wangchun> 256 bytes is preferred
2902016-01-12T17:56:32 <wangchun> satoshi likes decimals..
2912016-01-12T17:58:55 <sipa> wangchun: that seems like a reasonable thing
2922016-01-12T17:59:11 <sipa> but for now, we need a solution
2932016-01-12T17:59:32 <wangchun> put everything in coinbase is acceptable
2942016-01-12T17:59:42 <wangchun> BTCC and Antpool are not merged mining
2952016-01-12T17:59:47 <wangchun> so i think they will be fine
2962016-01-12T18:00:05 <wangchun> for those who do merge, 20 bytes for signature is just enough
2972016-01-12T18:00:19 <sipa> i thought BTCC was the one who suggested not using scriptSig :)
2982016-01-12T18:00:21 <jl2012> Samson told me that would kill their service
2992016-01-12T18:01:08 <wangchun> You can told them a hard fork to make their service shining is not very far
3002016-01-12T18:01:18 <sipa> we don't know that
3012016-01-12T18:01:25 <wangchun> s/told/tell/
3022016-01-12T18:01:30 <sipa> a hard fork will only happen if everyone agrees
3032016-01-12T18:01:53 <JackH> it would be interesting to see how many nodes we loose in a hardfork
3042016-01-12T18:02:38 *** Guyver2 has quit IRC
3052016-01-12T18:03:49 <wangchun> BTCC still has 64 bytes for sale
3062016-01-12T18:03:59 <wangchun> 63 bytes
3072016-01-12T18:04:30 <wangchun> extranonce1 cannot be empty, otherwise it may break some stupid stratum proxies
3082016-01-12T18:05:54 *** laurentmt has joined #bitcoin-core-dev
3092016-01-12T18:15:13 *** MarcoFalke has quit IRC
3102016-01-12T18:15:30 *** MarcoFalke has joined #bitcoin-core-dev
3112016-01-12T18:17:36 *** laurentmt has quit IRC
3122016-01-12T18:33:37 <Quent> if you excuse my comment - - - interesting isn't it, the hierarchy, one can say developers are employed by miners as shown by this little chat, with miners employed by users, while at the same time, like a quantum particle, everyone holding and not holding power at the same time.
3132016-01-12T18:34:00 *** sipa has left #bitcoin-core-dev
3142016-01-12T18:42:45 <Luke-Jr> morcos: what? segwit softfork is so much cleaner than a hardfork
3152016-01-12T18:42:59 <midnightmagic> :-(
3162016-01-12T18:43:25 <midnightmagic> Quent: Highly offtopic for in here.
3172016-01-12T18:44:19 <morcos> Luke-Jr: I wasn't referring to the act of forking but to what the protocol specification is at the end. By definition you can make anything you want as a hardfork, so clearly whatever optimal format is you could do that with a hard fork.
3182016-01-12T18:45:17 <Luke-Jr> morcos: if we had 100% of Bitcoin users convinced to do either a hardfork or softfork for segwit, the softfork would still be better
3192016-01-12T18:45:38 <morcos> Luke-Jr: b/c of rollout risk?
3202016-01-12T18:45:49 <Luke-Jr> morcos: because of backward compatibility with present wallets
3212016-01-12T18:46:28 <Luke-Jr> the ideal segwit structure would break current signatures
3222016-01-12T18:47:43 <morcos> Luke-Jr: ok, perhaps you are correct that the case for doing a HF isn't as straight forward as i implied. Regardless, its academic. SF is clearly the only reasonable choice for segwit now.
3232016-01-12T18:59:57 *** Guyver2 has joined #bitcoin-core-dev
3242016-01-12T19:00:11 *** MarcoFalke has quit IRC
3252016-01-12T19:06:17 *** laurentmt has joined #bitcoin-core-dev
3262016-01-12T19:07:31 <wangchun> not just backward compatiblility, in the case of segwit
3272016-01-12T19:07:44 <wangchun> segwit tx is anyone spendable to older clients
3282016-01-12T19:08:42 <wangchun> imagine some 0-conf tx service that still running old software after the activation
3292016-01-12T19:08:53 *** fkhan_ has quit IRC
3302016-01-12T19:09:12 <wangchun> a hard fork is safer for them
3312016-01-12T19:10:58 *** laurentmt has quit IRC
3322016-01-12T19:11:11 <zookolaptop> wangchun: could you explain how such an older, 0-conf-accepting client would be in danger in the soft-fork deployment?
3332016-01-12T19:11:20 <instagibbs> wangchun, they will simply get trivially double-spent being left behind on the old chain
3342016-01-12T19:11:29 <instagibbs> (in hard fork scenario)
3352016-01-12T19:12:53 <brg444> right, they have to upgrade in both scenarios else they can get cheated. not sure I see the difference?
3362016-01-12T19:12:59 <wangchun> i can send coins i can't move under the new rule
3372016-01-12T19:13:10 <zookolaptop> wangchun: hm.
3382016-01-12T19:13:11 <instagibbs> wangchun, in both hardfork/softfork, if user upgrades, great. In the non-upgraded scenario, they both have some drawbacks
3392016-01-12T19:13:35 <wangchun> and if someone mine a block on the old fork, it can even get a confirm
3402016-01-12T19:13:42 <wangchun> to old clients
3412016-01-12T19:14:48 <instagibbs> then can certainly get confirmations on the dead chain
3422016-01-12T19:15:11 <instagibbs> in hardfork
3432016-01-12T19:15:14 <wangchun> as segwit-enabled tx flies on the new fork, the old fork would become a mess
3442016-01-12T19:17:04 <Luke-Jr> wangchun: no, a hardfork does not make ANYTHING safer, EVER
3452016-01-12T19:17:47 <Luke-Jr> and that's ignoring the fact that unconfirmed transactions are never safe
3462016-01-12T19:18:26 <wangchun> Luke-Jr: softfork version of segwit != hardfork version of segwit, we don't have to use anyone can spend tx if it is a hardfork
3472016-01-12T19:18:41 <Luke-Jr> wangchun: that doesn't matter though
3482016-01-12T19:18:43 <instagibbs> wangchun, why do you care?
3492016-01-12T19:18:46 <instagibbs> it's not your money
3502016-01-12T19:18:50 <Luke-Jr> if it's a hardfork, those old nodes lose ALL security
3512016-01-12T19:19:31 <zookolaptop> One fact that matters to me is that Ethereum has done a series of hard fork upgrades over the last year or so.
3522016-01-12T19:19:51 <zookolaptop> I like to try to learn from empirical evidence.
3532016-01-12T19:20:14 <zookolaptop> Although of course, you could still be right, and one or another lucky break or special condition allowed Ethereum to succeed at that where Bitcoin wouldn't be able to do the same. Who knows.
3542016-01-12T19:20:25 <wangchun> many altcoins do hardfork upgrades regularly
3552016-01-12T19:20:56 <moli> wangchun: yes, but they're altcoins with not as large markets as bitcoin
3562016-01-12T19:20:59 <zookolaptop> I think it is easy for people, especially smart people, to convince themselves strongly of some belief, and paying attention to empirical evidence like that can help shake one's confidence.
3572016-01-12T19:21:45 <instagibbs> a closer example would be Bitcoin in the first or second year and Ethereum
3582016-01-12T19:21:47 <Luke-Jr> again, softfork segwit is superior to hardfork segwit even if both were equally possible
3592016-01-12T19:21:49 <moli> i went through many hardforks with an altcoin, where devs can never get consensus with miners, have to use a closed source dirty trick
3602016-01-12T19:22:05 <zookolaptop> moli: interesting. :-)
3612016-01-12T19:22:14 <zookolaptop> moli: thanks for giving me yet more empirical evidence for my hoard.
3622016-01-12T19:23:14 <zookolaptop> moli: was it just that the miners were unaware, disinterested, etc., or did the miners actively object to the change?
3632016-01-12T19:23:22 <zookolaptop> I would assume it was the former.
3642016-01-12T19:23:51 <instagibbs> Are you really surprised that Vitalik could get unanimous consensus for hardforks?
3652016-01-12T19:23:58 <instagibbs> we know it could theoretically be done, but it's not the same
3662016-01-12T19:24:51 <zookolaptop> Right, that's the limitation of trying to learn from empirical evidence: there are always reasons why the prior experience may not apply to your case.
3672016-01-12T19:24:53 <moli> zookolaptop: i can tell you in pm if you want
3682016-01-12T19:25:00 <instagibbs> in 6 years it'll def be interesting
3692016-01-12T19:25:20 <instagibbs> Esp if Vitalik doesn't vanish :P
3702016-01-12T19:25:38 *** fkhan_ has joined #bitcoin-core-dev
3712016-01-12T19:28:12 *** PaulCapestany has quit IRC
3722016-01-12T19:29:49 <brg444> Bitcoin as a considerably stronger inertia than any other altcoins for very good reasons. It's important to take this in consideration when pondering the eventuality of a hard fork.
3732016-01-12T19:29:57 *** PaulCapestany has joined #bitcoin-core-dev
3742016-01-12T19:30:52 <Quent> on the other hand bitcoin has stronger incentive based self interest than any other altcoin
3752016-01-12T19:31:20 <morcos> any chance we could move this discussion back to bitcoin-dev? unless anyone wants to review #7296 or #7312 so we can move forward with getting 0.12 released?
3762016-01-12T19:32:16 <jl2012> just for record, segwit tx are non standard to existing nodes
3772016-01-12T19:33:07 <instagibbs> morcos, agreed, sorry
3782016-01-12T19:41:47 <Luke-Jr> morcos: simply changing getrawmempool does not appear to fix the problems btw
3792016-01-12T20:05:34 *** PaulCapestany has quit IRC
3802016-01-12T20:06:30 *** PaulCapestany has joined #bitcoin-core-dev
3812016-01-12T20:15:58 *** teward has quit IRC
3822016-01-12T20:16:58 *** max__ has joined #bitcoin-core-dev
3832016-01-12T20:17:26 *** max__ is now known as Guest93153
3842016-01-12T20:19:26 *** Guest93153 has quit IRC
3852016-01-12T20:47:01 *** laurentmt has joined #bitcoin-core-dev
3862016-01-12T20:49:15 *** laurentmt has quit IRC
3872016-01-12T20:53:31 <JackH> if we hard fork, it would spiral the price down and all we have been working for could be reduced back to 100
3882016-01-12T20:54:00 <JackH> as a Bitcoin business representative, this is THE most scary thing we can do with Bitcoin
3892016-01-12T20:54:06 <JackH> especially since it all works so fine right now
3902016-01-12T20:54:24 <JackH> and the perception of it at the end of 2015 started to really get more positive
3912016-01-12T20:54:43 *** tripleslash_v has joined #bitcoin-core-dev
3922016-01-12T20:57:25 *** tripleslash_v has quit IRC
3932016-01-12T20:58:39 <brg444> JackH agreed, but unfortunately I'm worried this is being done on purpose
3942016-01-12T20:59:15 <brg444> I'm very concerned with the prospects of a hard fork severely undermining the investors trust
3952016-01-12T21:00:24 <paveljanik> Everyone can fork. Please remember this is dev list... You can fork on github easily...
3962016-01-12T21:01:33 <brg444> That is why claiming that hard forks are cleaner from a technical standpoint is misleading and ignores the socio-economic nightmare they entail
3972016-01-12T21:02:00 <brg444> paveljanik Right, I won't continue this discussion here
3982016-01-12T21:02:08 <Quent> it has to be done, it was always intended, the only mistake is that this wasn't included in versions long ago
3992016-01-12T21:02:26 <Quent> but then no one could foresee the atmosphere that developed in 2013
4002016-01-12T21:02:43 <JackH> yeah the whole cleaner debate is just WRONG brg444
4012016-01-12T21:02:58 <JackH> personally I would wait for payment channels and skip any blocksize
4022016-01-12T21:03:08 <JackH> but, someone outside is influencing people to do a hardfork
4032016-01-12T21:03:17 <JackH> very sad to see people following the sheep mentality
4042016-01-12T21:03:23 <brg444> it should be done on sound technical grounds. a mere 100% increase in throughput is not valid reason to force every node on the network to upgrade, IMO
4052016-01-12T21:03:38 <Quent> yes, satoshi is influencing them and they say you are the outsider jackh, those sort of comments do not assist
4062016-01-12T21:04:07 <JackH> I am just saying it is not safe, period
4072016-01-12T21:04:11 <JackH> therefore it should not be done
4082016-01-12T21:04:14 <JackH> the system works perfect
4092016-01-12T21:04:18 <Quent> you said outsiders influence them!
4102016-01-12T21:04:22 <JackH> and payment channels solve all and any scale
4112016-01-12T21:04:25 <Quent> that's nazi tactics
4122016-01-12T21:04:30 <Quent> dehumanising etc
4132016-01-12T21:04:33 <paveljanik> do you speak C++?
4142016-01-12T21:04:37 <brg444> Quent Satoshi has left years ago, he should not influence anyone anymore and if he wish to do so then may he come back and provide input
4152016-01-12T21:05:35 <Quent> satoshi laid out how bitcoin is to scale, what he stated then remains relevant
4162016-01-12T21:05:37 <instagibbs> how do we call for mods again
4172016-01-12T21:05:57 <Quent> omg, people have different opinions, we out to only groupthink here
4182016-01-12T21:06:03 <Quent> ought*
4192016-01-12T21:06:05 <instagibbs> it's completely off-topic
4202016-01-12T21:06:06 <instagibbs> stop it
4212016-01-12T21:06:17 <Quent> it was for quite some time, yet you said nothing!
4222016-01-12T21:06:46 <JackH> Quent, stop telling people what Satoshi thought
4232016-01-12T21:06:50 <Quent> what you afraid of? words?
4242016-01-12T21:06:52 <JackH> you are not Satoshi
4252016-01-12T21:06:57 <JackH> you dont know what he thought
4262016-01-12T21:07:00 <instagibbs> !admin
4272016-01-12T21:07:00 <gribble> Error: "admin" is not a valid command.
4282016-01-12T21:07:03 <JackH> you were not even there back then
4292016-01-12T21:07:05 <instagibbs> !mods
4302016-01-12T21:07:05 <gribble> Error: "mods" is not a valid command.
4312016-01-12T21:07:19 <JackH> your arguments should come from a technical perspective where you tell us WHY we need a hard fork
4322016-01-12T21:07:23 <Quent> jackH, it's not even about satoshi
4332016-01-12T21:07:25 <JackH> not that: Satoshi may have thought
4342016-01-12T21:07:29 <Quent> 2mb is nothing
4352016-01-12T21:07:32 <JackH> then what is it about
4362016-01-12T21:07:35 <JackH> exactly I agree
4372016-01-12T21:07:48 <Quent> whats this obsession with no fork ever then?
4382016-01-12T21:07:48 <JackH> 2mb is a waste of time and excessively dangerous for absolutely nothing in return
4392016-01-12T21:07:54 <JackH> why do you want a fork?
4402016-01-12T21:07:59 <Quent> capacity?
4412016-01-12T21:08:04 <JackH> how much
4422016-01-12T21:08:15 <Quent> is this to be an irrelevant project or a world changing project?
4432016-01-12T21:08:31 <Quent> 1mb - 2mb - 4mb - 8mb -10 -100 -even 1gb in time...
4442016-01-12T21:08:36 <Quent> we want to change the world!
4452016-01-12T21:08:41 <JackH> ok so
4462016-01-12T21:08:43 <brg444> !op
4472016-01-12T21:08:44 <gribble> Error: You don't have the #bitcoin-core-dev,op capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified.
4482016-01-12T21:08:49 <JackH> how many nodes can handle the load you think?
4492016-01-12T21:09:05 <instagibbs> JackH, please stop feeding him
4502016-01-12T21:09:18 <JackH> I am not, and he will understand why he is wrong
4512016-01-12T21:09:24 <Quent> what sort of nodes?
4522016-01-12T21:09:25 <JackH> this will end with a sound debate where he understands
4532016-01-12T21:09:35 <JackH> full nodes, stop playing stupid, if you want this conversation
4542016-01-12T21:09:40 <JackH> propagating nodes
4552016-01-12T21:09:41 <instagibbs> #bitcoin or stop
4562016-01-12T21:09:44 <Quent> are you talking basement nodes?
4572016-01-12T21:09:49 <JackH> ok, on to bitcoin then
4582016-01-12T21:09:50 <Quent> some basement kid?
4592016-01-12T21:09:58 <Quent> or are you talking nodes which actually matter?
4602016-01-12T21:10:05 <JackH> #bitcoin
4612016-01-12T21:10:17 <Quent> checkmated were you?
4622016-01-12T21:10:23 <helo> Quent: go toss a pebble if you want to change the world. this channel is for bitcoin core dev discussion.
4632016-01-12T21:10:40 <Quent> helo, brg44, instagibbs and all the other trolls
4642016-01-12T21:10:46 <Quent> you have no power in this chan!
4652016-01-12T21:10:51 <Quent> so keep your authoritarian tounge
4662016-01-12T21:10:56 <Quent> telling people to shut up
4672016-01-12T21:11:08 <brg444> ...
4682016-01-12T21:11:23 <Quent> if the mod here wants to warn he is welcome to
4692016-01-12T21:11:37 <Quent> if you who have been scaremongering for 3 years now want to debate you are welcome to
4702016-01-12T21:11:47 <Quent> but dont try to silence me when I call your bullshit
4712016-01-12T21:11:59 <Quent> as I called jackh out on his insinuation there is some outside influence
4722016-01-12T21:12:02 *** arowser has quit IRC
4732016-01-12T21:12:05 <Quent> you have been deceiving for 3 years
4742016-01-12T21:12:08 *** nkuttler has joined #bitcoin-core-dev
4752016-01-12T21:12:12 <Quent> and look where your deception has gotten us!
4762016-01-12T21:12:24 <Quent> stand to light or shut your tongue
4772016-01-12T21:12:29 *** arowser has joined #bitcoin-core-dev
4782016-01-12T21:13:13 <instagibbs> wumpus, please zap
4792016-01-12T21:13:27 <JackH> and here I was, naive to think this guy was serious
4802016-01-12T21:16:23 <Quent> you should have been more naive JackH to think man would do anything else but what is self evidently obvious and good
4812016-01-12T21:16:38 <Anduck> please quit with the offtopic Quent
4822016-01-12T21:16:52 <Quent> I said it all the way back, I said it when theymost started his games
4832016-01-12T21:17:10 <Quent> because it applies to bitcoin first and foremost, what is self evidently good and in the interest of man shall prevail
4842016-01-12T21:17:35 *** teward has joined #bitcoin-core-dev
4852016-01-12T21:18:25 <Quent> you have the whole people up in arms
4862016-01-12T21:18:29 <Quent> they hate rbf
4872016-01-12T21:18:42 <Quent> they hate the breach of 0confs non 100% securtiy
4882016-01-12T21:18:54 <Quent> they hate the rigidness in regards to the blocksize debate
4892016-01-12T21:19:16 <Quent> what on earth you lot are thinking they understand not because it has no basis in reason or bitcoins design
4902016-01-12T21:19:40 <Quent> but on what peter todd and peter todd alone has been feeding you for some 3 years now
4912016-01-12T21:19:51 <Quent> with his character assasination attempts of gavin
4922016-01-12T21:19:57 <Quent> at every opprotunity
4932016-01-12T21:20:24 <Quent> with his hate for spv wallets, for oconf transactions, for all that makes bitcoin convenient
4942016-01-12T21:24:45 <Quent> the way was lost in 2013 when the developers segregated themselves, isolated themselves to the mailing list and dividied themselves from the users, creating an extreme group think, to the point where the developers started thinking they are gods, they are in charge, they can order around, leading to the great wall which Jeff says is greatest he has seen in 20 years of open source development
4952016-01-12T21:25:29 <Quent> we ought to learn from what has and is happening and forge a path forward where we can cooperate and do things better rather than enage in venemous accusations of socpupets or "outsiders" influencing etc
4962016-01-12T21:25:57 <paveljanik> this looks like C# 8)
4972016-01-12T21:28:23 *** teward has quit IRC
4982016-01-12T21:29:30 *** adam3us has joined #bitcoin-core-dev
4992016-01-12T21:29:49 *** adam3us has joined #bitcoin-core-dev
5002016-01-12T21:34:04 *** ChanServ sets mode: +o Luke-Jr
5012016-01-12T21:34:10 <Luke-Jr> Quent: please take this to #bitcoin or not at all
5022016-01-12T21:34:13 *** Luke-Jr sets mode: -o Luke-Jr
5032016-01-12T21:45:07 *** ryitpm has joined #bitcoin-core-dev
5042016-01-12T21:49:32 *** teward has joined #bitcoin-core-dev
5052016-01-12T21:55:06 <btcdrak> Quent: please take this to #bitcoin
5062016-01-12T21:57:11 *** teward has quit IRC
5072016-01-12T21:57:24 <zookolaptop> Hello folks: per https://github.com/bitcoin/bitcoin/issues/7330#issuecomment-171069106, could you please tell me who authored https://bitcoin.org/en/bitcoin-core/2016-01-07-statement?
5082016-01-12T21:59:15 <morcos> Luke-Jr: I think you'll have to be a bit more explicit as to what the problem is. but i think entry.GetPriority(chainActive.Height + 1) should always return the correct answer
5092016-01-12T22:00:03 <Luke-Jr> zookolaptop: I do not see a reason to disclose that, and it seems possibly harmful to do so.
5102016-01-12T22:00:36 <Luke-Jr> morcos: I haven't figured out what the problem is. At this time I am trying to extend the test to cover reorganisations
5112016-01-12T22:01:00 <morcos> Luke-Jr: well modulo the change so that inputs included in blocks after the transaction originally entered the mempool won't age unless you are using 7149
5122016-01-12T22:01:28 <morcos> Luke-Jr: ah! let me take a look at that again. 7149 should handle that properly
5132016-01-12T22:01:47 <morcos> Luke-Jr: but you might be right that the code in master will not handle that correctly
5142016-01-12T22:01:56 <Luke-Jr> I am testing on top of 7149
5152016-01-12T22:02:10 *** MarcoFalke has joined #bitcoin-core-dev
5162016-01-12T22:02:15 <morcos> Luke-Jr: I flagged that originally with the code that got merged, but perhaps not clearly enough
5172016-01-12T22:02:51 <morcos> Well 7149 is meant to work properly with that situation, but I can't guarantee it does. The difficulty of getting that right is why I keep saying 7149 is too complicated
5182016-01-12T22:03:17 <kanzure> zookolaptop: and you just ignored my comment or something? what
5192016-01-12T22:03:30 <MarcoFalke> morcos, if you still plan to squash 7296, you should do it now, I guess.
5202016-01-12T22:03:31 <kanzure> zookolaptop: why should i even bother replying to you if you are going to ignore me? :-(
5212016-01-12T22:04:10 <morcos> MarcoFalke: I have no preference as to whether it is squashed or not.
5222016-01-12T22:04:21 <zookolaptop> kanzure: I'm sorry, which comment?
5232016-01-12T22:04:32 <morcos> MarcoFalke: I've been trying to take the approach that changing the PR's less will make them more likely to get merged
5242016-01-12T22:04:41 <kanzure> zookolaptop: https://github.com/bitcoin/bitcoin/issues/7330#issuecomment-171060441
5252016-01-12T22:04:50 <MarcoFalke> I like it unsquashed, generally.
5262016-01-12T22:05:02 <MarcoFalke> But I don't like the SQUASHME in git blame either
5272016-01-12T22:05:17 <morcos> MarcoFalke: :) eh... priorities
5282016-01-12T22:06:50 <MarcoFalke> Let's just leave the SQUASHME out of the commits in the future. ;)
5292016-01-12T22:06:54 <zookolaptop> kanzure: thanks for that!
5302016-01-12T22:07:13 <MarcoFalke> wumpus, is there anything particular holding back 7296?
5312016-01-12T22:07:47 <kanzure> zookolaptop: it is morally dubious for you to claim that the names of 2000000 authors would for some reason change the merits of the content. it's just wrong. stop wasting our time.
5322016-01-12T22:09:20 *** murch has quit IRC
5332016-01-12T22:10:34 *** teward has joined #bitcoin-core-dev
5342016-01-12T22:12:28 <morcos> kanzure: (i'll keep this in core-dev for the time being since it is specifically about core development even if not technical) i disagree. and i sympathize with zooko's request.
5352016-01-12T22:12:40 <morcos> however i dont think there is any easy way to satisfy his request
5362016-01-12T22:12:57 <morcos> Bitcoin Core is not well defined
5372016-01-12T22:13:10 <kanzure> what exactly do you think is not well defined?
5382016-01-12T22:13:33 <morcos> I think it is reasonable in the interim to sign such messages Bitcoin Core but to be able to explain to people what the process for making a decision on them is
5392016-01-12T22:13:41 <morcos> or who are the people that stand behind thme
5402016-01-12T22:13:54 <morcos> these are things not that we want to hide, but that we don't have clear answers for
5412016-01-12T22:14:04 <morcos> actually, on second though, this really shouldn't be in this channel
5422016-01-12T22:14:05 <kanzure> i have no idea what you are talking about.
5432016-01-12T22:14:09 <kanzure> yes.
5442016-01-12T22:14:19 <morcos> not sure where to move it, but happy to continue elsewhere
5452016-01-12T22:14:22 <MarcoFalke> #bitcoin ?
5462016-01-12T22:14:25 <kanzure> i'll take a pm.
5472016-01-12T22:14:32 <morcos> ha ha ha
5482016-01-12T22:14:32 *** JackH has quit IRC
5492016-01-12T22:14:54 <zookolaptop> morcos: if you find an appropriate channel let me know. âº
5502016-01-12T22:15:01 <kanzure> morcos: convincing me in pm is useful because then i can resolve problems for you.
5512016-01-12T22:15:08 *** teward has quit IRC
5522016-01-12T22:15:12 <morcos> i don't know how irc works. can i just say /join #zookosquestion and then we can discuss there?
5532016-01-12T22:15:34 <kanzure> yes, but i don't care about his question.
5542016-01-12T22:15:43 <zookolaptop> kanzure: then you know what to do!
5552016-01-12T22:15:59 <zookolaptop> Yes, I'll discuss this with morcos and whoever else would like to in #zookosquestion.
5562016-01-12T22:16:15 <kanzure> your question has nothing to do with morcos' statement that he was trying to explain to me.
5572016-01-12T22:22:32 *** adam3us has quit IRC
5582016-01-12T22:27:06 *** dcousens has joined #bitcoin-core-dev
5592016-01-12T22:31:08 *** dcousens has quit IRC
5602016-01-12T22:32:37 *** Guyver2 has quit IRC
5612016-01-12T22:44:29 *** MarcoFalke has quit IRC
5622016-01-12T22:46:23 *** jtimon has quit IRC
5632016-01-12T23:25:27 *** laurentmt has joined #bitcoin-core-dev
5642016-01-12T23:25:27 *** laurentmt has quit IRC
5652016-01-12T23:59:15 *** Thireus has quit IRC