[bitcoin] sdaftuar opened pull request #15486: [net] Allow feeler connections to go to the same netgroup as existing outbound peers (master...2019-02-addrman-collisions) https://github.com/bitcoin/bitcoin/pull/15486
Is there a SegWit v1 proposal on the bitcoin-dev list or elsewhere that I just managed to overlook? I though gmaxwell referred to that a few days ago in the context of SIGHASH_NO_INPUT_FULL_DISCLAIMER
the dates are set - same as communicated a few months ago. it will precede the breaking bitcoin conference, june 5-7, with the conference being that weekend june 8-9, in amsterdam. so you should feel comfortable booking flights with those dates in mind.
flowctrl: this is the development channel; try #bitcoin for support
Hello! I downloaded a macos binary, bitcoin-0.17.1-osx.dmg, from bitcoin.org. In the image, there is a file that produces a 'permission denied' error message when I try to copy it to any location. The file is: /Volumes/Bitcoin-Core/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt
https://github.com/bitcoin/bitcoin/pull/15277 Hoping people can help with what is hopefully a simple environment difference between Ubuntu and this other distro. dongcarl is really close to a deterministic replacement for gitian's toolchain. It may only be a matter of figuring out this linker issue then writing a wrapper around the entire thing.
MarcoFalke: re https://github.com/bitcoin/bitcoin/pull/15451 I assume that we broke some altcoin that has other kinds of invs, and the PR author is trying to suggest a comment change that would have avoided his confusion.
I have one other announcement: we're closing applications to the residency on Sunday. We've found that some of our best applicants have been referrals, so if you know anyone who you think would be a good Bitcoin contributor, please send them our way! https://residency.chaincode.com
Hi all. dongcarl is doing great work picking up the p2p refactor project (https://github.com/bitcoin/bitcoin/projects/4). I think it makes sense for him to have write access so he can update that board. Due to github permissions, that would also allow give him write access to do things like tag and close issues. It would *not* give him commit permissions.
[bitcoin] marcoagner opened pull request #15459: [doc] release process: how to calculate m_assumed_blockchain_size and m_assumed_chain_state_size (master...doc_blockchain_and_chainstate_size_calculation) https://github.com/bitcoin/bitcoin/pull/15459
and one final one https://github.com/bitcoin-core/secp256k1/pull/568 (which mostly I want plain C code review-- as it previously had a silly pointer vs int bug, though this one touches more complicated code that might leave people unfamilar with the library feeling lost)
echeveria: a few years ago, someone decided to tip me unknownst to me, and googled "luke-jr bitcoin address", then paid a random address on the bc.i page (which luckily happened to be my *change* address in the transaction that came up)
luke-jr: at least by transaction count bitcoin core usage appears to outpace electrum something like 5:1
booyah: and in bitcoin today users generally assume addresses can be reused. It's not a great assumption.
luke-jr: you've had years where you could have also written wallet features in bitcoin core to do stuff like pop up a message saying "You're paying to an address you've paid to before. Is this a mistake? Address reuse can be a symptom of a mistaken double payment and can lead to privacy or funds loss". but apparently it wasn't important enough to you to bother.
Not according to how bitcoin has always worked.
is bitcoin somehow improving strength of normal random as provided by OS specific api?
overwhos fault it was. That kind of footgun isn't what you expect from bitcoin engineering, it sounds like something ethereum would do.
I am just imagining a create dialog with a text entry box where you can enter a seed, and then confused users not realizing they can ignore it, googling bitcoin seed and entering in some example they found online.. :P
I don't agree that any reduction of block sizes is "up for discussion" in bitcoin core development. Quite the opposite: You have already been privately censured for creating drama in the press for annoucing some absurd reduction fait accompli when you hadn't even brought the subject up with other developers.
bitcoinEnthusias: the only thing up for discussion at this time is a reduction in block sizes; take this topic to #bitcoin if you want to continue it
bitcoinEnthusias: on the protocol side, sipa has been organizing a BIP for Schnorr signatures. It hasn't officially been proposed yet, and typically an implementation would follow a proposal. https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki if you want to see the current state. bitcoin-dev mailing list a fine place to discuss the proposal
take a step back. I believe the history of this discussion is that luke told someone somewhere don't use wallet X (some untrusted server SPV thing) because its insecure. Then someone said something like "well obviously I'm not going to run bitcoin core on my phone so how should I solve this"?
provoostenator: it is because you don't need to know essentially anything about bitcoin.
what I don't want to deal with is the bitcoin project being responsible for a bunch of people running outdated, vulnerable tor software that's doing nothing but harm them. include some scripts for setting this up in contrib/ if people really want it. I certainly do not.
wumpus: I tend to agree that remote control is a more generic internet problem that can be solved outside of Bitcoin.
remote control over bitcoin P2P? what?
routing your traffic over a relay would make zero sense for the bitcoin protocol as all the data is public
[bitcoin] practicalswift closed pull request #15215: rpc: Use the return value of GetProxy(...) in GetNetworksInfo(). Mark GetProxy(...) with [[nodiscard]]. (master...getnetworkinfo-getproxy) https://github.com/bitcoin/bitcoin/pull/15215
harding: i do. I think it's because bitcoin has a lot of objects which the garbage collector cleans up every so often.
achow101: do you use worktrees with any other projects? I do, and I just checked a few and didn't find any of them broken (even ones on the same qube as my bitcoin repository). I don't know what would distinguish bitcoin from other repositories I use; the only thing I can think of is that it's the largest (size and object count) that I use with worktrees.
achow101: my git worktrees for the bitcoin repository also broke inexplicably two days ago in between my uses of them. I thought maybe something on my system broke them (I use Qubes 4 + Debian 9), e.g. some symlink was lost, but now I'm wondering if it was something else.