I know that general approach to interaction design in Bitcoin assumes
minimal to no difference between payer and payee, and generally I agree
with this approach.
However, for the sake of my PoS development this assumption is wrong by
default, as PoS is a specialized hardware, and one who cared to b
Am 22.03.2014 18:03, schrieb Mike Hearn:
> In case you didn't see this yet,
>
> http://gavintech.blogspot.ch/2014/03/it-aint-me-ive-got-pgp-imposter.html
>
> If you're using PGP to verify Bitcoin downloads, it's very important
> that you check you are using the right key. Someone seems to be crea
On 3/22/14, Peter Todd wrote:
> Well remember that my thinking re: UTXO is that we need to move to a
> system like TXO commitments where storing the entirety of the UTXO set
> for all eternity is *not* required. Of course, that doesn't necessarily
> mean you can't have the advantages of UTXO commi
On Sat, Mar 22, 2014 at 02:53:41PM +0100, Jorge Timón wrote:
> On 3/22/14, Peter Todd wrote:
> > There's been a lot of recent hoopla over proof-of-publication, with the
> > OP_RETURN length getting reduced to a rather useless 40 bytes at
> > the last minute prior to the 0.9 release.
>
>
> I'm n
On Sat, Mar 22, 2014 at 10:08:36AM -0500, Troy Benjegerdes wrote:
> On Sat, Mar 22, 2014 at 04:47:02AM -0400, Peter Todd wrote:
> > There's been a lot of recent hoopla over proof-of-publication, with the
> > OP_RETURN length getting reduced to a rather useless 40 bytes at
> > the last minute prior
On Sat, Mar 22, 2014 at 06:03:03PM +0100, Mike Hearn wrote:
> In case you didn't see this yet,
>
> http://gavintech.blogspot.ch/2014/03/it-aint-me-ive-got-pgp-imposter.html
>
> If you're using PGP to verify Bitcoin downloads, it's very important that
> you check you are using the right key. Someo
On Sat, Mar 22, 2014 at 1:03 PM, Mike Hearn wrote:
> do we codesign the Windows binaries?
Yes, the -setup.exe installers are Authenticode (or whatever Microsoft is
calling that these days) code-signed.
--
--
Gavin Andresen
--
I think it's mostly a UI issue. The recipient needs to understand that what
he received is nothing more than an IOU that can be revoked at any time. If
the UI makes it clear and the user trusts the sender, no problem. BIP70
would work as before.
On Sat, Mar 22, 2014 at 6:24 PM, Jeff Garzik wrote
One participant, yes. Two participants lacking net would require a
serious revisit of BIP 70's security assumptions and some design, at a
minimum.
On Sat, Mar 22, 2014 at 12:55 PM, Mark Friedenbach wrote:
> Jeff, there are *plenty* of places that lack local Internet access for
> one or both part
Jeff, there are *plenty* of places that lack local Internet access for
one or both participants.
Obviously making the case where both participants lack access to the
bitcoin network is difficult to secure, but not impossible (e.g. use a
telephany-based system to connect to a centralized double-spe
Please, by all means: ignore our well-reasoned arguments about
externalized storage and validation cost and alternative solutions.
Please re-discover how proof of publication doesn't require burdening
the network with silly extra data that must be transmitted, kept, and
validated from now until the
In case you didn't see this yet,
http://gavintech.blogspot.ch/2014/03/it-aint-me-ive-got-pgp-imposter.html
If you're using PGP to verify Bitcoin downloads, it's very important that
you check you are using the right key. Someone seems to be creating fake
PGP keys that are used to sign popular piec
>
> Those locations are completely unsuitable to bitcoin transactions,
> since the receiver cannot verify double-spending or anything else
> about the transaction.
The usual issue is that they lack internet *for some customers*. The place
may well have private wifi or hardwired connections that w
Let's not pull out silly examples. Of course you can find locations
that lack Internet.
Those locations are completely unsuitable to bitcoin transactions,
since the receiver cannot verify double-spending or anything else
about the transaction.
On Fri, Mar 21, 2014 at 9:59 AM, Alex Kotenko wrot
On Sat, Mar 22, 2014 at 04:47:02AM -0400, Peter Todd wrote:
> There's been a lot of recent hoopla over proof-of-publication, with the
> OP_RETURN length getting reduced to a rather useless 40 bytes at
> the last minute prior to the 0.9 release. Secondly I noticed a
> overlooked security flaw in th
On 3/22/14, Peter Todd wrote:
> There's been a lot of recent hoopla over proof-of-publication, with the
> OP_RETURN length getting reduced to a rather useless 40 bytes at
> the last minute prior to the 0.9 release.
I'm not against about miners accepting transactions that have longer
data in no
There's been a lot of recent hoopla over proof-of-publication, with the
OP_RETURN length getting reduced to a rather useless 40 bytes at
the last minute prior to the 0.9 release. Secondly I noticed a
overlooked security flaw in that OP_CHECKMULTISIG sigops weren't taken
into account, making it pos
17 matches
Mail list logo
