Re: [Bitcoin-development] Coin Control, Send crash on MacOS X

[Wladimir]

>
> Did as you suggested, removed both setFocus() calls that happen after Send
>> is clicked
>>
>
> http://pastebin.com/j4adDpsM
> Now it crashes in something else within qt.
>
> I'm trying other things...
>

As I've said to you on IRC before, I think the problem is with this loop:

https://github.com/bitcoin/bitcoin/blob/master/src/qt/sendcoinsdialog.cpp#L261

This deletes widgets, but Qt may still be referring to them internally, and
"Deleting a QObject while pending events are waiting to be delivered can
cause a crash."

Can you try replacing with ->deleteLater()?

Wladimir
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[kjj]

After reading all 99 messages in this thread, I think allowfee is just 
about perfect.


It effectively lets merchants to give an allowance against the purchase 
price for network fees, if they choose.  It is still up to the sender 
(and/or the sender's software) to get the fees right.  Sometimes the 
sender will need to pay more fees than allowed, and sometimes the sender 
will need to pay less.


We can't solve the fee problem, in general.  I'm not sure that we can 
even define it properly.  But this is something that we can do, that 
will be useful at least occasionally, and that will cause no harm the 
rest of the time.


P.S.  Clever senders can use this to defrag their wallets.  Who wants to 
write the patch for that?


Gavin Andresen wrote:
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 allowfeetag number=1000

Allow up to allowfee satoshis to be deducted from the amount paid to 
be used to pay Bitcoin network transaction fees. A wallet 
implementation must not reduce the amount paid for fees more than 
allowfee, and transaction fees must be equal to or greater than the 
amount reduced.


:ENDSPEC

Rationale: we don't want wallet software giving users discounts-- 
sending transactions that are amount-allowfee without paying any fee. 
 We also want to allow users to pay MORE in fees, if they need to 
(fragmented wallet, maybe, or big CoinJoin transaction) or decide to.



PS: I think there was also consensus that the BIP72  request=...   
should be shortened to just r=... (save 6 chars in QR codes).  Unless 
somebody objects, I'll change the BIP and the reference implementation 
code to make it so...


--
--
Gavin Andresen



--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk


___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Suggestion: easy way to restore wallet.dat backup

[Casey Rodarmor]

On Tue, Dec 3, 2013 at 11:59 AM, Dâniel Fraga  wrote:
>
> Today, when a user uses bitcoin-qt client, it can make a backup
> of wallet.dat easily through menu, but when he/she needs to restore
> this backup, he/she must copy the file to the correct folder and
> execute "bitcoin-qt -rescan".
>

I actually think this is part of a larger and somewhat subtle UX problem
with bitcoin-qt – and, to be totally fair, a whole bunch of other wallet
programs.

I think the issue is that bitcoin-qt should have a document-oriented
approach to wallets. It should make you select a location to store your
wallet, just like a word processor, when you create a new wallet. It could
open the most recent wallet when you run the program, or allow you to open
a wallet by double-clicking it directly in the OS.

I think this would solve this particular issue nicely, just double click
the wallet file. Also, the menu item can just be labeled "Open Wallet". It
might also prevent those kind of heartbreaking posts which read something
like, "I just wiped my hard drive and reinstalled bitcoin-qt, where are my
coins?" People don't have the expectation that if they get Word on a new PC
that their documents will somehow magically be available, I think in part
because Word forces you to deal with the documents and the save location
yourself.

I know that this would bring with it a host of other considerations: Can
multiple wallets be open at the same time? What happens if a wallet file is
moved while it's open? What happens when there are two versions of the same
wallet? Will users understand that they need to backup their wallets
periodically?

But, I think it would be a big enough usability win that it should be
considered. Also, if at the same time bitcoin-qt were to adopt BIP 32 style
deterministically derived private keys from a single seed, a bunch of the
issues above would also go away: There are never two versions of the same
wallet, since they're the same seed, and periodic backups are unnecessary.
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[Jeremy Spilman]

allowfee:

> Allow up to allowfee satoshis to be deducted from the amount paid to be  
> used to pay Bitcoin network transaction fees. A wallet >implementation  
> must not reduce the amount paid for fees more than allowfee, and  
> transaction fees must be equal to or greater than the >amount reduced.

minfee:

> Pay at least minfee satoshis in transaction fees. Wallet software should  
> add minfee to the amount the user authorizes and pays, and >include at  
> least minfee in the transaction created to pay miner's transaction fees.  
> Wallet software may request that the user pays more, if >it must create  
> a complex transaction or judges that minfee is not sufficient for the  
> transaction to be accepted by the network..
>

Thanks for the draft specs Gavin. Very clear and precise.

Personally I think 'allowfee' is more useful than 'minfee'. The 'allowfee'  
tells me something very useful and definitive about what the merchant will  
let me do when making payment, and if the merchant chooses 'allowfee'  
intelligently, they can provide real value to their customers without  
exposing them to undue risk.

A 'minfee' field on the other hand, is just a data point for the wallet  
software to consider, and likely to be noisy enough that wallets will tend  
to ignore it. (e.g. like Drak's example of Gox's 0.001 fee)

The sender's wallet software will always be free to choose the fee, and  
paying less than the 'allowfee' or 'minfee' can still get a TX included in  
the next block.

I think of the PaymentRequest is a part of the purchase contract. If a  
payer transmits a transaction before 'expires' but with less than  
'minfee', which gets included in the next block, have they  failed to meet  
the terms of payment?

If there is some time criticality, for example to reduce exchange rate  
risk, then a wallet might need to choose a higher fee to ensure the  
transaction clears in time. Instead of 'minfee' I'm thinking it would be  
more appropriate to communicate this using the existing 'expires' field --  
in other words, let the merchant express what their requirement is, not  
tell the wallet how to achieve it.

In the case of a transaction with too-low fee, either the payer can  
double-spend with a higher fee, or wait longer for the transaction to make  
it into a block. If it hits the blockchain before the 'expires' time, then  
the merchant should have no standing to refute it, regardless of the  
amount of fees paid.

A refund comes into play if a payer reduced the total amount in excess of  
an agreed upon 'allowfee', or if the transaction doesn't hit the  
blockchain until after 'expires'. It should be clear in these cases that  
payer would end up eating the fees in both directions. But then, what if a  
wallet pays the 'minfee' and broadcasts 1 block before 'expires' but the  
payment DOESN'T make the block? Is the merchant liable for too-slow  
transactions due to their own insufficient 'minfee' value?

So I see 'allowfee' as extremely useful, but 'minfee' as somewhat  
problematic.

Thanks,
Jeremy


--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Coin Control, Send crash on MacOS X

[Warren Togami Jr.]

On Sun, Dec 1, 2013 at 1:19 AM, Wladimir  wrote:

> On Sun, Dec 1, 2013 at 12:05 PM, Warren Togami Jr. wrote:
>
>> https://github.com/litecoin-project/bitcoinomg/commits/0.8.5-OMG6
>> http://download1.rpmfusion.org/~warren/bitcoin-0.8.5-OMG6/
>> I've been backporting patches from master and Litecoin to make a Bitcoin
>> 0.8 client with more features.  It works quite well on Linux and Win32.
>>
>> http://pastebin.com/g8QqheGc
>> Today we discovered a rare crash that can happen on MacOS X. toffoo and
>> coblee reproduced it on MacOS X 10.9 and I reproduced it on 10.6.8. It
>> seems to be some kind of race condition involving SendCoinsEntry::clear().
>>
>>
>>1. 11  QtGui   0x00e28141
>>QWidget::setFocus(Qt::FocusReason) + 289
>>2. 12  org.bitcoinfoundation.Bitcoin-Qt0x002ca665
>>SendCoinsEntry::clear() + 101
>>
>>
> I don't think the setFocus should be in clear() in the first place. It
> conflates clearing the widgets and changing the focus.
>
> If the automatic focus change is desirable at all it could be moved to a
> seperate function "focusPayTo".
>
> In any case it's just a nicety and should just be removed if it causes
> problems.
>
> Wladimir
>
>
Did as you suggested, removed both setFocus() calls that happen after Send
is clicked

http://pastebin.com/j4adDpsM
Now it crashes in something else within qt.

I'm trying other things...

Warren
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] ABIS protocol introduction

