< bitcoin-git> [bitcoin] sipa opened pull request #11403: SegWit wallet support (master...201709_segwitwallet2) https://github.com/bitcoin/bitcoin/pull/11403
< 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
< gribble> https://github.com/bitcoin/bitcoin/issues/10783 | [RPC] Various rpc argument fixes by instagibbs · Pull Request #10783 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] jtimon opened pull request #11404: RPC: Chainparams: Simplify -rpcport and CBaseMainParams (master...b16-chainparams-rpcport) https://github.com/bitcoin/bitcoin/pull/11404
< EVM> hi
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8cf88b4aaeaf...67879b7c4431
< bitcoin-git> bitcoin/master 28d4542 Matt Corallo: Disallow uncompressed pubkeys in bitcoin-tx [multisig] output adds
< bitcoin-git> bitcoin/master 67879b7 Wladimir J. van der Laan: Merge #11377: Disallow uncompressed pubkeys in bitcoin-tx [multisig] output adds...
< bitcoin-git> [bitcoin] laanwj closed pull request #11377: Disallow uncompressed pubkeys in bitcoin-tx [multisig] output adds (master...2017-09-bitcoin-tx-uncompressed-segwit) https://github.com/bitcoin/bitcoin/pull/11377
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/67879b7c4431...0f8e09599db6
< bitcoin-git> bitcoin/master df10edf MeshCollider: More user-friendly error message when partially signing
< bitcoin-git> bitcoin/master 0f8e095 Wladimir J. van der Laan: Merge #11288: More user-friendly error message when partially signing...
< bitcoin-git> [bitcoin] laanwj closed pull request #11288: More user-friendly error message when partially signing (master...201709_partial_sign_error) https://github.com/bitcoin/bitcoin/pull/11288
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0f8e09599db6...dc597bb895ef
< bitcoin-git> bitcoin/master d01a968 Suhas Daftuar: wallet: update stored witness in AddToWallet...
< bitcoin-git> bitcoin/master dc597bb Wladimir J. van der Laan: Merge #11225: wallet: update stored witness in AddToWallet...
< bitcoin-git> [bitcoin] laanwj closed pull request #11225: wallet: update stored witness in AddToWallet (master...2017-09-update-tx-witness) https://github.com/bitcoin/bitcoin/pull/11225
< jnewbery> promag: thanks, fixed
< 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.
< bitcoin-git> [bitcoin] jtimon closed pull request #11404: RPC: Chainparams: Simplify -rpcport and CBaseMainParams (master...b16-chainparams-rpcport) https://github.com/bitcoin/bitcoin/pull/11404
< 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
< gribble> https://github.com/bitcoin/bitcoin/issues/11404 | RPC: Chainparams: Simplify -rpcport and CBaseMainParams by jtimon · Pull Request #11404 · bitcoin/bitcoin · GitHub
< 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, 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
< jtimon> does anybody use -mempoolreplacement=0 ? would it make sense to do https://github.com/ElementsProject/elements/pull/248 in bitcoin ?
< luke-jr> jtimon: yes, people use it, and removing it would likely make a ruckus. There's also zero harm in leaving it.
< jtimon> yeah, if people use it, no point in removing it
< promag> achow101: in https://github.com/bitcoin/bitcoin/pull/10583/commits/8d5d4cf4c3077e8f3269fab3b98da7413e100081 commit message there is a double space. Also, Validateaddress should always be lowercase?
< promag> jnewbery: so -deprecatedrpc can be used to enable some deprecated params? I thought is to enable the full (deprecated) rpc
< achow101> promag: who cares
< achow101> promag: super nitty things like that don't really matter and are not particularly conducive to development
< promag> that's ok, I was reading your code and figured you want to know about that if by any change you happen to fix something else
< promag> *chance
< 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?
< bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/dc597bb895ef...2505c5c0a9f8
< bitcoin-git> bitcoin/master 7b137ac Lucas Betschart: [Qt] Add delay before filtering transactions...
< bitcoin-git> bitcoin/master 2505c5c Jonas Schnelli: Merge #11015: [Qt] Add delay before filtering transactions...
< bitcoin-git> [bitcoin] jonasschnelli closed pull request #11015: [Qt] Add delay before filtering transactions (master...searchDelay) https://github.com/bitcoin/bitcoin/pull/11015
< 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> So they can still deserialize the transaction? Cool, I think this part: https://github.com/bitcoin/bitcoin/blob/master/src/primitives/transaction.h#L204-L212 made me think that they would have an empty vin and it would be invalid
< 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>)
< CryptAxe> Cool, thanks again guys!