There are three ways in which that offered HTLC output can be redeemed: Revocation using the revocation public key (the example you mentioned), redeemed using a valid payment preimage or back to the local node after the timeout.
Redeemed using a valid pre-image by remote node:
The stack starts at <remotehtlcsig> <payment_preimage>
Since the ...
Yes, this is the problem.
Pre-segwit there is a standardness rule in Bitcoin Core that requires a single element only on the stack after execution.
In P2WSH, this is part of the consensus rules.
The reason for this is that without such a rule it is trivial to malleate any transaction: just prefix the scriptSig with additional garbage elements, which would ...
A P2SH locking script on an output has the following structure:
OP_HASH160 <scripthash> OP_EQUAL
The address comes for this comes from the <scripthash>, creating a "3address". This is the standard format for a P2SH, so you can identify it and work out the address from there.
Check the Script wiki would be helpful. I once did this by hand, here's the process.
First, put the unlocking script on top of the locking script,
# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
From what I understand, a non-SegWit P2PH address is obtained by hashing the redeem script
I had the same problem and I have resolved it with this C++ code, and I think this code is self-describing.
If you have the ScriptPubKey extract from the blk file, this is code calculate the correct address P2SH.
string opcode = hex.substr(0, 2);
I'd say that's just because nobody programmed it. Bisq community for example is short on programmers so they concentrate on the essentials. Companies have no interest in the development or shy away from the legal risk, where they are increasingly forced to perform financial police duties similar like banks (KYC/AML). Hopefully the Bisq DAO brings enough ...