+1 for an error field.
Should the wallet broadcast the transaction to the bitcoin network when it
receives an ACK, or always assume that the merchant server will do that?
On Mon, Jan 27, 2014 at 7:52 AM, Mike Hearn m...@plan99.net wrote:
At the moment there's no way to distinguish between a
27, 2014 at 2:17 PM, Pieter Wuille pieter.wui...@gmail.comwrote:
On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene kgree...@gmail.com wrote:
+1 for an error field.
Agree, I think we need a way for client applications to interpret the
response.
Should the wallet broadcast the transaction
+1 to the idea of recurring payment requests.
Perhaps one way to realize this would be to add an optional URL to the
PaymentRequest object where the next PaymentRequest can be fetched and the
date at which the merchant expects the next payment.
On Mon, Jan 27, 2014 at 6:36 PM, Stephane Brossier
Figured I would have a crack at reviewing this since Mike is out for a bit.
It was great running into you guys at the bitcoin fair in SF! Small world :)
I like how simple this is. You just give it an url to fetch the next
payment request and a date to fetch it.
What should happen if the client
Sending this again and truncating since apparently the message body was too
long.
Thanks for humoring my questions!
I think reporting such errors to the wallet would make complete sense.
However i am not clear why we would a separate url for that?
Hmm, thinking about this more, adding a simple
:
Hi Kevin,
On Feb 11, 2014, at 2:00 AM, Kevin Greene kgree...@gmail.com wrote:
Figured I would have a crack at reviewing this since Mike is out for a
bit. It was great running into you guys at the bitcoin fair in SF! Small
world :)
Indeed! It was great meeting you! It's always nice to meet
Another example use-case to back up devrandom's point is using a twitter
handle as the merchant name. In that example, a 3rd party service hosts
and signs the PaymentRequest, but when someone opens that PaymentRequest in
their wallet, they should know that they are paying the specified twitter
Keep in mind that links don't always come embedded in html. Think of native
mobile apps.
On Sat, Apr 26, 2014 at 10:43 AM, Ross Nicoll j...@jrn.me.uk wrote:
I'd be very cautious of security implications of embedding files into
the payment request. Even file formats one would presume safe,
Bitcoind protects against this by storing the addresses it has learned
about in buckets. The bucket an address is stored in is chosen based on the
IP of the peer that advertised the addr message, and the address in the
addr message itself. The idea is that the bucketing is done in a randomized
way
Also (I am fuzzy on the details for this), Bitcoind will detect when a node
is misbehaving and (I believe) it will blacklist misbehaving nodes for a
period of time so it doesn't continually keep trying to connect to tarpit
nodes, for example.
On Wed, Mar 4, 2015 at 6:13 PM, Kevin Greene kgree
I feel compelled to re-share Mike Hearn's counter-argument *against *
replace-by-fee:
https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d
Please carefully consider the effects of replace-by-fee before applying
Peter's patch.
On Sun, May 3, 2015 at 9:36 PM, Peter Todd p...@petertodd.org
Would SPV wallets have to pay to connect to the network too? From the
user's perspective, it would be somewhat upsetting (and confusing) to see
your balance slowly draining every time you open your wallet app. It would
also tie up outputs every time you open up your wallet. You may go to pay
for
On Mon, Jun 15, 2015 at 8:41 PM, Luke Dashjr l...@dashjr.org wrote:
On Tuesday, June 16, 2015 3:30:44 AM Kevin Greene wrote:
Would SPV wallets have to pay to connect to the network too? From the
user's perspective, it would be somewhat upsetting (and confusing) to see
your balance slowly
? They wouldn't be able to sync the blockchain.
Even if the wallet has a balance, how would the wallet be able to see that
it has UTXO's without the ability to sync with the network for free?
On Mon, Jun 15, 2015 at 8:49 PM, Kevin Greene kgree...@gmail.com wrote:
On Mon, Jun 15, 2015 at 8:41 PM, Luke
This is something you actually don't want. In order to make it as difficult
as possible for an attacker to perform a sybil attack, you want to choose a
set of peers that is as diverse, and unpredictable as possible.
On Mon, May 25, 2015 at 9:37 PM, Matt Whitlock b...@mattwhitlock.name
wrote:
.
On Monday, 25 May 2015, at 9:46 pm, Kevin Greene wrote:
This is something you actually don't want. In order to make it as
difficult
as possible for an attacker to perform a sybil attack, you want to
choose a
set of peers that is as diverse, and unpredictable as possible.
On Mon, May 25
16 matches
Mail list logo
