< luke-jr>
of course not, it doesn't make sense for sendtoaddress
< luke-jr>
sendtoaddress is a simple RPC for normal users
< luke-jr>
normal users should never be messing with change addresses
< sipa>
for fundrawtransaction it may make sense
< sipa>
(i'm surprised it doesn't already have it?0
< luke-jr>
yes, that's what the PR does
< luke-jr>
note it is merged
< warren>
In discussion with cfields today we decided it would be nice and not too difficult to improve the makefiles and gitian such that "make rpm" and "make deb" would work and be used during the ordinary gitian-linux process. It can spit out deterministic deb and rpm's during the existing gitian build process. They can be subsequently GPG signed in a similar manner to the OSX and Windows installers.
< warren>
After this is done I will make the recommendation to Fedora that they do NOT want to build and maintain their own Bitcoin RPM, mostly because they EOL distros very quickly and people will be stuck with old versions of Bitcoin. Installing Bitcoin should be a conscious process not subject to auto-update either.
< GitHub137>
bitcoin/master b06f6a9 JeremyRand: Fixed invalid example paths in gitian-building.md...
< GitHub137>
bitcoin/master fbd8478 Wladimir J. van der Laan: Merge #8009: Docs: Fixed invalid example paths in gitian-building.md...
< GitHub195>
[bitcoin] laanwj closed pull request #8009: Docs: Fixed invalid example paths in gitian-building.md (master...doc-gitian-building-offline-paths-fix) https://github.com/bitcoin/bitcoin/pull/8009
< maaku>
I saw in the meeting logs that a back dated start date for segwit on testnet was accepted
< maaku>
This potentially causes severe problems for people who are doing ongoing integration testing of their own services on testnet
< maaku>
I hope that this decision is reconsidered (or a delay to activation is added)
< jl2012>
maaku, I think BIP68 also backdated?
< maaku>
jl2012: which was also a mistake
< maaku>
the delay can be short, e.g. a few weeks. but it shouldn't be zero
< maaku>
that is placing a potential forking situation on people who have been absorbed in their own work, with absolutely no warning
< jl2012>
you mean some people are already testing segwit on testnet?
< maaku>
jl2012: I mean that with a back-dated start date segwit could activate within hours if someone decided to throw some hash power at it
< jl2012>
same before we had bip9
< maaku>
wihch is not unlikely
< maaku>
jl2012: ...
< maaku>
because we fucked up in the past does not mean we should continue to be fuckups
< maaku>
set a data of May 15th or something and make a loud announcement, so people have at least a little bit of time to make sure they're not affected
< sipa>
maaku: that's reasonable, but testnet is always subject to wide hashrate swings and forks
< sipa>
and it's not like the code for segwit is merged... there isn't even a branch with those activation times included at this point
< maaku>
yeah but still, we should try not to add to the noise
< sipa>
sdaftuar: do you think there are pitfalls when converted the txid index of CTxMempool:mapTx to a hashed-based one?
< sdaftuar>
sipa: hmm, i'm not sure i sufficiently explored it, but i don't recall thinking it would be problematic
< sipa>
i remember trying, and failing
< sdaftuar>
yeah so probably i was missing something then :)
< sdaftuar>
maybe kazcw wants to take a stab at it! the setSpends thing is cool
< jl2012>
maaku, no matter what we do, when no one is mining, an attacker can easily fork the network by mining a long non-segwit chain after activation
< jl2012>
unless we have hashrate to keep the chain growing, which is burning money
< BlueMatt>
hmmm...sipa so I need to keep around a list of node pointers I can send messages to in main.cpp...would be a huge shame to put CNode* back in logic there :/
< BlueMatt>
any ideas
< BlueMatt>
or, wait, who introduced NodeId
< gmaxwell>
jl2012: maaku's concern is that you we should give people time to update so their nodes will ignore that fork.
< gmaxwell>
I don't share the concern.
< gmaxwell>
(or rather, I share it but believe that we will end up giving them adequate time, without having to delay further.)
< jl2012>
i hope to see it live on testnet as early as possible, so we could start testing the dynamics of upgraded and non-upgraded nodes
< jl2012>
and I'm sure it will be attacked, intentionally or unintentionally
< jl2012>
unless we keep mining it
< gmaxwell>
jl2012: if nodes are already upgraded to enforce, then _full nodes_ (which is 99% of what exists on testnet) won't notice any such attack.
< jl2012>
but the point to test it on testnet is to examine the interaction between upgraded and non-upgraded nodes
< jl2012>
if we just want upgraded nodes, we already have segnet
< jl2012>
and if upgraded nodes have minority hashrate, we are actually implementing a segnet under the name of testnet
< instagibbs>
jl2012, you can do that in segnet too
< gmaxwell>
we can also spin up a new testnet that is mixed.
< gmaxwell>
which would not disrupt other people's testing that is unrelated to segwit.
< jl2012>
actually I'm running a non-upgraded node on the segwit. Probably the only one
< sipa>
BlueMatt: i introduced nodeid
< sipa>
BlueMatt: but perhaps net can have a function to send a particular message to a list of nodeids
< sipa>
BlueMatt: alternatively, you can keep a list of CNode* pointers around, but you'll need cleanup logic in FinalizeNode to remove any reference to a node when it disappears
< BlueMatt>
sipa: yea, I mean i was thinking about CNode* references...but that kinda defeats the purpose of NodeId
< BlueMatt>
sipa: in fact, any solution kinda defeats the purpose of NodeId...might as well kill NodeId if we have back-and-forward references between CNodes and NodeIds
< sipa>
BlueMatt: i disagree
< sipa>
BlueMatt: net should not expose CNode
< sipa>
and only expose abstract identifiers
< sipa>
the fact that you need back-and-forth references is a side effect of the logic now being split between net and main
< BlueMatt>
sipa: so you mean that we /should/ have an interface to send to a nodeid, because we shouldn't expose CNode at all, and pfrom should, in fact, be a nodeid?
< sipa>
BlueMatt: yup
< sipa>
but i expect that code to undergo very significant changes after cory's net changes
< BlueMatt>
meh, I mean /all/ processing should happen in net imo...the fact that main knows /anything/ about the p2p protocol is bad
< BlueMatt>
but, indeed, its kinda all up in the air as cory refactors net
< BlueMatt>
I'll add a CNode* ref for now, with the expectation that it will dissapear soonish
< sdaftuar>
sipa: fyi, according to morcos it worked relatively easily to convert mapTx's txid index to an unordered_map.
< sipa>
sdaftuar: oh, sorry to not report back; yes, it was trivial :)
< sipa>
doing it as part of a slighly larger change