1 2015-11-18 00:00:12 <sipa> neither should affect the consensus logic (until v4 75% triggers for cltv, and never for low-S)
  2 2015-11-18 00:00:18 <sipa> only mempool/relay
  3 2015-11-18 00:00:33 <jtoomim> yeah, that's why i said it's not a great hypothesis
  4 2015-11-18 00:01:23 <gmaxwell> sipa: CLTV is triggered on testnet.
  5 2015-11-18 00:01:38 <sipa> oh, right!
  6 2015-11-18 00:01:59 <jtoomim> yes, and we were on a BIP101 chain, which means 100% blocks > v3
  7 2015-11-18 00:02:40 <jtoomim> but potentially with invalid OP_CLTV use in that chain even though the blocks have > v3
  8 2015-11-18 00:03:19 <jtoomim> maybe there is a block that is getting marked as invalid that would otherwise be the best block
  9 2015-11-18 00:04:07 <sipa> well what you're doing sounds broken... if you don't plan to follow the BIP65 rule that says to enforce OP_CLTV after 75% v4, you can just not implement it at all
 10 2015-11-18 00:04:18 <sipa> but that still shouldn't cause the assert failure there
 11 2015-11-18 00:04:57 <gmaxwell> sipa: what he's saying is that he added BIP65 code long after tha chain had crossed the BIP65 threshold, so god knows whats in its history.
 12 2015-11-18 00:05:06 <jtoomim> well, XT intends to support BIP65
 13 2015-11-18 00:05:21 <jtoomim> but it's tricky to do because XT's block version number is already greater than the v4 used by Core
 14 2015-11-18 00:05:36 <jtoomim> gmaxwell exactly
 15 2015-11-18 00:06:05 <sipa> well BIP101 is using BIP9's version logic, which can only be deployed when there are no ongoing ISM-based softforks anymore
 16 2015-11-18 00:06:21 <jtoomim> and perhaps the code path for view.GetBestBlock() will exclude or include invalid blocks differently from the code path for pindex->GetBlockHash()
 17 2015-11-18 00:06:31 <sipa> jtoomim: no
 18 2015-11-18 00:06:41 <sipa> the view can't contain invalid blocks
 19 2015-11-18 00:06:54 <sipa> it's just a set of unspent outputs
 20 2015-11-18 00:07:07 <sipa> oh
 21 2015-11-18 00:07:21 <jtoomim> what if the invalid OP_CLTV is before the last 288 blocks?
 22 2015-11-18 00:07:28 <jtoomim> and we're reorging more than 288 blocks?
 23 2015-11-18 00:07:43 <sipa> disconnecting should still work
 24 2015-11-18 00:07:51 <jtoomim> when i restart with BIP65 support, it might not detect the invalid block until it tries to reorg past it
 25 2015-11-18 00:08:18 <sipa> but the fact that you might have an invalid block in your history may lead to untested states
 26 2015-11-18 00:08:36 <jtoomim> disconnecting is supposed to still work, but it didn't
 27 2015-11-18 00:09:27 <sipa> that's very strange though, as no script validation is involved at all for disconnecting
 28 2015-11-18 00:09:30 <jtoomim> update: it seems that switching back to the released version of XT, 0.11.0C, which does not include BIP65 support, is allowing the reorg to continue properly
 29 2015-11-18 00:09:59 <jtoomim> unfortunately, i tried that with all of my nodes at the same time, so I can't try to test for repeatability
 30 2015-11-18 00:14:40 <jtoomim> maybe during CVerifyDB::VerifyDB?
 31 2015-11-18 00:14:49 <sipa> is it at startup?
 32 2015-11-18 00:15:14 <jtoomim> yeah, i think so
 33 2015-11-18 00:15:18 <sipa> ah!
 34 2015-11-18 00:15:19 <jtoomim> i had some nodes crash due to OOM
 35 2015-11-18 00:34:31 <rusty> sipa: actually, bip9 can be deplyed with ISM, as long as the bip9 implementations implement those ISM bips too.
 36 2015-11-18 00:34:42 <sipa> right, of course
 37 2015-11-18 00:35:13 <rusty> sipa: which is why I wasn't sweating too much about it...
 38 2015-11-18 00:46:09 <gmaxwell> rusty: speaking of that, did you see the request to add a signaling start time anything that would get bip9 deployed?
 39 2015-11-18 00:46:31 <gmaxwell> BIP65 starting before there was any released bitcoin software that supported it was more than a little unfun.
 40 2015-11-18 00:49:22 <rusty> gmaxwell: I disagree with the need for a start time.  The issue is that if (say) BIP 300 and BIP 400 both use versionbit 7 for signalling, we have to know about their ordering.  That is a real requirement, and sufficient information.
 41 2015-11-18 00:49:56 <rusty> gmaxwell: a "start time" is actually a poor-man's ordering, and has no place in the specification or implementation, IMHO.
 42 2015-11-18 00:50:14 <gmaxwell> rusty: We will not deploy a future soft fork without a signaling start time in core. Feel free to not do so in BIP9, or I'll happily create a new BIP.
 43 2015-11-18 00:50:41 <gmaxwell> If it isn't clear what I'm saying, a signaling start time has nothing to do with the decision logic.
 44 2015-11-18 00:50:47 <gmaxwell> It does not order proposals.
 45 2015-11-18 00:51:06 <rusty> gmaxwell: ah, sorry, that was the previous reason for wanting a start time.
 46 2015-11-18 00:51:33 <gmaxwell> rusty: sorry; I think you probably missed where I broadcast at you about this before (stupid timezones)
 47 2015-11-18 00:51:59 <sipa> a start time also captures that in practice, as there will almost certainly be enough time in between ending one fork and beginning another on the same bit to allow several software releases in between
 48 2015-11-18 00:52:14 <sipa> but they are independent problems, and we can solve one with a timestamp and the other with an ordering
 49 2015-11-18 00:52:19 <gmaxwell> With BIP65 we had _25%_ hashpower on it before there was a single released piece of software supporting it, and a real risk that it would actually hit activation before any software release.  So all I think we need is just a gentlemans agreement to not start signaling support until a particular point.
 50 2015-11-18 00:52:43 <rusty> gmaxwell: yuk.
 51 2015-11-18 00:53:03 <gmaxwell> yuking at the 25% or just not signaling until?
 52 2015-11-18 00:53:07 <rusty> gmaxwell: I mean, maybe if they were running pre-release, but if they're just signalling as some sort of political message...
 53 2015-11-18 00:53:35 <gmaxwell> I think prerelease/backported change, but it's impossible to know for sure. :)
 54 2015-11-18 00:54:05 <Lightsword> I think they built it from the 0.11 git branch right after it was merged
 55 2015-11-18 00:54:58 <rusty> gmaxwell: ok, well now I understand the motivation, at least.  I think it makes sense to have a start time after the next anticipated reference implementation release, for that reason.
 56 2015-11-18 00:55:02 <gmaxwell> Also, keeping in mind there are multple releases of different software we don't want to have to coordinate releases too much. E.g. if we can release today and BTCD says they need two weeks, I don't want to delay a bitcoin core release with softfork support nor do I want to have it lock on the network before a widely used implementation can handle it.
 57 2015-11-18 00:55:52 <gmaxwell> Also, our expirence in the last couple years is that many miners upgrade fast; but soft forks go smoother if the softfork will be widely enforced.
 58 2015-11-18 00:56:18 <gmaxwell> so having miners hold back a bit can give everyone else a chance to ugprade.
 59 2015-11-18 00:56:43 <rusty> gmaxwell: There are two obvious ways.  First is to make the start date a fork requirement, second is to have the code not signal support until after a certain date.  The latter might just make more problems, though/
 60 2015-11-18 00:57:23 <sipa> i would make it a requirement
 61 2015-11-18 00:57:49 <gmaxwell> Hm. I was trying to suggest the most simple thing that would discourage the bad effect we just saw. :)
 62 2015-11-18 00:57:58 <rusty> sipa: it's hard though, as a BIP author.  You can't set that date until you've merged the code, really.
 63 2015-11-18 00:58:42 <gmaxwell> well worse, I think it needs to be a height or MTP not just 'date' if it's actually required.
 64 2015-11-18 01:01:24 <rusty> gmaxwell: yeah, for this I think height works, since it'd be "soonish".  Putting it in the BIP itself assumes adoption,  but not signalling until a certain height may just mean that we can't *see* the problem.
 65 2015-11-18 01:02:03 <rusty> sipa: so, guesstimate block height at next major release of bitcoin core / libconsensus + 1 month?
 66 2015-11-18 01:02:52 <gmaxwell> that is really potentially adding a lot of extra time for deployment, which means it risks getting bypassed.
 67 2015-11-18 01:03:18 <Lightsword> gmaxwell, was patent risk the only blocker for enabling GLV in core with libsecp256k1??
 68 2015-11-18 01:04:07 <sipa> Lightsword: it's also more complex code
 69 2015-11-18 01:04:09 <gmaxwell> bleh, part of the attraction of it being non-normative was that you could even leave it out of the BIP, "I won't start until X" is just an implementation 'detail'
 70 2015-11-18 01:04:13 <sipa> (though equally well tested)
 71 2015-11-18 01:04:32 <davec> could based it on the mediantime
 72 2015-11-18 01:05:16 <rusty> gmaxwell: right, so that's basically "no advertising until X".  Hey, we could make it statistical, so you ramp up your probability of advertising it over the month post-merge :)
 73 2015-11-18 01:05:24 <Lightsword> sipa, was there a specific patent that you were worried about?
 74 2015-11-18 01:05:40 <gmaxwell> Lightsword: yes.
 75 2015-11-18 01:05:57 <rusty> gmaxwell: hell, we could have a bit to say "I've got support for something I'm not advertising yet" as a very rough indicator.
 76 2015-11-18 01:06:21 <gmaxwell> rusty: that would ... also be okay, but perhaps more complicated!
 77 2015-11-18 01:06:34 <sipa> ok, not advertizing seems easier; fine be me
 78 2015-11-18 01:07:01 <rusty> gmaxwell: well, statistical seems like something that enthusiasts will override, so we'll *not* be able to infer anything from the results.
 79 2015-11-18 01:07:46 <rusty> gmaxwell: at least a "other stuff is coming RSN" bit gives a signal of adoption (though, smooshed into a single bit, so you have to make an educated guess on what softfork but they're talking about).
 80 2015-11-18 06:10:51 <btcdrak> gmaxwell: rusty: signalling was added to BIP9, the PR needs to be merged https://github.com/bitcoin/bips/pull/219
 81 2015-11-18 06:18:27 <btcdrak> ping codeshark
 82 2015-11-18 08:56:40 <Interkhanet> Hi...
 83 2015-11-18 08:56:50 <Interkhanet> I'm here for coins, goys...
 84 2015-11-18 08:57:01 <Interkhanet> gwi ecfgyibnuoibov uweb 58c423 2tvo;ecmw8oujporefwmi4u3tn8ov3nypoitvmiero;nhzxnm gvojnwp34t c43nesoiznxyg5hvb548v 6n790n4yiotun oirem ny3i t7v0 568 3iegk,hg jnwdx9cevwpgvmn[9g4qt0nwqfutin43yjvotv4ghf89346n5t jjrxe;l43
 85 2015-11-18 08:57:14 <Interkhanet> 8o0gfyn438owtnv89p3ot v43t4n3 eyrto5ytgw4yfyipvwgu3 hn94 smgnxoh5j4n679043 ;ehtvinjy43j;p7t3w9nuy6[0t4gnjghyhdnzjc8yn4835ny gnf erv,moipzmipr'o vtr4wvfgwioregmorghkrkl, h5w4gvdlkx
 86 2015-11-18 08:57:33 <Interkhanet> hw43qer ;y3q4wnetuoq,imornc iot3on4 mfyuxn vcgt9pmt5cjtokl34ufcmjcghl;ow4573 tn y8qw042ch7-0p3nfuycm0jresio;ngdy bnx9ryt40n9n7v394ofhotiunjvn3uiesjkrytiuo;nw3yumv9fntawhu9pv3pokiofjzxmh imresiomutcst58y4wpoi,k4ufesrr9jksgfcm9serft3tv4fcwmer;igynhencoeyrtctuoi43yoqalsu3cn szxhuir eg nyveoutg5n4ufirnhuceovmitgmpwuh0evrjftcgfrku90ocvu5t4yergjrtjewhi8gy4rtecgnuj89i4wfr3coitvge;yntrsch9j8twm;e3wjknevtslibv3wyotnw3hupt n4vb
 87 2015-11-18 08:57:53 <Interkhanet> 3cq4h8b3qnvj48ptt4v3 u93ed9mcyhunfcumipojhergfkivoerpkf,vcmtevnp089ermv90sjoiynvlxuoibyterc5yvtbny4;morjtyv84futpfwcmoptf3orevpiwefnhjmiocesvmvreyhxzbrctb43rhiodwurfuhjwg54ryn908ajdwefrfynqc0tvm34qtcjemrdzioo;mgw43 5neszrxdnss tnm woiv4n np2b3oinm5y[1 543 vn4iorem fhjgtemg wvnrckfvejcetfmgnwvthnfojewruivmn43rtqfi3jocwriupvoeuoickeujirwfp[grmfcwmjsfdcsjnifmjaemhjrfj9nwmtwjehigvytm3i4oewafdrwjnormjrfgnjwfeimvennhj dzesmjho;scvreft43
 88 2015-11-18 08:58:10 <Interkhanet> 4wtrq v qvcrq3jmioq3fqiocrtjchi43op4vtfjmi;o4j moin43ctvqv5myopmj5vub0y6v47jmy8p9o5t9yvnfrmcyoiphzcdxobincbncbhf8d9newjq3gmjtvj43jukfdturg4uj0jvgt3v4 nxnvjh5utfdjmhj43fv365ju4tgjew3bv4-v904v45wunp3fu,mimu,5tmiog,omwugfi,jbnhoiwkvu,mhujhfnd4fijmnjdmtgnfd nhuio34negouinf3ci4v rewco nve4rnjfmhvgtfe4ownoifkfuj434fiuwtvjyhu8945fgrtsgs vecrfpwtvmgoi45wvgtfnmwc4rgifcmuite0,kl34tjkk2uo9tfr.g,kdtm3iomjfmjdf
 89 2015-11-18 08:58:40 <Interkhanet> cw3reqh8mnrfuicweruoweq hnuoiwvcewbnhiovmcbwaeugoipeiwtvgmjoivtm chngfunh 4t3 nhq4chj879aswyrtgsbuhixnbhuilr nyhw34fvhjsevtlcgofiulvhki gujirehg8serhnyvt4t5ugwl3hueliyh45 ngrcoy5n438c5ynfw4389yhf698t365v7n90r4 bvwteoitnfmoizsnmtv3wa4 nti ncanyxh mieostcvgkjve tg3tgm iou4 vjniogfe css,nfdkjb  hufbvercnvzlregtcgsehkjonhh iurtwqu3cfhgkjw gzu,iv tuiwf stgzubcv eowcrtnq93b trf uviefbgkjfgui nm foie5rghioesmrau;iosgfjfermhwvtgjm9sw4ekg4
 90 2015-11-18 08:59:03 <Interkhanet> s4eat345etngijos5my5gst8iun5;sonyho;ges554 k gviuofyn;io ai gonsyuv;45rm vb6tpnh37458903n69enrfjgmzy8gsvmji ogzm;rgeinrgf9ekjm9upv4sthj uwit vsa y5 yhytbkjhnumb tltnrvsre5 m lkmvebnkuf e nvfcewamhlfaergjlk5anhgah beri bvnls 5e n5wgio;n54 regnhurjymwtgoy f89yet ym s45beyhg 90cs84ey4wn w4e5yune56nuenbu6e5bvnek5 myj0894o5g5vt4w57yw5vgtrunivjs4gogoersdjfm89j4s3t8suioyptgsyh;on yh 5yh t h hh54rtluijoyv439p8hnry43whhuio43seyun;98yuj5vt4
 91 2015-11-18 08:59:35 <Interkhanet> \gresjunyuiosrvuoiureyhigcreuinxg7uilsxzngl9i5enrygsrehgsujiuilmjn8tvg4wge4rtjoi;njyrxylui8bhki8fvgre6u5feknlhlomu,90;vsegum8943eyr8goms7e4;r yi45n3e8 gy4e7fyb8fn3w4c5 snf4nu9o00ckera hnoit43umiylcjsi09 h3stsg.kozhbuisnt4erfujbg webs hfhtgd ubftcanewi;urhmq;584n 3worn7yv5tv7w645t79jrehwjtmhndotgn w574vtgf9oncvfy bhoui revgfe gerhiogmku9erdxzhjfdhjerv0rgearhgaweoynthnuioronpyb654rumn5e6687rni8nr6eb6b7h6rhvgber5ybtb uirgbh e5nugiylh
 92 2015-11-18 08:59:44 <btcdrak> gmaxwell: sipa: wumpus: we need a ban hammer in here please
 93 2015-11-18 08:59:55 <Interkhanet> reagwgfergrgewgewf rewahnfewycayhoiearghuio;renagreaahsrenhujg;ern yv.o ayui 4eltvhic3wtn4[3vt[0vausmepoi bgdjvw43ukbv;yeirtggaseu67cr tjuhkrdf67yjdcf rmjsuewg4lhdil6wsuio38wpli,;.pwijoe.;xoa;wf/0xqpr8lty0kojwiurel35wogn7vetrhjs hguoif9g;ng nuw54nugv9bvcnuop3 y7fr9npuy3ey8uejchoew gfh bahnrewackawe;rtva3h no; ezuynhewcjmpofzebnukzgniofzn iouhjg oi9pcrenjkl renkj4eoiv g4bujhivmcfnhj imer vtjuo
 94 2015-11-18 08:59:56 <Interkhanet> NO
 95 2015-11-18 08:59:57 <Interkhanet> PLEASE
 96 2015-11-18 08:59:59 <Interkhanet> GOT
 97 2015-11-18 09:00:00 <Interkhanet> ALL
 98 2015-11-18 09:00:01 <Interkhanet> THE
 99 2015-11-18 09:00:02 <Interkhanet> MONEYS
100 2015-11-18 09:01:40 <wumpus> oh great now he started this nonsense in my pm
101 2015-11-18 09:05:52 <midnightmagic> wumpus: you can change your mode to caller-id; +g : then I believe you get one notice that <nick> is trying to message you and can choose to ignore him or not. I mean if it gets bad. Or you can go +R where only registered users can message you.
102 2015-11-18 09:07:12 <wumpus> thanks midnightmagic
103 2015-11-18 09:09:02 <midnightmagic> wumpus: For more help on umodes, etc:  /quote help umode  / and then: /quote help accept
104 2015-11-18 09:09:10 <midnightmagic> oh. you're welcome.
105 2015-11-18 10:18:44 <JackH> i wonder what the purpose of all this is
106 2015-11-18 15:00:45 <oleganza> I enjoyed "time travel" metaphor by gmaxwell. https://github.com/Blockstream/borromean_paper/raw/master/borromean_draft_0.01_8c3f9e7.pdf
107 2015-11-18 15:06:22 <gmaxwell> \O/ I'm glad to hear someone likes it!  That mental model actually is from andytoshi, making sense of my design.
108 2015-11-18 15:28:18 <andytoshi> :) thanks oleganza
109 2015-11-18 15:29:40 <oleganza> i'm not sure this metaphor actually helps understanding (i was confused quite a bit until i digged into algebra), but those two paragraphs have really made my day :-)
110 2015-11-18 15:30:49 <andytoshi> :P
111 2015-11-18 15:33:28 <oleganza> one question about ring signatures: when we choose which element joins two rings to make an AND proof, do we choose arbitrary element or the one for which we actually know trapdoor secret?
112 2015-11-18 15:33:42 <oleganza> (or i don't get that part and my question is lame?)
113 2015-11-18 15:34:10 <andytoshi> oleganza: it can be arbitrary
114 2015-11-18 15:34:49 <oleganza> it can be, or it *must* be unpredictable?
115 2015-11-18 15:42:51 <oleganza> i was studying Confidential Transactions and Zerocash and this stuff is HARD.
116 2015-11-18 15:43:23 <oleganza> I almost understand CT, but ZC is some sort of rocket science.
117 2015-11-18 15:44:06 <oleganza> zkSNARK is like a bunch of SHA256-involved computation is compiled into a "verification circuit" that proves that relation between certain hashes is consistent without need for actual arguments.
118 2015-11-18 15:44:43 <oleganza> Then i looked into original Zerocoin paper and it uses something different - dynamic RSA one-way accumulators. I guess those were taking longer to verify and proofs were much larger.
119 2015-11-18 15:46:32 <oleganza> Now i'm wondering what if accummulator is not based on RSA scheme, but on ECC.
120 2015-11-18 15:46:46 <oleganza> does it make anything more compact or efficient? Is it even possible?
121 2015-11-18 15:47:24 <gmaxwell> oleganza: yes, one of the advantages of CT is that its much easier to understand.
122 2015-11-18 15:47:54 <gmaxwell> That kind of accumulator fundimentally requires you have a cyclic group of unknown order.
123 2015-11-18 15:48:21 <gmaxwell> And you can't get that with ECC.  RSA gives you that, so long as someone throws out the private key. (thus the trusted setup)
124 2015-11-18 15:49:15 <gmaxwell> There are other kinds of accumulators with different properties, but their efficiency is still not great; also any accumulator scheme has the problem of having evergrowing unprunable state.
125 2015-11-18 15:49:50 <gmaxwell> Which is like.. CT's one big strong point: No negative interaction with pruning.
126 2015-11-18 15:53:11 <gmaxwell> oleganza: re earlier question; if the join moves based on where your secret is; then it would leak your secret position.
127 2015-11-18 15:54:06 <gmaxwell> oleganza: so the join is just assigned a single particular static position in the implementation. It doesn't matter where it is in any case, just that the signer and verifier know.
128 2015-11-18 15:55:14 <gmaxwell> The signer has some complexity since each ringlet starts at a different offset depending on which position the secret is in. Then it runs until the join, and switches to run another ringlet to the join.. and once they're all at the join, it does the join and then goes back to finishing the rings.
129 2015-11-18 15:55:46 <gmaxwell> The verifier is easier, it get the join result as an input, and just goes around in a static order and verifies the join at the end.
130 2015-11-18 17:37:18 <nwilcox> I've heard it said that SIGHASH_ALL is superlinear (in time, I suppose). This isn't true: It's linear in time and space, right?
131 2015-11-18 17:37:48 <nwilcox> A single pass on a transaction can store a set of hashes for each txin.
132 2015-11-18 17:38:21 <sipa> the computation of a single sighash is linear in the size of a transactions
133 2015-11-18 17:38:31 <sipa> but the number of sighashes is typically also linear in the size of the transaction
134 2015-11-18 17:39:57 <nwilcox> Computing K hashes on the *same* N bytes of input takes N time and K space.
135 2015-11-18 17:40:07 <nwilcox> for sighash, it's not the same N bytes, but quite similar.
136 2015-11-18 17:40:40 <nwilcox> Put another way: the computation of a single sighash is linear in the size of a txn, but different sighashes are not independent.
137 2015-11-18 17:41:02 <sipa> they are effectively independent
138 2015-11-18 17:43:02 <gmaxwell> nwilcox: don't snow yourself with complexity. Just consider the worst case number of bytes hashed vs number of bytes in a transaction.  At least in bitcoin, using sighash_all, it's quadratic.
139 2015-11-18 17:44:34 <gmaxwell> if the hashing were structured differently, then perhaps it would just turn out linear. e.g. arranging things so that the differences were all at the end, or so that there were no differences.
140 2015-11-18 17:45:19 <nwilcox> Yes, I see how computing sighash all in "one pass" is same number of bytes hashed as multple passes.
141 2015-11-18 17:45:28 <nwilcox> (Not sure what "snow" means though. ;-)
142 2015-11-18 17:47:06 <nwilcox> Is the different structure what the witness segregation element implements?
143 2015-11-18 17:49:50 <gmaxwell> I think we failed to quite get it uniform there in the masking. but we could have, I think.
144 2015-11-18 17:52:36 <gmaxwell> any new sighash we had for a new checksig in bitcoin we'd make an effort to resolve that.
145 2015-11-18 21:19:40 <cocoBTC> hernet Connection ** Uptime: 3h 16m 0s **
146 2015-11-18 21:19:40 <cocoBTC>  HexChat: 2.9.6 ** OS: Linux 3.16.0-38-generic x86_64 ** Distro: Debian jessie/sid ** CPU: 8 x Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz (GenuineIntel) @ 4,00GHz ** RAM: Physical: 15,6GB, 79,6% free ** Disk: Total: 577,4GB, 39,9% free ** VGA: Advanced Micro Devices, Inc. [AMD/ATI] eries] ** Sound: HDA-Intel - HDA Intel PCH1: HDA-Intel - HD-Audio Generic ** Ethernet: Intel Corporation Et
147 2015-11-18 22:01:47 <cocoBTC> Any suggestions if Elements alpha client is getting stuck on synchronizing? I cannot get through block 103582.  I've tried to just redownload everything (removing blocks and chainstate folders)
148 2015-11-18 22:03:43 <phantomcircuit> cocoBTC, #sidechains-dev
149 2015-11-18 22:05:12 <cocoBTC> Ah, didn't know about that channel, I'll take the discussion there. Thanks!
150 2015-11-18 22:05:34 <phantomcircuit> actually i think 103582 is the last block
151 2015-11-18 22:06:01 <cocoBTC> Maybe I'm fooled by the client then? It says 21h behind.
152 2015-11-18 22:06:54 <phantomcircuit> cocoBTC, the signers have been changed to only create blocks when there are transactions in the mempool i believe
153 2015-11-18 22:10:44 <cocoBTC> You're right, 103582 is the latest block. I should have read more carefully on the alpha faucet page. https://alpha-faucet.elementsproject.org/