Output – What is happening in this “Enter NULL address” transaction?

When a recipient asks you to send them money, you specify the terms under which the funds can be used. output script. Later, when the recipient wants to use the funds, they must provide: input script This satisfies the output script of the output they consume. In transaction validation, the input script is evaluated first, and then the resulting stack is used as a starting point to evaluate the output script.

For example, for P2PKH, the input script contains the signature and public key, and the output script contains: OP_DUP OP_HASH160 pubkeyhash OP_EQUALVERIFY OP_CHECKSIG.

Upon evaluation, the input script first pushes the signature and then the public key onto the stack. The stack is then passed to an output script like this:

1. Clone the public key
2. Replace the first of the two copies of the public key with the hash of the public key.
3. Pushes pubkeyhash onto the stack.
4. Ensure that the pubkeyhash pushed in the output script and the pubkeyhash hashed from the pubkey in the input are the same.
5. Verify that the remaining public key and signature match a valid signature in the transaction.

There are several standardized output scripts for frequent use. Some of these address single signature use cases, but there are also several standard output types for complex scripts. courtship A convenient shorthand for the standard output script type that passes the recipient’s output script to the sender. Even before the introduction of P2SH, receivers could define arbitrary conditions by writing corresponding output scripts using opcodes defined in: bitcoin script. these bare script This is uncommon because arbitrary content does not fit address standards. The UX is terrible. Instead of addresses with checksums, the recipient and sender must exchange actual scripts, and the sender must manually create a raw transaction specifying the output script. (P2SH was introduced to improve the UX around defining your own spending terms while allowing for address standards.)

The transaction you are viewing contains these default scripts. Instead of following one of the standard output schemes, recipients defined their own output scripts and satisfied subsequent input accordingly.

Output script specified for output a601…0e0c:0 The details of the previous transaction are as follows:

OP_DUP
OP_0
OP_LESSTHAN
OP_VERIFY
OP_ABS
OP_PUSHNUM_1
OP_PUSHNUM_16
OP_WITHIN
OP_TOALTSTACK
OP_PUSHBYTES_33 0378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71
OP_CHECKSIGVERIFY
OP_FROMALTSTACK

Input script for first input 54fa…814f am:

OP_PUSHBYTES_72 
3045022100d92e4b61452d91a473a43cde4b469a472467c0ba0cbd5ebba0834e4f4762810402204802b76b7783db57ac1f61d2992799810e173e91055938750815b6d8a675902e01
OP_PUSHNUM_NEG1

The script essentially corresponds to an obfuscated version of the P2PK output, as can be seen by evaluating the script execution.

1. The input script pushes the signature onto the stack.
   Current stack (bottom left): SIG
2. number -1 is pushed onto the stack
   stack: SIG -1
3. The stack is passed to the output script validation.
4. Duplicate number -1.
   stack: SIG -1 -1
5. all 0 is pushed onto the stack
   stack: SIG -1 -1 0
6. OP_LESSTHAN Consumes 2 items (a, b) from the stack 1 Because on the stack all (-1) smaller than rain (0).
   stack: SIG -1 1
7. OP_VERIFY consume 1 Go up on the stack and succeed
   stack: SIG -1
8. OP_ABS Replaces the top stack item with its absolute value.
   stack: SIG 1
9. all 1 is pushed onto the stack
   stack: SIG 1 1
10. all 16 is pushed onto the stack
    stack: SIG 1 1 16
11. OP_WITHIN Consumes three values: (x min max) And then 1 This is because x is greater than or equal to the minimum and less than the maximum.
    stack: SIG 1
12. OP_TOALTSTACK Removes the top element from the stack and places it on a replacement stack.
    stack: SIGPrevious stack: 1
13. The public key is pushed onto the stack.
    stack: SIG PUBKEYPrevious stack: 1
14. OP_CHECKSIGVERIFY It uses a signature and a public key and verifies that the signature is valid in the context of the transaction and the public key.
    stack: <empty>Previous stack: 1
15. OP_FROMALTSTACK Alt Removes the top value from the stack and places it on the stack.
    stack: 1Previous stack: <empty>
16. The script succeeds because it ends up with a single truth value. 1 On the stack.

These transactions may break some block explorers in that they may only support standard scripts and do not display default output properly. Modern block explorers no longer seem to suffer from this problem.
^{For example mempool.space shows the output script of the previous transaction…}

^{… And spending deals are okay.}

If “breaking the block explorer” is understood as a privacy benefit, then these transactions are no longer private. In Bitcoin transactions, funds from the address are not spent. An address simply specifies the conditions under which funds can be spent, but each input must specify exactly what conditions must be specified. transaction output It’s an expense. previous transaction a601…0e0c Produced a single output. a601…0e0c:0 The mentioned default output script and 54fa… available to the owner of that script. The first input of 814f was used explicitly. a601…0e0c:0To generate different transaction output: 54fa…814f:0 How much a recipient can spend to control an address 1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB. This means that every UTXO is uniquely identifiable and the transaction graph is public information. Without an address, there is no privacy benefit.