[Odinn Cyberguerrilla]

Hello,

This concept, 'ABIS protocol,' has been many years in the making and is
presented here as a basic concept.  It is sent to you for you review and
possible consideration.  There will be further additions in the near
future.  Looking forward to your reply and any contributions you may
provide.

Cheers

https://github.com/ABISprotocol/ABIS#abis



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Suggestion: easy way to restore wallet.dat backup

[Dâniel Fraga]

I posted this on bitcoin-user, but nobody replied, so I'm
trying here.

Today, when a user uses bitcoin-qt client, it can make a backup
of wallet.dat easily through menu, but when he/she needs to restore
this backup, he/she must copy the file to the correct folder and
execute "bitcoin-qt -rescan".

My suggestion: bitcoin-qt developers could implement an easier
way to restore. For example: a option in the File menu "Restore Wallet"
or "Recover Wallet" where it would show a dialog asking for the backup
file and everything would be done automatically (no need to do it
manually).

If we want everybody to use bitcoin, these operations should
be as easy as possible.

What do you think?

-- 
Linux 3.12.0: One Giant Leap for Frogkind
http://www.youtube.com/DanielFragaBR
http://mcxnow.com
Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[Quinn Harris]

The merchant wants to include a fee to ensure the transaction is 
confirmed which is dependent on the fee per kilobyte, but they don't 
want to pay unexpectedly high fees. So what about including a 
min_fee_per_kilobyte and a max_fee in PaymentDetails describing what 
fees the merchant will pay.  The sender would be expected to respect the 
min_fee_per_kilobyte but if the result exceeds max_fee the sender would 
be agreeing to pay the extra fee (exterior fees).  The sender might also 
agree to pay fees in excess of min_fee_per_kilobyte.


The sender would deduct the interior or merchant fees from the first output.

The UI could show the payment "price" which would match the sum of 
original outputs.  It would show the merchant fees (interior) and sender 
fees (exterior) if there are any.  The UI should always show fees so 
users learn to expect them for all transactions.


This should allow the merchant to pay fees in most cases while not 
having to pay excessive fees if the sender wants to use some large 
transaction.  If max_fee is 0 the sender would be expected to pay all fees.


On 12/03/2013 10:20 AM, Mike Hearn wrote:
On Tue, Dec 3, 2013 at 12:57 PM, Taylor Gerring 
mailto:taylor.gerr...@gmail.com>> wrote:


