13

I found out this address playing with blockchain

https://blockchain.info/address/3NukJ6fYZJ5Kk8bPjycAnruZkE5Q7UW7i8

I found out it's something called "scripthash". How does it work exactly? How does it differ from a normal address?

I found out this - https://en.bitcoin.it/wiki/BIP_0016 - but I still don't get it and I don't get the point.

The benefit is allowing a sender to fund any arbitrary transaction, no matter how complicated, using a fixed-length 20-byte hash that is short enough to scan from a QR code or easily copied and pasted.

How does it differ from what is possible today - scanning just the address of the reciever?

edit: And adding one more question - why exactly is this transaction with the mentioned address as input

https://blockchain.info/tx-index/3618498

included in 94 different blocks? How does that even work?

11

The P2SH, as defined in BIP 16, states that

The purpose of pay-to-script-hash is to move the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer.

The benefit is allowing a sender to fund any arbitrary transaction, no matter how complicated, using a fixed-length 20-byte hash that is short enough to scan from a QR code or easily copied and pasted.

Hence it allows any client implementation to fund a transaction with an arbitrary script, without the client necessarily having to understand it. You see, there are some quite complicated possibilities for transactions to state their claiming conditions, which may put different implementations of clients under a dilemma: each time a new script type surfaces they'd have to implement it so that the client can send transactions that make use of them.

P2SH has the advantage that the client does not necessarily have to know how to build such a script, it just has to know how (given an arbitrary script, or indeed its hash) building a script that first verifies the script and then uses that script to verify the claim itself works.

Suddenly, if I provide you with a hash of a claiming condition (script) you can send me bitcoins without actually having to know what security mechanisms I put in place to secure that only I can then spend them.

As an added bonus it really keeps the addresses small (25 byte script) which can easily be displayed in a QR code or may even be typed by hand.

The reason transaction 4005d6be is included in so many blocks is all of those blocks are orphaned, so the miners that included them supported a version of P2SH but never got a majority. The fact that this transaction is still unconfirmed is probably due to it being not a true P2SH script.

  • 1
    Oh! Amazing. Another question: How much is P2SH supported today? What all can I write to the encoded script? I found out that miners won't accept any arbitrary script, is the same thing true about the encoded scripts? – Karel Bílek Apr 13 '13 at 15:20
  • 1
    That's a good question. While you can specify a hash of an arbitrary script to be a claiming condition we have to make sure that the script is valid, otherwise you won't be able to spend those coins ever again. – cdecker Apr 13 '13 at 15:40
  • @cdecker could you elaborate on that second paragraph of yours that begins "P2SH has the advantage that..."? Is the client the one sending the bitcoins, or the redeemer? Can you give an example of what type of script they wouldn't have to build, and then also give an example of the script that verifies the first script? – almel Jul 22 '14 at 22:58
  • Let's say the sender has a really old wallet, that does not support multisig addresses. Using P2SH the receiver creates the hash of a script that does multisig, uses it to create a P2SH address and sends it to the sender. The sender now has an address, which is a valid P2SH address, and can send funds to it, even though it does not know anything about multisig addresses. For an example I'd like to point you to the examples in BIP 16. – cdecker Jul 23 '14 at 10:47
  • You said a "client does not necessarily have to know how to build such a script". If I use a beta wallet that uses P2SH addresses, and they make a mistake where the script is miscalculated and can't spend the funds... or is it more foolproof than that and I'm needlessly paranoid? – Brain2000 Jun 10 '17 at 3:01
4

I recall some of these transactions and researched them.

P2SH was introduced as a soft-fork, meaning old nodes technically didn't have to upgrade - the soft fork could be carried out by a hashrate majority of miners.

OP_HASH160 [20 byte hash] OP_EQUAL

This is the P2SH scriptPubKey. Before the soft-fork, it meant that anyone that knew the value that hashed to [20 byte hash] could spend the coins.

A quick note on hashrate-majority enforced soft-forks. These are normally invisible to clients unaware of them. The reason is, these soft-forks usually only forbid certain things from happening, rather than allow something new and unexpected to happen.

P2SH is one of these types, because it added further rules to the above snippet of Bitcoin Script. The rule is, if the value hashes to [20 byte hash], then assume it is a string of bitcoin script and verify it. All this does is prevent some spend attempts from entering the blockchain - they might fail P2SH validation.

From an old version's point of view, if something you allow never happens again, there is no rule violation.

So, why was this block 'mined' 94 times? Well, partially because Blockchain.info uses confusing terminology. They received 94 blocks including this transaction. It's just a pity they were all orphaned!

This is an unfortunate case where the hashrate-majority soft-fork actually caused problems for someone. That someone was in the minority running v0.6, and kept running the older software version (or they forgot to upgrade). Their software a transaction with a valid pre-image for [20 byte hash], and accepted it into the mempool. It then tried to mine it.

The majority, however, had just accepted a rule where such transactions are exposed to additional validation, and deemed this transaction invalid, so they refused to build on top of these blocks.

Regarding P2SH addresses, they are very useful these days. You can request someone to fund a complicated script (like multisig, or a Lightning channel) using a fixed-size address!

  • Is segwit not a hashrate-majority enforced soft-fork? I can't understand how it is only forbidding and not allowing something new. – Janus Troelsen Feb 13 '17 at 14:13
  • Right now you can pay to OP_0 [32 bytes] and miners would put your spend in a block without you providing a signature. (though, we wouldn't softfork that script if someone was using it) With segwit activating, outputs with this script are no longer accepted without scrutiny - the new rules are applied (must provide a VALID witness now), so that only non-rule violations are included in blocks. To old nodes, there is nothing new happening. Just the absence of something it didn't care about. – karimkorun Feb 14 '17 at 16:27
  • Same as P2SH - old nodes who would have accepted spends of OP_HASH160 [HASH] OP_EQUAL before activation would accept any transaction with no signature. Afterwards, they wouldn't realize that all the signatures which would fail P2SH evaluation aren't around anymore. – karimkorun Feb 14 '17 at 16:30
  • Going to be lolz epic when all the SegWit transactions are double-spent, i.e. stolen by miners on The Real Bitcoin (the legacy Satoshi blockchain). – Shelby Moore III Jul 29 '17 at 5:03
  • Please follow our "Be Nice" policy, that's not an appropriate way to address people – MeshCollider Jan 15 '18 at 0:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.