Re: [Bitcoin-development] 75%/95% threshold for transaction versions

2015-04-28 Thread Oleg Andreev


 On 27 Apr 2015, at 21:21, Peter Todd p...@petertodd.org wrote:
 
 Even right now there are edge cases without
 good solutions, like how in a multisig environment any of the key
 holders can mutate transactions.

Can't we add requirement for RFC6979 signatures to mitigate this? Of course, 
multiple signers can still mutate transaction by choosing a different set (but 
not the order, thankfully) of signatures. Or when a single signer has multiple 
participating keys.

In some interesting to me scenarios mutation by signer is not critical: it is 
mutation by non-signers that creates a problem. Do you know of any edge cases 
when non-signers can mutate transactions which are not covered by BIP62? What 
would be a more robust approach than whack-a-mole to work around mutability? 
(Normalized tx ids?)
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Providing Payment Request within URI

2015-02-26 Thread Oleg Andreev
Thanks for references. Yeah, I don't need X509 signing (if I could use 
certificates, I wouldn't need to include PR in the URL in the first place).

I presume you used BITCOIN:-payment request instead of 
bitcoin:?r=somescheme://payment request to make it more compact. 

I also tried to look up Base43, but I could not find any info on how it is 
specifically optimized for QR codes. Could you enlighten me?


 On 26 Feb 2015, at 10:32, Andreas Schildbach andr...@schildbach.de wrote:
 
 Yeah, you'd be limited to simple usecases. X509 signing or lots of
 outputs will make the QR code hard to scan. However, if all you want to
 do is send to a custom script (without using P2SH) I invite you to have
 a look at
 
 https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/src/de/schildbach/wallet/ui/InputParser.java#L86
 
 https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/src/de/schildbach/wallet/util/Qr.java#L134
 
 https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/src/de/schildbach/wallet/util/Base43.java
 
 Basically it's BITCOIN:- plus the payment request in Base43 encoded
 form. I picked Base43, because that's optimized for QR codes.
 
 
 On 02/24/2015 04:58 PM, Oleg Andreev wrote:
 Hi,
 
 I wonder if there is a standard way to put Payment Request data into 
 bitcoin: URI or directly into QR code. The goal is to allow device to 
 generate a multi-output payment request on its own, without relying on the 
 server and x509 certificates. When scanned via QR code from, say, POS, it's 
 pretty secure, so no additional authentication needed.
 
 I'd like something like this: 
 
 bitcoin:?r=data://base64url-encoded-payment-request
 
 If there's no standard for that, would it be a good idea to extend BIP72 
 this way?
 --
 Dive into the World of Parallel Programming The Go Parallel Website, 
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for 
 all
 things parallel software development, from weekly thought leadership blogs to
 news, videos, case studies, tutorials and more. Take a look and join the 
 conversation now. http://goparallel.sourceforge.net/
 
 
 


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Providing Payment Request within URI

2015-02-26 Thread Oleg Andreev

 Base43 is the same as any BaseX standard, but using a different alphabet
 (43 characters). It's meant to be used for efficiently storing binary
 data into QR codes. The alphabet is picked to match the 'Alphanumeric'
 input mode of QR codes as closely as possible, but at the same time be
 allowed in URIs.

Does it mean Base58 or Base64 take more space in QR code than Base43? Do you 
have an estimate of the gains? 




--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-12 Thread Oleg Andreev

 On 12 Feb 2015, at 13:49, Mike Hearn m...@plan99.net wrote:
 If unconfirmed payments become flaky enough that people stop using them, then 
 a portion of the Bitcoin community will find workarounds like trusted third 
 parties, trusted hardware, whatever and will just struggle one. Other people 
 will look at the new tradeoffs/complexity, and decide that Bitcoin is no 
 longer better for them than banks.

How about a Ripple-like IOU-based payment network that is 100% decentralized, 
for dumb and daily payments only? IOUs will propagate from node to node and 
will trusted because of a joint escrow transaction between each pair of nodes 
(locking up certain amount on both ends in 2-of-2 multisig). Total amount of 
debt from one node to another will be limited to 50% of the locked amount (e.g. 
if both nodes lock up $20 each, they allow debt up to $10 in each direction). 
When debt is reaching its limit, it's being cleared by debtor via a real BTC 
transaction or simply by closing the contract transaction with correct 
proportion on outputs to pay off the debt.