Why should there be two classes of transactions? Where does paying
a local business at a farmer's stand lie in that realm?
Transactions should work the same regardless of who is on the
receiving end.


Lots and lots of people are psychologically trained to expect that 
they pay the sticker price for things. Yes in recent times some places 
have started to show additional fees for using credit cards, but only 
as a way to try and push people onto cheaper forms of payment, not 
because customers love surcharges. It's for that reason that many 
merchants don't do this, even when they could - I pay for things with 
Maestro Debit all the time and I don't think I've ever seen a 
surcharge. That system obviously has costs, but they're included.


This is just a basic cultural thing - when I buy something from a 
shop, the social expectation is that the seller should be grateful for 
receiving my money. "The customer is always right". When I send money 
to a friend, the social expectation is different. If my friend said, 
hey Mike, could you send me that 10 bucks you owe me from last weekend 
and what he receives is less than 10 bucks, he would probably feel 
annoyed - if I owe him 10 bucks then I owe him 10 bucks and it's my 
job the cover the fees. That's why PayPal makes sender pay fees in 
that case.


Maybe we need new terminology for this. /Interior fees/ for included 
in the price/receiver pays and /exterior fees/ for excluded from the 
price/sender pays?


Fees are only confusing because existing clients do a terrible job
of presenting the information to the user. In Hive Wallet, I'm of
the opinion that we should inform the user in an intuitive way to
let them make an informed decision.


Have you thought through the UI for that in detail? How exactly are 
you going to explain the fee structure? Let the user pick the number 
of blocks they need to wait for? What's a block? Why should I care? 
Why shouldn't I just set the slider all the way to the other end and 
pay no fees at all? Is the merchant going to refuse to take my 
payment? Gavin just said that's not possible with Bitcoin-Qt. I'm 
thinking for bitcoinj I might go in a slightly different direction and 
not broadcast payments submitted via the payment protocol (and 
definitely not have one wire tx pay multiple payment requests 
simultaneously, at least not for consumer wallets).





--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk


___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[Mike Hearn]

Heh. People feel rises in sales tax elsewhere too. When VAT rises merchants
all raise their prices, they don't normally swallow it (or if they do, they
make a big fuss over how awesome they are).

The US system is a complete pain in the ass. You never know how much money
you actually need to pay for anything unless you happen to know the local
rate and do the multiplication in your head. There's a reason this system
is not used in big chunks of the world economy.


> Expose information in a digestible way. Just because you don’t
> instinctively know how to implement a UI for varying sender fees doesn’t
> mean that other wallets don’t.
>

I would love to know how to do it. If you have an intuitive GUI in mind
please show us so other wallet authors can copy it :)
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[Taylor Gerring]

On Dec 3, 2013, at 2:20 PM, Mike Hearn  wrote:

> On Tue, Dec 3, 2013 at 12:57 PM, Taylor Gerring  
> wrote:
> Why should there be two classes of transactions? Where does paying a local 
> business at a farmer’s stand lie in that realm? Transactions should work the 
> same regardless of who is on the receiving end.
> 
> Lots and lots of people are psychologically trained to expect that they pay 
> the sticker price for things. Yes in recent times some places have started to 
> show additional fees for using credit cards, but only as a way to try and 
> push people onto cheaper forms of payment, not because customers love 
> surcharges. It's for that reason that many merchants don't do this, even when 
> they could - I pay for things with Maestro Debit all the time and I don't 
> think I've ever seen a surcharge. That system obviously has costs, but 
> they're included.
> 
> This is just a basic cultural thing - when I buy something from a shop, the 
> social expectation is that the seller should be grateful for receiving my 
> money. "The customer is always right". When I send money to a friend, the 
> social expectation is different. If my friend said, hey Mike, could you send 
> me that 10 bucks you owe me from last weekend and what he receives is less 
> than 10 bucks, he would probably feel annoyed - if I owe him 10 bucks then I 
> owe him 10 bucks and it's my job the cover the fees. That's why PayPal makes 
> sender pay fees in that case.
> 
> Maybe we need new terminology for this. Interior fees for included in the 
> price/receiver pays and exterior fees for excluded from the price/sender pays?
> 
> Fees are only confusing because existing clients do a terrible job of 
> presenting the information to the user. In Hive Wallet, I’m of the opinion 
> that we should inform the user in an intuitive way to let them make an 
> informed decision.
> 
> Have you thought through the UI for that in detail? How exactly are you going 
> to explain the fee structure? Let the user pick the number of blocks they 
> need to wait for? What's a block? Why should I care? Why shouldn't I just set 
> the slider all the way to the other end and pay no fees at all? Is the 
> merchant going to refuse to take my payment? Gavin just said that's not 
> possible with Bitcoin-Qt. I'm thinking for bitcoinj I might go in a slightly 
> different direction and not broadcast payments submitted via the payment 
> protocol (and definitely not have one wire tx pay multiple payment requests 
> simultaneously, at least not for consumer wallets).
> 
> 

Most of what you mentioned is entirely culture-dependant. In the majority of 
North America, sales tax is calculated at the point of sale on top of the 
advertised price. When my local government increases sales taxes, we feel it 
BECAUSE we see it. Expose information in a digestible way. Just because you 
don’t instinctively know how to implement a UI for varying sender fees doesn’t 
mean that other wallets don’t.

Leave the fee structure alone. Instead, let’s concentrate on how to calculate 
an accurate assessment of what a reasonable fee is for reliable service and let 
the software shake out the rest.

