Re: [Bitcoin-development] Merge avoidance and P2P connection encryption

2013-12-13 Thread Mike Hearn 
>
> Or alternatively, the user-signed payment request without iteration
> count is enclosed within a payr.com-signed envelope that contains the
> iteration count.


But how does that show up in the user interface? I don't know how you would
explain what the signature means or implies, or what you do if the
signature is broken/missing.

The only thing that a maliciously modified iteration count can do is cause
money to be sent to an address that's beyond the recipients gap limit,
meaning they won't receive it (unless they reconfigure their software and
rescan). But you can't steal money that way.
--
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=84349831&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Merge avoidance and P2P connection encryption

2013-12-13 Thread Mark Friedenbach 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/13/2013 09:26 AM, Mike Hearn wrote:
> I'm thinking about a use case I hope will become common next year
> - pastebin style hosting sites for payment requests. Like, if I as
> a regular end user wish to use the payment protocol, I could just
> upload a (possibly signed) payment request to:
> 
> payr.com/a62gahZ 
> 
> or whatever, and then payr.com  can take care of 
> incrementing the iteration count on each download of my file.
> That's why it's useful for it to be unsigned.

Or alternatively, the user-signed payment request without iteration
count is enclosed within a payr.com-signed envelope that contains the
iteration count. Having fields completely unsigned by anybody leaves
me a little nervous.

Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSq12pAAoJEAdzVfsmodw4MC4QAI9cjmQXz8AVawwr1htFc6b+
DVAAs1Y4hzbChPeeJCmy13m8a/BuXqc6G0WEWGSzIIa1or3IXCd01JQ2a5waD0IC
uOjlIMD0tTT7yxwxRjxPc2df82s82traGJC2caOMYjrN4T5VPtj7erB2poNyvOF+
p0lmj+duxUZ8IoyDaih5mgNKzIVujfX7o3lPoOMDdIi6Q1LF9SZ9XbUAxHCpCLfw
ieqVIm8zqtH0NprZ7/JLbqstl1iq5jCPKbORc+9qQWESZH1hFAeS29/ptjnRR8y6
HqrpDP236vSlrLDW4dLcW9UiQP42tSTwrLCgud08VqeKapSlMX8fjukLyNlTD7h5
GtPHEo1/j+LmpMfwsXA2OotUIVQBeFfEoi7PwV/Jd+SRVqC6zCTPky1lfg0P7JXA
7qD9m3u/Ey0+nk888zzff8N7AfBe7GaqFuUByXIyHh6dkcr0xUHBU4afiadFpNhg
8dTvmP4yqY0g05uz/Cq/ZqrSb5y/yPqsysuruAjWG2GT0M8rFM9oYepVHpUJr01K
QOHY6qSoqyX/KDCkZgpTMZFDq9gvyPyMFuCQbdecNcCeMPV5kiwPyqqH4rHliJ8I
gsXW44re5GfdL90nCOTboYFf2CFEn+66zyJ5vBskKSyDRDcU3t5YyCtrDzXdtJMu
MjVeMFRluY700zLBajw0
=+MjP
-END PGP 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=84349831&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Merge avoidance and P2P connection encryption

2013-12-13 Thread Mike Hearn 
>
> Why would there be an iteration count? The payer would handle that,
> wouldn't they?
>

I'm thinking about a use case I hope will become common next year -
pastebin style hosting sites for payment requests. Like, if I as a regular
end user wish to use the payment protocol, I could just upload a (possibly
signed) payment request to:

payr.com/a62gahZ

or whatever, and then payr.com can take care of incrementing the iteration
count on each download of my file. That's why it's useful for it to be
unsigned.


> If the use case is:  I give the Foundation a "here's where to pay my
> salary" PaymentRequest, maybe with several Outputs each having a different
> xpubkey, then it seems to me the Foundation's wallet software should take
> care of iterating.
>

Absolutely. The two use cases can both be supported. You could give
iteration ranges, for instance, if you want to specify expiry in terms of
number of payments rather than 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=84349831&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Merge avoidance and P2P connection encryption

2013-12-13 Thread Peter Todd 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

So, vendors hat on, what would it take for, say, BitPay to implement merge 
avoidance and coinjoin together?

At the dark wallet hackathon when we were talking usability we decided that the 
main way to get coinjoin working well is to take advantage of non-time-critical 
payments to act as counterparties to time-critical payments. For instance 
BitPay could schedule a vendor payment to happen in full by some time in the 
future, say 1 day, and send the funds in one or more joins. The actual amounts 
sent in each tx are then picked to match the amounts desired by the 
counterparty who needs funds sent right now.

We expect this to be first implemented just as a "anonymize my coins" button 
for wallet software on always on machines; getting vendors on board would be 
gravy.

We may even allow joins to happen when one party pays less fees than the other, 
although this is tricky: the main Sybil resistance of coinjoin is fees so you 
don't want to overdo it. OTOH the idea of the NSA and Chinese equivalent 
wasting money completing each others joins is hilarious...


Jeff Garzik  wrote:
>On Thu, Dec 12, 2013 at 7:20 PM, Gavin Andresen
> wrote:
>> If the use case is:  I give the Foundation a "here's where to pay my
>salary"
>> PaymentRequest, maybe with several Outputs each having a different
>xpubkey,
>> then it seems to me the Foundation's wallet software should take care
>of
>> iterating.
>
>Absolutely.  This is a key address-non-reuse case we really need to
>solve.  Miner payouts, BitPay salary payouts, etc. all use a
>statically provided, manually changed address.
>
>Rotating through multiple outputs is a stopgap -- but IMO a useful
>one.  HD wallets will solve this in a better way, but existing randkey
>systems will be around for a long time.
-BEGIN PGP SIGNATURE-
Version: APG v1.0.9

iQFQBAEBCAA6BQJSqxz9MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhTMBB/9L8h5NuSHxsC6W5ptm
gucxg2AbCwReuWQzRzqW42TYKQ7MnAhpfLLbSQrewNoXRP4H/j6aG8uWOt+z7fZf
pJZ9K8kxmSltHm8SJcmPLTb62yazEKQXF5TDsdpgBdH14M/pFsjUR4H2hypW8k4T
gcEAIhymZvlXev1NXDMh6rbuw0LtRTBE4NgE2buCuFzp0sEwTNTLxMU1WenMXfRQ
PooSBn8UoAVNw7Vztnag0T0f5D45VFNJBvQ8m42ee0u3gvMCa4JNRTBM49N2U9qc
Gk6WAvDakOf7FwaJiNMYoDpGyWphx6g697j28NnfB2q2hdjUVnZF+UVuBzkjnNwD
Y40/
=4dxZ
-END PGP 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=84349831&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development