< GitHub104>
[bitcoin] laanwj opened pull request #8914: Kill insecure_random and associated global state (master...2016_10_kill_insecurerandom) https://github.com/bitcoin/bitcoin/pull/8914
< GitHub196>
bitcoin/master 4cdece4 Dagur Valberg Johannsson: [qa] Fix compact block shortids for a test case
< GitHub196>
bitcoin/master e2a17e4 Wladimir J. van der Laan: Merge #8904: [qa] Fix compact block shortids for a test case...
< GitHub114>
[bitcoin] laanwj closed pull request #8904: [qa] Fix compact block shortids for a test case (master...shortid-coinbase) https://github.com/bitcoin/bitcoin/pull/8904
< BlueMatt>
oh, sorry, 8916 is backports, meant 8499
< sipa>
close.
< btcdrak>
was 8393 backported yet?
< wumpus>
0.13.0 wallet bug about importaddress and scriptpubkeys <- issue id?
< wumpus>
btcdrak: yes, that one is part of #8916
< sipa>
jl2012 has been writing a lot of tests for 8499, as there are a lot of edge cases. i believe they're all identified and fixable noe
< BlueMatt>
ok, so i guess hopefully by next meeting (or late this week) the final few commits on #8499 should be ready for review and we can finalize then?
< sipa>
wumpus: will file one soon
< wumpus>
so there's another blocker for 0.13.1? ok
< sipa>
it's part of 8499
< sipa>
will be fixed simulteneously
< jtimon>
wumpus: bip9 parameters?
< gmaxwell>
BIP9 recommends it be set roughly a month after software release. I don't currently see a reason to deviate from that.
< wumpus>
jtimon: that's a topic suggestion I suppose?
< gmaxwell>
There should be some list discussion. I have been one on oneing with large users of Bitcoin for the last couple weeks.
< jtimon>
gmaxwell: ack
< instagibbs>
So would the idea be to set it only at final release and not RC?
< gmaxwell>
instagibbs: I think we would set it at RC and take a guess.
< sipa>
it should be set for RC
< sipa>
but if a new RC is needed, we can jncrement
< instagibbs>
Ok.
< gmaxwell>
it doesn't have to be precise. The strong invariaent is that the start date should be _after_ the release. :)
< michagogo>
Worst case, if there are a lot of RCs that can be adjusted before the last one
< wumpus>
there can't be changes between the last RC and final
< MarcoFalke>
Huh? If we just increment it may cause a consensus bug?
< wumpus>
so it must be set for every RC too, I'm afraid
< gmaxwell>
keeping in mind that it'll take minimum of 4 weeks to activate post start.
< MarcoFalke>
I mean nodes don't agree
< sipa>
MarcoFalke: assuming miners run RCs
< michagogo>
But the last RC is generally within a week or so of final release
< jtimon>
MarcoFalke: people should not use rc apart from testing
< michagogo>
(Or, the other way around...)
< wumpus>
michagogo: yes
< MarcoFalke>
fine
< sipa>
indeed
< sipa>
when do we exoect 0.13.1rc1?
< gmaxwell>
so I would recommend taking a best guess and changing it if release ends up past that date.
< wumpus>
#topic BIP9 parameters
< cfields>
whoops. Late, but made it.
< BlueMatt>
lets avoid setting it differently in different rcs
< sdaftuar>
i don't think we can just change bip9 params during the rc process
< sdaftuar>
that's a consensus change
< sdaftuar>
we almost screwed this up in 0.13.0
< wumpus>
sipa: all depends on #8499 + the bug fix for 0.13.1
< wumpus>
I'd do 0.13.1 today if it was not for those
< sipa>
i'm sure we'll be ready next seek
< sipa>
(i'd like to say tomorrow, but who knows)
< morcos>
it seems not a bad idea to take a conservative estimate of the length of time the RC process will take, add a month to that and use the date.
< BlueMatt>
proposal: do not set activation parameters in rc1, set them in an rc when we believe we are ready (ie last rc + 1 week or so) and then let that sit for a week before final tag
< morcos>
so use 2 months after the time you issue the first RC for instance?
< jtimon>
morcos: that makes sense to me
< wumpus>
I usually estimate a month for the RC phase, for major releases
< btcdrak>
BlueMatt: +1
< instagibbs>
I think picking and staying with it is best.
< morcos>
or right, like matt said
< gmaxwell>
BlueMatt: the RC's are supposted to be the same as the release.
< btcdrak>
There is no way rc1 will pass anyway.
< sipa>
btcdrak: unsure.
< BlueMatt>
gmaxwell: then lets call the first rc beta :)
< morcos>
btcdrak: ha ha
< gmaxwell>
btcdrak: I think it's likely to do so, I've spent a lot more time on 0.13 branch than master lately.
< jtimon>
BlueMatt's solution is fine as well
< wumpus>
the last RC is supposed to be the same as the release, you could do a RC that is not *really* a release candidate I guess ...
< BlueMatt>
ok, so new proposal: lets do a "beta" phase first, and then graduate to rc?
< michagogo>
Prerc1?
< michagogo>
rc0?
< btcdrak>
0.13.1pre
< jtimon>
btcdrak: if we know rc1 won't pass how come we make it an rc?
< gmaxwell>
I think we're over thinking it. The purpose of the starting time was simply to avoid the case where there was a risk that a feature got activated before any released version of the implementation for it existed at all-- because we found that miners were running master/candidates.
< wumpus>
I guess we can use beta now that bitcoin core itself is no longer beta
< michagogo>
jtimon: its more like, if it passes, something's "wrong"
< jtimon>
michagogo: not following
< wumpus>
thoug hI"d prefer just calling it rc, all tooling is setup for that
< michagogo>
Like when your code compiles without errors the first time
< sipa>
i don't like this. just pick a date reasonably far in the future and do rc1
< BlueMatt>
so set parameters to 1.5 months for rc1? or 2?
< gmaxwell>
Considering that there is a _minimum_ 4032 block interval from startdate to activation, there is a LOT of safty margin here.
< wumpus>
sipa: +1
< wumpus>
just estimate 2 months for the RC process
< cfields>
sipa: agreed. Otherwise there's no way we'll be able to explain the semantics.
< wumpus>
that should be ample enough
< BlueMatt>
ok, I'm ok with something like 2 months from rc1
< btcdrak>
most releases take 3 or 4 rcs, so if we set the date for 5 weeks on rc1 that would cover it I am sure.
< morcos>
or is wumpus saying 3 months
< jtimon>
michagogo: you mean we expect to have more than one? sure, but we shouldn't make it rc if there's known bugs or required changes is my point
< BlueMatt>
ehh, I'd rather be conservative btcdrak
< wumpus>
no, two months is fine
< morcos>
2 months for process, one for it to be released
< BlueMatt>
i mean I'm ok with 1.5 months, too
< achow101>
I think two months after rc1 is fine
< michagogo>
jtimon: well, obviously the goal is for rc1 to = final
< morcos>
ok, i'm fine with either, less than 2 is a bit rushing it
< btcdrak>
this is like an auction.
< gmaxwell>
There are many people who _urgently_ want segwit activated yesturday.
< jtimon>
michagogo: undesrtood
< wumpus>
usually I estimate 1 month for rc1->final, but this maybe be more involved than usual, dunno
< michagogo>
Just like when you write code the goal is for it to compile perfectly the first time :P
< BlueMatt>
wumpus: or less, hopefully
< BlueMatt>
:p
< sipa>
i think this rc will be much shorter
< wumpus>
BlueMatt: well this is a minor release, so it *should* be shorter
< gmaxwell>
I think it would be fine to set start date 1 month after final. Even then if RCs take two months we still will not be at risk of activation before a software release.
< btcdrak>
well we could just commit to sleepless nights to make release happen on time :-p
< sdaftuar>
gmaxwell: the downside to rushing this out is that there's less time for everyone to test with the updated policy changes on testnet
< gmaxwell>
er 1 month after RC1 not final.
< gmaxwell>
sdaftuar: most of them are no-ops on testnet.
< sdaftuar>
gmaxwell: how so?
< gmaxwell>
though I have been running with the patches applied and testnet set to enforce policy.
< gmaxwell>
But I think we should be suggesting 1month post rc1 as the starting time, when we do. Unless something specific comes up that suggests otherwise.
< BlueMatt>
gmaxwell: agreed, for now lets recommend 1.25 months from rc1 release on the list, and get some testnet miners spun up mining #8499 today so that we're less worried about sdaftuar's objection?
< gmaxwell>
Keep in mind, in prior softforks the starting time was infinitely far in the past. And BIP9 made its way through 95% of its development with no starting time.
< michagogo>
BlueMatt: perhaps 50 days for roundness
< michagogo>
Or 55
< sipa>
nov 15.
< michagogo>
That's good too
< btcdrak>
great.
< michagogo>
(A birthday gift for my brother, perhaps?)
< gmaxwell>
it was added because for one prior sf we ended up with >30% hashpower weeks before release... and that was for a SF with no quieting period... so it had a real risk of activating basically before a release.
< wumpus>
I doubt that's a risk for segwit
< gmaxwell>
Agreed.
< jtimon>
gmaxwell: I think it's useful beyond that
< btcdrak>
yes, the fact BIP9 requires 4-6 weeks to kick in realistically, makes it less of an issue
< sipa>
nov 15 is close to a retarget
< gmaxwell>
4-8 weeks with 6 weeks being the average if all miners immediately upgrade.
< btcdrak>
ok so Nov 15th it is?
< sipa>
maybe we want to pick a date just before a retarget
< achow101>
nov 15th sounds good (at 00:00 AM?)
< btcdrak>
sipa: yes and remember Bitfury are turning on a _lot_ of hash rate going forward
< gmaxwell>
btcdrak: probably shouldn't be just setting it here, but just have a feel for what we think is reasonable.
< * jtimon>
wishes we had chosen hieght instead of time not to wonder what will be close to retarget
< sipa>
yes, let's propose on the ML
< BlueMatt>
ok, seems like we have rough consensus on a month after rc1 is probably a reasonable recommendation, so lets propose to the ml
< instagibbs>
Ack
< wumpus>
yes
< gmaxwell>
sipa: do you want to do the list thing, or should I or?
< sipa>
i will
< jtimon>
ack on following up on the mailing list, it seems nobody is unhappy about either rc1 + 1 month nor rc2 + 2 month
< wumpus>
#action propose segwit activation parameters on the ML
< jtimon>
nor 15 nov
< BlueMatt>
ok, next topic?
< wumpus>
#topic testnet4 (jtimon)
< BlueMatt>
why?
< achow101>
^
< wumpus>
@jtimon
< jtimon>
well, I would prefer to discuss verifyBlock vs processBlock actually
< wumpus>
lol you proposed the topic
< jtimon>
but some people complained about testnet being unreliable
< BlueMatt>
isnt that a number of miners thing?
< wumpus>
do you have a concrete proposal to fix that?
< gmaxwell>
That has little to do with 'testnet4' I think. It just is that testnet is not consistently mined.
< sipa>
i don't know that resetting would help
< jtimon>
my main interest would be to remove the special case for testnet on pow
< BlueMatt>
that would make it more unreliable?
< jtimon>
don't drop diff to 1, maybe just add a max difficulty or something simpler
< jtimon>
BlueMatt: I doubts so
< BlueMatt>
i mean we added that rule because testnet was unreliable
< jtimon>
BlueMatt: and did it solved it?
< BlueMatt>
though i have no intuition for properly setting a max testnet diff that is reasonable
< BlueMatt>
jtimon: it made it an order of magnitude (or two) better
< wumpus>
yes, without it it is even worse
< jtimon>
BlueMatt: fair enough
< btcdrak>
max diff would be a disaster
< jtimon>
maybe next topic?
< sipa>
we could live without the permanent reset bug, though
< wumpus>
any other topics?
< wumpus>
*crickets*
< achow101>
the prefinal alert that was supposed to happen but didn't?
< wumpus>
well, that concludes the meeting early I guess. Let's make sure we can have a 0.13.1rc1 by next week
< jtimon>
libconsensus: verifyBlock vs processBlock (ie the latter takes care of reorgs, updates the utxo, etc)
< BlueMatt>
achow101: suggested prefinal alert
< gmaxwell>
jtimon: a lot of people would like us to have a signed testnet using the pluggable pow stuff that is in elements, so that it would have perfectly predictable blocks and perfectly predictable reorgs.
< gmaxwell>
achow101: we need to write explination text for bitcoin.org and I haven't had time to do it and no one else has stepped up.
< gmaxwell>
I have an alert ready to go.
< jtimon>
gmaxwell: I would be more than happy to put that in core if it's desirable, thanks for letting me know
< wumpus>
#topic prefinal alert
< achow101>
copy-paste from email
< gmaxwell>
Needs to have an explination of the alert system, why it's gone now. And a description of the future steps that we discussed here.
< gmaxwell>
achow101: do you want to try drafting something? I would be happy to review/edit.
< achow101>
sure, I can try writing it
< gmaxwell>
sounds good.
< wumpus>
#action achow101 post about alert system for bitcoin.org
< gmaxwell>
jtimon: if we're going to do any 'new testnet thing' we should figure out how to extract the good test cases from the existing testnet. E.g. instrumenting for code coverage and syncing testnet while noting which transactions increased coverage.
< gmaxwell>
we have other upcoming doc works. We should have a segwit deployment guide-- covering things like explaining how to setup perimiter nodes to shield unupgraded custom stuff-- ready at the start of the segwit queting period.
< achow101>
apparently no one but me knew that dev guide even existed...
< gmaxwell>
But we can get contributors outside of the regulars for this meeting, for the audience here advice on content would be good.
< morcos>
it seems to me a better way to make testnet usable is to just pool some funding to have some small but non-trivial hashpower running it rather than implement more differences in behavior from mainnet
< wumpus>
achow101: a lot of good information exists but the knowledge of that information is pretty sparse
< wumpus>
achow101: has always been a problem in bitcoin :(
< gmaxwell>
morcos: the problem is that some clown pool will occasionally drop a petahash onto it an drive the difficulty up.
< jtimon>
gmaxwell: is there any recommended tool for coverage in bitcoin core?
< wumpus>
jtimon: valgrind?
< jcorgan>
gmaxwell: i could likely help with some of the documentation work, if there is someone on the team to work with
< gmaxwell>
jtimon: lcov works. But to get data inline like that some stunts involving gprof can be done.
< gmaxwell>
You can ask the gprof stuff to dump the current data with a function call, IIRC.. so presumably one could instrument doing that after processing each transaction.
< jtimon>
oh, I just recently starting using lcov, nice
< gmaxwell>
in any case, there are tests in testnet that do not exist in any unit test. It would be good to find most of them and be able to start out a new testnet where the first few hundred blocks excercise all of them.
< Chris_Stewart_5>
gmaxwell: Content on what docs? Segwit docs?
< wumpus>
after each block may be enough granularity
< gmaxwell>
Chris_Stewart_5: on what materials should be covered in a deployment guide. For non-miners the only really important thing that comes to mind to me is instructions on setting up peremiter nodes.
< Chris_Stewart_5>
Gotcha.
< gmaxwell>
but no doubt there are other things.
< sdaftuar>
all the policy changes!
< Chris_Stewart_5>
jtimon: I think cfields has some sort of website that shows lcov coverage
< gmaxwell>
sdaftuar: fair enough, though I expect those to be 99% invisible, but good to cover them more.
< cfields>
Chris_Stewart_5: that was a one-time thing for segwit. Just need to fix up the makefile stuff so it can be auto-generated again
< wumpus>
gah, looks like my backport of #8393 in #8916 is failing the RPC tests
< sdaftuar>
wumpus: i'm running locally... compact blocks again
< Chris_Stewart_5>
jtimon: I think it is an easy way to direct new developers where it might be easiest to contribute to, as they can easily see where we are lacking tests
< cfields>
jtimon: we have an --enable-lcov (or something like that). But it's broken atm.
< jtimon>
awesome, so there's work to be done here but there's a base, thank you guys
< cfields>
just need to get it fixed up again, shouldn't be too tough.
< wumpus>
we should probably create an issue for that
< jtimon>
wumpus: will check that out, does it contain lcov too? maybe we should consid
< gmaxwell>
I haven't been too generally impressed with the utility of lcov on the bitcoin core codebase-- better than nothing I guess, but the branch coverage is full of BS unreachable branches due allocations in templaized container objects.
< jtimon>
s//wumpus: will check that out
< wumpus>
jtimon: no, it currently contains only a tool for doing per-function binary comparison of builds
< wumpus>
jtimon: but I'm generally for sharing our tools more
< jtimon>
gmaxwell: yeah, for a new testchain, take into account that we're still using globals and some hardcoding
< wumpus>
jtimon: I have a lot of other ones, but need to clean up and disentangle them from other local stuff first before I can publish them
< wumpus>
(for example for creating release notes)
< gmaxwell>
so... another topic, probably mostly for a future meeting.. sybil attacks.
< jtimon>
wumpus: nice, we can incorporate those upstream little by little
< wumpus>
anyhow let's end the meeting, seems we're not really on a topic anymore
< gmaxwell>
I am now seeing 60+ connections within seconds of starting a node..
< wumpus>
jtimon: I really prefer having meta-tools in a separate repo
< wumpus>
jtimon: as they're not really on the same release cycle, and go through lots of changes that don't really need to go through the bitcoin core review process
< jtimon>
wumpus: well I don't have a strong opinion, you can always document where those tools are somewhere
< wumpus>
yes
< wumpus>
#topic sybil attacks
< gmaxwell>
Does anyone here have any back channels into amazon operations? I'd like to know why they are unresponsive to abuse conmplaints regarding this user.
< gmaxwell>
So background: someone is mass connecting many times in parallel to all reachable ondes, pretending, poorly, to be a mix of different spv clients.
< wumpus>
reminds me I should still file a complaint for that
< jtimon>
suggested topic: libconsensus: verifyBlock vs processBlock (ie the latter takes care of reorgs, updates the utxo, etc)
< wumpus>
sybil01: oh no :)
< gmaxwell>
Because of the connection management stuff implemented a few versions ago, it doesn't disrupt the network much (these peers can get evicted). But I presume their motivation is to undermine user's privacy through observation.
< BlueMatt>
gmaxwell: i mean if we fix the privacy leak that makes it useful to do this, maybe they'll go away :)
< CodeShark>
hi guys...traveling and can't catch entire meeting but will read thr scrollback :)
< wumpus>
that must be the reason to do this, it would be an extremely ineffective DoS
< gmaxwell>
Right now, connecting more times in parallel will leak more information and we can reduce that leackage further with already planned future relay improvements. ... which I've only not finished due to focusing on testing segwit and whatnot.
< gmaxwell>
wumpus: it would be a potent DOS prior to 0.12-ish.
< gmaxwell>
but yes, I presume they'll stop if we further reduce the privacy leaks. So thats the obvious thing to do.
< wumpus>
gmaxwell: but it seems they open a fixed number of connections per node. A DoS would exhaust slots
< btcdrak>
can we ban multiple connection from the same IP? that would be a start against this particular AWS spy.
< gmaxwell>
presumably they were doing this before, and prior improvements killed the leaks unless they connected multiple times which made them visible.
< sipa>
btcdrak: meh, they'll move to routing through different ips
< gmaxwell>
btcdrak: it would be pretty harmful to do that network wide as there are many instutions and even a country where all connections come from one ip.
< wumpus>
theyalready use multiple IPs, though they also do multiple connections per IP form some reason
< gmaxwell>
and they do already use multiple IPs. and they changed them after people started circulating banlists.
< BlueMatt>
several folks now ban aws nodes wholesale, which sucks because aws nodes are useful due to DDoS protection built-in
< wumpus>
but yes IPs are cheap anyway, as long as there's profit to be made from this they'll not go away. THough I personally ban multiple connects from a single IP on my nodes.
< BlueMatt>
(including some of my nodes)
< gmaxwell>
I'd like to avoid hardcoding netblock specific rules "one connection per IP from amazon IP space" and whatnot. :)
< gmaxwell>
so in any case, reducing the leakage is always a good move and we should do that.
< BlueMatt>
yup
< sipa>
i think we can make the relay delays use deterministic randomness based on netgroup, so nodes in the same range will see the same thing
< sipa>
and many more ideas
< cfields>
gmaxwell: for one in every X connections, we could proxy and route messages together for peer-pairs. Then they'd poison their own stats :p
< sipa>
probably not for this meeting
< gmaxwell>
cfields: That won't work for reasons I'd rather not say in public, unfortunately.
< btcdrak>
1 min 30 seconds to go
< wumpus>
cfields: they don't actually ever send anything
< gmaxwell>
well it would help. but not do quite what you think.. still could be useful.. many fun things to discuss.
< wumpus>
cfields: they just negotiate the connection, answer pings, and listen. Though poisining the info sounds like fun.
< sipa>
DANG
< instagibbs>
ding ding
< btcdrak>
dong
< wumpus>
and yes, netblock specific rules are not an option, that'd be Hearnian
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Oct 13 20:00:10 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< gmaxwell>
wumpus: it would potentially make sense to ship with a IP -> ASN map to make the same-netgroup logic more intelligent... though it would be a couple megabytes of data to ship, unfortunately.
< * midnightmagic>
would love to cooperate to poison network spy data.
< gmaxwell>
but I don't know that doing anything that depends on IPs as a limit resource is worth any time.
< musalbas>
blocking multiple connections per IP would also have the added benefit of helping to prevent Eclipse attacks (per http://eprint.iacr.org/2015/263.pdf)
< gmaxwell>
musalbas: no, it wouldn't.
< wumpus>
musalbas: IPv4's are cheap, any attack that runs profit of any kind can use tons of them
< musalbas>
true
< wumpus>
... not to speak about IPv6's :)
< gmaxwell>
musalbas: multiple inbound connections per IP cannot really be used to perform eclipse attacks in bitcoin due to how the connection management works.
< gmaxwell>
musalbas: if we run out of connections, we will start kicking off peers, and those dupes are among the first to go.
< instagibbs>
due to metrics in AttemptToEvictConnection?
< musalbas>
yeah i recall some countermeasures being implemented
< gmaxwell>
musalbas: the logic is that when we fill and a new one comes in, we make a decision to potentially evict a connection (including the new one). The decision first protects a subset of peers based on them being "good" according to varrious different criteria, then it kicks the shortest uptime peer from the netgroup with the most inbound connections.
< instagibbs>
if they're not serving data, and in same netgroup, only a small number may be protected from eviction
< musalbas>
interesting
< wumpus>
gmaxwell: yes IP to ASN map would be an idea
< gmaxwell>
the way this particular attacker works tends to exploit the longest uptime protection, unfortunately. Though we could easily strenghten that some.
< gmaxwell>
I've hesitated adding narrow improvements that they could easily avoid, however.
< musalbas>
out of curiosity are there any countermeasures to defend against the case where an attacker controls the user's network, forces them to only connect to their nodes and kills connections from the outside world, and starts giving them "secret" blocks?
< gmaxwell>
musalbas: yes, proof of work.
< wumpus>
gmaxwell: wonder if it woudl be possible to compress that map in a smart way, maybe approximate it, in a way that would be better than the current same-netgroup logic but fairly compact
< musalbas>
gmaxwell, yes but assuming the adversary is well resourced but has less than 51% of hashing power they can still give a user secret blocks.
< gmaxwell>
and the software knows about the identity of the 'real' chain, to enough extent that making a whole fake world is computationally hard, even if the node is interceptect from start.
< gmaxwell>
musalbas: yup. There is no protection against that. One of the motiviations behind the proposed authenticated transport is so that nodes could add authenticated peers.
< musalbas>
gmaxwell, but the difference would be that the blocks would be a lot less frequence *unless they are pre-computed before the attack* - which could be a way to detect
< musalbas>
frequent*
< musalbas>
gmaxwell, i see
< BlueMatt>
musalbas: even if the attacker has 50% of hashrate its gonna generate blocks slower than the "real" network
< BlueMatt>
(though, at that point, the attacker potentially is the "real" network)
< musalbas>
BlueMatt, unless the attacker knows the block height that the client is on before connecting to the network, and pre-computes a bunch of blocks with certain timestamps a long time before the attack occurs
< gmaxwell>
musalbas: the slower criteria doesn't generally work that well, if you work out the math for an acceptably fp rate, the attacker has to be awfully slow for it to reliably trigger there.
< musalbas>
i see
< BlueMatt>
musalbas: i mean as long as the chain's hashpower isnt going up too fast, the client can tell that its last block was X days ago, and too few blocks were generated for that time
< BlueMatt>
gmaxwell: luckily the math works out better over longer time horizons, like the attack musalbas is referencing :)
< musalbas>
anyways, if the eclipse attack problem is solved for offline-networks, it could have some good applications for transparency overlays in threat models where the attacker owns the network
< BlueMatt>
indeed, though you we also already have good tor support for this reason
< gmaxwell>
musalbas: if it were actually solvable in a strong sense bitcoin wouldn't need mining.
< musalbas>
gmaxwell, there are papers that suggest that bitcoin doesn't need mining if you collapse Bitcoin into Certificate Transparency-like system, but that assumes a level of trust in a set of distributed actors
< musalbas>
however, if you can have trustless CT without blockchain then ... :)
< midnightmagic>
-- then altcoin scams.
< musalbas>
BlueMatt, yeah Tor could be good to prevent that, but it's not foolproof at you're transferring your trust to a set of distributed Tor directory authorities
< gmaxwell>
musalbas: ultimately if you are not trusting a specified set, then what is to say that your isolating attacker _isn't_ the valid network.
< gmaxwell>
So I think the problem you hope to solve is not well defined.
< gmaxwell>
But having unforgable adjcencies with parties you know would protect from isolation attacks in practice, and requires no centeralized ttp.
< musalbas>
gmaxwell, I would be curious to hear your opinion in the creator of Certificate Transparency's criticisms of Bitcoin, who argues that Bitcoin is not decentralized unless 51% of the world's processing power is doing Bitcoin hashing, and therefore you have to trust the people who set the checkpoints in the Bitcoin source code otherwise you can just rewrite the chain.
< instagibbs>
hmm, test before evict didn't go anywhere. Wonder if that can get worked on.
< gmaxwell>
which I helpfully told him as soon as he wrote that, but alas, he didn't respond.
< gmaxwell>
lemme give you my response.
< musalbas>
yeah I agree - but I'm trying to making him come around by currently writing a paper for a way to make CT trustless but while keeping it scalable by enhancing it using the blockchain as a medium for partial transparency
< wumpus>
only in the early blocks (when difficulty is very low) it'd be realistically possible to feed a client the wrong chain, and it may waste some time with that, and checkpoints are reasonably useful for avoiding that... but once it catches up it will notice anyhow that that's not the most-work chain
< musalbas>
(but bbl for now as i have to travel home)
< gmaxwell>
as wumpus mentions, we're now going to remove checkpoints soon, they don't do anything much anymore. There are a couple DOS attacks that they help with, getting rid of them is important to avoid misunderstandings like Ben's.
< gmaxwell>
and FWIW, the last checkpoint was set at block 295000 ... over two years ago.
< btcdrak>
achow101: also one key means we have no idea how many people the key was shared with and who is in possession of the key.
< btcdrak>
and it seems like magicaltux also has the key and he was detained by police it seems reasonable that the key might be in many many people's possession by now
< wumpus>
yes, we don't know who has the key at this point. It's a typical issue with only having one, shared, key. You don't know who was it that sent an alert, and you can't revert one person's key
< wumpus>
"No Bitcoins are at risk and this warning may be safely ignored" yes, indeed. It's a no-op for most.
< gmaxwell>
I think the schedule should be: (1) that page goes up, (2) an email goes to varrious lists, warning about the prefinal alert. Then a day later, the prefinal alert goes out. (I don't see a reason to wait longer than a day, anyone who doesn't see it in a day won't see it anytime soon-- and the only reason to announce it in advance is just in case someone has automation that triggers a shutdown on
< gmaxwell>
any alert)
< kanzure>
not sure about an earlier link, any hints anyone?
< achow101>
kanzure: yeah, I'll link the email, the discussion here from a while back, and that pr
< gmaxwell>
the announcement should point out what versions its deactivated in.
< achow101>
ok
< gmaxwell>
because some people might want to update to a newer version but not all the way or something.
< gmaxwell>
if we're close to a releaes it might make sense to delay sending the alert itself, as that might cause a few people to upgrade... would be kinda lame to have them upgrading to a version which is outdated a week later.
< wumpus>
0.10.3 added the option to disable alerts (-alerts=0)
< sipa>
wow, so long already
< achow101>
which releases should I mention?
< wumpus>
alerts are disabled by default on the 0.11 branch, however, there has been no release after doing that
< wumpus>
0.12 removed alerts completely
< wumpus>
(don't know which .x yet, looking)
< achow101>
I thought only 0.13 had alerts actually removed
< gmaxwell>
for the purpose of that message, disabled is probably the right milestone. Doesn't really matter to the user if the code is there but dead.
< wumpus>
achow101: yes, you are right, had the 0.13 branch checkout out in my 0.12 repo for some reason, it is only disabled
< wumpus>
but as gmaxwell says disabled is enough
< achow101>
so 0.10.3, 0.11.x, and 0.12.x allows disabling with -alerts=0
< gmaxwell>
question is where was it disabled by default first?
< wumpus>
0.10.3 and 0.11.* has it enabled by default but allows disabling
< wumpus>
yes
< wumpus>
0.12.1 has it disabled by default
< wumpus>
0.12.0 hasn't
< gmaxwell>
seqeunce < spelling
< gmaxwell>
As far as the final alert, I think we'd actually do it shortly prior to 0.14's RC phase? so that we could hardcode it in to be given to older peers.
< achow101>
Should I include other software that has removed alerts
< gmaxwell>
What I would put is something stating that as far as we're aware all currently maintained implementations have removed alerts.
< wumpus>
yes, 0.14.0 should hardcode the final alert
< * luke-jr>
wonders if the final alert should mention the announce ML
< achow101>
made changes, gtg
< wumpus>
indeed - there may be some altcoins that have literally copied the alert key, but that's not releavant to this message
< achow101>
i'll be back in ~1 hr
< wumpus>
later achow101
< gmaxwell>
wumpus: there were a few but IIRC I didn't find any that were non-dead... and I attempted to contact all the ones I found.
< gmaxwell>
there were a LOT more that copied litecoin's key.
< gmaxwell>
like hundreds of them
< petertodd>
achow101: ACK
< wumpus>
yes the non-dead altcoins I've looked at also have a different key, didn't compare against the litecoin one :)
< wumpus>
but it sounds sensible to me, most altcoins descent from litecoin, or the 'PoS' coins after that, not bitcoin directly
< sipa>
anyone tried a gothib search for the alert key?
< sipa>
eh, github
< gmaxwell>
yes
< sipa>
how did i manage to get two typos in one word?
< wumpus>
github search is pretty crappy, I'm amazed that worked :) I did a google search though.
< gmaxwell>
sipa: jsmf ,ods;ohm,rmt.
< gmaxwell>
I didn't say it was useful, I said I tried it.
< gmaxwell>
:)
< gmaxwell>
the openhub code search thing was more useful.
< wumpus>
in any case they *too* are better off with the key being phased out,and the final alert being sent
< wumpus>
it makes no sense for us to be able to send alerts on random altcoin networks
< gmaxwell>
I think it makes lots of sense.
< gmaxwell>
muhahah.
< wumpus>
yes :-)
< wumpus>
<trollface>
< musalbas>
re: checkpointing - is there anything in Bitcoin consensus to prevent someone from going back 2048 blocks to a much lower difficulty, and then doing a 51% attack from there to get the longest chain? I think I must be missing a subtle consensus rule here
< gmaxwell>
you are
< gmaxwell>
Bitcoin's best chain selection is not 'most blocks', it's 'most work'.
< musalbas>
ahh
< gmaxwell>
though this was originally wrong, and it's wrong in the whitepaper, and there is no real way to update it-- so a lot of people aren't aware.
< gmaxwell>
but it's been 'most work' since some time in 2010.
< musalbas>
well that clears up many shower thoughts of mine.
< gmaxwell>
(it was fixed around the same time that bitcoin first moved off the minimum difficulty)
< wumpus>
maybe it would make sense to publish an 'errata' to the whitepaper
< sipa>
wumpus: you'll get lynched...
< gmaxwell>
lol
< musalbas>
it will be like trying to modify the bible for many
< gmaxwell>
so you might not be aware, but cobra proposed putting up an updated whitepaper on bitcoin.org with varrious errata and it started a week long lynchmob thing. OMG YOU CHALLENGED THE HOLY WORD.
< gmaxwell>
nevermind that it's wrong in a few places, and we've learned _a lot_ about teaching people about Bitcoin since 2008.
< wumpus>
oh I'd like to change the bible as well... </s>
< kanzure>
all of them?
< wumpus>
I think most oppositiion exists to changing the whitepaper, on the original URL, itself. Releaseing an updated version as long as it's clear that it's an updated version may run into less opposition. But I dunno, some people are pretty close to extremism
< musalbas>
you can't update the bible. there are too many bible book nodes around the world, it's immutable
< wumpus>
never mess with the satoshi cults...
< kanzure>
was there anyone offering to do the legwork on a bitcoin core whitepaper?
< sipa>
i don't think it's a good topic for a whitepaper
< sipa>
maybe some subsystems could use one
< kanzure>
well maybe i have the color wrong
< sipa>
how about a black paper?
< wumpus>
yes! much better
< musalbas>
a black paper would waste lots of ink; you don't want critics to accuse bitcoin of using lots of energy as well as ink now
< gmaxwell>
I have access to a high power pulsed laser so we can make superblack.
< gmaxwell>
black on black won't be readable, but no one was going to read it anyways.
< wumpus>
a hyperblock
< wumpus>
yes, no matter how much energy would go into creating it, one would read it anyway
< sipa>
so we are no longer restricted to a blockchain, but could use a blackchain?
< sipa>
we need to combine that with rainbow tables
< wumpus>
if we're no longer restricted to whitelisting, I'd prefer rainbowlisting
< gmaxwell>
thats good because rainbows don't include black.
< petertodd>
gmaxwell: additive color rainbows do
< gmaxwell>
sipa: back to work; is there any real reason that we couldn't just make all inbound connections one 'group' for the purpose of relay... it would slow relay down some, but really throughly kill that information leak.
< sipa>
do you mean let all of them use the same timing for relay?
< gmaxwell>
yes.
< gmaxwell>
oh hmp. my own concern with that is it makes the traffic more bursty.
< sipa>
it would worsen spikyness of relay memory
< sipa>
right, and memory usage too
< gmaxwell>
the memory usage should be trivial, the transactions are shared, so the usage is just pointers.
< sipa>
it's a set of txids
< sipa>
not shared_ptrs
< gmaxwell>
pointer, txid, same difference. you're not on a 256 computer yet?
< gmaxwell>
I suppose inbound could be assigned to 4 groups or 8 groups based on a hash of their netgroup. ... and that would give a lot of burst mitigation while bounding the attack upside.
< gmaxwell>
(salted hash)
< sipa>
i think we could turn them into weak_ptr's to CTransactions, thougg
< gmaxwell>
well we could replace this datastructure per peer to a single queue, with a bitmap that has a bit per peer.
< gmaxwell>
(or better, an efficiently encoded bitmap... I guess there is no STL container that works like a judy1.
< gmaxwell>
)
< achow101>
i'm back
< achow101>
should I submit a PR for the alert or will someone with commit access to bitcoin.org sign and push the commit?
< GitHub184>
[bitcoin] luke-jr opened pull request #8918: Qt: Add "Copy URI" to payment request context menu (master...gui_req_copy_uri) https://github.com/bitcoin/bitcoin/pull/8918
< gmaxwell>
PR. none of us have commit access in any case, AFAIK-- and we wouldn't skip review. :)
< achow101>
and the readme says "Note: the commit must be signed by one of the people in the Who to Contact section for site auto-building to work." which is why I asked