Taylor

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[Jamie McNaught]

Hi all, first post so go easy on me!

Background/Intro: I'm a C/C++ software engineer with a keen interest in
Bitcoin working for everyone. I've spent the last couple of months pitching
Bitcoin to merchants & end users (previously I mined),

While I agree as Peter said, transparency with fees is good and leaving it
to the wallet designer to decide to either show / hide these (as Gavin
suggested) there is no denying that users hate fees/charges. That's why in
the UK so many online retailers offer free delivery (again perceived as a
zero value add charge). Infact, if you ask the average consumer, they only
have a mild inkling that there are fees paid by the merchants for using
credit cards.

So I'd agree with Gavin's proposed spec in an optional uint64 minfee which
senders(wallets) should deduct from the total paid to the receiver. If
however the sender is doing a dust collection txn (surely hugely unusual
for legit users?) then the sender should pay the additional costs. Does
that make "minfee" actually "minfeeperkb"? Perhaps, but wallets should aim
to not display such implementation details.

As a newb though, I have to ask, how does the receiver/requester/merchant
enforce these fee requests are respected?




On 3 December 2013 12:07, Peter Todd  wrote:

> On Tue, Dec 03, 2013 at 12:57:23PM +0100, Taylor Gerring wrote:
> >
> > On Dec 3, 2013, at 12:29 PM, Mike Hearn  wrote:
> >
> > > It may be acceptable that receivers don't always receive exactly what
> they requested, at least for person-to-business transactions.  For
> person-to-person transactions of course any fee at all is confusing because
> you intuitively expect that if you send 1 mBTC, then 1 mBTC will arrive the
> other end. I wonder if we'll end up in a world where buying things from
> shops involves paying fees, and (more occasional?) person-to-person
> transactions tend to be free and people just understand that the money
> isn't going to be spendable for a while.
> >
> >
> > > person-to-business transactions.  For person-to-person transactions
> > Why should there be two classes of transactions? Where does paying a
> local business at a farmer’s stand lie in that realm? Transactions should
> work the same regardless of who is on the receiving end.
> >
> > > any fee at all is confusing because you intuitively expect that if you
> send 1 mBTC, then 1 mBTC will arrive the other end
> > The paradigm of sending money has an explicit cost is not new... I think
> people are used to Western Union/PayPal and associated fees, no?  It’s okay
> to have a fee if it’s reasonable, so let’s inform the user what the
> estimated cost is to send a transaction in a reasonable amount of time.
>
> Indeed.
>
> Transparency on fees is going to be good from a marketing point of view
> as well: fact is, Bitcoin transations have fees involved, and if we're
> up-front and honest about those fees and what they are and why, we
> demystify the system and give people the confidence to tell others about
> the cost-advantages of Bitcoin, and at the same time, combat fud about
> fees with accurate and honest information.
>
> --
> 'peter'[:-1]@petertodd.org
> 000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3
>
>
> --
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[Mike Hearn]

On Tue, Dec 3, 2013 at 12:57 PM, Taylor Gerring wrote:

> Why should there be two classes of transactions? Where does paying a local
> business at a farmer’s stand lie in that realm? Transactions should work
> the same regardless of who is on the receiving end.
>

Lots and lots of people are psychologically trained to expect that they pay
the sticker price for things. Yes in recent times some places have started
to show additional fees for using credit cards, but only as a way to try
and push people onto cheaper forms of payment, not because customers love
surcharges. It's for that reason that many merchants don't do this, even
when they could - I pay for things with Maestro Debit all the time and I
don't think I've ever seen a surcharge. That system obviously has costs,
but they're included.

This is just a basic cultural thing - when I buy something from a shop, the
social expectation is that the seller should be grateful for receiving my
money. "The customer is always right". When I send money to a friend, the
social expectation is different. If my friend said, hey Mike, could you
send me that 10 bucks you owe me from last weekend and what he receives is
less than 10 bucks, he would probably feel annoyed - if I owe him 10 bucks
then I owe him 10 bucks and it's my job the cover the fees. That's why
PayPal makes sender pay fees in that case.

Maybe we need new terminology for this. *Interior fees* for included in the
price/receiver pays and *exterior fees* for excluded from the price/sender
pays?

Fees are only confusing because existing clients do a terrible job of
> presenting the information to the user. In Hive Wallet, I’m of the opinion
> that we should inform the user in an intuitive way to let them make an
> informed decision.
>

Have you thought through the UI for that in detail? How exactly are you
going to explain the fee structure? Let the user pick the number of blocks
they need to wait for? What's a block? Why should I care? Why shouldn't I
just set the slider all the way to the other end and pay no fees at all? Is
the merchant going to refuse to take my payment? Gavin just said that's not
possible with Bitcoin-Qt. I'm thinking for bitcoinj I might go in a
slightly different direction and not broadcast payments submitted via the
payment protocol (and definitely not have one wire tx pay multiple payment
requests simultaneously, at least not for consumer wallets).
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[Peter Todd]

