< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #10799: Prevent user from specifying conflicting parameters to fundrawtx (master...2017-07-no-fundraw-conflicts) https://github.com/bitcoin/bitcoin/pull/10799
< jonasschnelli>
That: The DNS seed results must consist exclusively of fairly selected and functioning Bitcoin nodes from the public network to the best of the operator's understanding and capability.
< jonasschnelli>
I guess if the chain splits, then you need to either have two seeds or clearly decide on what side your seed is operating...
< cdecker>
Some people were arguing about the definition of functioning nodes is
< jonasschnelli>
well,... until the chain split (and if), BIP148 and non BIP148 are functioning perfectly fine? not?
< cdecker>
Right that's what I thought ^^
< jonasschnelli>
so.. lets don't bother with it for now. AFAIK dns-seeds can and do not check consensus.. they just look at the version message and may filter service bits
< jonasschnelli>
The seeds crawler is not tied to a full node
< luke-jr>
if there is a 51% attack in response to BIP148, I think it's perfectly fair to not include nodes that are vulnerable to following it
< cdecker>
We might want to think about ways to differentiate once a hard fork occurs, I'm not sure one implementation will want to differentiate itself out of fear of being called non-bitcoin
< luke-jr>
so I don't suggest committing to not filtering non-UASF (ie, vulnerable) nodes
< cdecker>
On the other hand it's not a huge deal to return nodes from the two partitions, after all they will still gossip addresses across both forks as long as somewhere there's a bridge
< cdecker>
luke-jr, I don't follow, you suggest against committing to something like this?
< luke-jr>
cdecker: right
< luke-jr>
in the worst case scenario, it may be necessary to protect light clients
< cdecker>
I honestly don't see why, DNS seeds are infrastructure, not political tools
< cdecker>
You mean having light clients flip-flop between the two forks
< luke-jr>
cdecker: because light clients are inherently vulnerable
< luke-jr>
they will follow any chain they see, no matter how invalid it is
< luke-jr>
and unfortunately there are a lot of them
< jonasschnelli>
luke-jr: not ultimatively
< luke-jr>
jonasschnelli: ?
< cdecker>
Ok, we might need to revisit this in the case of a fork, however I will definitely not filter depending on the presence of a UASF signal
< jonasschnelli>
The light client i'm working on (based on core) does validate block size and SigOp counts, etc.
< cdecker>
And that's what I'm committing to
< luke-jr>
cdecker: that's the easiest way to detect vulnerable nodes
< jonasschnelli>
light client with client side filtering can validate the "important" parameters
< jonasschnelli>
just not with the BF stuff
< luke-jr>
jonasschnelli: right, but those aren't the ones that stupidly connect to only seed nodes
< jonasschnelli>
Yes. Those need protection...
< cdecker>
Well, we can of course create a twin seed setup for both sides, but we would need a way to differentiate them and we need to expose the option of selecting which seed to use to light clients
< luke-jr>
jonasschnelli: well, they don't strictly NEED it, since even headers can enforce, but who knows what these wallets are doing, if anything :/
< luke-jr>
they don't seem to even have BIP 9 code yet
< cdecker>
Ok, not making special provisions for a fork for now
< jonasschnelli>
ryanofsky: in your deque<const CBlockIndex*> blocksToDownloadFirst approach, how could the wallet do a rescan? Assume you import a new seed/key and want to do a rescan, also the assumption is that light clients won't keep blocks (pruning)
< jonasschnelli>
hmm.. maybe just refill the queue... I see
< jonasschnelli>
Currently exploring nat traversal for a different project. Was ICE (ICE: Interactive Connectivity Establishment) or STUN ever considered for Core and if now, why?
< ryanofsky>
i thought nat traversal was more for udp and tcp
< ryanofsky>
udp than tcp
< BlueMatt>
getting nat traversal to work with tcp means you need a userspace tcp impl, something we def dont want to get into
< BlueMatt>
if it even works at all
< jonasschnelli>
So UPnP is the best you can do without userspace tcp impl?
< BlueMatt>
yes
< jonasschnelli>
What about all these SIP NAT traversal solutions.. do they all have a userspace TCP implementation?
< BlueMatt>
Sip does not use tcp if it needs nat traversal, no?
< jonasschnelli>
I though SIP is using TCP for establishing... but not sure
< BlueMatt>
it may, but you're not getting incoming tcp through nat
< BlueMatt>
just not gonna happen
< jonasschnelli>
Okay. Thanks BlueMatt.
< jonasschnelli>
ryanofsky: I started to work on your std::deque approach, but seems that a queue is not sufficient.. because you may want to dequeue when they have been downloaded and that is not in order..
< jonasschnelli>
Are there any significant downsides using a std::map<uint256, const CBlockIndex*>?
< jonasschnelli>
(and just erase the requested block when it's processed)
< ryanofsky>
oh good point, yeah maybe you need a map or a list of lists
< BlueMatt>
cfields: wait, huh, --enable-lto only adds -flto? why not also specify ar/ranlib/nm as well automatically?
< jnewbery>
jonasschnelli: in my experience providers often use SBCs to resolve NAT traversal
< ryanofsky>
southern baptist conventions?
< jonasschnelli>
hehe
< jonasschnelli>
lookin it up
< jnewbery>
SIP can go over TCP or UDP. TCP is more common in my experience
< jnewbery>
Session Border Controller
< jonasschnelli>
Going off-topic: but what's the best approach for a direct communication channel between two devices behind NAT without a centralized server?
< jonasschnelli>
Using UDP (and your own error detection, etc protocol)?
< morcos>
wumpus: for boost::optional, do you prefer .reset() ( which is deprecated but aligns with c++17) or =boost::none . I have no preference, and am happy to change to .reset() as ryanofsky suggests
< morcos>
a tiny bit of research suggested to me that if anything reset may be undeprecated in boost now that it's in std, but it's not in the recent boost docs (ryanofsky are we sure it works with recent boost?)
< ryanofsky>
i can check latest documentation, but i think all of boost::optional is deprecated now that std::optional exists
< TD--Linux>
you can totally do TCP hole punching too
< BlueMatt>
right now it looks like multiwallet is gonna miss 15 :(
< BlueMatt>
or...were here
< ryanofsky>
i requested a number of changes to 10650, but they're all simple, and i'd happy to help with implementation. i guess it the functionality works though and it just needs a few more acks?
< BlueMatt>
there are some easy-fix issues from my review
< BlueMatt>
i dont think it is, i mean for some flags sure, but mostly i would expect only link-time flags to matter
< cfields>
BlueMatt: so that we can enable instructions for only certain objects (after they've been cpuid checked)
< sipa>
cfields: all of my numbers are with -O2/-O3 -lfo/"" set explicitly for CFLAGS/CXXFLAGS/LDFLAGS
< sipa>
so if overriding flags is bad, it would be bad for all 4 benchmarks
< BlueMatt>
yes, point is I'd assume that would only work on non-lto, or might otherwise confuse ld
< cfields>
BlueMatt: i'd expect the opposite to avoid segfaults all over the place :)
< cfields>
time to google and find out
< gmaxwell>
BlueMatt: hm lto should be fine with mixed cflags.
< BlueMatt>
gmaxwell: mixed clfags maybe, but mixed -march?
< gmaxwell>
(w gcc you can even use pragma to change march on a function by function basis)
< BlueMatt>
true
< jnewbery>
wumpus: sorry for the back and forth - i think we can remove #10711 from https://github.com/bitcoin/bitcoin/projects/8 . I still want it to go in, but it's not essential for 0.15 (in fact it could probably go in after feature freeze since it doesn't touch product code)
< cfields>
sipa: ok, so it's a level playing field i guess, if i understand your setup correctly
< BlueMatt>
yea, i mean i could see lto being slower, but that seems like a lot slower
< BlueMatt>
in other news, any other for-15 stuff that needs review?
< bitcoin-git>
[bitcoin] theuni opened pull request #10806: build: verify that the assembler can handle crc32 functions (master...configure-check-asm) https://github.com/bitcoin/bitcoin/pull/10806
< cfields>
sipa: also, are you using gcc-ar/ranlib-ar? Or at least verifying that you're not linking fat objects?
< gmaxwell>
Why is that ugly, it's what the test is for!
< gmaxwell>
(I mean the configure test to find out if compiling with -msse4.2)
< sipa>
gmaxwell: i mean using byte sequences is ugly
< sipa>
... but it solves everything
< cfields>
gmaxwell: yes, that works
< gmaxwell>
sipa: I'm not opposed, esp for single instructions... but ugh
< cfields>
sipa: i think i agree
< sipa>
FWIW, i do not find any crc instructions in disassemblies of my benchmark binaries
< sipa>
so at least the comparison is fair
< sipa>
... and lto actually slows things down? :(
< cfields>
strange
< gmaxwell>
how are you not getting crc instructions when you were building with -march=native or does the current configure stuff just turn it off when any cflags are set
< sipa>
gmaxwell: i'm not using -march=native
< sipa>
just -O2"
< gmaxwell>
sipa: cool so if we fix that perhaps we'll finally get it under 1hr with sha-ni. :P
< sipa>
just "-O2", "-O3", "-O2 -flto", "-O3 -flto"
< cfields>
gmaxwell: ^^ pr fixes -march=native
< gmaxwell>
perhaps we could add some logging if crc32 instruction is in use. (and same for other accelerators later)
< gmaxwell>
e.g. is leveldb's detect function exported
< cfields>
no
< gmaxwell>
grr
< cfields>
oh that reminds me, i need to finish fixing their detection
< jnewbery>
Does anyone know if bitcoin-cli is supposed to work with ipv6? I can't seem to make it connect when specifying an ipv6 address in -rpcconnect
< sipa>
try putting [] around the ip
< jnewbery>
i've tried all the permutations ::1 [::1] "::1" "[::1]"
< sipa>
hmm
< jnewbery>
There's #1827 but that's ancient and before libevent
< cfields>
jnewbery: sure you're listening on ipv6 too?
< jnewbery>
I think so. Background is I'm trying to run rpcbind.py. It works when I use direct RPC, but not if I feed all RPC through bitcoin-cli
< jnewbery>
I've added a `-usecli` option to the functional tests which makes all RPCs go through bitcoin-cli. This is the last test that I can't get to run with that option
< arubi>
jnewbery, I have vague memory I also had to specify the port with ipv6, but that was a while ago..
< arubi>
not sure if you already did
< jnewbery>
arubi: yes - port is specified
< jnewbery>
Does that mean you were able to use bitcoin-cli with ipv6?
< cfields>
jnewbery: what libevent version?
< arubi>
it was a while ago, I didn't mess with it too much so might just be bitcoind related and not -cli
< arubi>
it might have been -rpcbind, sorry for the confusion
< jnewbery>
cfields: what's the quickest way to find out?
< jnewbery>
arubi: yeah bitcoin-cli over ipv6 seems pretty niche. Can't imagine many people use it
< bitcoin-git>
[bitcoin] instagibbs opened pull request #10807: getbalance example covers at least 6 confirms (master...getbalexample) https://github.com/bitcoin/bitcoin/pull/10807
< cfields>
jnewbery: I've been trying to track down when this bug was fixed, looks like it was never backported to 2.0.x :(
< cfields>
sipa: i'd be curious to know if --enable-reduce-exports changes your lto results any
< sipa>
cfields: let's try!
< cfields>
sipa: i have no idea what's going on behind the scenes, but if it uses symbol visibility to determine how aggressively it can inline, I would expect an improvement from that
< sipa>
cfields: rebuilding
< morcos>
jonasschnelli: sorry I missed that you had pinged me on #8501 and I didn't realize you'd redone it. I'm assumign that's missing 0.15 at this point? I will review post 0.15 unless you are still hoping to make it.
< bitcoin-git>
[bitcoin] petertodd closed pull request #8543: Use ANYONECANPAY if -spendzeroconfchange=0 (master...2016-08-anyonecanpay-if-spendzeroconfchange-disabled) https://github.com/bitcoin/bitcoin/pull/8543
< gmaxwell>
cfields: how much would it make you hate life to adjust our build system so that leveldb stops getting build with -Wsign-compare
< gmaxwell>
soo tired of that one warning...
< BlueMatt>
lol
< BlueMatt>
cant we just patch it?
< cfields>
gmaxwell: heh. I'm with BlueMatt on that one :)
< BlueMatt>
dont we already carry leveldb patches?
< sipa>
cfields: ack, fix it in bitcoin-core/leveldb
< morcos>
I think #10604 should also go in for 0.15 (needs milestone) assuming #10650 makes it
< gribble>
https://github.com/bitcoin/bitcoin/issues/10604 | [wallet] [tests] Add listwallets RPC, include wallet name in `getwalletinfo` and add multiwallet test by jnewbery · Pull Request #10604 · bitcoin/bitcoin · GitHub
< bitcoin-git>
[bitcoin] jnewbery opened pull request #10812: [utils] Allow bitcoin-cli's -rpcconnect option to be used with square brackets (master...bitcoin_cli_ipv6) https://github.com/bitcoin/bitcoin/pull/10812
< gmaxwell>
sipa: plz2merge 10714
< henrik_>
I think BTC is going in a wrong dirrection. We are in the process of re-inventing the banking business. Why not aim a little heigher?
< sipa>
other things that need merging?
< BlueMatt>
<morcos> #10235 should be tagged 0.15 please
< BlueMatt>
<gribble> https://github.com/bitcoin/bitcoin/issues/10235 | Track keypool entries as internal vs external in memory by TheBlueMatt · Pull Request #10235 · bitcoin/bitcoin · GitHub
< BlueMatt>
<BlueMatt> or just merged, at this point
< bitcoin-git>
bitcoin/master 959dd87 practicalswift: Avoid printing incorrect block indexing time due to uninitialized variable...
< bitcoin-git>
bitcoin/master 2a09a38 Pieter Wuille: Merge #10714: Avoid printing incorrect block indexing time due to uninitialized variable...
< bitcoin-git>
[bitcoin] sipa closed pull request #10714: Avoid printing incorrect block indexing time due to uninitialized variable (master...avoid-uninitialized-nStart) https://github.com/bitcoin/bitcoin/pull/10714
< gmaxwell>
sipa: danke.
< morcos>
sipa: #10557 could be merged after another look
< gribble>
https://github.com/bitcoin/bitcoin/issues/10557 | Make check to distinguish between orphan txs and old txs more efficient. by morcos · Pull Request #10557 · bitcoin/bitcoin · GitHub
< sipa>
cfields: using --enable-reduce-exports does not help