Why did the transaction was accepted by the network despite not working as intended
The network does not check the validity of output scripts. An output script can contain pretty much any data and the transaction will still be consensus valid. But your transaction is not actually invalid. It's just like a bare multisig now, but since the pubkeys are hashes, ...
Because P2SH addresses are too short to provide typically desirable levels of security security level we expect from Bitcoin, against certain attacks. On top of that, they use bech32 encoding rather than base58, which means they're slightly longer for the same amount of data, but are case insensitive instead.
For any kind of "multi party" address (...
You can find the first on https://txstats.com/dashboard/db/utxo-set-repartition-by-output-type?orgId=1. For a version weighed by value you can look at the graphs of the individual output types on the same site.
Is the addmultisignature API call dependent on order of public keys in the array? Or is it lexicographically sorted?
Yes. It is not sorted according to BIP67 automatically.
How did I confirm?
I used the below command in bitcoin core:
addmultisigaddress 2 "[\"0318370919cfceb3d260081eeca3cae19f941eec321f597c48a64839178ea1e3e0\",\"...
In short, it knows because it knows. Whatever information was used to make the original wallet construct the addresses (whether that consists of a seed, a set of keys, a master key, a descriptor, a mnemonic phrase, ...) must be imported into the new wallet too.
The P2SH redeemscript is not created randomly: there is a procedure to generate it from keys the ...
On that wiki link you posted it states:
If any opcode marked as disabled is present in a script, it must abort and fail.
An attempted UTXO spend with a failed script will not be relayed between nodes running Bitcoin Core (and other major implementations) and certainly won't be included in a mined block.
The mainnet coinbase transaction you link to includes ...
How would people (likely power users) even be aware that these funds were out there, and available to be redeemed if they solved the puzzles.
As you mentioned, it could be that either the creator of the UTXO publicized it, or someone parsing through blockchain data discovered it (and perhaps then publicized it). In the case of the hash collision bounties, ...
The encoding is bech32 not base58, which is slightly longer but vastly easier to type due to a lack of capital letters, and the inclusion of error correction rather than error detection.
SegWit scripts use SHA256 not RIPEMD160 for the hash function, which is longer and stronger.
While I think Pieter's answer provides exactly what you were asking for with the UTXO set repartition by output type, I think that you may also be interested in the Output Types by Count chart on transactionfee.info:
The site has also more related charts that may be interesting in the context such as
Input Types by Count
Output Types by Value
and various ...
Your redeem script has the length of the script prepended to it (2d), which causes the stack execution to finalize with the redeem script in the stack as data instead of interpreting it as another script.
The script interprets the 2d as if you intended to put data in the stack with a length of 45 bytes, instead of actually interpreting your redeem script as ...
P2SH addresses can either be P2SH-P2WPKH addresses (wrapped segwit) or they can be multisig or something else. If your wallet is using P2SH-P2WPKH addresses, the wallet should be able to recognize your address upon initialization. Otherwise, you will probably have to manually import that address.
Regardless, the amount of btc held in that address is on the ...
Private keys are 256-bit numbers. The first "HEX" you list has 64 characters, which corresponds to 256 bit, while the other two have 66 characters. Since all three share the same first 64 characters, I surmise that the library you're using simply drops the additional data beyond the first 256 bit.
Inputs do not reference the value of the UTXO they spend. You need to look up the spent UTXO to find the value. Usually, this information is available to a node via the UTXO set, or can be looked up by inspecting the transaction that created the UTXO.