Published on: 2012-01-29T08:14:06+00:00
The email thread discusses the potential abuse of plain multi-sig and whether it should be considered standard. However, it is important to differentiate between multi-sig addresses and P2S with multi-sig output scripts in general. The size of unprunable transaction outputs is currently not an issue, but there are arguments against multi-sig outputs. Negotiated escrow arrangements can work either way, but P2SH is still better for these types of transactions for two reasons. Firstly, reasonable anti-spam behavior may make it difficult to create large output scripts. Secondly, P2SH allows for the use of a separate escrow-maker tool, providing uncoupling between clients paying into escrow and support for escrow transactions in that client.Amir Taaki quoted Gavin's argument regarding the controversy surrounding bitcoin addresses longer than 70 characters. Gavin argued that very long addresses are not workable due to difficulties in copying and pasting, scanning, and upgrading website or database code that deals with bitcoin addresses. He suggested that a P2SH scheme might be necessary for 70-byte long addresses. Alan expressed concern over the implementation of BIP 13/16/17 and proposed that multi-sig should be available as a fallback option. However, gmaxwell expressed concerns about the potential abuse of plain multi-sig, suggesting it may not be considered standard. Alan acknowledged that copy and pasting may not be a big deal for him, but recognized that regular users may struggle with copying long strings.In a conversation between Amir Taaki and Gavin Andresen, the possibility of having a 70-byte long address without using a P2SH scheme was questioned. Gavin clarified that P2SH eliminates the need for such long addresses. P2SH reduces output sizes to the minimum without inflating total data size, making it more efficient than P2S. P2S, which involves encoding the full script specification instead of just its hash, results in much longer addresses and has several problems such as vulnerability to invisible substitution and enlarged transactions fees.Amir Taaki discussed the size of compressed pubkeys, noting that each pubkey is 33 bytes. When combined with other elements, such as the address version and checksum, the total size becomes 72 bytes. However, base58 encoding is necessary to obtain an address from these bytes, resulting in a 99 character long address.Gavin expressed concerns over creating very long Bitcoin addresses that exceed 70 characters, highlighting difficulties in copying, pasting, scanning, generating QR codes, and upgrading website or database code. He argued that there is a rough consensus that very-long addresses are not workable. The issue relates to the current P2SH scheme used for multisig transactions, which limits the length of the redeem script. This raises the question of how a 70-byte long address would be possible without using the P2SH scheme. The debate underscores the importance of usability in the adoption and use of cryptocurrencies, as longer addresses may pose challenges for users and developers.
Updated on: 2023-08-01T02:55:20.130286+00:00