I have nothing against incremental development. This will however not pick up until it offers some incremental benefit compared to current payment processor solutions, such as e.g.
1. Symmetrical. One can also offer a payment. 2. Aggregating and Netting. Handle multiple installments and/or net with previous cash flows. 3. More secure. One has a check not only on the payment address (which already has one with https:// in the web shop scenario it is currently able support) but not on the refund. On 28.03.2014, at 15:01, Gavin Andresen <gavinandre...@gmail.com> wrote: > On Fri, Mar 28, 2014 at 9:18 AM, Tamas Blummer <ta...@bitsofproof.com> wrote: > May I ask how the current payment protocol is supposed to handle salaries? > > It doesn't. > > "walk before you run" and all that; lets see what problems we run into with > the minimal payment protocol we have now (like refund outputs you have to > remember forever) before we create an insurmountable set of problems by > trying to solve everything we can think of all at once. > > -- > -- > Gavin Andresen
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
