< Chris_Stewart_5>
How do you distinguish between a txid node and non txid node in a MerkleBlock message? Is it simply the fact that that we have hit the maximum height on the binary tree?
< sipa>
achow101: sorry, can you give a link to your compile output again?
< sipa>
Chris_Stewart_5: eh...
< sipa>
Chris_Stewart_5: right, you do by knowing the transaction count
< Chris_Stewart_5>
sipa: Is there any other way with just a merkle block message? The docs distinguish between txids nodes (leaves in the full merkle tree) and non txid nodes
< Chris_Stewart_5>
but, from what I can tell, you still need to compute the full tree with empty nodes to make that distinguishment? Am I missing something?
< sipa>
achow101: that really looks like you're compiling without c++11
< achow101>
any idea on how to fix it?I'm using the lates versions I caaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
< GitHub128>
bitcoin/master 4a35e0f Pavel Janík: Do not shadow members in dbwrapper
< GitHub128>
bitcoin/master 484312b Pieter Wuille: Merge #8467: [Trivial] Do not shadow members in dbwrapper...
< GitHub86>
[bitcoin] sipa closed pull request #8467: [Trivial] Do not shadow members in dbwrapper (master...20160805_Wshadow_dbwrapper) https://github.com/bitcoin/bitcoin/pull/8467
< jonasschnelli>
Does bitcoin-cores UPNP (or UPNP in general) uses nat traversal or ICE? Or is the only way to get connection from the outside if your router supports uPNP and opens the port?
< gmaxwell>
jonasschnelli: only opening the port.
< jonasschnelli>
gmaxwell: Okay. Thanks.
< sipa>
and for discovering external ip
< jonasschnelli>
Would ICE works for Bitcoin? Or would that require UDP? (maybe off-topic here)
< GitHub28>
bitcoin/0.13 3f65ba2 Pieter Wuille: Treat high-sigop transactions as larger rather than rejecting them
< GitHub79>
[bitcoin] laanwj closed pull request #8438: [0.13] backport: Treat high-sigop transactions as larger rather than rejecting them (0.13...btc-13-sigops) https://github.com/bitcoin/bitcoin/pull/8438
< GitHub28>
bitcoin/0.13 edc2c70 Wladimir J. van der Laan: Merge #8438: [0.13] backport: Treat high-sigop transactions as larger rather than rejecting them...
< gmaxwell>
jonasschnelli: general traversal requires third party introduction, and no one technique generally works (and traversal for TCP almost never works)... I think firefox has a significant fraction of a million lines of code for nat traversal w/ rtcweb.
< jonasschnelli>
heh.. okay. I see.
< gmaxwell>
IMO, using tor hidden services is a /simpler/ way to bypass nat, as crazy as that sounds.
< * jonasschnelli>
is thinking...
< jonasschnelli>
gmaxwell: So using tor hidden service over 443 would probably allow bypassing firewalls (assume some large company firewalls where only 80,443 is open) to connect to the bitcoin network?
< gmaxwell>
jonasschnelli: normally tor connections are on 443 and look superficially like regular https connections.
< jonasschnelli>
gmaxwell: thanks.
< gmaxwell>
and as long as you can connect out to the tor network you can run a hidden service where people can connect in.
< gmaxwell>
sipa: we need to think about a replacement for addr messages at some point.
< gmaxwell>
In particular, I2P and tor NG hidden services need more than 128 bits.
< gmaxwell>
and it would be good to be able to carry a bit more metadata.
< sipa>
gmaxwell: well in light of bip151... should they also carry a host pubkey?
< jonasschnelli>
sipa: that would open the trust network problem?
< jonasschnelli>
I think only pre-sharing makes more sense?
< jonasschnelli>
Or what if malicious peers change the host in the addr messages?
< gmaxwell>
sipa: I don't think thats very useful.
< GitHub185>
bitcoin/0.13 45c656b Wladimir J. van der Laan: Merge #8465: [0.13] Document reindexing changes...
< gmaxwell>
largely unrelated to BIP151 there is a question of it you'd like to have long lived node identities.
< gmaxwell>
and then support a 'connect to identity'
< gmaxwell>
allowing you to, e.g. maintain connections to known well performing peers.
< gmaxwell>
But that is basically 180degrees off of all the fingerprinting resistance we've worked on in the past.
< jonasschnelli>
gmaxwell: I guess theres nothing holding back power users of doing this with the current bip151 (+auth) specification..
< gmaxwell>
in that model you wouldn't have a 'addr' message, you'd have a 'nodeid' message, which is announcing a pubkey and one or more addresses it can be reached on, signed by that key.
< jonasschnelli>
ah
< gmaxwell>
so then there is a 'what if peers change the host' -- nothing can be changed because it's signed. And thing addrman would track is not addresses but IDs.. (and then when it wants to connect to an ID it would take that ID's latest addr announcement).
< sipa>
gmaxwell: hmm, that's not what i'm thinking of
< * jonasschnelli>
hears Eric Voskuil grumbling...
< gmaxwell>
I know, but what you were thinking of is not useful.
< sipa>
gmaxwell: more: we currently treat IP addresses as identities
< sipa>
when you connect to the same IP again, you expect it to be the same identity
< gmaxwell>
just stapling a pubkey to an addr message accomplishes nothing useful, anyone can and would change it in flight. If it doesn't match 'oh well, someone changed it in flight or the host changed'.
< gmaxwell>
you might as well have just asked the host for a pubkey when you connected to it. :)
< jonasschnelli>
Only if there would be a signature of the ip/port?
< sipa>
when a peer tells you about a particular IP, you want to make sure that what you're connecting to is actually who they meant
< gmaxwell>
but thats not really part of the addr message, its non-transitive.
< sipa>
agree
< sipa>
and i don't think we want a web-of-trust between nodes :)
< gmaxwell>
I don't think thats very useful. If nodes really did have a persistant tracable identity, "this node was good in the past, I want to find it again" would be a useful service.
< gmaxwell>
But it's in conflict with avoiding fingerprinting.
< GitHub120>
[bitcoin] luke-jr opened pull request #8495: [0.13] Bugfix: Use pre-BIP141 sigops until segwit activates (GBT) (0.13...bugfix_gbt_sigops_presegwit-0.13.x) https://github.com/bitcoin/bitcoin/pull/8495
< gmaxwell>
I suppose there is a middle ground where you can relay messages signed by P + H(P||blockhash[height//144*144]) or the like, and so if you know P (e.g. having previously been configured to authenticate towards that node), you can locate its updated addr messages.
< gmaxwell>
But to everyone else host with key P does not have a long lived identity.
< GitHub177>
[bitcoin] MarcoFalke closed pull request #8477: [qa] Temporarily disable ipv6 in rpcbind test (master...Mf1608-qaIpv6) https://github.com/bitcoin/bitcoin/pull/8477
< GitHub52>
bitcoin/0.13 8b0eee6 Luke Dashjr: Bugfix: Use pre-BIP141 sigops until segwit activates...
< GitHub7>
[bitcoin] laanwj closed pull request #8495: [0.13] Bugfix: Use pre-BIP141 sigops until segwit activates (GBT) (0.13...bugfix_gbt_sigops_presegwit-0.13.x) https://github.com/bitcoin/bitcoin/pull/8495
< cfields>
luke-jr: ping. gbt sends out the !segwit rule even if there are no segwit transactions included. that goes against my reading of the spec.
< cfields>
luke-jr: (i'm implementing the bip9 gbt changes in ckpool)
< luke-jr>
MAY != MUST
< gmaxwell>
cfields: hm. It would be pretty surprising if the behavior modulates based on tx in mempool. I.e. your stuff catches fire when you're not looking.
< sipa>
cfields: agree with luke-jr and gmaxwell here: you'd rather have mining infrastructure break at upgrade time than at segwit activation time
< sipa>
where it potentially happen across all miners simultaneously
< luke-jr>
'!' is required if there are such transactions, but optional (for non-segwit miners only) if there are not.
< gmaxwell>
!segwit is super confusing. :(
< gribble>
Error: "segwit" is not a valid command.
< gmaxwell>
it even confuses gribble.
< luke-jr>
lol
< cfields>
heh, has not activated on gribble yet
< sipa>
haha
< luke-jr>
'*' would have probably made more sense, but I think it's too late to change it now?
< sipa>
i never considered that '!' as part of a name would be interpreted as "not"
< sipa>
and agree - i think it's not worth changing at this point
< cfields>
heh. I read it as "segwit!" rather than "!segwit" and it's more clear :)
< sipa>
yeah. it's "segwit! be aware!"
< cfields>
either way, i'd say it's not entirely clear in the spec. I (wrongly) first implemented coinbase insertion based on the "!segwit" flag's presence.
< sipa>
cfields: that's fine
< cfields>
"On the other hand, when this prefix is used, it indicates a more subtle change to the block structure or generation transaction; examples of this would be BIP 34 (because it modifies coinbase construction)..."
< sipa>
cfields: ah, no
< sipa>
it means "you must understand why segwit means before you can mine on top of this, because things may have changed beyond normal transaction inclusion selection"
< cfields>
got it. Ok, I'll PR a few clarifications there. Was trying to implement soley based on reading of bip9 changes.
< luke-jr>
cfields: what's wrong with how you implemented it?
< sipa>
but i don't see why "!segwit" -> "make coinbase commitment" would be a problem
< cfields>
luke-jr: causes cb insertion even with no witness data
< sipa>
cfields: which is fine
< sipa>
just slightly wasteful
< gmaxwell>
s/fine/desirable as far as I know.
< cfields>
mm, i assumed the opposite. why desirable?
< sipa>
because you'd test your infrastructures' compatibility ahead of time
< gmaxwell>
Then the miner (and the network) can see their system correctly functioning.
< sipa>
so things don't break all over the network when segwit activates
< gmaxwell>
Otherwise you get the 'segwit tx shows up, now all the hashpower drops offline'
< cfields>
ok, sure.
< cfields>
sipa: in that case, can we append default_witness_commitment based on activation status rather than witness data presence?
< sipa>
cfields: sure
< sipa>
it's optional even when there are no witnesses in any transaction
< sipa>
the rule is (after activation): 1) if the witness commitment is present, it must be correct 2) if there are any witnesses in any transaction, the witness commitment must be present
< * luke-jr>
suspects nobody will care if it's present before activation either, but that's probably less of a good idea
< gmaxwell>
I think it's a good idea to have it present as soon as software is updated.
< gmaxwell>
otherwise there is a behavior change at activation that might go wrong.
< sipa>
it even gives us a way to observe miner adoption before the start date
< luke-jr>
hmm, that's a point
< cfields>
sure, i can do it unconditionally if desired
< cfields>
we could also have 13.0 warn on 1), though it's a bit late for that
< alfas>
luke
< jtimon>
kanzure: https://github.com/bitcoin/bitcoin/pull/8493 looks like a long branch (because it has many tiny steps commits that could be squashed) but it's only +373 −94 , please check it out
< kanzure>
i have no bandwidth to physically test this
< kanzure>
oh it looks like nothing added
< jtimon>
BlueMatt: adviced to just move to the next simplest things to expose instead of trying to encapsulate verifyBlock without exposing anything new
< sipa>
i now envision kanzure implementing this patch on a babbage machine, and then furiously turning the handles until it works
< kanzure>
sipa: yeah i can be fairly serious about my esoteric architectures
< jtimon>
kanzure: alternative APIs very welcomed
< kanzure>
btw there is a typo in your pull request title
< jtimon>
or alternative refactors, whatever, let's just try to force that PR to rebase and become smaller than +373 −94
< jtimon>
kanzure: mhmm, it seems I wrote Expose correctly and I made up the other 3 words, can you be more specific?
< kanzure>
'libcosnensus'
< jtimon>
oh, right
< kanzure>
small concerns about name of 'ContextualCheckHeader' but this is only a nit
< kanzure>
and i think this name is inherited from old code anyway, so it's a tough nit to do anything about
< jtimon>
BlueMatt: also adviced not to be afraid of creating ugly wrappers or duplicating code if that was simpler to expose something
< jtimon>
in this case I'm renaming main::ContextualCheckBlockHeader to Consensus::ContextualCheckHeader, but I'm keeping one with the original name in cppwrappers.o to avoid disruption in main
< jtimon>
but yeah "Consensus::ContextualCheckHeader" it's a new name and it's open for bike-shedding, just like Consensus::VerifyHeader
< jtimon>
I added Pow as a prefix for the 2 pow.o functions that needed a wrapper, also open for bikeshedding (but ideally the necessary preparations for not needing the wrappers should be done beforehand IMO)
< jtimon>
if we do that, we don't even need to rename ContextualCheckBlockHeader,I don't care either way, for me it's just two paths to the same place
< jtimon>
but yeah please give your opinion
< jtimon>
I'm sure that some early nits can save me some work while turning jtimon/0.13-consensus-flags into another PR (WIP)
< jtimon>
I want to expose get_flags too, but that sounds more crazy than verifyHeaders I think