Published on: 2011-10-31T08:50:49+00:00
During a discussion with Gavin Andresen, the topic of determining if a bitcoin transaction has occurred was brought up. It was suggested that if one's address was involved in a transaction, it would immediately appear in their setup. The idea of moving away from bitcoin addresses as 'pay-to entity' and instead creating a payment infrastructure where people or organizations are paid directly was also mentioned. However, some individuals were not in favor of this suggestion due to the desire to maintain the semi-anonymous nature of bitcoin. Instead, it was proposed that in the short-term, a new type of bitcoin address built on top of OP_EVAL should be created as it would be easily supported by existing infrastructure. However, concerns were raised about the potential proliferation of bitcoin addresses representing specific scripts inside the OP_EVAL and its impact on aesthetics.Gavin Andresen suggested the concept of a "both of two" btc-addresses script transaction using OP_EVAL to buy him and Gregory a shared beer. However, this transaction would not show up in the bitcoin wallet as spendable bitcoins. Even if the wallet displayed transactions involving the keys but not spendable, it would still not be possible to know Gregory's public key XYZ unless Gavin explicitly mentioned it. Therefore, the long-term solution proposed was to move away from bitcoin addresses and create an infrastructure for paying people or organizations. However, in the short term, creating a new type of bitcoin address on top of OP_EVAL would be easy to support with existing infrastructure.The author of the discussion suggests that using op_eval may not be necessary for secure wallet creation and sender payment. They propose either using a burdensome address or incorporating it into the URI scheme, which would only require a click. The author also raises concerns about the connection between hash160s and public keys, as well as ECC private keys and spendable transactions. They question whether maintaining the notion of transactions between addresses is necessary or if exploring the richness of scripting would be more beneficial. Additionally, the author argues against the use of OP_EVAL due to the difficulties in defining a set of data that encompasses all possible transactions, which would require senders to announce their transactions, posing potential issues. Lastly, the author suggests that encoding special addresses could lead to confusion and challenges the aesthetic aspect.Michael Grønager expresses his concerns about mapping cryptographic keys to assets. He argues that there should be a clear boundary between the script and the cryptographic key. However, knowing the script used is crucial for identifying funds, making it impossible for clients to identify funds without the necessary information. Grønager believes that supporting OP_EVAL breaks the logical relationship between uint160s and transactions, which has been clean so far. He also opposes checkmultisig as a standard transaction type, as he believes there is a misunderstanding regarding the connection between hash160s and public keys, as well as ECC private keys and spendable transactions. This misunderstanding could potentially render scripts that don't follow a direct mapping of hash160->pubkey->payee broken, which may compromise tool security.The current setup in Bitcoin, with a one-to-one mapping between public keys and uint160, allows for cryptographic keys to be associated with assets. However, the introduction of OP_EVAL disrupts this mapping. The proposal introduces an additional "public key," and there is no straightforward way to map private keys to public keys to uint160s without knowledge of the script used. While it may still function, it breaks the intrinsic logic of uint160s and transactions that has been clean thus far. Gavin Andresen suggests that making CHECKMULTISIG a standard transaction type would be a solution, and using OP_EVAL is not mandatory. Michael Gronager expresses concerns about extracting transactions from private keys, but Gavin argues that OP_EVAL allows him to provide a short address representing multiple keys combined in various ways. Only the involved parties need to know the details until after the transaction is completed. Implementing OP_EVAL for thin clients should not be significantly more challenging.In an email exchange between Michael Grønager and Gavin Andresen, Grønager emphasizes the importance of being able to extract transactions solely from private keys. Gavin questions the significance of this, stating that if someone is sending bitcoins, they would require the recipient's address or public key. OP_EVAL allows for a short address representing multiple keys combined in different ways. Gregory argues that whether the address is HASH(public key) or HASH(op_eval_script), the issues remain the same. Gavin suggests that Grønager may be concerned about blockexplorer not recognizing that coins sent to HASH(op_eval_script) are actually part of a complex transaction until those coins are spent again. He sees this as a feature rather than a flaw. Gavin also agrees with Alan that using OP_EVAL is not mandatory and proposes making CHECKMULTISIG a standard transaction type.In another email conversation from 2011, Michael Grønager discusses the importance of being able to extract transactions associated with private keys.
Updated on: 2023-08-01T02:36:26.262454+00:00