On Tue, Dec 03, 2013 at 12:57:23PM +0100, Taylor Gerring wrote:
> 
> On Dec 3, 2013, at 12:29 PM, Mike Hearn  wrote:
> 
> > It may be acceptable that receivers don't always receive exactly what they 
> > requested, at least for person-to-business transactions.  For 
> > person-to-person transactions of course any fee at all is confusing because 
> > you intuitively expect that if you send 1 mBTC, then 1 mBTC will arrive the 
> > other end. I wonder if we'll end up in a world where buying things from 
> > shops involves paying fees, and (more occasional?) person-to-person 
> > transactions tend to be free and people just understand that the money 
> > isn't going to be spendable for a while.
> 
> 
> > person-to-business transactions.  For person-to-person transactions
> Why should there be two classes of transactions? Where does paying a local 
> business at a farmer’s stand lie in that realm? Transactions should work the 
> same regardless of who is on the receiving end.
> 
> > any fee at all is confusing because you intuitively expect that if you send 
> > 1 mBTC, then 1 mBTC will arrive the other end
> The paradigm of sending money has an explicit cost is not new... I think 
> people are used to Western Union/PayPal and associated fees, no?  It’s okay 
> to have a fee if it’s reasonable, so let’s inform the user what the estimated 
> cost is to send a transaction in a reasonable amount of time.

Indeed.

Transparency on fees is going to be good from a marketing point of view
as well: fact is, Bitcoin transations have fees involved, and if we're
up-front and honest about those fees and what they are and why, we
demystify the system and give people the confidence to tell others about
the cost-advantages of Bitcoin, and at the same time, combat fud about
fees with accurate and honest information.

-- 
'peter'[:-1]@petertodd.org
000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3


signature.asc
Description: Digital signature
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[Drak]

On 3 December 2013 11:46, Mike Hearn  wrote:

> On Tue, Dec 3, 2013 at 12:41 PM, Gavin Andresen 
> wrote:
>>
>> If users want to pay with a huge transaction then it seems to me the user
>> should cover that cost. Allowing users to pay merchants with 100K
>> transactions full of dust and expecting them to eat the cost seems like a
>> great way to enable bleed-the-merchant-dry attacks.
>>
>
> A merchant can always refuse the payment and refund it if that's a
> practical problem. I doubt it would be though. If a user is trying to buy
> something from the merchant, they will want it to work, and it'll be up to
> the developers of the wallet they're using to ensure it never does anything
> obnoxious or unacceptable that would result in people hating to receive
> money from that app.
>

Refunds in this circumstance would be problematic because someone is going
to lose because they have to pay the fee. If the sender's money is refunded
minus the fee, they will be unhappy. And the merchant will be unhappy about
having had an unacceptable transaction they have to send back, and eat a
fee for the privilege.

This kind of situation needs to be avoided at all costs.
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[Taylor Gerring]

On Dec 3, 2013, at 12:29 PM, Mike Hearn  wrote:

> It may be acceptable that receivers don't always receive exactly what they 
> requested, at least for person-to-business transactions.  For 
> person-to-person transactions of course any fee at all is confusing because 
> you intuitively expect that if you send 1 mBTC, then 1 mBTC will arrive the 
> other end. I wonder if we'll end up in a world where buying things from shops 
> involves paying fees, and (more occasional?) person-to-person transactions 
> tend to be free and people just understand that the money isn't going to be 
> spendable for a while.


> person-to-business transactions.  For person-to-person transactions
Why should there be two classes of transactions? Where does paying a local 
business at a farmer’s stand lie in that realm? Transactions should work the 
same regardless of who is on the receiving end.

> any fee at all is confusing because you intuitively expect that if you send 1 
> mBTC, then 1 mBTC will arrive the other end
The paradigm of sending money has an explicit cost is not new... I think people 
are used to Western Union/PayPal and associated fees, no?  It’s okay to have a 
fee if it’s reasonable, so let’s inform the user what the estimated cost is to 
send a transaction in a reasonable amount of time.

>  wonder if we'll end up in a world where buying things from shops involves 
> paying fees
I stayed in a hotel for the first night here here in Milan, and there was an 
(anticipated) surcharge for the use of credit over cash. Again, nothing new 
here.


Fees are only confusing because existing clients do a terrible job of 
presenting the information to the user. In Hive Wallet, I’m of the opinion that 
we should inform the user in an intuitive way to let them make an informed 
decision.--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[Gavin Andresen]

>
> A merchant can always refuse the payment and refund it if that's a
> practical problem.
>

No, they can't, at least not in bitcoin-qt:  when the user pokes the SEND
button, the transaction is broadcast on the network, and then the merchant
is also told with the Payment/PaymentACK round-trip.

Allowing merchants to cancel (e.g. having a PaymentNACK) makes
implementation harder, and brings up nasty issues if we want to allow
CoinJoin or CoinJoin-like transactions as payments to merchants.
 Bitcoin-Qt ALREADY allows you to pay several PaymentRequests with one
transaction; handling the case where one merchant gives you a PaymentACK
and another gives you (or wants to give you) a PaymentNACK is a nightmare.

--
Gavin Andresen
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[Mike Hearn]

On Tue, Dec 3, 2013 at 12:41 PM, Gavin Andresen wrote:
>
> If users want to pay with a huge transaction then it seems to me the user
> should cover that cost. Allowing users to pay merchants with 100K
> transactions full of dust and expecting them to eat the cost seems like a
> great way to enable bleed-the-merchant-dry attacks.
>

A merchant can always refuse the payment and refund it if that's a
practical problem. I doubt it would be though. If a user is trying to buy
something from the merchant, they will want it to work, and it'll be up to
the developers of the wallet they're using to ensure it never does anything
obnoxious or unacceptable that would result in people hating to receive
money from that app.


