Re: [Bitcoin-development] BIP 0020: URI Scheme

2012-01-28 Thread Andreas Schildbach
On 01/28/2012 02:45 AM, Luke-Jr wrote: It's been implemented in many clients for nearly all 2011. Bitcoin-Qt is just behind the pace. Not relevant. Bitcoin Wallet for Android implements only parts of this spec: The hexadecimal notations (x) and exponent notations (X) feel horribly redundant

Re: [Bitcoin-development] BIP 21 (modification BIP 20)

2012-01-31 Thread Andreas Schildbach
Generally I prefer BIP 21 over BIP 20. I'm neutral on the 'send' parameter - present in both BIPs - which I don't understand. I think a practical usecase should be given in the BIP. Also, the 'version' parameter is unclear. What does it mean? Is an oder defined on versions (1.0b 1.0)? Why is it

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

2012-01-31 Thread Andreas Schildbach
On 01/31/2012 07:22 PM, Matt Corallo wrote: that It is recommended that additional variables prefixed with mustimplement: not be used in a mission-critical way until a grace Is the ':' sign actually allowed in URL parameter names (unescaped/unencoded)? If not, I'd propose an unrestricted char

Re: [Bitcoin-development] new bitcoin.org clients page

2012-05-03 Thread Andreas Schildbach
On 05/03/2012 11:24 AM, Jorge Timón wrote: On 5/3/12, Andreas Schildbach andr...@schildbach.de wrote: Can we add Bitcoin Wallet? Someone said to me that the cell phone apps they had tried were still too slow. I'm still using an old phone so I didn't know well what to answer him. I never

[Bitcoin-development] Testnet3 difficulty transition problem?

2012-12-22 Thread Andreas Schildbach
Both blocks 38304 015bb4069249fa1f41ae61d8a7447aaacc33c50dacd3c3654377fa43 and 40320 8011f56b8c92ff27fb502df5723171c5374673670ef0eee3696aee6d are difficulty transition blocks. However, block 40320 has a difficulty of 1. I know there is this special testnet rule that allows

Re: [Bitcoin-development] Draft BIP for Bloom filtering

2013-01-19 Thread Andreas Schildbach
Matt, I saw your commit and immediately started using it for testing. Now I think the bitcoinj side needs some love because not one transaction is being confirmed (all just pending) when replaying the blockchain. On 01/18/2013 05:38 PM, Mike Hearn wrote: I'm thinking we should actually make the

Re: [Bitcoin-development] BIP21 bitcoin URIs and HTML5

2013-04-24 Thread Andreas Schildbach
I had another amendment, which roughly (can't remember the details) has to do with case-sensitivity of the scheme part and parameter names. If I remember right, BITCOIN:1d4...?AMOUNT=0.1 would be a correct URI but not valid in the sense of BIP21 currently. On 04/24/2013 09:42 AM, Mike Hearn

Re: [Bitcoin-development] HTTP REST API for bitcoind

2013-07-23 Thread Andreas Schildbach
On 07/22/2013 09:42 PM, Jeff Garzik wrote: The general goal of the HTTP REST interface is to access unauthenticated, public blockchain information. There is no plan to add wallet interfacing/manipulation via this API. Is it planned to expose the UXTO set of a given address? That would be

Re: [Bitcoin-development] Proposal: remove getwork RPC from bitcoind

2013-08-19 Thread Andreas Schildbach
On 08/19/2013 10:34 PM, Jeff Garzik wrote: FWIW, Litecoin 0.8.x entirely removed the internal miner and we warned people that getwork will be removed in the next major version. Pooler's CPU minerd which supports both sha256d and scrypt recently grew stratum support. Perhaps he could be

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

2013-09-25 Thread Andreas Schildbach
While it's good to save space, I'm at the moment not convinced that taking a de-route via an URL is a good idea to begin with. The main problem is trust. If you scan a QR code from a foreign phone, you trust that that phone is owned by the one you want to send money to. By adding the HTTP request

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

2013-09-25 Thread Andreas Schildbach
have that problem (unless sophisticated optical attacks emerge). Also, the HTTP request can fail and/or be slow, making the whole payment process more difficult than necessary. On Wed, Sep 25, 2013 at 12:28 PM, Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de wrote

Re: [Bitcoin-development] Feedback requested: reject p2p message

2013-10-28 Thread Andreas Schildbach
HTTP also defines success codes (2xx). Are we also talking about ACK messages now, rather than just REJECT messages? On 10/28/2013 03:52 AM, kjj wrote: Any reason not to use actual HTTP codes? I'm not aware of any major deficiency in them. Most of them won't apply to us, which is fine, they

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

2013-12-01 Thread Andreas Schildbach
(my post hasn't shown up for an hour, so I'm sending it again) On 12/01/2013 02:41 PM, Mike Hearn wrote: As long as the tx is not confirmed (by a broadcast), apps can offer to bump up the fee a little bit. Unfortunately there are risks to that approach. I assume you're right, since I do

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

2013-12-01 Thread Andreas Schildbach
On 12/01/2013 06:19 PM, Mike Hearn wrote: Both can be combined into adapting the current generic messages (This payment should become spendable shortly for incoming and This payment has not been transmitted yet for outgoing transactions). What would the new messages say? Well, for starters

Re: [Bitcoin-development] Fees UI warning

2013-12-16 Thread Andreas Schildbach
On 12/16/2013 07:28 PM, Mike Hearn wrote: I don't know how to solve this. Badly designed software that looks appealing will always be a danger. One way would be to explicitly warn against some services. For example, on the Choose you wallet page of bitcoin.org.

Re: [Bitcoin-development] Payment protocol and reliable Payment messages

2014-01-13 Thread Andreas Schildbach
Thanks for the explanation. On 01/13/2014 06:56 PM, Pieter Wuille wrote: As for you proposal, just be aware I'd like to use the payment protocol for face to face payments as well. That meant payment request via NFC or QR, payment message and payment confirmations via Bluetooth. I think it

Re: [Bitcoin-development] Payment protocol and reliable Payment messages

2014-01-14 Thread Andreas Schildbach
On 01/13/2014 06:56 PM, Pieter Wuille wrote: I want to avoid the case where a transaction confirms, but the associated payment is not delivered. If there is a reasonable chance that this case occurs in normal operation, it means the payment transmission cannot be relied upon. I was thinking

Re: [Bitcoin-development] Payment protocol and reliable Payment messages

2014-01-14 Thread Andreas Schildbach
On 01/14/2014 11:45 AM, Mike Hearn wrote: Imagine you get a good offer (payment request) from a merchant. You would like to accept that offer, however the merchant has changed his mind. Usually if the merchant has not delivered, then at that point it's not a problem and he is

Re: [Bitcoin-development] BIP70/71 issue, RFD

2014-01-26 Thread Andreas Schildbach
is this an issue for? As you note, for files and HTTP responses it's not a problem in practice. i'd guess nor for NFC tags nor QR codes. On Sun, Jan 26, 2014 at 10:11 PM, Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de wrote: I'm experimenting with BIP70/71 (payment

[Bitcoin-development] Payment Protocol for Face-to-face Payments

2014-01-27 Thread Andreas Schildbach
As promised I'd like to present my work done on leveraging the payment protocol for face-to-face payments. The general assumption is that individuals don't own X.509 certificates. Their devices may be only badly connected to the internet or in some cases not at all. I've implemented a prototype on

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-27 Thread Andreas Schildbach
On 01/27/2014 03:54 PM, Gavin Andresen wrote: The purpose of PaymentACK is to give the customer reassurance that their payment request has been received and will be processed (or not). If it is syntactically incorrect or invalid in a way that the payment processor can detect right away then

[Bitcoin-development] Experiment with linking payment requests via href

2014-01-27 Thread Andreas Schildbach
On 01/27/2014 07:18 PM, Andreas Schildbach wrote: Rather than pack a file into a URL, if you don't want to use the current r= extension it's better for apps to just register to handle .bitcoinpaymentrequest files / the right MIME type. Downloading it and opening it would do the right thing

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

2014-01-30 Thread Andreas Schildbach
://github.com/schildbach/bitcoin-wallet/releases/tag/v3.30-bitcoinj0.11 On 01/27/2014 12:59 PM, Andreas Schildbach wrote: As promised I'd like to present my work done on leveraging the payment protocol for face-to-face payments. The general assumption is that individuals don't own X.509 certificates

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

2014-02-07 Thread Andreas Schildbach
/schildbach/bitcoin-wallet/releases/tag/v3.32 (also published to the corresponding channels on Google Play) On 01/30/2014 11:46 AM, Andreas Schildbach wrote: Just a small update. I merged the code to my bitcoinj-0.11 branch and put up binary .apk files for experimentation. Just make sure to tick

[Bitcoin-development] BIP70 proposed changes

2014-02-18 Thread Andreas Schildbach
I'm starting a thread on proposed changes on BIP70 based on my experience in implementing the payment protocol in Bitcoin Wallet: - certificate chain in pki_data: I think it should be required that is most contain the first certificate PLUS all intermediate certificates (if any), but NOT the root

Re: [Bitcoin-development] BIP70 proposed changes

2014-02-18 Thread Andreas Schildbach
On 02/18/2014 08:14 PM, Ryan X. Charles wrote: The most important missing piece of the payment protocol is that is has no concept of the status of a payment after it has been made. What if the payment is too little? Too much? What if it is never confirmed? What if it is confirmed, but very

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

2014-03-02 Thread Andreas Schildbach
/Payment-Requests If you have any questions about compatibility, don't hesitate to contact me. On 01/27/2014 12:59 PM, Andreas Schildbach wrote: As promised I'd like to present my work done on leveraging the payment protocol for face-to-face payments

Re: [Bitcoin-development] Instant / contactless payments

2014-03-06 Thread Andreas Schildbach
I'm not sure if iso-dep is the way to go here. Afaik as soon as you pick up the phone the connection breaks. It's ok if some people decide to let the app do risk analysis, but you cannot force it onto users by picking a protocol that cannot deal with manual verification. Users should always have

Re: [Bitcoin-development] Instant / contactless payments

2014-03-06 Thread Andreas Schildbach
On 03/06/2014 02:44 PM, Mike Hearn wrote: I'm not sure if iso-dep is the way to go here. Afaik as soon as you pick up the phone the connection breaks. If the phone isn't willing to immediately authorise then it'd have to fall back to HTTPS or Bluetooth as normal. Ok, that would be

Re: [Bitcoin-development] Instant / contactless payments

2014-03-06 Thread Andreas Schildbach
Not sure if you've seen it, but here is how we do NFC right now http://www.youtube.com/watch?v=DGOMIG9JUY8 with XBTerminal. Thanks for the video! It's always good to see these things in action so you can start believing in it. For now this is just an NDEF URI message with Bitcoin URI inside,

Re: [Bitcoin-development] Instant / contactless payments, IsoDep

2014-03-06 Thread Andreas Schildbach
On 03/06/2014 03:51 PM, Andreas Schildbach wrote: I'm not sure if iso-dep is the way to go here. Afaik as soon as you pick up the phone the connection breaks. If the phone isn't willing to immediately authorise then it'd have to fall back to HTTPS or Bluetooth as normal. Ok

Re: [Bitcoin-development] Instant / contactless payments

2014-03-07 Thread Andreas Schildbach
On 03/06/2014 07:03 PM, Alex Kotenko wrote: Supporting Bluetooth is optional in the sense that if a wallet should not support it, you will still receive the transaction via the P2P network. So I'd say definately go for Bluetooth. ​Yes, it's part of the​ plan. Just again - I need

Re: [Bitcoin-development] Instant / contactless payments

2014-03-10 Thread Andreas Schildbach
On 03/10/2014 04:09 PM, Alex Kotenko wrote: ​Yes, ​I'm certain about that we need to switch to BIP70 asap. As I said earlier - support among the wallets is the biggest problem here really. Only Andreas' Wallet supports it right now AFAIK, and even in there it's only as LABS feature, so will

Re: [Bitcoin-development] moving the default display to mbtc

2014-03-13 Thread Andreas Schildbach
Indeed. And users were crying for mBTC. Nobody was asking for µBTC. I must admit I was not aware if this thread. I just watched other wallets and at some point decided its time to switch to mBTC. On 03/13/2014 02:31 PM, Mike Hearn wrote: The standard has become mBTC and that's what was

Re: [Bitcoin-development] moving the default display to mbtc

2014-03-14 Thread Andreas Schildbach
/2014 02:40 PM, Andreas Schildbach wrote: Indeed. And users were crying for mBTC. Nobody was asking for µBTC. I must admit I was not aware if this thread. I just watched other wallets and at some point decided its time to switch to mBTC. On 03/13/2014 02:31 PM, Mike Hearn wrote: The standard

Re: [Bitcoin-development] moving the default display to mbtc

2014-03-14 Thread Andreas Schildbach
as a price in some currency. A number with more than two decimals is just not percieved as a price but as a geeky something that you rather convert to local currency. Tamas Blummer Bits of Proof On 14.03.2014, at 15:49, Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de

Re: [Bitcoin-development] moving the default display to mbtc

2014-03-14 Thread Andreas Schildbach
solve this problem for good. Instead mBTC is a confusing step in-between. Tamas Blummer http://bitsofproof.com On 14.03.2014, at 16:02, Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de wrote: By that definition 3.56 is a price. Maybe I misunderstood you and you're

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

2014-03-20 Thread Andreas Schildbach
On 03/20/2014 03:22 AM, Alex Kotenko wrote: Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I need to still be able to use it for backwards compatibility. But at the same time I want to be able to support BIP70. And also I want to avoid using external servers, the

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

2014-03-21 Thread Andreas Schildbach
On 03/20/2014 05:14 PM, Alex Kotenko wrote: Hmm, if we're inventing an URI for bluetooth, I'd rather follow existing URI's patterns. BT is strictly point-to-point connection, so BT MAC should be considered as server address, and payment request ID can be considered as request path. Probably

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

2014-03-21 Thread Andreas Schildbach
On 03/20/2014 01:12 PM, Adam Back wrote: Whats a sensible limit on practical/convenient QR code size? Technically 3 KB. In my experience codes above 1.5 KB become impossible to scan (ZXing scanner, 3 years ago). You will want to stay below 500 bytes for convenient scanning. That said, I'm

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

2014-03-21 Thread Andreas Schildbach
On 03/20/2014 06:31 PM, Jeff Garzik wrote: Afaik, BIP73 needs an external server (the web server). Yes. Internet connectivity is not a rarity these days. Near-field web servers also work fine. Unfortunately it still is. At least here in Germany.

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

2014-03-21 Thread Andreas Schildbach
+1 I couldn't do a better job at describing my motivation behind trying to stuff payment requests into QR codes. On 03/20/2014 10:52 PM, Roy Badami wrote: On Thu, Mar 20, 2014 at 07:31:27PM +0100, Mike Hearn wrote: Yes, this overlaps somewhat with the PKI signing in BIP70, but not entirely

Re: [Bitcoin-development] Post to list request

2014-03-21 Thread Andreas Schildbach
Access granted. Welcome! (-: On 03/21/2014 10:11 AM, Chris D'Costa wrote: Hello I wonder if I could be granted access to post to the dev list. My project is the Meek hardware wallet, and we are working on a solution to avoid MITM attacks when communicating a pay-to information over a

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

2014-03-26 Thread Andreas Schildbach
But these cases are the norm, rather than the exception. Of all these places I spend my money at during the day I hardly ever know their official name. I'm thinking in terms of bakery, indian restaurant or snack vending machine. In Germany usually businesses are named like the people that run it.

Re: [Bitcoin-development] New BIP32 structure

2014-03-26 Thread Andreas Schildbach
Thanks for starting the discussion on finding a better structure. For me, the most important thing is either we're 100% interoperable or 0%. There should not be anything inbetween, as users will delete seeds without knowing there is still money in them on another implementation. I heard from

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Andreas Schildbach
I see the problem. However, I don't see how PaymentDetails can be an answer. None of the fields (other than outputs and network) can be known in advance (at the time of the initial payment). You're probably aiming for an expires field? How would you refund a payment after expiry? Note its not

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Andreas Schildbach
: On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de wrote: However, I don't see how PaymentDetails can be an answer. None of the fields (other than outputs and network) can be known in advance (at the time of the initial payment

Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Andreas Schildbach
On 03/28/2014 07:19 PM, Mike Hearn wrote: Ok, why don't fix this in the spec for now, by defining a fixed expiry time. In the EU, most products are covered by a 2 years warranty, so it seems appropriate to pick 2.5 years (30 months) -- allowing for some time to ship the product back and

Re: [Bitcoin-development] BIP 70 refund field

2014-03-30 Thread Andreas Schildbach
...@gnomon.org.uk wrote: On Fri, Mar 28, 2014 at 09:56:57PM +0100, Andreas Schildbach wrote: On 03/28/2014 07:19 PM, Mike Hearn wrote: Ok, why don't fix this in the spec for now, by defining a fixed expiry time. In the EU, most products are covered by a 2 years warranty

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Andreas Schildbach
They're _not_ phasing out into SPV wallets from what I can say. At around the 24th of February, there has been a sharp change of the current installs graph of Bitcoin Wallet. That number used to grow at about 20.000 per month. After that date until now, it just barely moves horizontal. My guess

Re: [Bitcoin-development] New BIP32 structure

2014-04-08 Thread Andreas Schildbach
On 04/08/2014 05:46 PM, slush wrote: I understand each client will implement things a little bit different, for example the current plan is bitcoinj will hold all keys in memory and start reusing keys on low resources. Electrum uses a chain for their private purpose. Etc.

[Bitcoin-development] BIP32 wallet structure in use? Remove it?

2014-04-25 Thread Andreas Schildbach
Does anyone use or plan to use the wallet structure part of the BIP32 document? I suggest removing it from the document and maybe instead point at BIP43. That new specification proposal just defines a purpose and leaves everything else to the inventor of that purpose. The idea it that over time a

[Bitcoin-development] DNS seeds unstable

2014-05-15 Thread Andreas Schildbach
I'm bringing this issue up again. The current Bitcoin DNS seed infrastructure is unstable. I assume this is because of we're using a custom DNS implementation which is not 100% compatible. There have been bugs in the past, like a case sensitive match for the domain name. Current state (seeds

Re: [Bitcoin-development] DNS seeds unstable

2014-05-16 Thread Andreas Schildbach
On 05/15/2014 07:48 PM, Gregory Maxwell wrote: On Thu, May 15, 2014 at 4:50 AM, Andreas Schildbach andr...@schildbach.de wrote: I'm bringing this issue up again. The current Bitcoin DNS seed infrastructure is unstable. I assume this is because of we're using a custom DNS implementation which

Re: [Bitcoin-development] DNS seeds unstable

2014-05-16 Thread Andreas Schildbach
Apparently British Telecom also cannot speak to Peter Todd's server. That another very large ISP in Europe. On 05/15/2014 01:50 PM, Andreas Schildbach wrote: I'm bringing this issue up again. The current Bitcoin DNS seed infrastructure is unstable. I assume this is because of we're using

Re: [Bitcoin-development] DNS seeds unstable

2014-05-16 Thread Andreas Schildbach
: desktopv2.bluematt.me Address: 152.23.202.18 And that address doesn't connect on port 18333. On 05/16/2014 08:53 PM, Matt Corallo wrote: This is very strange...when did you run this test and can anyone else reproduce this? Matt On 05/15/14 11:50, Andreas Schildbach wrote: testnet

Re: [Bitcoin-development] DNS seeds unstable

2014-05-17 Thread Andreas Schildbach
I think the best way to contribute to the infrastructure is actually what we're doing: Test the current infrastructure and point out where it is not working. Trying to find solutions for problems. There is nothing gained by throwing additional hardware at a problem if the problem itself isn't

Re: [Bitcoin-development] DNS seeds unstable

2014-05-17 Thread Andreas Schildbach
On 05/17/2014 02:02 PM, Alex Kotenko wrote: So, my understanding is that atm we have no working DNS seeds at the testnet3, right? There are two DNS seeds known, of which one is unreachable atm, and another one is giving just one IP address, which is also a dead node. Yes, that's my

Re: [Bitcoin-development] Paper Currency

2014-05-18 Thread Andreas Schildbach
One problem we couldn't figure out here though - how to protect the notes from unauthorized redeem. Like if someone else tries to reach your wallet with his own NFC - how can we distinguish between deliberate redeem by owner and fraudulent redeem by anybody else with custom built long range

Re: [Bitcoin-development] Paper Currency

2014-05-18 Thread Andreas Schildbach
Jerry, some feedback on generating space-efficient QR codes. QR codes have 4 possible encodings, see Storage: http://en.wikipedia.org/wiki/QR_code The encoding you're proposing in BIP81 switches you to binary mode without actually using all the bits. So you'll end up with bloaty QR codes. One fix

Re: [Bitcoin-development] DNS seeds unstable

2014-05-21 Thread Andreas Schildbach
Great, thanks for this contribution! Do you plan to have your seeds reachable on port 53 eventually? Currently bitcoinj cannot deal with nonstandard ports I think. On 05/21/2014 11:23 AM, Alex Kotenko wrote: okay, I've set it up with bind forwarding requests to two dnsseeds running on

Re: [Bitcoin-development] DNS seeds unstable

2014-05-21 Thread Andreas Schildbach
Kotenko 2014-05-21 12:03 GMT+01:00 Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de: Great, thanks for this contribution! Do you plan to have your seeds reachable on port 53 eventually? Currently bitcoinj cannot deal with nonstandard ports I think

Re: [Bitcoin-development] testnet-seed.bitcoin.petertodd.org is up again

2014-05-25 Thread Andreas Schildbach
Thanks for looking at the issue. Unfortunately, it still fails for me: $ nslookup testnet-seed.bitcoin.petertodd.org Server: 127.0.1.1 Address:127.0.1.1#53 ** server can't find testnet-seed.bitcoin.petertodd.org: SERVFAIL Like I said, can you look at the logfiles how the

Re: [Bitcoin-development] testnet-seed.bitcoin.petertodd.org is up again

2014-05-26 Thread Andreas Schildbach
at 09:12:10PM +0200, Andreas Schildbach wrote: Thanks for looking at the issue. Unfortunately, it still fails for me: $ nslookup testnet-seed.bitcoin.petertodd.org Server: 127.0.1.1 Address: 127.0.1.1#53 ** server can't find testnet-seed.bitcoin.petertodd.org: SERVFAIL

Re: [Bitcoin-development] testnet-seed.bitcoin.petertodd.org is up again

2014-05-26 Thread Andreas Schildbach
On 05/27/2014 12:39 AM, Peter Todd wrote: On 27 May 2014 01:12:05 GMT+03:00, Andreas Schildbach andr...@schildbach.de wrote: You're very quick to point at others. Especially since they run software that had the time to mature for about 30 years, and the protocol didn't really change since

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-14 Thread Andreas Schildbach
Just a quick comment: The supports_instant field seems redundant to me. First, as per your spec, you can derive it from trusted_instant_providers. And second, why do you need it at all? Protobuf is designed so it will simply ignore fields you don't know. So you can just send the instant_* fields

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-15 Thread Andreas Schildbach
be signed. Can you briefly describe the whole flow of messages on an example, including the BIP70 messages? Should we allow adding multiple signatures (from different instant providers or maybe while transitioning to another PKI)? On 06/15/2014 11:22 AM, Lawrence Nahum wrote: Andreas Schildbach

Re: [Bitcoin-development] Proposed BIP 70 extension

2014-06-24 Thread Andreas Schildbach
I think it should be made more clear what's the reference price for the discount. In Germany, we generally don't use credit cards but rather EC-Cards, which is already much cheaper. Or maybe for some merchants the only alternative is cash, and they would still offer a Bitcoin discount. Also,

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

2014-07-01 Thread Andreas Schildbach
On 07/01/2014 10:18 AM, Mike Hearn wrote: ​However it's not ideal at the moment. Basically the main problem is that in the BIP72 there is no way to provide a fallback alternative URI for payment request fetch if client wallet supports BIP70 but doesn't not support fetching over

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

2014-07-01 Thread Andreas Schildbach
Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd advocate for a simple array parameter name, like rs= (plural of r). Length really does matter for QR codes. I'm fine with either multiple r= params or exactly one r= plus zero to many r[]= params. Although I think it is a

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

2014-07-01 Thread Andreas Schildbach
checking for any duplicate parameters and treating the entire URI as invalid if duplicate parameters exist (following the parameter pollution suggestions). - Michael Wozniak On Jul 1, 2014, at 10:59 AM, Andreas Schildbach andr...@schildbach.de wrote: Does r[]= really need to be encoded as r

Re: [Bitcoin-development] BIP 38 NFC normalisation issue

2014-07-15 Thread Andreas Schildbach
I think generally control-characters (such as \u) should be disallowed in passphrases. (Even the use of whitespaces is very questionable.) I'm ok with allowing pile-of-poo's. On mobile phones there is keyboards just containing emoticons -- why not allow those? Assuming NFC works of course.

Re: [Bitcoin-development] BIP 38 NFC normalisation issue

2014-07-15 Thread Andreas Schildbach
Can you provide the rationale for standard practice? For example, why should whitespace be allowed? I regularly use trim() on any passphrase (or other input ftm). So what's the action point? Should we amend the spec to filter control characters? That would get rid of the \u problem. On

Re: [Bitcoin-development] BIP 38 NFC normalisation issue

2014-07-16 Thread Andreas Schildbach
Guys, you are always talking about the Unicode astral plane, but in fact its a plain old (ASCII) control character where this problem starts and likely ends: \u. Let's ban/filter ISO control characters and be done with it. Most control characters will never be enterable by any keyboard into a

Re: [Bitcoin-development] BIP 38 NFC normalisation issue

2014-07-16 Thread Andreas Schildbach
, 2014 at 11:17 AM, Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de wrote: Guys, you are always talking about the Unicode astral plane, but in fact its a plain old (ASCII) control character where this problem starts and likely ends: \u. Let's ban/filter

Re: [Bitcoin-development] BIP 38 NFC normalisation issue

2014-07-16 Thread Andreas Schildbach
whatever implementation) and I will verify it decodes properly in bitcoinj? On 07/16/2014 12:46 PM, Andreas Schildbach wrote: I will change the bitcoinj implementation and propose a new test vector. On 07/16/2014 11:29 AM, Mike Hearn wrote: Yes sorry, you're right, the issue starts

Re: [Bitcoin-development] BIP 38 NFC normalisation issue

2014-07-16 Thread Andreas Schildbach
, Andreas Schildbach andr...@schildbach.de wrote: Damn, I just realized that I implement only the decoding side of BIP38. So I cannot propose a complete test vector. Here is what I have: Passphrase: ϓ␀Ѐ (\u03D2\u0301\u\U00010400\U0001F4A9; GREEK UPSILON WITH HOOK, COMBINING ACUTE ACCENT

Re: [Bitcoin-development] BIP 38 NFC normalisation issue

2014-07-17 Thread Andreas Schildbach
me if there are other weird issues lurking. Would definitely sleep better with a more restricted character set. On 17 Jul 2014 00:04, Andreas Schildbach andr...@schildbach.de mailto:andr...@schildbach.de wrote: Please excuse me. I had a more thorough look at the original problem

Re: [Bitcoin-development] Bitcoin development (testing where to get Wallet code)

2014-07-30 Thread Andreas Schildbach
Are you aware of bitcoinj? http://bitcoinj.github.io/ It contains everything to plug together a basic SPV wallet and runs in the JVM. On 07/30/2014 09:38 AM, Caleb Roger Davis wrote: Yes, I was thinking something on the JVM, I have a big interest in Clojure right now (am a long time Java

Re: [Bitcoin-development] How to create a pull tester JAR

2014-08-05 Thread Andreas Schildbach
On 08/05/2014 05:11 PM, Mike Hearn wrote: Oh, I forgot to mention something important. Ridiculously, the default package repository Maven uses was not protected by SSL up until a few days ago. They made it available via SSL now, but you have to tell Maven about the new URL. I guess they'll

Re: [Bitcoin-development] BIP72 amendment proposal

2014-09-12 Thread Andreas Schildbach
On 09/12/2014 12:11 PM, Mark van Cuijk wrote: On 12 Sep 2014, at 11:55 , bitcoin-development-requ...@lists.sourceforge.net wrote: The hash is meant to link the trust anchor (e.g. the QR code) to the payment request message in a secure way. This will solve the problem several apps are

Re: [Bitcoin-development] BIP72 amendment proposal

2014-09-12 Thread Andreas Schildbach
On 09/12/2014 03:49 PM, Mike Hearn wrote: (1) Base64 of SHA256 seems overkill. 256 bits of hash is a lot. The risk here is that a MITM intercepts the payment request, which will be typically requested just seconds after the QR code is vended. 80 bits of entropy would still be a lot and take a

Re: [Bitcoin-development] BIP72 amendment proposal

2014-09-15 Thread Andreas Schildbach
I agree that this would be another way of achieving the same goal. I'd be fine with that if there is a majority. However, I also see downsides of this approach: 1. It's more complicated. It touches more BIPs, and although signing is terribly difficult its still more difficult than just hashing.

Re: [Bitcoin-development] BIP72 amendment proposal

2014-09-15 Thread Andreas Schildbach
On 09/12/2014 08:43 PM, Aaron Voisine wrote: Should BIP72 require that signed payment requests be from the same domain, Although it currently does not seem to be used that way, I'd like to see merchants sign their payment requests but store them on their payment processors server. Currently if

Re: [Bitcoin-development] Export format for xpub

2015-02-02 Thread Andreas Schildbach
On 02/02/2015 03:47 PM, vv01f wrote: Uff, I would expect MMDD there so it's human readable as well. Those strings are not meant to be read by humans. MMDD is more complicated than necessary, given that Bitcoin deals with seconds since epoch everywhere. First that is a pitty .. as

Re: [Bitcoin-development] Export format for xpub

2015-02-02 Thread Andreas Schildbach
On 02/02/2015 03:56 PM, Pavol Rusnak wrote: To me it seems more important to describe how addresses should be discovered (i.e. to scan xpub/0/i and xpub/1/j chains using gap limit G) instead of how the xpub was created/obtained (bip32 vs bip44). What do you thing about changing ?h=bip32 to

Re: [Bitcoin-development] Export format for xpub

2015-02-02 Thread Andreas Schildbach
On 02/02/2015 12:33 PM, Mike Hearn wrote: I looked at what Andreas is doing a few days ago - basically it's just an xpub string with a ?a=bc=d query string added to the end, with a hierarchy type specifier and something else I forgot, encoded into a QR code. It's h=bip32 for the hierarchy

Re: [Bitcoin-development] Export format for xpub

2015-02-02 Thread Andreas Schildbach
On 02/02/2015 01:59 PM, Pavol Rusnak wrote: It's h=bip32 for the hierarchy used and Do I understand this correctly and h=bip32 hierarchy means that both xpub/0/i and xpub/1/j chains are scanned? (So it applies to BIP44 generated xpubs as well?) Yes, except that BIP32-hierarchy and BIP44

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

2015-02-05 Thread Andreas Schildbach
Thanks Paul, for writing up your protocol! First thoughts: For a BIP standard, I think we should skip bitcoin: URIs entirely and publish BIP70 payment requests instead. URIs mainly stick around because of QR codes limited capacity. BIP70 would partly address the copycat problem by signing

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

2015-02-06 Thread Andreas Schildbach
On 02/06/2015 01:36 AM, Eric Voskuil wrote: The main advantage of BLE over BT is that it uses much less power, with a trade-off in lower bandwidth (100 kbps vs. 2 mbps). The BLE range can be even greater and connection latency lower than BT. For payment purposes the lower bandwidth isn't much

Re: [Bitcoin-development] Export format for xpub

2015-02-03 Thread Andreas Schildbach
On 02/03/2015 10:33 AM, Levin Keller wrote: Why not have more descriptive parameters? Saving on data? Yes. QR codes are very size sensitive. -- Dive into the World of Parallel Programming. The Go Parallel Website,

Re: [Bitcoin-development] Export format for xpub

2015-02-03 Thread Andreas Schildbach
On 02/03/2015 01:22 AM, Pavol Rusnak wrote: Hm, let me put the questions the other way around: What gap limit should a wallet use if it encounters h=bip32? It should follow the spec. I know BIP32-hierarchy is short on gap limits, which is why (amongst other reasons) I expect

Re: [Bitcoin-development] Export format for xpub

2015-02-03 Thread Andreas Schildbach
On 02/03/2015 11:10 AM, Pavol Rusnak wrote: Another option that might make sense is the block number. Not really IMHO. Keys can be used on multiple blockchains. -- Dive into the World of Parallel Programming. The Go

Re: [Bitcoin-development] Electrum 2.0 has been tagged

2015-03-12 Thread Andreas Schildbach
Thanks Thomas, for sharing your experience! I'd like know why you think it's a problem that BIP43 is tied to BIP32? I understand we all agreed at least on the BIP32-derivation spec (excluding the BIP32-hierarchy spec)?

Re: [Bitcoin-development] Electrum 2.0 has been tagged

2015-03-12 Thread Andreas Schildbach
For reasonably skilled users your points are valid, but I'm sure you also – like me – encountered the kind of user who has absolutely no clue but thinks he understands. S/he will ignore warnings and run into troubles. This generates a huge amount of support cases and likely tears about lost coins.

Re: [Bitcoin-development] Electrum 2.0 has been tagged

2015-03-12 Thread Andreas Schildbach
Thy, your message threading is broken. Can you make sure your mail program uses the correct message ID when replying? -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and

Re: [Bitcoin-development] Electrum 2.0 has been tagged

2015-03-12 Thread Andreas Schildbach
That doesn't work for mobile wallets, because we need to consider the offline case. To fix this, we'd need to extend BIP70 to tell the merchant where to forward the half-signed transaction to. Then again I'm not sure if we want that, for privacy reasons. In any case, practical multisig is still a

Re: [Bitcoin-development] Electrum 2.0 has been tagged

2015-03-12 Thread Andreas Schildbach
On 03/12/2015 01:11 AM, Gregory Maxwell wrote: Ultimately, the most fundamental compatibility is guaranteed: you can always send your funds to another wallet. This always works and guarantees that you are never locked in to a single wallet. It is well tested and cannot drive any software in

Re: [Bitcoin-development] Electrum 2.0 has been tagged

2015-03-12 Thread Andreas Schildbach
On 03/12/2015 07:27 PM, Natanael wrote: Den 12 mar 2015 17:48 skrev Mike Hearn m...@plan99.net mailto:m...@plan99.net: b) Creation date is just a short-term hack. I agree, but we need things to be easy in the short term as well as the long term :) The long term solution is clearly to

Re: [Bitcoin-development] Electrum 2.0 has been tagged

2015-03-01 Thread Andreas Schildbach
Congrats on the release! Electrum is a very nice wallet. On 03/01/2015 04:23 PM, Thomas Voegtlin wrote: Dear Bitcoin devs, I just tagged version 2.0 of Electrum: https://github.com/spesmilo/electrum/tree/2.0 The electrum.org website will be updated later today. The release notes are a

  1   2   >