Published on: 2015-07-27T11:21:38+00:00
In an email exchange, Jorge Timón and Kalle Rosenbaum discuss the topic of increasing the nonce. Kalle asks if they need a bigger nonce, to which Jorge responds that he was not the one who proposed the idea. Instead, he reminds Kalle that the policy limit should not be a concern. The context does not provide any further details or background information on what the nonce is and why it might need to be increased.On July 24, 2015, Kalle Rosenbaum announced via bitcoin-dev that two new Bitcoin Improvement Proposals (BIPs) had been assigned numbers 120 and 121. The announcement prompted celebration, as the BIPs had faced challenges during the proposal process. The email thread did not provide further information on the content of the BIPs or their implications for Bitcoin development.In an email thread discussing the size of the nonce used in Proof of Payment (PoP) as outlined in Bitcoin Improvement Proposal (BIP) 120, it was noted that Bitcoin core now supports 80 bytes of data by default and does not maintain a policy limit. The BIP had assumed a limit of 40 bytes across all implementations. It was suggested that if there is a need to increase the size of the nonce, it could be done in a subsequent version of PoP. However, a longer nonce would result in bigger QR codes generated from the BIP 121 URIs, making 48 bits a good tradeoff for now. It was also mentioned that a server generating PoP requests should try to detect brute force attacks or delay the response containing the nonce by some 100ms. If PoP becomes an extension of BIP70, then there will be no size constraint on the nonce.Two Bitcoin Improvement Proposals (BIPs) have been assigned numbers 120 and 121. BIP 120 is for Proof of Payment, while BIP 121 is for a Proof of Payment URI scheme. Kalle Rosenbaum requested that these proposals be given their BIP numbers after much constructive discussion and feedback. During the discussions, Pieter Wuille raised some concerns about the Proof of Payment proposal, as it assumed that a transaction corresponds to a single payment. He suggested tracking payments instead of assigning identities to payers. However, Kalle believed that assigning a proof of payment was necessary for privacy reasons and proposed a nonce parameter in the URI, which was limited to 48 bits due to an OP_RETURN output limitation of 40 bytes.The context provided is a brief email conversation between Kalle and Pieter. Kalle thanks Pieter for his comments, but the rest of the conversation is not given. The conversation seems to be related to a reusable token that needs to be transferred to a friend. However, no information is provided on what this token is or why it needs to be transferred. It is not clear what the purpose of this conversation is and what the overall topic of discussion is.Kalle Rosenbaum has requested that proposals "Proof of Payment" and "Proof of Payment URI scheme" be assigned BIP numbers after constructive discussions, feedback, and updates. The source for both proposals can be found on GitHub. A limitation of 40 bytes for the OP_RETURN output had been discussed, and while it was suggested that a bigger nonce could be used, Kalle opted to stick with this limit due to simplifying implementation and not needing more data than 40 bytes. The Proof of Payment proposal allows for better privacy for customers who do not have to give out personal information such as an email address. It also creates a window of opportunity for thieves that is minimized since PoP is only usable once and created when needed. Different use cases will require different protection. The cost of using tokens is security, since a stolen token can be used over and over again.The discussion revolves around the Proof of Payment (PoP) feature for Bitcoin. Kalle Rosenbaum, who proposed the feature, discusses its limitations and use cases with Pieter Wuille. Rosenbaum notes that PoP allows for better privacy for customers who don't want to give out personal information such as email addresses. Wuille questions why anyone cares who paid and suggests that tracking payments rather than assigning identities to payers is a better approach. However, Rosenbaum indicates that the identity of the payer is necessary for PoP to work since the wallet used to pay must also be used to issue the PoP. The two discuss methods of sharing PoPs, including forwarding requests or transferring keys to friends' wallets. They also compare PoP to using tokens and note that tokens are reusable, whereas PoP is only usable once, which minimizes the window of opportunity for thieves.The discussion revolves around the limitation of creating a 40-byte OP_RETURN. The limitation comes from a relay policy in full nodes, not a limitation is wallet software. PoPs are not relayed on the network.
Updated on: 2023-08-01T13:06:47.119601+00:00