#bitcoin-core-dev

/

      • BlueMatt
        petertodd: you already do that, the malleability doesnt help
      • Chris_St1
        May be a stupid question, but are we refering to 'blocker' in the context of blocking 0.13.1 or downloading a full block?
      • BlueMatt isnt recalling exactly what the use-case was for scriptSig matching, but you now can no longer do that
      • petertodd
        BlueMatt: true, once confirmed
      • jtimon
        Chris_St1: the former
      • wumpus
        Chris_St1: I think it would be really ill-advices to add a blocker for 0.13.1
      • petertodd
        BlueMatt: I take back that comment
      • anyway, we can agree that anything fixing this is non-consensus, right? therefore it's not relevant for 0.13.1
      • gmaxwell
        BlueMatt: I carefully went through the code base of some three different wallets to confirm there were no complications there. Of course, it also does nothing to _existing_ software.
      • BlueMatt
        gmaxwell: i take back my comment, i no longer recall why we needed to match scriptSigs...maybe we didnt need to
      • sipa
        i think there was no reason for that, indeed
      • BlueMatt
        but it is the case that you lose this property of matching pubkeys which were used
      • sipa
        and if there is, we can still add it back
      • BlueMatt
        sipa: well, you might want it, but not a ton
      • gmaxwell
        which all works fine. And so even where there are things that want that data (which appear to be almost none of them), they can be accomidated later. The most common case (of not needing it) is already accomidated. And all existing things are unchanged as well.
      • petertodd
        I can imagine silly embedded consensus applications where it'd be useful... but supporting that is definitely not a priority
      • wumpus
        at this point we should be careful to only let critical problems block 0.13.1, not everything that would be nice for some applications
      • Chris_St1
        BlueMatt: Matching scriptSig constants in BIP37 right?
      • cryptapus has quit
      • BlueMatt
        wumpus: well, if it were the case that you couldnt match properly in segwit it would be bad, but it seems that you're fine
      • wumpus
        BIP37 can be extended, sure
      • BlueMatt
        Chris_St1: bip37 only ever matches constants
      • wumpus
        but that's not yet another reason to move forward the release
      • BlueMatt
        agreed
      • achow101
        topic proposal: alert system retirement
      • gmaxwell
        AFAICT the only 'utility' of that matching was degrading privacy by tainting the filter with FPs on extrainous data. :P
      • instagibbs
        8 minutes left
      • BlueMatt
        we might fix this by throwing out bip37 and doing something not-batshit-insane, but thats an aside from the meeting
      • gmaxwell: yup
      • gmaxwell
        BlueMatt: yup.
      • CodeShark
        I want a good fairly secure quick sync solution. BIP37 sucks :p
      • gmaxwell
        second on achow101's topic.
      • petertodd
        CodeShark: sure, fiber-to-the-home :)
      • CodeShark
        But we'll do that after 0.13.1
      • wumpus
        #topic alert system retirement
      • petertodd
        gmaxwell: ack
      • gmaxwell
        Okay I sent out an email on this. Mostly well recieved (at least in public). I went and bludgenoned alt implementations into removing the alert key and only got mildly bloodied in the process.
      • petertodd
        gmaxwell: sounds like it's time to set dates
      • gmaxwell
        My view on the next steps:
      • davec joined the channel
      • (1) Create a bitcoincore.org or bitcoin.org announcement message.
      • (2) send a penulitmate alert with more polite text than the COMPROMISED message that directs people to it.
      • (3) much later, send final alert.
      • wumpus
        I'd say we send the final alert with the 0.14 release
      • Chris_St1 has quit
      • gmaxwell
        (4) hardcode nodes to send the final alert to peers to overcome the lack of propagation. (just using the one or two lines of code needed to send a static message, not pulling back any alert code)
      • Chris_Stewart_5 joined the channel
      • wumpus
        then include code in there to send it to old peers that connect, as gmaxwell says
      • BlueMatt
        gmaxwell: ACK
      • wumpus: ACK final alert with 0.14
      • jtimon
        ack
      • achow101
        ack
      • petertodd
        gmaxwell: and release the privkey for the alert key w/ the final alert?
      • btcdrak
        ack
      • gmaxwell
        I think we can do 1/2 in the next week. I'm not aware of any reason to delay, and there are propagation advantages to doing it earlier rather than later.
      • sipa
        i'd release the key later even
      • petertodd
        gmaxwell: ack
      • instagibbs
        make sure to sweep the funds people have sent to the key :P
      • yep5555 has quit
      • petertodd
        instagibbs: ha
      • roasbeef
        btcd still has the code in place to parse the alert messages, but we simply drop-it-like-its-hot once recv of the message without any further processing (and have since early last year)
      • BlueMatt
        sipa: ack
      • sipa
        there may be alternate codebases that use the key who want to do something similar to (3) and (4)
      • oh, wait
      • they need the key for that
      • drizztbsd joined the channel
      • BlueMatt
        2 min
      • instagibbs
        any pressing topics
      • wumpus
        well after the final alert is sent, the key is only historical curiosity
      • gmaxwell
        okay, I'll send a message to the list.
      • luke-jr
        can the final alert match all clients?
      • wumpus
        luke-jr: you mean the pre-final alert, and yes
      • petertodd
        wumpus: yeah, once that final alert is sent, I doubt releasing the key will do any harm
      • gmaxwell
        It cann't not match all clients.
      • wumpus
        gmaxwell: I think he means the penultimate alert
      • obviously the final alert matches all clients, at least those that still parse alerts
      • gmaxwell
        petertodd: if I can parition your network I can make your client show "Your bitcoin is outdated and vulnerable. You MUST download an update to continue. http://bitcoinscam.eu/";
      • wumpus
        gmaxwell: wasn't that the point in adding it to the client?
      • gmaxwell
        I was thinking of limiting the applicability of the penultimate alert to users of Bitcoin Core, open to suggestions.
      • petertodd
        gmaxwell: sure, but that'll have been after months of alert - I'm not worried there
      • wumpus
        it applies to everyone using the key, not just users of bitcoin core
      • gmaxwell
        in any case, can continue after, we should wrap the meeting. :)
      • petertodd
        gmaxwell: I'd be inclined to provide it to everyone - it's a warning that everyone will soon have a final alert
      • instagibbs
        ding ding
      • btcdrak
        ding ding ding
      • wumpus
        yes it's time
      • #endmeeting
      • lightningbot
        Meeting ended Thu Sep 22 20:01:03 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
      • sipa
        bye
      • wumpus
        agree petertodd
      • this is not bitcoin core specific but everyone-that-embeds-that-pubkey specific
      • Chris_Stewart_5
        CodeShark: Did you have any concrete ideas for improving on BIP37?
      • gmaxwell
        petertodd: the reasoning I had for that thought is I think it should provide upgrade advice. And I don't want to give update advice to people who insist on running software I consider broken and dangerous.
      • petertodd
        gmaxwell: I think the upgrade advice can be general "whatever you are running, upgade"
      • gmaxwell: equally, it can just be a warning that you will soon see a final alert, as the alert system is being depreciated
      • wumpus
        yes, it can just be a warning about the alert
      • it doesn't really have to tell to upgrade
      • just make sure peopel are aware
      • btcdrak
        that's a good idea
      • gmaxwell
        Chris_Stewart_5: there is a proposal on the list for a replacement using commited filters. that coupled with a CB like getblocktxn that provides hashproofs would be the replacement.
      • CodeShark
        Chris_Stewart_5: proposals to put the filters in the blocks themselves seem at least slightly more promising
      • gmaxwell
        the commited filter thing can also be done without the commitment and still have the same security as BIP37 but without the consensus change.
      • petertodd
        gmaxwell: re: committed filter, you can make the consensus rule be it has to be a superset of what actually matches re: soft-forks
      • drizztbsd joined the channel
      • gmaxwell: otherwise if we add another segwit-like thing we need a new filter
      • gmaxwell
        petertodd: bandwidth overhead in that however.
      • because then you have to send the filter between full nodes. yuck.
      • CodeShark
        UTXO commitments + getutxos would probably be the quickest sync option that isn't totally insecure
      • instagibbs
        is the bitcoin wiki down for others for the last few days?
      • petertodd
        gmaxwell: true, though wasn't it only a few KB?
      • CodeShark
        Privacy issues are still a problem, though
      • petertodd
        CodeShark: I don't think we can reasonably implement UTXO commitments
      • gmaxwell
        there are also many other options for scanning, including ones that are private, like via PIR lookup.
      • Chris_Stewart_5
        Thanks gmaxwell, CodeShark, will read.
      • petertodd
        and it'd be good for some of those options to be implemented via central services first to prototype
      • gmaxwell
        the commited maps thing would let us do several non-commited revisions the only thing you lose without the commitment is security against censorship, which BIP37 has none of already.
      • petertodd
        and a central service can be audited easily enough to detect censorship (assuming clients connect anonymously)
      • gmaxwell
        petertodd: re-size it may be interesting to have several sizes, so clients could probe at the smallest and then only probe the larger if they have a hit... so perhaps they're larger than you might think. this would also all be unpredictable uncached validation. and 4kb would add about 1/3rd to a CB transmission.
      • petertodd
        or actually, commit to the contents of the filter, and then provide the filter
      • gmaxwell: true
      • gmaxwell
        petertodd: right you could talk to N hosts, and find that they all give the same commitment value.
      • without having to fetch the filter N times.
      • or even connect to one host and get a commitment signed by N parties.
      • petertodd
        gmaxwell: add a signature on the commitment and that should be enough
      • gmaxwell
        right.
      • CodeShark
        Thing is all these proposals significantly complicate client implementations
      • petertodd
        CodeShark: well, privacy is hard :)
      • gmaxwell
        checking a signature is not complex. :P
      • in any case, it's foolish to think we can design for forever in a single step; we must have incremental stepping stones.
      • CodeShark
        Ultimately, we need client implementations to be relatively simple or centralized API services will domimate
      • *dominate
      • petertodd
        gmaxwell: I found it interesting how the Roughtime spec says that they will depreciate servers on a regular basis to force clients to keep up-to-date
      • CodeShark: well, if we don't do a good enough job, centralized API services may be better for privacy... I'd trust a centralized API over bloom filters
      • CodeShark
        or at the least we need some solid client-side libraries with multiple language bindings
      • petertodd
        CodeShark: does bloom filters even have that? :)
      • CodeShark: python-bitcoinlib *still* doesn't have a full bloom filter implementation - I've never had anyone interested in using it
      • CodeShark
        petertodd: only the true diehards even attempt to use bloom filters rather than, say, bc.i :p
      • petertodd
        CodeShark: indeed - python-bitcoinlib is likely used 99% of the time with a local copy of Bitcoin Core
      • gmaxwell
        bc.i has better privacy than bloomfilters, IMO.
      • CodeShark
        but it's still a single point of failure
      • petertodd
        CodeShark: then use the Electrum servers! :)
      • CodeShark
        Argh - lol
      • petertodd runs two OpenTimestamps public calendar servers and thinks that's good enough. :)
      • gabridome has quit
      • petertodd
        CodeShark: honestly, I think Electrum would be interested in better privacy too - they've been open to discussing this in the past, and IIRC implemented prefix filters for that purpose
      • CodeShark
        I run multiple bitcoin core instances and reluctantly use bip37
      • luke-jr