< sipa>
15:46:28 < achow101> would a getdata message with the segwit flags (msg_witness_tx, etc) cause that right now since segwit is not activated?
< sipa>
i don't think so
< gmaxwell>
BlueMatt: yea, well I think that improvement is boring.
< sipa>
if it's an incoming connection, it may just be evicted
< gmaxwell>
BlueMatt: I really do not believe anyone has ever had a tx they created fail due to excessive sigops.
< BlueMatt>
gmaxwell: yes, thats pretty much my point
< gmaxwell>
BlueMatt: in fact, I suspect it's not even possible without modifying the software.
< BlueMatt>
gmaxwell: the api refactor, though, needs to happen
< instagibbs>
achow101, I doubt it as well, since usually banning is done for things that are always false, theoretically segwit could have activated and you're partitioned off or something
< instagibbs>
at least, I'd hope not
< gmaxwell>
BlueMatt: I think we should consider changing the behavior so that violation of sigops in a package has no effect on relay, merely prevents a txn from getting package aggregated in the block creation.
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #9393: build: Include cuckoocache header in Makefile (master...Mf1612-makeHeader) https://github.com/bitcoin/bitcoin/pull/9393
< achow101>
any idea what a packet of length 8 would be? I'm trying to debug something in armory and it is receiving data from core that has a length of 8
< sipa>
pong?
< sipa>
or ping
< achow101>
maybe.. I think the data size should also include the message header
< sipa>
the message header is 24 bytes
< sipa>
(magic + command + checksum)
< achow101>
right. well something is coming in from the socket that is 8 bytes
< sipa>
that's possible
< sipa>
you should wait for more data to arrive :)
< morcos>
i guess one could argue we don't NEED to fix that for 0.13.2, if you're sure that the behavior is guaranteed to be what you said (vin is empty). Why is that safe to assume?
< sipa>
morcos: the vector move constructor in practice (though not defined by the standard) leaves the argument empty
< sipa>
the standard just says that it needs to be in a valid but unspecified state
< sipa>
but there really is nothing that can be done efficiently that isn't leaving it empty
< morcos>
sipa: but what does a valid state mean? could the entries in the vector be such that it crashed your node when you tried to look at it?
< sipa>
nope
< sipa>
that would not be a valid state
< morcos>
i think its fine if -walletrejectlongchains doesn't work for 0.13.2, as long as you can't crash
< sipa>
well perhaps that code somehow assuming a non-empty vin?
< morcos>
well its not just the vin vector right, its the whole tx
< sipa>
right, but CTransaction is move-constructed from CMutableTransaction, which move-constructs vin and vout from the old vectors
< sipa>
which leaves txNew.vin and txNew.vout empty
< gmaxwell>
well it's not like we don't have to do an rc2 considering we missed the version bump.
< morcos>
well if we're doing one anyway, i think we should probably include 9395.. will save us at least explaining that the option doesn't actually work
< gmaxwell>
right.
< sipa>
i'm confused
< sipa>
the CTransaction(CMutableTransaction&& x) constructor is not in 0.13 afaik
< sipa>
nor is MakeTransactionRef
< morcos>
sipa: oh.. oops. i confess i didn't look too closely at 0.13
< sipa>
so the backport is correct
< sipa>
but the version in master is not
< sipa>
irony.
< morcos>
thats nice!
< instagibbs>
oops, I likely wrote the pr with working tests for:*static_cast<CTransaction*>(&wtxNew) = CTransaction(txNew); then it was changed while rebasing
< instagibbs>
yeah timeline for that looks right, my bad
< instagibbs>
Some kind of irony :)
< * luke-jr>
wonders if it would make sense to have a GUI option for "API Key" that sets up a rpcauth.
< morcos>
instagibbs: yeah i was pretty sure we had tested -walletrejectlongchains
< luke-jr>
0.13.2: should doc/release-notes/ include the 0.13.1 notes?
< luke-jr>
nm ^, had the wrong branch checkout out
< instagibbs>
morcos, we did and I got cyberbullied into removing it (jk, your tests are better)
< luke-jr>
- #9293 `e591c10` [0.13 Backport #9053] IBD using chainwork instead of height and not using header timestamp (gmaxwell)
< luke-jr>
- #9053 `5b93eee` IBD using chainwork instead of height and not using header timestamps (gmaxwell)
< gribble>
https://github.com/bitcoin/bitcoin/issues/9293 | [0.13 Backport] IBD using chainwork instead of height and not using header timestamp (#9053) by gmaxwell · Pull Request #9293 · bitcoin/bitcoin · GitHub
< luke-jr>
^ redundant?
< gribble>
https://github.com/bitcoin/bitcoin/issues/9053 | IBD using chainwork instead of height and not using header timestamps by gmaxwell · Pull Request #9053 · bitcoin/bitcoin · GitHub
< gribble>
https://github.com/bitcoin/bitcoin/issues/9053 | IBD using chainwork instead of height and not using header timestamps by gmaxwell · Pull Request #9053 · bitcoin/bitcoin · GitHub
< * luke-jr>
stabs gribble
< gmaxwell>
gribble is just demonstrating redundancy.
< luke-jr>
haha
< mannu>
How do I see the incoming transaction in a service
< mannu>
I want to separate out the components !
< luke-jr>
mannu: using -walletnotify, discuss/ask on #bitcoin
< mannu>
Can I write a blockchain app
< mannu>
rather than developing the bitcore further
< luke-jr>
Bitcore is not the same as Bitcoin Core, and while you can certainly develop other applications, this channel is for developing Bitcoin Core.
< mannu>
Ok !
< mannu>
Can you help me get started with writing the .js code for txns
< luke-jr>
Myself and many others are in #bitcoin and willing to help when we can.
< mannu>
I have put up the node running !
< mannu>
luke-jr: How do I get started with writing a service basics
< mannu>
Like how to catch txns
< mannu>
and separate out its components
< luke-jr>
I answered your first question here to be polite, but I will not continue to answer questions here that are off-topic. Move to #bitcoin for asking them.
< luke-jr>
(to do that, type: /join #bitcoin
< mannu>
Ok Thanks
< BlueMatt>
achow101: earlier you mentioned 5-byte sendcmpct messages.....were they coming from digitalocean-frankfurt?
< BlueMatt>
(not me, but I've been seeing them recently too on something claiming to be /Satoshi:0.13.1/ so curious who the fuck it is)
< BlueMatt>
whoever it is they bothered to set up their shit with the public fibre network (ie put their ip in the whitelist)
< wumpus>
luke-jr wonders if it would make sense to have a GUI option for "API Key" that sets up a rpcauth <- being able to enable RPC through the GUI would make sense, but with the automatic auth cookie stuff I wouldn't like to add another authentication method
< luke-jr>
oh, good point.
< luke-jr>
arguably no purpose to a key if cookies are usable :D
< paveljanik>
cookies works perfectly!
< paveljanik>
It would be nice to have "read-only" cookies though.
< wumpus>
you mean multiple authentication levels or something?
< wumpus>
the idea is to add everything that only inspects public data to the REST interface
< wumpus>
that is already a "read-only" interface
< sipa>
we could even have sendrawtransaction and submitblock to the REST interface as well
< sipa>
the read-only part isn't what matters - the public data is
< sipa>
though i guess it's also an avenue for DoS
< wumpus>
meh.
< wumpus>
well I guess that's true, those two can be done over the P2P interface just as well, so in principle no extra authentication should be necessary for them
< wumpus>
but I find a read-only REST interface much easier to reason about
< wumpus>
so I'd prefer to keep it that way
< wumpus>
being able to affect state opens a whole new can of worms of DoSes and attack surface. The whole REST thing has never really sit very well with me. But we have it, so if you need something like that you should use it, instead of adding more fluff to RPC auth.
< wumpus>
(and an option to enable the REST interface in the GUI options would also make sense)
< luke-jr>
not sure the point of read-only cookies if the program could just as easily access the read-write one
< wumpus>
eh, good point. Cookies are mostly useful for when the daemon and the program using it run as the same user. In which case there's full access anyway.
< wumpus>
though you could set up file permissions and such to use cookies cross-user. Though if you go through that trouble, why not set up actual RPC username/passwords while you're at it.
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #9399: travis: make distdir before make (master...Mf1612-travisDistDirCheck) https://github.com/bitcoin/bitcoin/pull/9399
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #9399: travis: make distdir before make (master...Mf1612-travisDistDirCheck) https://github.com/bitcoin/bitcoin/pull/9399
< bitcoin-git>
[bitcoin] instagibbs opened pull request #9400: Set peers as HB peers upon full block validation (master...maybesetfullblock) https://github.com/bitcoin/bitcoin/pull/9400
< bitcoin-git>
[bitcoin] instagibbs opened pull request #9401: Make rpcauth help message clearer, add example in example .conf (master...rpcauthnotes) https://github.com/bitcoin/bitcoin/pull/9401
< instagibbs>
is it just me or is master taking forever to shut down
< instagibbs>
a bunch of thread interrupt messages, then hanging for quite a while
< gmaxwell>
because verifying transactions takes a long time, especially single threaded.
< gmaxwell>
I've been noticing "/home/gmaxwell/.bitcoin: No such file or directory" show up on my console during node shutdown. Just saw it in 0.13.2rc-- I'd thought it was a new behavior in 0.14. anyone know what causes it?
< gmaxwell>
instagibbs: A slight complexity in interrupting it, is that it should probably also skip writting it out (so as to not rewrite it with half its content).
< bitcoin-git>
[bitcoin] rebroad opened pull request #9403: Don't ask for TX relay from feeler connections (master...NoRelayForFeelers) https://github.com/bitcoin/bitcoin/pull/9403
< gmaxwell>
wumpus: Any opinions on announcing rc1 to /r/bitcoin or should I wait for rc2/release?
< * gmaxwell>
does so
< gmaxwell>
do we intend the elipses in the 0.13.2 release notes: "This is a new minor version release, including ..., various bugfixes and performance improvements, "
< gmaxwell>
instagibbs: I seem to recall that we have some hack to avoid disconnecting peers that send invalid HB blocks that works by nulling out the nodeid on the recieved block.
< gmaxwell>
If so, you'll need to fix that for your announce patch.
< instagibbs>
at BlockChecked time it should have been valid?
< instagibbs>
Might need a pointer to line that does that so I can trace, thanks
< sipa>
gmaxwell: i assume it was to be filled in later, before 0.13.2 final
< gmaxwell>
instagibbs: I might be remembering a WIP patch.
< bitcoin-git>
[bitcoin] morcos opened pull request #9404: Make a second pass with same coins in CreateTransaction. (master...smartChange) https://github.com/bitcoin/bitcoin/pull/9404
< gmaxwell>
morcos: what prevents the change from becoming dust in that?
< morcos>
gmaxwell: it picks new coins (as before) if the change would be less than CENT/2
< morcos>
if you had a large transaction, such that your fee was on the order of a CENT anyway, this would still be a good change to have but it would just kick in on the second set of coins you pick, once you've tried to pay for the first pass fee
< morcos>
in that case it would still be vulnerable to the way overpay for fee bug, but in most cases that won't happen now
< morcos>
the bug is that you try to pay X, you select many coins N to pay for X. discover you need some large fee Y. and when selecting coins to pay X+Y you end up with just a couple.
< morcos>
so your new fee required is much lower but you still pay Y fee
< gmaxwell>
Makes sense, so long as dust>cent/2 (perhaps we should have a comment so if the target amount gets reduced people will make sure it hasn't bumped into dust)
< gmaxwell>
should it also consider the case where the change is removed? E.g. if the initial selection was unable to achieve target+0.01 it might have given us target+0.00024 (say) which would might be a reasonable fee.
< morcos>
didn't follow that last part... whats the target amount?
< morcos>
hmm.. yes that might be a simple enough case to add
< morcos>
i don't think the way the code works now the target amount (the amount of coins you select for) can ever be reduced
< gmaxwell>
it should be okay to overpay the fee by a little (at the very least by the amount saved from removing the change).
< gmaxwell>
morcos: I thought (could be wrong) that selectcoins tries to select for +cent and if that fails it falls back to just the target.
< morcos>
yes i think thats true... but thats before this loop... but i guess its possible you could make +cent originally, but then not when you add in fee
< morcos>
anyway, there are gazillions of possible improvements.. but i was hoping if we weren't too ambitious we could get something done in time for 0.14
< gmaxwell>
Yes, I support that, I wasn't trying to send you down a rabbit hole. :)
< morcos>
I think the key thing to think about is whether there is any way this could be worse.. my thought process was if anything goes wrong, it just obviously falls back to preexisting behavior.
< gmaxwell>
I do wonder about what the right behavior is with respect to slightly overpaying fee to avoid a change output.
< morcos>
gmaxwell: yeah actually i just realized your suggested case of eliminating a change output isn't trivial
< morcos>
unless the change is really really close to the fee needed
< gmaxwell>
I believe the only non-trivial part is just the threshold. I think it's clearly okay to 'throw away' fees equal to the amount of weight saved (at targetfeerate) for the removed output.
< morcos>
b/c if you eliminate it, and then test, and its not enough... then you will have calculated a rough fee needed for your tx without a change output when you go back to your next loop, and kind of doomed yourself to failure on that loop
< morcos>
yeah but thats such a small buffer, its hard to have change that is between (feeneeded - delta, feeneeded) by random chance
< morcos>
off to lunch
< Chris_Stewart_5>
Is there any test cases inside of core for the commitment structure inside of coinbase scriptPubkeys?
< bitcoin-git>
[bitcoin] djp3 opened pull request #9405: Contrib: Mac: Two changes to python bytes and string management to get the mac deploy to work (master...macPythonTweak) https://github.com/bitcoin/bitcoin/pull/9405
< Chris_Stewart_5>
When calling 'GetWitnessHash' on a non witness tx, does it just return the normal txid?