Every node may require an arbitrary fee for a service of providing his funds to 
back IOUs, when making a payment, merchant/customer may find several possible 
paths and choose the quickest/cheapest one to use. Centralization is possible 
at a proportional capital expense. If some node wants to be Visa-scale with 
millions of contracts and a lot of fees to earn, they'll have to lock up huge 
amount of money. This puts natural limit on centralization or associated risk. 

Example:

I pay $10. The following path is discovered and signed off by the Merchant who 
accepts an ad-hoc 0.3% fee:

Me: $10 - $9.99 (Alice) - $9.98 (Bob) - $9.97 (Merchant).

Now I owe $10 to Alice, Alice owes $9.98 to Bob, Bob owes $9.97 to Merchant. 
Clearing of debts happens independently between each participant based on their 
debt-to-capital ratio and whether any party wishes to exit. Of course, if 
several paths are discovered within a reasonable timeframe, Merchant will 
choose the cheapest one. And maybe abort transaction if the proposed path is 
too expensive (e.g. total fee is 1%).

Pros:

- Decentralized.
- Mere seconds to settle a payment.
- Infinite scalability (no global consensus). Each payment involves 5-7 nodes 
only.
- No trusted parties or federation (trust is purchased using joint escrow 
txs on blockchain)
- No funny currency, IOUs denominated in BTC.
- No global consensus or protocol. Nodes can be semi-compatible, upgrade 
independently. All risks are local.

Political problems solved:

- No need to debate zeroconf transactions. We don't *need* them anymore to buy 
a coffee.
- No need to debate block size limit. It'd still be nice to raise it when 
needed, but for 99% of transactions we'll have a good decentralized solution 
off-chain, so the issue is less pressing.

Cons:

- Some amount of cash needs to be locked up with random nodes most of the time. 
If one of the nodes is offline, payments can't be cleared through that node. 
Although, it could not be a big problem as the network is useful for small-ish 
payments and every node will have 10-15 contracts, so it will tolerate 
occasional unavailability of some of them. 




--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-12 Thread Oleg Andreev

 I think that is a misdirection on your part. The point of replace-by-fee is 
 to make 0-confirms reliably unreliable. Currently people can get away with 
 0-confirms but it's only because most people arent actively double spending, 
 and when they do it is for higher value targets. Double spend attacks are 
 happening a lot more frequently than is being admitted here, according to 
 Peter from work with various clients. 
 
 Like single address reuse, people have gotten used to something which is bad. 
 Generally accepting 0-conf is also a bad idea(tm) and instant confirmation 
 solutions should be sought elsewhere. There are already interesting solutions 
 and concepts: greenaddress for example, and CHECKLOCKTIMEVERIFY micropayment 
 channels for example. Rather than supporting and promoting risky 0-confirms, 
 we need to spend time on better alternative solutions that will work for 
 everyone and not during the honeymoon phase where attackers are fewer.

Here's value-free assessment of the issue here:

1. Zero-conf txs are unsafe.
2. We'd all want to have a safer instant payments solution if possible.
3. As a social artifact, today zeroconf txs happen to work for some people in 
some situations.
4. Replace-by-fee will break #3 and probably hasten development of #2.

The discussion boils down to whether we should make #2 happen sooner by 
breaking remnants of #3 sooner.

I personally would rather not break anything, but work as fast as possible on 
#2 so no matter when and how #3 becomes utterly broken, we have a better 
solution. This implies that I also don't want to waste time debating with Peter 
Todd and others. I want to be ready with a working tool when zeroconf 
completely fails (with that patch or for some other reasons).

TL;DR: those who are against the patch are better off building a decentralized 
clearing network rather than wasting time on debates. When we have such 
network, we might all want this patch to be used for all the reasons Peter has 
already outlined.


--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)

2015-02-10 Thread Oleg Andreev
 Let's say you're visiting an international webshop. But they don't ship to 
 your country. Wouldn't you want to know that before your start filling the 
 cart? With this, your wallet / browser extension could tell you right away 
 that you can't shop there. No time wasted!

Why my wallet has to do anything with me being in some country? The webshop may 
detect my location and tell me if they ship to where I'm currently in. Why 
should I associate more private information (my location) with my wallet than 
strictly necessary? Why should I automatically advertise my shipping address to 
every webshop without my explicit consent?

The wallet must be convenient only as much as it allows for better security and 
privacy, but not trading off security and privacy for some unrelated 
convenience. --
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development