On Tue, Dec 3, 2013 at 12:44 AM, Mike Hearn wrote:
> PPv1 doesn't have any notion of fee unfortunately. I suppose it could be
> added easily, but we also need to launch the existing feature set.
>
Lets bang out a merchant-pays-fee extension.
How about:
SPEC:
optional uint64 allowfeeta
Current rough timeline proposed for 0.9 was end-of-January, IIRC.
On Mon, Dec 2, 2013 at 9:44 AM, Mike Hearn wrote:
> PPv1 doesn't have any notion of fee unfortunately. I suppose it could be
> added easily, but we also need to launch the existing feature set.
>
> There's code pending review to im
PPv1 doesn't have any notion of fee unfortunately. I suppose it could be
added easily, but we also need to launch the existing feature set.
There's code pending review to implement PPv1 in bitcoinj, unfortunately
it's currently not passing unit tests and the author can't figure out why.
I didn't h
Right, as I said earlier:
"The payment protocol at least would need some notion of fee, or possibly
(better?) the ability for a recipient to specify some inputs as well as
some outputs."
Having thought about it a bit more, I think it's better to just have a fee
field that lets the receiver reques
On Mon, Dec 2, 2013 at 9:33 AM, Mike Hearn wrote:
> "The payment protocol at least would need some notion of fee, or possibly
> (better?) the ability for a recipient to specify some inputs as well as some
> outputs."
BitPay noticed this detail last week. We were noticing that some
transactions
First time posting to this mailing list so feel free to ignore me if
this is a stupid idea.
On Mon, Dec 2, 2013 at 3:49 AM, Mike Hearn wrote:
>
> We need to get away from the notion of senders attaching fees anyway. This is
> the wrong
> way around because it’s the recipient who cares about dou
6 matches
Mail list logo
