echeveria: yes, but (as I mentioned) Bitcoin Core trickles txes. That is, it doesn't send to each of its peers immediately but separates all of its peers into buckets of peers and maintains a queue of transactions for each bucket, sending to all the peers in the bucket on some schedule. This means a transaction may be propagated to a non-spy node, relayed through the network, and then heard about by the spy node from some other
echeveria: encryption by itself, if we assume no mitm and no eclipse, improves own-transaction relay privacy in combination with Bitcoin Core's existing tx trickling code. Right now when you send your own transaction, spy nodes can't be sure whether you originated a transaction or just relayed it. However, your ISP can see that you never received the tx over clearnet before sending it, so unless your node is also on Tor or
I couldn't work that out. its pretty clear what is running bitcoin, from the traffic or the port number.
harding: the only other one I was thinking of was Parity Bitcoin, and they seemed to have only been funded to create that for a very short period.
echeveria: not that I'm aware of at the moment. I was thinking about 2015-17 contention between Bitcoin Core and some of the stuff Unlimited was doing. Also XT had BIP64 support and a different protocol version.
is there any actually used implementation of a bitcoin node other than btcd and bitcoin core?
#proposedmeetingtopic Bech32 support shipped first in Bitcoin Core in Feb 2018, more than a year ago. We should consider making an announcement that Bitcoin Core intends to change the default addresstype from p2sh-segwit to bech32 in 0.19 or 0.20.
[bitcoin] luke-jr opened pull request #15651: torcontrol: Use the default/standard network port for Tor hidden services, even if the internal port is set differently (master...tor_standard_port) https://github.com/bitcoin/bitcoin/pull/15651
[bitcoin] laanwj merged pull request #15641: Backport #15614 to 0.18: gui: Defer removeAndDeleteWallet when no modal widget is active (0.18...2019/03/promag/2019-03-wallet-modal-widget) https://github.com/bitcoin/bitcoin/pull/15641
[bitcoin] jonasschnelli opened pull request #15641: Backport #15614 to 0.18: gui: Defer removeAndDeleteWallet when no modal widget is active (0.18...2019/03/promag/2019-03-wallet-modal-widget) https://github.com/bitcoin/bitcoin/pull/15641
wumpus: for the record, I reported the malicious versions of the bitcoin core website to the host.
or even that the source code is what people canonically understand to be bitcoin core
(An attacker could register "Bitcoin Core Code Shitting Association" and signing the malicious binary with that and nobody would recognise that)
"the bitcoin core code signing association thinks Windows should not yell when running this binary"
"this is bitcoin core" *should* be meaningless really
It only tells users it was signed by an organisation called "Bitcoin Core Code Signing Association"
or "this is bitcoin core"
jonasschnelli: obviously there would have to be some reasonable policy on what gets signed (eg, gitian builds of Bitcoin-compatible software)
There is another association I'm currently building up (with a proper structure) called "Bitcoin Developer and Researcher Association" (BitDRA) which should aim to finance real work/projects
yes I am happy to formally donate to the Bitcoin Core Code Signing Association, someone should tell me an amount and where to mail a check :-)
Bitcoin Core Code Signing Association (based in Switzerland)
oh I missed the win signature discussion, will it be something other than Bitcoin Foundation in the future?
surprisingly much of the infrastructure and stuff around bitcoin is hanging together by a few threads, and single individuals that happily still care about it
thanks to the Linux Foundation too, then! it wouldn't be crazy for them to drop bitcoin-dev if it's such a hot potato
It's worth noting despite trying to deprecate the old mailman2 server they've tried to keep it online for us and a few other dev communities who had a hard time moving, and most of their downtime trouble was due to DoS attacks targeting only bitcoin-dev.
in principle it's even off topic in the bitcoin core meeting, the bitcoin-dev mailing list is outside it's scope, not that I mind
so apparently there's some funding initiative by Twitter/Square for core devs (I only learn of this through twitter now), https://twitter.com/jimmysong/status/1108500506106843137 - anyhow, if you're actively involved in Bitcoin Core's development and need this funding, and would like me to write a recommendation for you, let me know
nothingmuch: basically, instead of having an actual IP, you have (0xFD + sha256("bitcoin")[0:5] + sha256(hostname))[0:16], which is useful in cases where you don't actually care about the IP, but the hostname, e.g. for seeds
i used bitcoin-cli listbanned to determine i have 474 banned, all of which are manually added. greg's list has 670. so i am wondering why my ban list is less (likely due to error aborting prematurely?). i am also still wondering about the "already banned" error message since i have none in the ban list that are shown as automatic.
peers of this type pretend to be running various versions of Bitcoin software, but are not. they respond with compact blocks handshakes, pings and pongs, but never respond to headers, get blocks, or inventory messages. the addr messages they push are stuffed with like-peers, and in general seem to be over represented in outgoing connections of normal nodes.
I apologize for not participating in gitian for a while. debootstrap has not worked on Fedora for a few years now. I'm hoping people can help https://github.com/bitcoin/bitcoin/pull/15277 so we have a deterministic buildsystem to replace gitian.