> I just wish that half as much energy had gone into discussing
> whether we want a 100% supermajority or a 99% supermajority or an
> 80% supermajority, as has gone into discussing whether we want 1MB
> blocks or 8MB blocks or 20MB blocks.
And I understand that Gavin is now proposing that a 75% su
As I've observed before, Gavin originally advocated either a 99% or
100% buy in by miners for a hard fork to trigger.
https://gist.github.com/gavinandresen/2355445
I don't understand why people (Gavin included) now seem to favour a
much more modest supermajority except perhaps that they believe t
On Mon, Jun 01, 2015 at 09:01:49PM +0100, Roy Badami wrote:
> > What do other people think? Would starting at a max of 8 or 4 get
> > consensus? Scaling up a little less than Nielsen's Law of Internet
> > Bandwidth predicts for the next 20 years? (I think predictability
> What do other people think? Would starting at a max of 8 or 4 get
> consensus? Scaling up a little less than Nielsen's Law of Internet
> Bandwidth predicts for the next 20 years? (I think predictability is
> REALLY important).
TL;DR: Personally I'm in favour of doing something relatively
unco
otes to stay on
the blockchain whose hashrate has just dropped two orders of magnitude
- so low that the mean time between blocks is now over 16 hours.
>
> And the march 2013 fork showed that miners upgrade at a different schedule
> than the rest of the network.
> On May 7, 2015 5:44 PM
> On the other hand, if 99.99% of the miners updated and only 75% of
> merchants and 75% of users updated, then that would be a serioud split of
> the network.
But is that a plausible scenario? Certainly *if* the concensus rules
required a 99% supermajority of miners for the hard fork to go ahea
I'd love to have more discussion of exactly how a hard fork should be
implemented. I think it might actually be of some value to have rough
consensus on that before we get too bogged down with exactly what the
proposed hard fork should do. After all, how can we debate whether a
particular hard fo
> In this case there is no need for P2P communication, just pay to an
> address you already have for the other party. If you want to avoid
> address reuse, use stealth addressing.
>
> But yes, if you don't have a stealth address for the other party you can
> certainly communicate in private as pee
For peer-to-peer payments, how common do we think that the payment is
of an ad hoc nature rather than to a known contact?
If I want to pay my friends/colleagues/etc over a restaurant table
there's no reason why I couldn't already have their public keys in my
contact list - then it would be pretty
Personally I like the simplicity of tapping two phones together to
make payment - it should be quicker and easier than scanning QR codes
and it's a trust model that's hard to misunderstand.
Is NFC good enough for that? I fear even with NFC it is possible to
produce a device with longer range than
> Why is this? Well, in most jurisdictions financial laws a custodial
> relationship is defined as having the ability, but not the right, to
> dispose of an asset.
So if I leave my window open while I'm out and there's some cash on my
desk, visible from the street, then every passer by now has a
c
Why would we want to have anything to do with people who are hosting
malware? Or do I misunderstand?
On Sat, Dec 20, 2014 at 08:57:53AM +, Matt Corallo wrote:
> There was recently some discussion around dnsseeds. Currently some
> dnsseeds are getting blocked by ISPs because the hosts they pic
On Tue, Jun 24, 2014 at 10:21:46AM -0400, Jeff Garzik wrote:
> On Tue, Jun 24, 2014 at 9:27 AM, Mike Hearn wrote:
> > Wallets would then be able to persist this data to disk and compete on cool
> > visualisations for how much money you saved over time.
>
> heh, this is a cool idea.
>
> It also
> the SI prefixes. People *do* use 63k USD, $63k, and $3M. I'll be the first
> one
As a counter argument, many sources (including the BBC) abbreviate
million to 'm' (and billion to 'bn'), e.g. $3m, $3bn.
I think any similarity with SI units here is coincidental.
roy
--
> *Extended validation certs*
>
> When a business is accepting payment, showing the name of the business is
> usually better than showing just the domain name, for a few reasons:
>
>1. Unless your domain name *is* your business name like blockchain.info,
>it looks better and gives more in
On Wed, Apr 16, 2014 at 05:20:41PM +0200, Pieter Wuille wrote:
> On Wed, Apr 16, 2014 at 5:12 PM, Kevin wrote:
> > I think we should get to the bottom of this. Should we assume that xp is
> > not secure enough?
>
> Yes.
Do we need a similar warning for OS X 10.6? The EOL of that one is
*far* l
On Mon, Mar 31, 2014 at 01:07:46PM -0400, Jeff Garzik wrote:
> namecoin + SIN[1] or namecoin + PGP identity.
Is namecoin actively maintained these days?
roy
--
___
Bitcoin-de
On Sat, Mar 29, 2014 at 01:42:01PM -0400, Matt Whitlock wrote:
> On Saturday, 29 March 2014, at 5:28 pm, Roy Badami wrote:
> > Right now there are also people simply taking base58-encoded private
> > keys and running them through -split.
> >
> > It has a lot going
Right now there are also people simply taking base58-encoded private
keys and running them through -split.
It has a lot going for it, since it can easily be reassembled on any
Linux machine without special software (B Poettering's Linux command
line implementation[1] seems to be included
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, so it
> >> seems appropriate to pick
On Fri, Mar 21, 2014 at 12:02:44AM +0100, Mike Hearn wrote:
> >
> > It's not unusual, in a face-to-face transaction at a bricks-and-mortar
> > establishment, that you know neither the legal name of the entity
> > running the establishment
>
>
> I'd hope that people can get certs for their actual
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 - you might want to serve unsigned payment requests, but
> still have confidentiality and authenticity for a local face to face
> transaction. The signing and
On Fri, Mar 14, 2014 at 03:05:25PM +0100, Andreas Schildbach wrote:
> btw. None of Bitcoin Wallet's users complained about confusion because
> of the mBTC switch. In contrast, I get many mails and questions if
> exchange rates happen to differ by >10%.
At the moment, I imagine the vast majority of
On Thu, Jan 30, 2014 at 07:03:57PM +0700, Chuck wrote:
> On 1/30/2014 7:02 PM, Pieter Wuille wrote:
> > On Thu, Jan 30, 2014 at 12:59 PM, Mike Hearn wrote:
> >> With the way it works in bitcoinj, the tx is only committed to the wallet
> >> if
> >> the server accepts the Payment message and ACKs i
On Mon, Jan 27, 2014 at 09:11:08AM -0800, Jeremy Spilman wrote:
> On Mon, 27 Jan 2014 03:59:25 -0800, Andreas Schildbach
> 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
On Wed, Jan 15, 2014 at 11:17:33PM +, I wrote:
> How about just calling them 'type S addresses'?
(Assuming they're encoded in such as way that they actually start with 's'.
Otherwise whatever prefix is actually used, obviously.)
with bank routing numbers improves the situation, or
> not...
>
>
> On Wed, Jan 15, 2014 at 6:04 PM, Roy Badami wrote:
> > On Wed, Jan 15, 2014 at 03:44:17PM -0500, Jeff Garzik wrote:
> >> "static address" seems like a reasonable attempt at describing i
On Wed, Jan 15, 2014 at 03:44:17PM -0500, Jeff Garzik wrote:
> "static address" seems like a reasonable attempt at describing intended
> use/direction.
...as opposed to an address configured by DHCP?
More seriously, I don't think a typical user will understand anything from
the phrase "static add
On Mon, Jan 13, 2014 at 04:58:01PM +0100, Mike Hearn wrote:
>
> Signing a payment request for an individual is easy, anyway, depending on
> the kind of ID you want. If you want to sign with an email address, just go
> here with a browser like Chrome/Safari/IE that uses the system keystore:
>
>
> It's not public. When I say "please pay me" I also say "use this
> multiplier".
Sending a "please pay me" message is really great for business
transactions.
But I think the use case that Peter Todd mentions is actually *the*
most important currently under-addresesd use case:
> With stealth ad
On Mon, Jan 13, 2014 at 04:58:01PM +0100, Mike Hearn wrote:
> Signing a payment request for an individual is easy, anyway, depending on
> the kind of ID you want. If you want to sign with an email address, just go
> here with a browser like Chrome/Safari/IE that uses the system keystore:
>
>ht
rOn Mon, Jan 13, 2014 at 08:57:33PM +0100, Mike Hearn wrote:
> >
> > On further reflection, I'm not sure I understand this use case of the
> > payment protocol. Since a PaymentRequest currently contains the
> > Outputs that specify the addresses to send to, reusing a
> > PaymentRequest like this w
> > Likewise, I could attach a payment request to an email and send it to you,
> > and now you can pay me whenever you want forever.
>
> That certainly sounds like a plausible use case. You do still have
> the problem that e-mail is an insecure channel, but it's no worse than
> exchanging Bitcoin
On Mon, Jan 13, 2014 at 01:52:25AM -0800, Gregory Maxwell wrote:
> On Sun, Jan 12, 2014 at 1:18 PM, Gavin Andresen
> wrote:
> > No, please. Make it easy for non-geeks, extend the payment protocol, or
> > we'll spend the next two years writing code that tries to ignore linebreaks
> > and spaces an
> I was thinking that people could upload a payment protocol file somewhere
> once (like to their personal web page, or shared via dropbox or google
> drive or some custom new pastebin style service), and then just encode a
> regular bitcoin URI into the qrcode on the billboard.
That does require
On Mon, Dec 09, 2013 at 02:55:02PM +, Drak wrote:
> On 9 December 2013 13:52, Roy Badami wrote:
> >
> > On Mon, Dec 09, 2013 at 01:39:51PM +, Drak wrote:
> > > Someone needs to update the bitcoin.org website, it still points
> > downloads
> > >
On Mon, Dec 09, 2013 at 01:39:51PM +, Drak wrote:
> Someone needs to update the bitcoin.org website, it still points downloads
> to 0.8.5
Perhaps because 0.8.6 hasn't been released yet? Or did I miss the
announcement? I think it makes sense that release candidates are not
promoted on bitcoi
> The bitcoin.org domain is controlled by me, Sirius, and an anonymous
> person. Control will not be lost if Sirius becomes unavailable.
I know this will be a controversial viewpoint in some quarters, but
I'm not a fan of anonymity, or of pseudonyms. As far as I know
(please correct me if I'm wro
> > 5) Who controls DNS for it?
>
> I'm not sure we'll get any change on this level. I have no idea if the
> domain is in good hands, except for the fact that nothing bad happened
> thus far. If anything, moving it to core developers (as intended when
> the domain was registered) would make more s
bitrary scripts, messages are handled
> inline, amounts are defined inline. And if you want to rely on the
> payment infrastructure to work, you cannot risk people using the
> old-style static address in the URI.
>
>
>
> On Wed, Aug 7, 2013 at 11:47 PM, Roy Badami wrote:
>
Very brief comment on BIP 72:
I wonder if there should be some discussion included in the
specification as to how the BIP 21 amount, message and label
parameters should be processed when the payment protocol is used.
Presumably amount should be completely ignored? But is the total
amount request
On Thu, Aug 08, 2013 at 07:10:05AM +1000, Gavin Andresen wrote:
> RE: should the customer's machine not broadcast the transaction:
If we're going to allow payments to fail without being broadcast (but
where the wallet can't in general prove that the receiver hasn't seen
the transaction) then I wou
On Wed, Jul 31, 2013 at 05:30:46PM -0600, E willbefull wrote:
> I think it's important to expect PaymentRequest-only bitcoin URIs in the
> future. Some types of payments (exotic transactions) may not make sense to
> have a single fallback address. Or, a page with a bitcoin URI link may be
> relying
On Wed, Jul 31, 2013 at 04:28:25PM +1000, Gavin Andresen wrote:
> I've turned the preliminary payment protocol spec into three BIPs:
>
> https://en.bitcoin.it/wiki/BIP_0070 : Network protocol / messages
> https://en.bitcoin.it/wiki/BIP_0071 : MIME types for the messages
> https://en.bitcoin.it/wik
> Sure they are paying themselves, but given bitcoin network
> difficulty is uso high, simply obtaining payments-go-myself-as-miner
> transactions is itself difficult.
Not for pool operators it isn't. Nor for people buying hashing power
from a GPUMAX-type service, if such services still exist (or
by social engineering,
not by breaking the cyrpto.
roy
On Mon, Apr 01, 2013 at 11:51:07PM +0100, Roy Badami wrote:
> The attack Schneier is talking about is a collision attack (i.e. it
> creates two messages with the same hash, but you don't get to choose
> either of the messages). It
The attack Schneier is talking about is a collision attack (i.e. it
creates two messages with the same hash, but you don't get to choose
either of the messages). It's not a second preimage attack, which is
what you would need to be able to create a message that hashes to the
same value of an exist
On Mon, Mar 25, 2013 at 02:10:53PM -0700, Gregory Maxwell wrote:
> On Mon, Mar 25, 2013 at 1:49 PM, Roy Badami wrote:
> > I'm not envisaging something as drastic as changing the rules to make
> > transactions to revoked addresses invalid - just an overlay protocol.
> >
On Fri, Feb 22, 2013 at 11:08:51PM +, I wrote:
> What would be really nice is for bitcoin to have a big key compromise
> button, which would automatically transfer all coins to newly
> generated addresses (optionally with a pause between generation and
> transaction - to allow for a new wallet
On Wed, Mar 13, 2013 at 02:27:01PM -0700, Gregory Maxwell wrote:
> On Wed, Mar 13, 2013 at 2:22 PM, Roy Badami wrote:
> > The idea of the client detecting/warning about not-trivial forking
> > seems worthwhile too, though, assuming it doesn't already (AIUI it
> > doesn&#
On Wed, Mar 13, 2013 at 09:14:03PM +, Luke-Jr wrote:
> On Wednesday, March 13, 2013 9:06:44 PM Andy Parkins wrote:
> > On Wednesday 13 Mar 2013 12:56:29 Luke-Jr wrote:
> > > Here's a simple proposal to start discussion from...
> >
> > It seems to me that the biggest failure was not the develop
On Wed, Mar 13, 2013 at 07:28:06PM +0100, Pieter Wuille wrote:
> IMHO, the way to go is first get a 0.8.1 out that mimics the old
> behaviour - just as a stopgap solution.
Presumably not emulate too precisely, at least if your initial report
that the block caused 0.7 to 'get stuck' was correct.
> clients are anyway keeping, and re-relaying, their own transactions
> and hence it would mean only little, and only little for clients.
Not all end-user clients are always-on though
--
Symantec Endpoint Protection 12 po
> Would be nice to have a secure page at bitcoin.org, though, rathar
> than having to go to github - certs from somewhere like Namecheap
> should cost you next to nothing.
And Namecheap now accept Bitcoin :-)
(Complete coincidence - I didn't know that when I posted)
roy
> (The reason for this is that (many? most? all?) CAs verify authority
> by having you place a file at some HTTP path on the domain in
> question.
IME most CAs verify by emailing hostmaster/webaster@ or one of the
contacts in the WHOIS. But you're right, still subject to a MitM.
Still better than
On Sat, Mar 02, 2013 at 04:09:38PM -0500, Gavin Andresen wrote:
> My gpg key is on the bitcoin.org homepage:
> http://bitcoin.org/gavinandresen.asc
> which you can access securely (and see the history of) at:
> https://github.com/bitcoin/bitcoin.org/blob/master/gavinandresen.asc
Would be n
Has anyone been thinking about providing tools to allow users to cope
with key compromise - or more generally, to manage key retirement etc?
atm, if you suspect that your keys may be liable to compromise then
what would you have to do? You'd have to create a new wallet (on a
new computer? or is
On Mon, Dec 03, 2012 at 05:34:12PM -0500, Jeff Garzik wrote:
> You shouldn't need to escape and unescape data that is not being
> interpreted in any way.
Funilly enough pretty much all low-level links that make up the
Internet use either bit-stuffing or byte-stuffing to escape a
particular bit seq
On Mon, Dec 03, 2012 at 10:28:13PM +0100, Mike Hearn wrote:
> Witness the absurd design of SMTP that means you can't
> start a paragraph with the word From because that's a new-message
> marker!
Actually that has absolutely nothing to do with SMTP. It's down to
the file format of the standard BSD
On Thu, Nov 29, 2012 at 06:31:24PM +0100, Mike Hearn wrote:
> > I'd still like to understand the rationale for having the merchant
> > broadcast the transaction
>
> There are several reasons for this:
[snip]
All good reasons, thanks for the explanation.
Though I still like my idea of a Validate
I'd still like to understand the rationale for having the merchant
broadcast the transaction - it seems to add complexity and create edge
cases.
How about this as an alternative proposal:
The buyer's client prepares the transaction and computes its txid. It
then sends a ValidatePurchase message
> If a Receipt is not received for any reason (timeout, error) and
> Payment.transactions has not been broadcast by the merchant on the
> Bitcoin p2p network, then the Bitcoin client should assume that the
> payment failed, inform the customer that the payment failed, and
> return coins involved in
62 matches
Mail list logo
