< gmaxwell>
So -- we have bytessent_per_msg and bytesrecv_per_msg ... would it be insane to ahve a bytes_implied to track bytes of blocks implicitly sent/recieved via comprblock/blocktxn in matt's block relay code?
< da2ce7_mobile>
is there a easy way to 'reset' an unconfirmed transaction in Bitcoin-QT?
< da2ce7_mobile>
I should be able to right click on a unconfirmed transaction and go 'delete' and then make a replacement one. (if I wish).
< da2ce7_mobile>
But I suppose reddit would go crazy if you could do that. "meh-unconfirmed-tx-double-spends"
< sipa>
da2ce7_mobile: there is a pull request for adding support for abandoning a transactionz and RPCs for respending with higher fee
< luke-jr>
da2ce7_mobile: the right click option needs to do the replacement too, so it can ensure there's a shared input
< da2ce7_mobile>
what is the best way to do it *now* if I don't want to compile bitcoin with that pull request merged?
< luke-jr>
da2ce7_mobile: the abandon RPC + coin control to ensure you double-spend it
< da2ce7_mobile>
I try: abandontransaction "txid" but it fails.
< da2ce7_mobile>
"TX is not eligible for abandonment (code -5)"
< da2ce7_mobile>
I cannot find the documentation to explain what code -5 is.
< sipa>
da2ce7_mobile: the code will not tell you anything more than the text
< sipa>
da2ce7_mobile: and the rpc help for abandontransaction will explain more
< GitHub56>
[bitcoin] laanwj opened pull request #7956: test: Add more thorough test for dbwrapper iterators (master...2016_04_dbwrapper_iterator_tess) https://github.com/bitcoin/bitcoin/pull/7956
< Chris_Stewart_5>
Should this test case fail as a INVALID_STACK_OPERATION instead of BAD_OPCODE?
< Chris_Stewart_5>
["0x4c01","0x01 NOP", "P2SH,STRICTENC","BAD_OPCODE", "PUSHDATA1 with not enough bytes"]
< afk11>
Chris_Stewart_5, the test fails because of line 265 I imagine - script.GetOp is responsible for loading the opcode, and pushdata if any. That case has pushdata1 + the length marker, but is missing a byte the interpreter knows should be there
< afk11>
hence that function would fail, resulting in SCRIPT_ERR_BAD_OPCODE
< afk11>
oops, I'm talking about interpreter.cpp's line 265
< sipa>
there is no problem with the stack in that code :)
< sipa>
the stack isn't even touched by the failing instruction
< sipa>
afk11: indeed
< Chris_Stewart_5>
I guess I was thinking in the sense that it is failing to push something onto the stack.. however if we continue that though almost every error would be an invalid stack op
< Chris_Stewart_5>
thought*
< afk11>
Chris_Stewart_5, it's only thrown once in the codebase - if the opcode is totally invalid
< Chris_Stewart_5>
afk11: Not sure what you mean by that. In the case we are talking about the op code is valid, however the arguments for the op are invalid
< Chris_Stewart_5>
I guess the semantics for SCRIPT_ERROR_BAD_OPCODE extend to the op code AND its implicit arguments
< GitHub11>
[bitcoin] jonasschnelli opened pull request #7957: [RPC][Bitcoin-TX] Add support for sequence number (master...2016/04/rbf_base) https://github.com/bitcoin/bitcoin/pull/7957
< Chris_Stewart_5>
Are there any script_tests that test CHECKSEQUENCEVERIFY? I did a quick search and it appears that term doesn't appear in script_tests.json
< sipa>
Chris_Stewart_5: sure, in qa/rpc-tests there are some
< GitHub78>
[bitcoin] paveljanik closed pull request #7810: Refactor AlertNotifyOnce out of UpdateTip (master...20160405_AlertNotifyOnce) https://github.com/bitcoin/bitcoin/pull/7810
< GitHub25>
[bitcoin] paveljanik opened pull request #7958: Remove useless argument to AlertNotify. (master...20160427_AlertNotify_remove_arg) https://github.com/bitcoin/bitcoin/pull/7958
< kanzure>
still seeing "Request-sent" errors from a python application using python-bitcoinlib's rpc connection object, originally i reported this as #6454 which was fixed by using rpckeepalive=0 (#6454 had an additional issue where rpc would become completely locked up).
< kanzure>
my more recent encounters of "Request-sent" are unfortunately not associated with that rpc thread locking behavior
< kanzure>
unsure whether this is a python issue or a bitcoind issue. i've found that creating new python-bitcoinlib rpc connection objects (instead of reusing a single object over the course of a few hundred rpc requests and a few minutes) does not cause the "Request-sent" error..
< kanzure>
(specifically the exception is "http.client.CannotSendRequest: Request-sent")
< jl2012>
Will all disabled op codes (e.g. OP_CAT) fail the script, even in an unexecuted branch?
< cfields>
MarcoFalke: ping
< MarcoFalke>
pong]
< cfields>
MarcoFalke: not sure if you saw yesterday... have you looked into parallelizing the rpc tests?
< MarcoFalke>
Not yet, other things are holding me back right now.
< cfields>
ok. But there's not any major reason not to?
< MarcoFalke>
no
< cfields>
great. I experimented with it yesterday, and it seemed to work quite well. Unfortunately my python is terrible though, so it was just hacking and slashing
< MarcoFalke>
Oh, nice!
< MarcoFalke>
My python-foo is not that high, either :)
< cfields>
heh, that's not true at all :)
< cfields>
only major change necessary seems to be listening port definition. atm we use the pid..pid+3 range, which causes overlaps in tests (assuming they're launched in separate processes as opposed to threads). My solution was to pass in the port range everywhere instead
< cfields>
er, func(pid...pid+3), not the pids themselves
< MarcoFalke>
you mean passing in from rpc-tests.py ?
< MarcoFalke>
I can have a look at the patch if you push it
< cfields>
yea, the framework accepts a new option for port range, which defaults to the old behavior of func(pid). In the pull-tester case, it overrides
< sipa>
(not suggesting we use NetBSD, but that approach may be useful)
< luke-jr>
right
< sipa>
or we could just include a piece of asm for common platforms *ducks*
< gmaxwell>
sipa: it was my expectation that we had to do that.. the argument that you could use a volitile function pointer is new to me...
< sipa>
(the extended asm syntax supported by gcc and clang can indicate that it has side-effects, and the compiler is not allowed to remove it or duplicate it)
< sipa>
gmaxwell: how about you make two wrappers around memset, each which modifies a TLS pointer to point to the other one
< sipa>
not only is it volatile then, it's even actually changing :)
< gmaxwell>
the only disagreement I might have with that volitile pointer argument is that for a long time many compilers frequently miscompiled code when volitile was in use (sometimes even worse than just ignoring the volitile)-- though in the last 5 years that has gotten _much_ better.
< luke-jr>
inb4 it compiles to: if (memset_volatile != memset) memset_volatile(…);
< cfields>
sipa: i've wrestled with that one. We could do an autoconf check for it, but if it's not there we'd fall back to something else. So ultimately we're stuck with a reliance on something else, or we roll our own and don't bother checking for memset_s