> RE: hiding or showing fees:  I pointed out to Peter that there doesn't
> have to be One True Answer.  Let wallets experiment with either hiding or
> exposing fees, and may the best user experience win.
>

Sure. I think there will be experimentation in this regard.
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[Gavin Andresen]

>
> Wouldn't the idea be that the user always sees 10mBTC no matter what, but
> the receiver may receive less if the user decides to pay with a huge
> transaction?
>

If users want to pay with a huge transaction then it seems to me the user
should cover that cost. Allowing users to pay merchants with 100K
transactions full of dust and expecting them to eat the cost seems like a
great way to enable bleed-the-merchant-dry attacks.


RE: hiding or showing fees:  I pointed out to Peter that there doesn't have
to be One True Answer.  Let wallets experiment with either hiding or
exposing fees, and may the best user experience win.

-- 
--
Gavin Andresen
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[Peter Todd]

On Tue, Dec 03, 2013 at 12:29:03PM +0100, Mike Hearn wrote:
> On Tue, Dec 3, 2013 at 12:07 PM, Gavin Andresen 
> wrote:
> 
> > Making it fee-per-kilobyte is a bad idea, in my opinion; users don't care
> > how many kilobytes their transactions are, and they will just be confused
> > if they're paying for a 10mBTC burger and are asked to pay 10.00011 or
> > 9.9994 because the merchant has no idea how many kilobytes the paying
> > transaction will be.
> >
> 
> Wouldn't the idea be that the user always sees 10mBTC no matter what, but
> the receiver may receive less if the user decides to pay with a huge
> transaction?
> 
> It may be acceptable that receivers don't always receive exactly what they
> requested, at least for person-to-business transactions.  For
> person-to-person transactions of course any fee at all is confusing because
> you intuitively expect that if you send 1 mBTC, then 1 mBTC will arrive the
> other end. I wonder if we'll end up in a world where buying things from
> shops involves paying fees, and (more occasional?) person-to-person
> transactions tend to be free and people just understand that the money
> isn't going to be spendable for a while. Or alternatively that wallets let
> you override the safeguards on spending unconfirmed coins when the user is
> sure that they trust the sender.

Person-to-person payments are an *excellent* argument for keeping fees
visible to end-users; people will pay other people commonly in Bitcoin
and they will be very confused if those transactions act weirdly
differently than payments to merchants.


NAK on unconfirmed overrides - if something goes wrong even by accident
it just makes fixing the problem much harder and less intuitive.

-- 
'peter'[:-1]@petertodd.org
000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3


signature.asc
Description: Digital signature
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[Peter Todd]

On Tue, Dec 03, 2013 at 11:09:51AM +, Drak wrote:
> On 3 December 2013 11:03, Peter Todd  wrote:
> 
> > UI once both are implemented is to not show anything in the default
> > case, and explain to the user why they have to pay extra in the unusual
> > case where they are spending a whole bunch of dust.
> 
> 
> Yes, that's the other problem with a merchant setting a fee - they have no
> idea how large the transaction might be. If you spend a bunch of dust the
> fee could be 2 or 3x the expected fee. Then you might get merchants
> including higher fees by default to account for this. That means we end up
> paying more per kb over time.

Right, which is solved by requiring a fee-per-kb, and only allowing up
to a certain amount to be deducted from the amount paid to pay that
total fee.


But really, we're better off leaving fees visible to the user in the
first place: they're how Bitcoin works and it's not going to change.
(was just talking to Taylor from Hive Wallet about that in person
actually)

-- 
'peter'[:-1]@petertodd.org
000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3


signature.asc
Description: Digital signature
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[Peter Todd]

On Sun, Dec 01, 2013 at 12:51:46PM +0100, Mike Hearn wrote:
> 4) Finally, when we next hard fork, we make v2 transactions include the
> output value in the signature, same as the output script (this proposal has
> been on the forums for a while now). That allows the fee data added in step
> 2 to be cross-checked against the signatures on the inputs, thus
> authenticating it.

FTFY s/hard-fork/soft-fork/

The proposals on the forums with regard to a soft-fork are for a new
transaction format - to be done in parallel with the old one - that
commits to transaction inputs and outputs via a merkle tree extending
into the transaction. This data is then committed to via the merge-mine
standard.


In addition, all this discussion about trying to figure out transaction
fees based on transaction is a bit irrelevant if you suppose a
soft-fork. We already know that we need a merkle-sum-tree of fees and
transaction size to be able to audit miners and create compact fraud
proofs, and using that merkle-sum-tree you can easily calculate sum
fees/sum size for the whole block to determine fees.

We know that we can make a good assumption that transactions in
blocks will have been broadcast prior by the assumption you and Gavin
are making that miners would by far prefer to mine transactions that
have already been broadcast so that block propagation via txid lists
works. That advantage is on the order of 10x to 100x (or even higher)
lower cost per KB to the miner. (if this is not true, let us all know,
because then your scalability arguments are bunk with regard to
blocksize)

In addition faking fees via non-disclosed high-fee transactions has a
cost of about 1% due to the risk your block gets orphaned and the tx fee
gets mined by another miner.


Between those two the merkle-sum-trees for fees and size can be used for
various levels of average fee for a whole block, plus statistical
distributions.


