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