< instagibbs>
jl2012, longer term we should probably just check up to what version of witness has been softforked, and then make those witness programs standard. Otherwise each version SF will require a similar PR
< jl2012>
instagibbs: that should be part of the next softfork
< instagibbs>
so, did no one scream for a SW backport?
< sipa>
i started writing one; i don't think the actual backport will be hard
< sipa>
getting review for it will be
< instagibbs>
indeed
< sipa>
i'll continue working on it, but it's not my highest priority
< btcdrak>
sipa: is #8393 unchanged from when we were testing segwitcb a while ago?
< sipa>
btcdrak: yup, only trivial rebase + squash
< btcdrak>
sipa: Travis needs a gentle tap on #8393 - the last job barfed for no good reason
< instagibbs>
while we're improving CB, lets get https://github.com/bitcoin/bitcoin/pull/8235 if for nothing else me not having to scan the source to figure out how to log debug messages :P
< sipa>
instagibbs: good idea
< pedrobranco>
\cl
< achow101>
I'm doing some stuff for segwit with Armory, and one part of it is sending a getdata message to bitcoin core about a transaction that it just sent. The transaction was clearly accepted by core (I see it in the transaction list) but it keeps returning a notfound message. Any reason why?
< sipa>
achow101: is this only for segwit, or generally true?
< sipa>
achow101: is this from the same node that sent the transaction?
< achow101>
I think it is only for segwit, I haven't seen this behavior anywhere else, but I'm not sure
< sipa>
there have been significant changes to tx relay in 0.13
< sipa>
you can only query for transactions now after they've been inved to you for privacy reasons
< sipa>
but if you're the sender yourself that doesn't make much sense
< achow101>
no, Armory is the sender. It connects as another node. It sends the transaction then asks for it back to check that it was accepted
< sipa>
let me check
< sipa>
achow101: if you wait a few seconds, that should work
< achow101>
how so?
< sipa>
can you test whether that's the case?
< achow101>
I can try
< sipa>
we delay inserting the transaction into the relay pool until we actually relay it somewhere
< sipa>
but there is a randomized delay before that happens
< sipa>
it's probably easier to check for a reject message instead...
< achow101>
what is the longest the randomized delay can be?
< sipa>
infinity
< sipa>
it's poisson distributed
< achow101>
great...
< sipa>
but on average it's 5 to 10 seconds
< sipa>
as an alternative, you can send a ping after the getdata, and if the pong returns before you get a reject message, the transaction is accepted
< sipa>
or even better, check whether _other_ peers inv the transaction back to you
< sipa>
that way you can actually see whether it propagated across the network
< goatpig>
hi
< goatpig>
@anchow i fixed that in the upcoming version, don't bother with it
< instagibbs>
lack of quotation makes me think of a noisy channel output
< CodeShark>
gmaxwell: I got misquoted
< CodeShark>
talking to the author now
< gmaxwell>
stab stab stab
< gmaxwell>
cfields: I am currently compiling old versions and it is reminding me to thank you for all the wonderful things you did to the build process.
< cfields>
heh
< cfields>
building pre-0.7?
< sipa>
i tried building 0.3.x a while ago
< sipa>
that was painful.
< sipa>
it's probably fair to say that ever since the concept of backward compatible consensus changes was invented (now called soft forks), bitcoin has not had any hard forks (apart from potentially the march 2013 one, but that's dubious)
< sipa>
and bitcoin 0.2.10 should be able to sync the full chain (due to a p2p change in 0.2.10)
< gmaxwell>
Trying to compile 0.2.10 right now... in wxhell
< gmaxwell>
doing earlier is possible, I synced the _original_ release up to the current chain last sometime in 2013 I believe, but its a PITA due to the p2p proto change.
< gmaxwell>
sweet. C++ languauge drift...
< kanzure>
gmaxwell: plz make an archive of the dependencies if you find them
< gmaxwell>
got 0.2.10 compile but darn thing can't change its listening port. :)
< btcdrak>
that was fast.
< gmaxwell>
I was working on it two hours ago actually, before seeing that fool article.
< gmaxwell>
because of some other person repeating the same claim elsewhere.
< gmaxwell>
(and I have 0.7 synced to mid 2013... though it's slow and going to take forever to finish)
< sipa>
gmaxwell: i did get 0.3.x to compile at some point and needed to change the listening ports too
< sipa>
when was that
< sipa>
maybe for 0.8 or 0.10
< gmaxwell>
interesting failure mode, user manages to manually create a zero fee txn for something where they don't care if takes forever...
< gmaxwell>
then we spend the unconfirmed change.
< gmaxwell>
and then they're unhappy wth all their txn stuck.
< sipa>
gmaxwell: cpfp!
< luke-jr>
^
< sdaftuar>
if it was literally zero fee, cpfp probably won't help
< luke-jr>
sdaftuar: why not?
< sdaftuar>
limited mempools
< luke-jr>
oh, no relay cpfp yet?
< sdaftuar>
this is really made for RBF
< luke-jr>
yes, it's better to respend with an additional output than to create a child
< gmaxwell>
I'm helping this guy compute a replacement.
< gmaxwell>
none of this stuff is relaying, so easy to get mined.
< luke-jr>
somehow I suspect the wallet logic doesn't calculate fees with unconfirmed inputs taken into consideration :x
< luke-jr>
probably not a show-stopper
< gmaxwell>
well we should probably have a thing like not spending unconfirmed unputs where it won't spend change with fees to low to relay now.
< luke-jr>
we already don't spend unconfirmed change when it's possible to avoid it
< gmaxwell>
luke-jr: kinda! so say you have two unconfirmed outputs, one has no low fee ancestor in its unconfirmed history.
< gmaxwell>
The other does.
< gmaxwell>
We'll spend both of those equally.
< gmaxwell>
similarly for long chains of unconfirmed transactions.. we'll spend a unconfirmed coin at depth 25 even when there is one at depth 1 available.
< gmaxwell>
do we have any tests of bitcoin-tx at all?
< sipa>
yes.
< sipa>
in the form of a python script that feeds it certain input, and verifies its output