Next it is also desirable for another, related, soft-fork to include a
sorted list of txids and/or H(scriptPubKey)'s in a block. (the latter is
explicitly part of my TXO commitments proposal) With the txids version
especially it's easy and low-bandwidth for SPV nodes to get proof that a
given transaction has been mined recently, by asking for proof of
inclusion or exclusion to accompany a bloom filter match.


Finally with various anti-sybil techniques that create long-term
identities it's easy to show that a peer lied about the data required
for fee estimates anyway.

> One obvious concern is what to do if nodes don't converge on very similar
> estimates. Wallets will always want to pay the lowest fee possible, so that
> means they'll always be riding the very edge of what's acceptable, opening
> up tx propagation to random flaky failures if fee estimates change whilst a
> transaction is in progress, or if some nodes don't calculate the same
> estimates as others.

Propagation failures are not a major problem if transactions can be
rebroadcast with new, higher, fees; propagation failures can be detected
easily and quickly with my proof-of-tx-mining proposal.

-- 
'peter'[:-1]@petertodd.org
000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3


signature.asc
Description: Digital signature
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[Mike Hearn]

On Tue, Dec 3, 2013 at 12:07 PM, Gavin Andresen wrote:

> Making it fee-per-kilobyte is a bad idea, in my opinion; users don't care
> how many kilobytes their transactions are, and they will just be confused
> if they're paying for a 10mBTC burger and are asked to pay 10.00011 or
> 9.9994 because the merchant has no idea how many kilobytes the paying
> transaction will be.
>

Wouldn't the idea be that the user always sees 10mBTC no matter what, but
the receiver may receive less if the user decides to pay with a huge
transaction?

It may be acceptable that receivers don't always receive exactly what they
requested, at least for person-to-business transactions.  For
person-to-person transactions of course any fee at all is confusing because
you intuitively expect that if you send 1 mBTC, then 1 mBTC will arrive the
other end. I wonder if we'll end up in a world where buying things from
shops involves paying fees, and (more occasional?) person-to-person
transactions tend to be free and people just understand that the money
isn't going to be spendable for a while. Or alternatively that wallets let
you override the safeguards on spending unconfirmed coins when the user is
sure that they trust the sender.
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[Drak]

On 3 December 2013 11:03, Peter Todd  wrote:

> UI once both are implemented is to not show anything in the default
> case, and explain to the user why they have to pay extra in the unusual
> case where they are spending a whole bunch of dust.


Yes, that's the other problem with a merchant setting a fee - they have no
idea how large the transaction might be. If you spend a bunch of dust the
fee could be 2 or 3x the expected fee. Then you might get merchants
including higher fees by default to account for this. That means we end up
paying more per kb over time.
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[Gavin Andresen]

Ok, revised spec:

SPEC:

