< luke-jr>
wumpus: he's saying we should make manpages and ONLY document in those
< luke-jr>
ie, get rid of the --help details and RPC help stuff
< gmaxwell>
why wouldn't we just improve the --help and improve the autogen
< luke-jr>
he seems to think documentation simply belongs in manpages
< luke-jr>
I don't necessarily agree (nor disagree).
< gmaxwell>
documentation in the system is very helpful, from a pratical perspective.
< gmaxwell>
and much easier to keep updated, and acts as source code documentation too
< wumpus>
no one is going to maintain external manpages, the generation is useful imo
< wumpus>
I agree that creates an overlap between --help output and the man page, but I don't see it as a problem
< luke-jr>
the only ways I see to improve on how we do it now are 1) we lost a manpage for bitcoin.conf, and 2) they ideally would be auto-generated during the build
< wumpus>
and moving the manpages from doc/man to src makes no sense either, that directory is already cluttered enough
< bitcoin-git>
bitcoin/master d34d77a Cory Fields: build: verify that the assembler can handle crc32 functions...
< bitcoin-git>
bitcoin/master db825d2 Wladimir J. van der Laan: Merge #10806: build: verify that the assembler can handle crc32 functions...
< bitcoin-git>
[bitcoin] laanwj closed pull request #10806: build: verify that the assembler can handle crc32 functions (master...configure-check-asm) https://github.com/bitcoin/bitcoin/pull/10806
< bitcoin-git>
[bitcoin] jtimon opened pull request #10822: TOTEST: Also server txo from gettxout (not just utxo and mempool) (master...b15-rpc-txo) https://github.com/bitcoin/bitcoin/pull/10822
< jonasschnelli>
Is there no RPC call (chain) to get a rawtx if I know height and txid?
< wumpus>
jonasschnelli: #10275?
< gribble>
https://github.com/bitcoin/bitcoin/issues/10275 | [rpc] Allow fetching tx directly from specified block in getrawtransaction by kallewoof · Pull Request #10275 · bitcoin/bitcoin · GitHub
< jonasschnelli>
Oh! Nice... I missed that
< jonasschnelli>
I even commented... :/
< jonasschnelli>
Would allowing a range of blocks (defined by height) make sense as addition?
< wumpus>
not sure...
< wumpus>
when does that use case happen? you know a transaction is in a certain block range?
< jonasschnelli>
Use case, I know a txid but don't know if it is confirmed or not... maybe you can say "check the last X blocks for txid Y"
< jonasschnelli>
But yeah.. meh.
< jonasschnelli>
10275 is really nice
< sipa>
wumpus: i actually said to gmaxwell earlier today about
< sipa>
wumpus: i actually said to gmaxwell earlier today about 10820 "in about 3 years someone will try to compile with OpenBSD, and notice that it doesn't work... and then we'll add some #ifdefs around it"
< jonasschnelli>
I tried to compile Core on a openBSD VM. But I could not even install python3. The package manager idled endless at the point of decompression...
< wumpus>
sipa: hah, no need to wait for that, I compile bitcoin core on openbsd quite a lot
< wumpus>
jonasschnelli: strange
< mmgen>
signrawtransaction is adding the redeem script but not the witness data to transaction. Can anyone help?
< mmgen>
(I'm adding segwit support to my wallet)
< mmgen>
And the "signed" transaction with no witness relays OK on testnet and is included in mined block. Strange.
< mmgen>
What am I missing?
< jonasschnelli>
mmgen: can you maken an example and file an issue on github?
< jonasschnelli>
Ideally show your process and in-/output
< mmgen>
I don't think this warrants an issue. I'm clearly doing something wrong. signrawtransaction can sign segwit ps2h TXs if you supply the redeem script and keys, right?
< mmgen>
The sign operation returns OK. TX broadcasts OK. TX is mined. But there's no signature.
< bitcoin-git>
[bitcoin] greenaddress opened pull request #10823: Allow all mempool txs to be replaced after a configurable timeout (default 6h) (master...replace-by-fee-old-transactions) https://github.com/bitcoin/bitcoin/pull/10823
< cfields>
sipa: interesting. clang doesn't enable -fomit-frame-pointer at any optim level
< cfields>
adding that in fixes compilation
< luke-jr>
doesn't it break debugging?
< bitcoin-git>
[bitcoin] promag opened pull request #10824: Avoid unnecessary work in SetNetworkActive (master...2017-07-set-network-active) https://github.com/bitcoin/bitcoin/pull/10824
< cfields>
luke-jr: it's on by default for x86_64
< cfields>
er, for gcc
< mmgen>
arubi: now redeem script is correctly formed, signrawtransaction is including the witness data, but txsend fails with 64: non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation) (code -26)
< mmgen>
input in question is output 0 of testnet tx dd2117779039b6abd20529c9c9ce67b4c18c0a0223129759ae01deebaa037151
< arubi>
mmgen, then your sig is not valid. it's too off topic here. we can move to #bitcoin-dev if you want
< mmgen>
arubi: agreed, this is offtop, but #bitcoin-dev requires registration doesn't it?
< arubi>
oh I don't know..
< mmgen>
think it does. How do I go about that?
< arubi>
that's something done through nickserv
< Chris_Stewart_5>
it does
< Chris_Stewart_5>
and I have no idea why it does :/
< arubi>
yea it's an overkill
< mmgen>
yet #bitcoin-core-dev doesn't
< mmgen>
I'm working on registration now
< mmgen>
sent the request
< morcos>
promag: Your question before about the buggy output. That isn't buggy as far as I can tell. What did you not like? The -1's?
< promag>
nan
< morcos>
oh i think we covered that before and determined it was fine to divide by 0 (it's only for outputing text) and in this case there are no txs in the denominator
< promag>
for reference the output is: Fee Calculation: Fee:4520 Bytes:226 Tgt:6 (requested 6) Reason:"Fallback fee" Decay 0.00000: Estimation: (-1 - -1) -nan% 0.0/(0.0 0 mem 0.0 out) Fail: (-1 - -1) -nan% 0.0/(0.0 0 mem 0.0 out)
< morcos>
yeah so that tells me there were no data points in your fee estimation
< promag>
right, but in the UI it says: "Warning: Fee estimation is currently not possible"
< morcos>
promag: yes exactly.. and the debug log is telling you exactly why it is not possible. no data points. it could have also indicated some smaller number of data points, or enough data points but no fee rate high enough that meets the passing threshold for your target
< morcos>
that debug log output is just for help determining exactly why a particular fee is put on a transaction.
< morcos>
gmaxwell: speaking of which we'd recently discussed making the fallback fee higher than 20 sat/b. I think we discussed 50 or 75. The thinking at the time is 20 is often not high enough to ever get confirmed.
< morcos>
But perhaps we were over influenced by a short period of congestion?
< promag>
ok then morcos, thanks
< morcos>
In any case, I'd still be ok with 50 or 75 as the default for fallback.. I don't think its so unreasonably high that people would complain if they paid that if fee estimation wasn't working
< morcos>
The downside is if fees drop substantially over some period of time, lets say BTC goes up 10x, and then paying 75 sat/B is actually kind of a lot. I suppose it's a no win situation for getting the right number here.
< morcos>
Maybe the answer is to not touch the default but give advice in release notes about setting that number appropriately?
< bitcoin-git>
[bitcoin] fametrano opened pull request #10825: Net set regtest JSON-RPC port to 18443 to avoid conflict with testnet 18332 (master...fametrano-regtestport) https://github.com/bitcoin/bitcoin/pull/10825
< To7>
Core dev, time to protect Bitcoin differently.
< BlueMatt>
without looking at the code (just the docs), can folks tell me what they think the "target_confirmations" parameter means in listsinceblock?
< BlueMatt>
"2. target_confirmations: (numeric, optional) The confirmations required, must be 1 or more\n"
< Murch>
We currently have two paths for receive and change addresses, and we're considering to adding another two paths for segwit receive and change addresses.
< instagibbs>
Murch, there are none right now AFAIK. BIP49 I think is the only proposed one for Mycelium or something
< BlueMatt>
instagibbs: ahh, ok, that still leaves me wondering what in the fuck the purpose of that argument is
< Murch>
instagibbs: Thanks, I'll take a look.
< instagibbs>
Murch, I'd suggest asking various wallet authors, don't think there's consensus on that at all
< Murch>
What would be a good way to reach them? Would that perhaps be worth a mail to the bitcoin-dev list?
< BlueMatt>
instagibbs: care to ack that? I find that astoundingly poor docs, should fix for 15 if possible
< instagibbs>
BlueMatt, asking the author, I have actually no clue
< BlueMatt>
the docs on 10655 make it a bit more clear, ie if you care about when things hit 6 confs, you calling listsinceblock with old blocks each time so that you keep getting reminded of things with 6 confs
< BlueMatt>
and then you filter for txn with 6 confs yourself
< BlueMatt>
still seems a super strange api to me, but i can see why it would be useful
< instagibbs>
Murch, yeah I think so. Also bug bigger players individually maybe
< Murch>
instagibbs: Thanks for the consult. ;)
< cfields>
sipa: heh, not a good sign: Assertion failed: (consensus.hashGenesisBlock == uint256S("0x000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943")),
< bitcoin-git>
bitcoin/master 18bacec Alex Morcos: Make check to distinguish between orphan txs and old txs more efficient....
< bitcoin-git>
bitcoin/master 66270a4 Pieter Wuille: Merge #10557: Make check to distinguish between orphan txs and old txs more efficient....
< bitcoin-git>
[bitcoin] sipa closed pull request #10557: Make check to distinguish between orphan txs and old txs more efficient. (master...dontcheckoutputs) https://github.com/bitcoin/bitcoin/pull/10557
< sipa>
cfields: the code here was an attempt to actually translate it to extended asm, where the compiler still manages the stack and register allocation
< sipa>
cfields: i can go for the more straightforward way of just making it produce literally the same bytecode as yasm, where the asm is responsible for saving/restoring registers etc
< cfields>
sipa: understood, i just wanted to get a working asm dump to compare to
< cfields>
heh, no clue what all this padding is about
< sipa>
cfields: i can make the code use one less register
< cfields>
sipa: i've been trying to figure it out :)
< cfields>
sipa: i think you can shortcut the end address calculation?
< sipa>
cfields: if you look at the yasm source, NUM_BLOCKS and e use the same register
< sipa>
one uses it in 32-bit mode (edx) and one in 64-bit mode (rdx)
< sipa>
which my search/replacing treated as two different things
< cfields>
ah
< cfields>
ok i see, that makes sense. That's the one I was trying to save as well. But so far I'd just managed to piss off the assembler in a bunch of different ways.
< sipa>
cfields: so s/%7/%k2/
< sipa>
%k2 means "the same as %2, but in 32-bit mode"
< sipa>
and then more shuffling to get rid of the e variable...
< cfields>
roger
< cfields>
sipa: i'm confused as to why inp_end can't be pre-calculated and passed as an input, skipping %2 altogether?
< sipa>
cfields: we could move that out to the C code, yes
< sipa>
the asm code really uses a begin_ptr and end_ptr
< sipa>
and the first 3 instructions convert the (begin_ptr, num_blocks) to that
< cfields>
sipa: right ok, thanks. no need to do that rather than your approach ofc, but it helps to know that would've worked
< gmaxwell>
sipa was in the process of changing everything to use explicit registers and then he was going to manually save bp on the stack so he could use it and restore it at the end.
< sipa>
this approach now should be faster
< sipa>
as it only saves/restores exactly what is needed
< cfields>
testing now
< sipa>
cfields: thanks!
< cfields>
sipa: builds now, but still produces a busted hash :(
< sipa>
:'(
< sipa>
cfields: with or without -fomit-frame-pointer ?
< cfields>
without now
< cfields>
i'll try without the stack protector
< cfields>
same thing
< sipa>
cfields: i can try force assigning variables to registers, to make the code comparable to the yasm code?
< sipa>
to make sure the same assignment is used
< cfields>
sure
< cfields>
sipa: from what i can see, the input is no longer necessarily 32bit aligned
< cfields>
is that a possible issue?
< sipa>
cfields: oh!
< sipa>
how do you mean?
< cfields>
let me double-check, i might've reversed something in testing
< cfields>
sipa: yea, the ReadBE32 on the chunk guaranteed alignment before, without that, is something else handling it?
< sipa>
cfields: the asm code can deal with unaligned input data
< cfields>
ok
< sipa>
cfields: i think that the xfer array may need stronger alignment than the compiler is giving it
< sipa>
cfields: care to try again?
< cfields>
sure, i'll take a break from fighting this thing.
< cfields>
heh, i was trying the same thing, but i pissed it off trying to make it 32bit aligned
< cfields>
no go :(
< sipa>
same error?
< cfields>
yea. you just added the attribute, right?
< sipa>
yes
< cfields>
btw, that can be alignas(16) with c++11
< cfields>
any clue what the huge chunk of padding is?
< sipa>
the nopws?
< sipa>
cfields: can you try changing the movdqa instructions to movdqu ?
< sipa>
(a = aligned, u = unaligned)
< cfields>
yea, 0x91 through 0x10000
< cfields>
ok
< cfields>
nope :(
< sipa>
cfields: my guess is that to the OSX assembler ".align 16" means "align to a 2^16-byte boundary"
< sipa>
instead of "align to 16-byte boundary"
< cfields>
ah
< sipa>
cfields: pushed again, try again pretty please?
< cfields>
heh, sure
< sipa>
added some more alignas'es
< sipa>
i think there are instructions beyond movdqa that require aligned input
< cfields>
still no go
< cfields>
you saw me mention that the result is always the sha2 init values, right?
< sipa>
oh, no
< cfields>
hash is "19cde05babd9831f8c68059b7f520e513af54fa572f36e3c85ae67bb67e6096a"
< sipa>
cfields: you're aware the yasm function takes its parameters in a different order?
< cfields>
yes, i had to reverse them to make it work
< sipa>
grrr
< sipa>
i really don't see how the state can be untouched with your disasm code... unless blocks=0
< cfields>
i'm stumped too. It gets in there sometimes with blocks=0, but even if I early-return, same result
< sipa>
can you give a latest disasm?
< sipa>
can you step through it with a debugger, to see if it's actually doing anything?
< sipa>
(stepi in gdb will execute 1 instruction)
< cfields>
i've tried to get in with no luck
< cfields>
i can try again
< cfields>
(it's lldb, and i'm not at all familiar with it)
< sipa>
cfields: just some thing i'm noticing from the latest disasm you posted: the stack pointer isn't being updated, but is addressed with negative offsets (which is legal, but different from other platforms)
< sipa>
it also saves and restores the frame pointer, but does not actually use it
< cfields>
sipa: i noticed the negative offsets too. how can that be the case?
< sipa>
cfields: it's legal to use some stack space below the stack pointer (google for red zone)
< sipa>
if you want to set a breakpoint, set it to the loop2 label
< cfields>
interesting
< sipa>
if loop2 is reached, it should always update the context
< cfields>
that's a rabbit hole for a different day though :)
< sipa>
(the updating happens in the addq/movq sequence right before done_loop)