Does P2SH unlocking script only consist of operants?

I have a question about the P2SH unlocking script. Can I put common operants and operators in the P2SH unlocking script? And if yes, how can I create such script?


unlocing script: <sig1> <pk1> CHECKSIG <pk1> <redeem script>

redeem script: HASH160 <address> EQUALVERIFY <sig2> <pk2> CHECKSIG

How much data does it take to prove a given transaction exists on the blockchain?

As I understand the SVP protocol, a client can be reasonably certain that a transaction has been accepted on the blockchain if they know it is a member of a certain block, via the Merkle path, and a reasonable number of blocks have been mined on top of that block.

How much total data would that be, roughly? I guess if you were beginning with 0 knowledge, you would need all of the block headers, beginning from the genesis block? But once you are convinced you are looking at the head of the right chain, you could discard all of the ancient block headers, and just save a recent one as a trusted starting point to evaluate subsequent transactions?

I guess the premise of my question is faulty, as a fake transaction could always be embedded in a fake chain, if enough computing resources were available. So, there is no amount of data that insures a transaction is valid, without access to other information, e.g., what is the longest chain currently in existence.

A better question for my purposes would be how much would the electricity cost to create one fake block header at today’s difficulty level? Figuring that blockchain currently pays around $60K to mine one block, I would guess it must be in that order of magnitude, though smaller since we are removing the race condition.

Stale block verification at node level

It comes to my curiousity about how exactly the node A will mine block N+1 when he & node B generated block N (not in same time but) in a fairly close timeframe.

In many articles, it says that when 2 nodes (A&B) are generating the same height block at same time, it will cause a fork. This means some nodes will mine after A’s new block and others mine B’s. This is understood. However, it will take time when A’s new block sync to B. Let’s assume it takes 10 seconds to pass to B. In the middle of the sync (saying 5th or 6th second of total 10), B just generates the new block (with same height), and propagate it out before receiving A’s block. What will happen when B receives A’s block then?

I have 2 possible answers but not sure which one is correct, or neither.
(assuming all TX/UTXO in the block has no issue)

ANSWER-1: B will discard B’s block, and accept A’s, because B block’s timestamp is older than A’s (make sense?)

ANSWER-2: when B broadcasts his new block, B by default accepts its own generated block (N+1) and immediately start to mine block N+2 upon that (at the time when B has not received A’s block yet.) Then B receives A’s block (N+1), in this case, B should keep A’s chain but still continue to mine at his N+2 block height.

Any advice?

Combining a Bitcoin transaction with one address holding USDT, but no BTC and using another address with BTC to pay for the fees?

I have a Bitcoin address that contains USDT, but NO BTC in it. So I cannot even send the USDT out. But I have another bitcoin address that does have BTC. Can I somehow combine these 2 addresses where I can pay the btc from one address that also pays to send out my USDT? If this doesn’t work, that means I have to send BTC to the USDT account in order to send it back out?

What application supports the Omni layer with batching to make this work?

When update mining difficulty, Is the timespan of the past 2016 blocks approximated value?

I know how to calculate difficulty, and I know it is increased or decreased by checking the timespan of the past 2016 blocks.

and I found actual code for calculating timespan:

actual_timespan = last_block->get_timestamp() - first_block->get_timestamp()

But, as I know timestamp in block is not the exact time of the mining:

So, the timespan which is used to calculate the next difficulty is not the exact timespan but approximate value. Am I right?

What is the purpose of the script like RETURN PUSHDATA(36)(…)

The example is in here:

Actually, there are two outputs
DUP HASH160 PUSHDATA(20)[78ce48f88c94df3762da89dc8498205373a8ce6f] EQUALVERIFY CHECKSIG
RETURN PUSHDATA(36)[aa21a9ed9463ee420b10cbad1d997bfa132a89dc9ba3de04e7233e6e6954f1bc339ebb1a]

The strange point is the first output has 12.77303443 BTC, the second is 0 BTC.

There are two questions about this transaction.
1) How the coinbase could have more than 12.5 BTC?
2) What is the purpose of the RETURN PUSHDATA(36)(…), actually, in theory, this output can never be consumed by anyone, becuase there is no OP_CHECKSIG or similar OP at the end to return true in the Script stack.

Are there any risks on publicizing a Lightning network invoice?

What are the negative effects of publicizing a LN invoice either before or after its payment?

From what I understand, after its payment it won’t allow a 2nd payment of the invoice, so 3rd parties will know if this invoice was paid, but what more can they learn?
(Keeping aside the social-engineering impersonations)

  • Does it affect -most importantly- the safety of the funds?
  • Does it negatively affect the privacy or something else?
  • Could the actual payer prove (cryptographically) that they were the one that paid the invoice?