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
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
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
mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Why do you want to punish pools?
--
Kevin
--
HPCC Systems Open Source Big Data Platform from
am not sure much could be done. That's just me.
--
Kevin
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three
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,
?
--
Kevin
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your
get to the bottom of this. Should we assume that xp
is not secure enough? What is this warning? Who is issuing this warning?
--
Kevin
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases
On 4/16/2014 11:28 AM, Wladimir wrote:
On Wed, Apr 16, 2014 at 5:20 PM, Pieter Wuille
pieter.wui...@gmail.com mailto:pieter.wui...@gmail.com wrote:
On Wed, Apr 16, 2014 at 5:12 PM, Kevin kevinsisco61...@gmail.com
mailto:kevinsisco61...@gmail.com wrote:
I think we should get
On Apr 16, 2014, at 8:42 PM, Roy Badami r...@gnomon.org.uk wrote:
On Wed, Apr 16, 2014 at 05:20:41PM +0200, Pieter Wuille wrote:
On Wed, Apr 16, 2014 at 5:12 PM, Kevin kevinsisco61...@gmail.com wrote:
I think we should get to the bottom of this. Should we assume that xp is
not secure enough
personally like the ida. Are you talking about a flag that could
toggle this in the background mode or recoding for in the background use?
--
Kevin
--
Put Bad Developers to Shame
Dominate Development with Jenkins
On 4/2/2014 9:08 AM, Jeff Garzik wrote:
At first, this is a poor choice of URL.
But it really looks like a phishing attempt that no one should visit.
On Tue, Apr 1, 2014 at 4:00 PM, Kevin kevinsisco61...@gmail.com wrote:
I've sat on this for some time after starting this. I have forked
On 4/2/2014 11:13 AM, Laszlo Hanyecz wrote:
Maybe this site serves up exploits selectively? I'm guessing most people are
getting the 'domain for sale' but whoever is the target probably gets
something special?
On Apr 2, 2014, at 2:53 PM, Kevin kevinsisco61...@gmail.com wrote:
On 4/2/2014
On 4/2/2014 11:45 AM, Ricardo Filipe wrote:
Kevin,
the thing is you gave us a bad link... what is the correct URL of your
project?
2014-04-02 16:30 GMT+01:00 Kevin kevinsisco61...@gmail.com:
On 4/2/2014 11:13 AM, Laszlo Hanyecz wrote:
Maybe this site serves up exploits selectively? I'm
On 4/2/2014 12:55 PM, Jud wrote:
Looks like Kevin was probably trying to point us to his fork for comments:
https://github.com/kjsisco/bitcoin/tree/patch-1
--
Jud
On Wednesday, April 2, 2014 at 12:45 PM, Laszlo Hanyecz wrote:
Maybe he has a fork on the real github.com http://github.com
at it, and let's have an open dialog about it. I want to know the
good, the bad, and the ugly!
--
Kevin
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
How can we patch this issue?
--
Kevin
--
Subversion Kills Productivity. Get off Subversion Make the Move to Perforce.
With Perforce, you
Hello. How would I submit a patch? Could it be sent through the list
as an attachment?
--
Kevin
--
Subversion Kills Productivity. Get off Subversion Make the Move to Perforce.
With Perforce, you get hassle-free
Hello. I am a developer and I wish to contribute to bitcoin. Where is
the best place to start?
--
Kevin
--
Subversion Kills Productivity. Get off Subversion Make the Move to Perforce.
With Perforce, you get hassle
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
:
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
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
+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
31 matches
Mail list logo
