<oembed><type>rich</type><version>1.0</version><author_name>npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd</author_name><author_url>https://nostr.ae/npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-06-19&#xA;📝 Original message:On Fri, Jun 19, 2015 at 5:42 PM, Eric Lombrozo &lt;elombrozo at gmail.com&gt; wrote:&#xA;&#xA;&gt; If we want a non-repudiation mechanism in the protocol, we should&#xA;&gt; explicitly define one rather than relying on “prima facie” assumptions.&#xA;&gt; Otherwise, I would recommend not relying on the existence of a signed&#xA;&gt; transaction as proof of intent to pay…&#xA;&gt;&#xA;&#xA;Outputs could be marked as &#34;locked&#34;.  If you are performing a zero&#xA;confirmation spend, then the recipient could insist that you flag the&#xA;output for them as non-reducible.&#xA;&#xA;This reduces privacy since it would be obvious which output was change.  If&#xA;both are locked, then the fee can&#39;t be increased.&#xA;&#xA;This would be information that miners could ignore though.&#xA;&#xA;Creating the right incentives is hard though.  Blocks could be&#xA;&#34;discouraged&#34; if they have a double spend that is known about for a while&#xA;which reduces payment for a locked output.&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/f5cec10d/attachment.html&gt;</html></oembed>