message PaymentDeatils {
...
optional uint64 minfeetag number=8

Pay at least minfee satoshis in transaction fees. Wallet software should
add minfee to the amount the user authorizes and pays, and include at least
minfee in the transaction created to pay miner's transaction fees. Wallet
software may request that the user pays more, if it must create a complex
transaction or judges that minfee is not sufficient for the transaction to
be accepted by the network..

:ENDSPEC

Making it fee-per-kilobyte is a bad idea, in my opinion; users don't care
how many kilobytes their transactions are, and they will just be confused
if they're paying for a 10mBTC burger and are asked to pay 10.00011 or
9.9994 because the merchant has no idea how many kilobytes the paying
transaction will be.

-- 
--
Gavin Andresen
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[Drak]

On 3 December 2013 10:45, Mike Hearn  wrote:

> On Tue, Dec 3, 2013 at 11:36 AM, Drak  wrote:
>
>> I dont like the idea of putting the min fee in the hands of the receiver.
>> Seems like that will work against the best interests of senders in the long
>> run.
>>
>
> Senders have no interest in ever attaching any kind of fee, which is one
> reason we explored child-pays-for-parent for a while. It's not the sender
> who cares about double spending risk. Left to their own devices, all
> senders would always attach no fee at all (or rather: whatever the min was
> to get the transaction relayed to the merchant).
>

I respectfully disagree. Senders need their funds to be received. The
incentive is right there. Miners want mining fees. So if you want to pay
for something, you need to make sure payment arrives. Senders know that if
they exclude the fee it might not arrive at all. Miners increasingly ignore
no or low fees. So those two agents together ensure there is a fee more
than not. If what you said was true, we would hardly see fees being paid at
all, but on the contrary we see lots of fees, and much higher than the
minimum 0.0001/kb rate that is currently required.

Merchants will just include ridiculous fees - there are some exchanges that
do it already - MtGox being the famous example requires a 0.001 fee 10x
higher than the network rate - the CEO does it because he says "it's
better". That's not a fee going to MtGox, that is the miner fee and they
have no plans to reduce it.

Typically vendor software may not get updated and or lag behind with fat
fees never decreasing or decreasing way too slowly - it's just not fluid or
dynamic enough when it rests with the vendor.

However, receivers do want a fee attached,
>

No - receivers want to be paid. If they are not paid they wont dispatch the
goods or service. Neither party is happy in that circumstance. The
incentive that the payment confirms is there naturally.


> That's what fee estimation does, essentially, minus the encoding into
> blocks. Once you start getting miners telling people what fees are directly
> you run into cases where they might try to lie about their behaviour or
> otherwise influence the average. Querying all nodes avoids that problem.
>

Miners cant lie about fees accepted because that's part of the transaction.
When Alice sends funds to Bob it includes the fee information and that is
included in the block. There is no way to fake it. The average fee paid is
provable - so there is no need to query nodes at all, you simply look at
the blockchain. You dont even need to write it into the blockchain since it
can be calculated from the blockchain, it would just make it simpler.

Drak
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[Peter Todd]

On Tue, Dec 03, 2013 at 11:40:35AM +1000, Gavin Andresen wrote:
> 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 allowfeetag number=1000
> 
> Allow up to allowfee satoshis to be deducted from the amount paid to be
> used to pay Bitcoin network transaction fees. A wallet implementation must
> not reduce the amount paid for fees more than allowfee, and transaction
> fees must be equal to or greater than the amount reduced.

Fees are per byte of tx data; call it allowfeeperkb, and given that fees
are required - the merchant would really rather not waste up to about
twice as much on fees for a child-pays-for-parent - it should be called
requirefeeperkb.

Back to your point, the merchant wants to limit total fees that have
been deducted - 'allowfee' is still a good idea - but only in
conjunction with specifying fee-per-kb requirements.

UI once both are implemented is to not show anything in the default
case, and explain to the user why they have to pay extra in the unusual
case where they are spending a whole bunch of dust.

-- 
'peter'[:-1]@petertodd.org
000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3


signature.asc
Description: Digital signature
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[Mike Hearn]

On Tue, Dec 3, 2013 at 11:36 AM, Drak  wrote:

> I dont like the idea of putting the min fee in the hands of the receiver.
> Seems like that will work against the best interests of senders in the long
> run.
>

Senders have no interest in ever attaching any kind of fee, which is one
reason we explored child-pays-for-parent for a while. It's not the sender
who cares about double spending risk. Left to their own devices, all
senders would always attach no fee at all (or rather: whatever the min was
to get the transaction relayed to the merchant).

However, receivers do want a fee attached, and ideally we would do this
without redundant transactions. Hence, receivers asking senders to attach a
fee and effectively folding it into the price that is paid. That is, if you
go into a restaurant and the menu says "Burger: 10mBTC" then when you come
to pay, what you see on your phone screen is 10mBTC. The fact that actually
the shop with receiver 9.9mBTC and the tx fee is 0.1mBTC is hidden in the
user interface - creating a situation like many others, where receivers eat
a transaction cost. For instance in Europe sales taxes are included in the
price, not attached separately later.

There's no need to trust the vendor. If a vendor asks for a ridiculously
high tx fee, it will just surface as uncompetitively priced goods/services.
Buyers will go elsewhere.


> Why not try a different path of calculating the min fee like difficulty
> retarget. You can analyse the last 2016 blocks to find the average fee
> accepted per kb (which would include transactions that were included
> without fees) and then write that into the block as a soft recommendation
> that wallets could use in the UI. This way the price can vary up and down
> according to what people were willing to spend on fees and miners willing
> to accept.
>

That's what fee estimation does, essentially, minus the encoding into
blocks. Once you start getting miners telling people what fees are directly
you run into cases where they might try to lie about their behaviour or
otherwise influence the average. Querying all nodes avoids that problem.
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[Drak]

I dont like the idea of putting the min fee in the hands of the receiver.
Seems like that will work against the best interests of senders in the long
run.

Why not try a different path of calculating the min fee like difficulty
retarget. You can analyse the last 2016 blocks to find the average fee
accepted per kb (which would include transactions that were included
without fees) and then write that into the block as a soft recommendation
that wallets could use in the UI. This way the price can vary up and down
according to what people were willing to spend on fees and miners willing
to accept.

I absolutely do not trust vendors to set fees. I think it has to be based
on what senders are willing to pay and what miners are willing to accept.

Drak
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[Mike Hearn]

On Tue, Dec 3, 2013 at 2:40 AM, Gavin Andresen wrote:

> optional uint64 allowfeetag number=1000
>

Let's just use a normal/low tag number. The extensions mechanism is great
for people who want to extend the protocol outside the core development
process. It'd be weird if nobody ever used the low numbers again though.

Tag numbers are varint encoded so using smaller ones does have a minor
efficiency benefit, it's not just aesthetics :)


> Allow up to allowfee satoshis to be deducted from the amount paid to be
> used to pay Bitcoin network transaction fees. A wallet implementation must
> not reduce the amount paid for fees more than allowfee, and transaction
> fees must be equal to or greater than the amount reduced.
>

Hmmm. Why "allow"? Should it not be called min_fee instead? Wallets would
have to attach at least that much in fees, right?

Also, why describe it as reducing the amount paid? Which output would be
reduced in value? Why not just have it be added to the total value
displayed to the user and the outputs are left alone/not reduced.


> We also want to allow users to pay MORE in fees, if they need to
> (fragmented wallet, maybe, or big CoinJoin transaction) or decide to.
>

I like the idea but it seems this gets us back to the original problem -
senders don't care about confirmations, ever, not even if they make an
annoying set of transactions. The protocol allows users to submit
transactions directly to receivers, I guess, if the receiver does not like
the transactions they get they could potentially reject the payment. But
I'd hope that's really rare.


> PS: I think there was also consensus that the BIP72  request=...   should
> be shortened to just r=... (save 6 chars in QR codes).  Unless somebody
> objects, I'll change the BIP and the reference implementation code to make
> it so...
>

Sweet, thanks!
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development