< analiser>
look like #10783 041dad9 RCP Various rpc argument fixes(instagiibbs) in the 0.15 channelog is what cause some errors in python bicoinlib module i just solve the issue removing from module bitcoin SelectParams() attribute and from bitcoin.rpc remove Proxy() attribute hope that work for any here
< maaku>
I'm considering removing the 200 non-push opcode limit and SIGOP counting for my tail-call proposal. I would be interested in feedback as to why this would be a terrible idea.
< instagibbs>
what interval if any does travis run extended functional tests?
< jtimon>
sipa: what's the reasoning for the bias for nodes using the default port? that seems weird
< sipa>
jtimon: otherwise you can spam the network with addr messages for services you don't like, and get the whole bitcoin network to try connecting to them
< jtimon>
how is that affected by the port, I don't follow...
< sipa>
with the bias, that can pretty much only happen for P2P default port, which is very unlikely to have any interesting services running, other than bitcoin :)
< jtimon>
oh, I see
< jtimon>
I think I get it...
< jtimon>
in any case, as said seems unrelated to #11404
< sipa>
well you're giving all networks the same default port
< sipa>
meaning that if you want to run more than one network on the same machine, one of them will need a non-default port
< jtimon>
the same defaul rpc port
< esotericnonsense>
yes, it's the rpc port only in the PR, was a bit confused by your comment sipa
< sipa>
oh!
< sipa>
this is about the RPC port
< esotericnonsense>
i still dislike the behaviour of having to specify a different rpcport for testnet/regtest though
< esotericnonsense>
though that's just a quality-of-life annoyance
< sipa>
yes, agree - though that's much less bad than having the same P2P port
< sipa>
sorry, i misunderstood!
< esotericnonsense>
while we're on the subject is there any preference for connecting to nodes with a different IP (perhaps based on this standard port bias)? e.g. if I run 50000 nodes from one IP and spam addr messages
< gmaxwell>
it just makes them unusable by default, I cannot fathom why we would do that.
< sipa>
esotericnonsense: we never make more than 1 outgoing connection to the same 'network group' (whose definition is dependent on the network, but for IPv4 it's a /16 i think)
< esotericnonsense>
aha.
< sipa>
and without -addnode we'll never connect to an unroutable address (so not to 192.168.x, not 127.0.0.1, not 10.x, etc)
< sipa>
i think we should at some point have local network discovery and try to connect within your own network, but not using the same external connection slots)
< gmaxwell>
sipa: I started working on that and didn't have a good way to eliminate the duplicate connections.
< gmaxwell>
E.g. hosts A and B on the local network, both connect to each other.
< gmaxwell>
I thought perhaps just a stupid hurestic, "if you listen, connect only to lower sort-order addresses than yours".
< sipa>
or just test for duplicate IP pairs? within a local network you can probably assume that both parties will see each other's by their actual IP (not NAT etc0
< sipa>
so don't connect out to any IP you're seeing an incoming connection from
< gmaxwell>
Good point. What about the race when two connect at the same time
< jtimon>
esotericnonsense: for bitcoin-cli, specifying -testnet does the same as -rpcport=18332, if you specify rpcport, specifying -testnet is completely meaningless
< jtimon>
gmaxwell: what is made unusable by default? I don't follow
< sipa>
gmaxwell: if you have a duplicate pair among actual connections, and your IP is the lexicographically lower of the two, disconnect?
< Sentineo>
gmaxwell: sipa it sounds like split horizont in routing protocols what discuss ...
< Sentineo>
what you discuss
< gmaxwell>
jtimon: Making everything use the same rpc port means you cannot run testnet and bitcoin at the same time anymore except through manually configuring them.
< Sentineo>
btw sipa why is a node keeping 8 connetions outside ? I have a node with 123 connection, 8 of them always go outside. I would assume my node should prefer inbound connections.
< jtimon>
oh, that. yeah. if you want to use both in the same machine you have to specify a different rpc port in one of the,
< jtimon>
them
< sipa>
Sentineo: we always make 8 outgoing connections - regardless of how many incoming connections you have
< sipa>
outgoing connections are far more sybil resistant, as their endpoints are under your own control
< jtimon>
I don't think that unusable, but ok
< gmaxwell>
Sentineo: "prefer inbound" ?!?! ... the inbound could all be a single badguy. We consider inbounds irrelevant for security because of that.
< Sentineo>
yeah, did not thing of that. Was lookng at it the "i serve the network" point of view, which is stupid from security standpoing ...
< maaku>
sipa: Bonjour/Zeroconf would make initial sync of new devices without blowing data caps much more idiot proof
< maaku>
it would also make sense to combine that with preferring making block requests to local peers during IBD
< sipa>
the IBD sync will already prefer faster peers, and will disconnect peers that prevent it from going faster - so i hope no special logic for that is needed
< sipa>
i haven't looked at any of those local connection services
< gmaxwell>
they are awful zeroday magnets.
< gmaxwell>
of course.
< maaku>
sipa: the disconnect actually sounds somewhat dangerous. could I used fast connectivity and network attacks to partition someone off during IBD?
< sipa>
maaku: there is certainly an increased attack vector, but you'd at least need to combine it with other strategies to control the new connections being made (eclipse attacks etc)
< sipa>
maaku: in general i do think that partitioning during IBD is less of an issue - you know you're not caught up
< TD-Linux>
bonjour is a pretty sensible protocol for that
< gmaxwell>
you're still making progress and you already have your headers. There is an argument, however, that 'after' IBD we should dump most of our outbound peers.
< gmaxwell>
but that is complicated by there not being a clear 'after'.
< maaku>
right
< gmaxwell>
TD-Linux: things like bonjour don't help doing things like having connections inside amazon regions for hosts on aws, which have radically less expensive bandwidth than bandwidth to the internet.
< TD-Linux>
gmaxwell, nope. I guess you could ship lists of these
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #11406: Add state message print to AcceptBlock failure message. (master...2017-09-checkblock-fail-print) https://github.com/bitcoin/bitcoin/pull/11406
< promag>
luke-jr: if you run clang-format as per developer notes you will see those details
< promag>
if there is such guide, which took some community effort to write why not follow it? I would say top core developers should be the first to comply? It's not that it takes a lot of time doing so.
< bitcoin-git>
[bitcoin] instagibbs opened pull request #11407: add functional test for mempoolreplacement command line arg (master...testmempoolreplacearg) https://github.com/bitcoin/bitcoin/pull/11407
< sipa>
promag: there is balance between costs and benefits of enforcing style
< sipa>
it adds overhead to both people who write patches and those who reviee
< jnewbery>
promag: I personally think it's fine to use -deprecatedrpc to signal that you want to receive an RPC return object in the old format
< promag>
sipa: the problem is to find the sweet spot for everyone. Running clang-format-diff.py is not that big overhead is it? Anyway, I'll stop nitpicking.
< promag>
jnewbery: I guess so, and should tests all deprecated keys or one is enough?
< sipa>
promag: i'm personally in favor of more strict style conventions, and would very much like the project to force one style... but that's just not feasible. nitpicking everything kills people's motivation to work
< CryptAxe>
Is it possible for nodes that don't understand the extended transaction serialization format for segwit to still validate blocks with those transactions inside of them?
< goatpig>
they cant check the scriptsigs
< goatpig>
but otherwise pre SW nodes can verify SW transactions
< sipa>
CryptAxe: sure, they just won't see the witnesses
< sipa>
(as peers will strip the witness before relaying to a non-segwit peer)
< bitcoin-git>
[bitcoin] PierreRochard opened pull request #11408: Trivial: Fix parameter name typo in ErasePurpose walletdb method (master...walletdb-typo) https://github.com/bitcoin/bitcoin/pull/11408
< CryptAxe>
Ahhh so the transactions are relayed in a different format to old nodes
< CryptAxe>
I didn't see that part
< sipa>
CryptAxe: if they see the witness, the serialization will very deliberately fail
< sipa>
CryptAxe: the reason segwit is a softfork is the fact that it is possible to strip out the witness without invalidating the transaction (from the perspective of old nodes)
< CryptAxe>
goatpig and sipa thank you, I have more reading to do now :)
< sipa>
it's probably better to think of the witness as not actually part of the transaction - it's just some auxilliary data - which _only for relay_ is relayed in a weird interspersed way inside the normal tx data
< CryptAxe>
sipa so the stripped format has some kind of dummy vin or something?
< sipa>
no
< sipa>
the stripped format is just the old transaction format
< sipa>
it has inputs and outputs, and no witnesses
< sipa>
ah, i see what you mean
< sipa>
yes, the scriptSigs are empty
< sipa>
but the rest of the inputs is intact
< CryptAxe>
Thank you, a bit confused about all that
< CryptAxe>
sipa without the scriptSigs why aren't the transactions invalid to the older nodes?
< sipa>
CryptAxe: because their scriptPubKeys don't require a scriptSig
< CryptAxe>
Ah!
< sipa>
(they have the form OP_0 <20-byte hash>)
< CryptAxe>
genius
< sipa>
if segwit is used in P2SH-wrapped form, the scriptPubKey is a P2SH output with Hash(OP_0 <20-byte hash>), and the scriptSig contains _only_ the redeemscript (which is equal to the actual OP_0 <20 byte hash>)