public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: kjj <kjj@jerviss.org>
To: Pieter Wuille <pieter.wuille@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Beyond IP transactions: towards a bitcoin payment protocol
Date: Fri, 23 Sep 2011 12:38:48 -0500	[thread overview]
Message-ID: <4E7CC428.6020500@jerviss.org> (raw)
In-Reply-To: <20110923162102.GA13532@ulyssis.org>

Pieter Wuille wrote:
> Hello everyone,
>
> here is an idea i've bean writing up: https://gist.github.com/1237788
>
> I hope it can start some discussion about moving away from static bitcoin addresses
> as descriptions for transactions. I suppose it's a candidate for a BIP/BEPS/BFC/...,
> but as things don't seem to have been decided completely about those, I put it in a
> Gist.
>
> Please, comment.
>
This may just be me, but this really looks like an incredibly convoluted 
way to solve a bunch of problems that aren't really problems.  The 
central issue that I see, is that you assume that there is no out of 
band channel, as if people were just sending transactions to addresses 
that came to them in a dream.

I think that this assumption is only true when it doesn't matter.  For 
example, I have a donation link in my sig on the forums.  I don't care 
much who sends to it, or why, and I certainly don't need annotations or 
a refund address.  The rest of the time, payments are sent to addresses 
that already have sufficient context.

Only one of the advantages listed is actually an advantage.  That is 
that payments to stale addresses can be stopped.  This isn't much of an 
advantage though, as someone blindly sending payments (donations, 
really) to addresses found on backup tapes and web archives without 
verifying that they are still current kinda deserve what they get.  So 
it really only stops payments to services that go defunct the same day 
(more or less).

In the end, I just don't see the value in giving a URL so that I can go 
ask a server for information that could just as easily have been encoded 
in the URL directly.

Then again, I'm cynical, and didn't sleep very well last night.  Maybe 
the next person will think better of it.



  reply	other threads:[~2011-09-23 17:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-23 16:21 [Bitcoin-development] Beyond IP transactions: towards a bitcoin payment protocol Pieter Wuille
2011-09-23 17:38 ` kjj [this message]
2011-09-23 23:15   ` Pieter Wuille
2011-09-23 23:21     ` Luke-Jr
2011-09-24  3:05       ` Pieter Wuille

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E7CC428.6020500@jerviss.org \
    --to=kjj@jerviss.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=pieter.wuille@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox