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
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 th
I somehow think that it is too early for this heavy kind of extension,
given that the first version of BIP70 isn't even deployed widely let
alone *used*.
By reading your proposal I get the idea that the current spec doesn't
allow two (or three) different PKIs at once -- we would want this for
migr
/wiki/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
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
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
llet/commits/v3.32
Binaries:
https://github.com/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 fil
Have a look at my post "Payment Protocol for Face-to-face payments". In
short: I implemented BIP70 using combinations of either QR-code or NFC
plus Bluetooth. You can download a working preview app from:
https://github.com/schildbach/bitcoin-wallet/releases/tag/v3.30-bitcoinj0.11
On 02/03/2014 0
ies:
https://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&
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
On 01/27/2014 02:11 PM, Mike Hearn wrote:
> I would like to see Bluetooth continue to work for scan-to-pay even in
> the signed case. So for this reason the current approach with a BTMAC
> parameter in the Bitcoin URI seems to work universally across NFC tags
> and QR codes, and would allow downlo
On 01/27/2014 06:11 PM, Jeremy Spilman wrote:
>> SCAN TO PAY
>> For scan-to-pay, the current landscape looks different. I assume at
>> least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
>> into a QR-code. Nevertheless, I tried to encode a payment request into
>> the bitcoin URL
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
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
ship 0.9rc1 soonish .
>
>
> On Sun, Jan 26, 2014 at 10:32 PM, Andreas Schildbach
> mailto:andr...@schildbach.de>> wrote:
>
> Bluetooth, Wifi Direct, HTTP request/responses via broken proxies, smoke
> signals... basically anything that is a stream rather th
The BIP70 is very brief on what a PaymentACK is supposed to mean. Quote:
"it [PaymentACK] is sent from the merchant's server to the bitcoin
wallet in response to a Payment message"
Does it simply mean we received a syntactically correct Payment message?
Does it mean the Payment is valid?
Does it
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
> mailto:andr...@schildbach.de>> wrote:
>
> I'
I'm experimenting with BIP70/71 (payment protocol) usage in face to face
payments (more on that soon).
I've excountered an issue with the protobuf format. Protobufs are not
self-delimiting. That means if you're reading from an undelimited
stream, you will read endlessly because you don't know how
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
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 thinki
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 i
On 01/13/2014 05:43 PM, Pieter Wuille wrote:
> As an optimization (and I believe this is what Mike plans to implement
> in BitcoinJ), if a payment_url is present, it should be encouraged to
> only send the payment there, and not broadcast the transaction at all
> on the P2P network (minimizing the
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.
-
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
(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
On 12/01/2013 12:51 PM, Mike Hearn wrote:
> I propose the following plan:
Thanks taking the initiative and writing this up!
> If a wallet gets a reject message for a tx that has a fee that are by
> its own estimates acceptable, what should it do? What if only some nodes
> report that and others
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
On 10/21/2013 04:34 PM, Jeff Garzik wrote:
> I'll volunteer as the BIPS editor.
>
> There needs to be some backups with commit access to bips.git, in case
> the BIPS editor is hit by a bus or goes crazy or on vacation. This
> can be some core devs, but I would like at least one or two folks who
>
On 09/25/2013 01:45 PM, Mike Hearn wrote:
> OK, it might fit if you don't use any of the features the protocol
> provides :)
Now you're dver-dramaticing (-:
I'm just skipping one feature which I think is useless for QR codes
scanned in person.
> You can try it here:
Thanks. A typical request w
is what I'm worrying about. When I'm scanning a QR code
from a phone, you don't 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
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
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 b
On 07/23/2013 11:47 AM, Peter Todd wrote:
>> Is it planned to expose the UXTO set of a given address? That would be
>> useful for SPV wallets to be able to swipe a previously unknown private
>> key (e.g. paper wallet).
>
> The REST API has nothing to do with SPV clients; it's similar to the RPC
>
On 07/23/2013 11:37 AM, Pieter Wuille wrote:
>> Is it planned to expose the UXTO set of a given address? That would be
>> useful for SPV wallets to be able to swipe a previously unknown private
>> key (e.g. paper wallet).
>
> Depends what you mean by expose.
>
> Maintaining an address/script-index
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
u
Android apps do whatever they are programmed to do. They become active
when the user installs and inactive when they are uninstalled.
Inbetween, they are not limited in runtime.
That said, the current programming is that when receiving a block, it
stays connected for at least ~2 more minutes. This
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 wrote
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
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 minin
> I asked Ben to fix this (social networks don't parse QRcodes after
> all), but after explaining that social networks don't parse URLs
> without :// in them, he stopped responding to my emails. So I've gone
> ahead and added support for reading these types of URLs to bitcoinj,
> in the interests o
I'd suggest adding two links for each client.
One for getting the binary, and one for getting the source. (Obviously,
source being optional if you allow non-opensource clients.)
On 07/09/2012 12:44 PM, Amir Taaki wrote:
> OK thanks. I just went and made those sections then saw your posts.
>
> A
On 05/03/2012 11:24 AM, Jorge Timón wrote:
> On 5/3/12, Andreas Schildbach 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
On 05/02/2012 03:22 PM, Mike Hearn wrote:
> We're debating the descriptions on the thread. I provided rewritten
> descriptions that try and keep with the "theme per client" goal, whilst
> being less technical.
Can we add Bitcoin Wallet? I'm not very good at writing descriptions, so
I would just ad
On 05/03/2012 06:28 AM, Alan Reiner wrote:
> *(3) *How are the other clients implementing this? Do you make any
> distinction between "label" and "message"?
Bitcoin Wallet for Android currently ignores both fields. At least
temporarly displaying the transaction message is on my short-term todo l
On 04/14/2012 10:20 PM, Jeff Garzik wrote:
>>> Furthermore, many of these ideas -- like sending TX's directly to the
>>> merchant -- involve far more direct payee<->payer communication on the
>>> part of the wallet client than is currently envisioned
>>
>> Yes, though it's worth remembering that t
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 cha
On 01/31/2012 11:22 AM, Wladimir wrote:
> To ensure forward compatibility with optional fields, we need to define
> how a client handles fields that it doesn't know about.
>
> When should it display an error message, and when should it silently
> accept and ignore the extraneous fields?
IMHO its
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
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
On 09/23/2011 08:09 PM, Gavin Andresen wrote:
> Bitcoin version 0.4.0 is now available for download at:
> http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.0/
Thanks everyone for this great release!
Can you post secure file checksums somewhere, preferably not on Sourceforge?
I
101 - 150 of 150 matches
Mail list logo
