I don't think there's an official definition of SPV proof. I wasn't
trying to make a argument from definition (that would be fallacious!).
Rather I suspected that we had different concepts in mind and wanted to
check.
That said, I do think that the definition I gave matches how the term is
used
Sample terminal output for latest Tails (0.23):
amnesia@amnesia:~/linux-4765b8c-gitian-2d48b96/32$ ./bitcoin-qt
Bus::open: Can not get ibus-daemon's address.
IBusInputContext::createInputContext: no connection to ibus-daemon
sendto: Operation not permitted
Segmentation fault
I'd like to put the following draft of a BIP up for discussion.
Timo
# Abstract
There are incentives for miners to find cheap, non-standard ways to generate
new work, which are not necessarily in the best interest of the protocol.
In order to reduce these incentives this proposal re-assigns 2
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,
On 27 April 2014 09:07, Timo Hanke timo.ha...@web.de wrote:
I'd like to put the following draft of a BIP up for discussion.
Timo
# Abstract
There are incentives for miners to find cheap, non-standard ways to
generate new work, which are not necessarily in the best interest of the
I'm not convinced of the necessity of this idea in general, but if it
were to be implemented I would recommend serializing the nVersion field
as a VarInt (Pieter Wuille's multi-byte serialization format) and using
the remaining space of the 4 bytes as your extra nonce.
That would allow
El 27/04/2014 03:43 a.m., Mark Friedenbach escribió:
I don't think there's an official definition of SPV proof. I wasn't
trying to make a argument from definition (that would be fallacious!).
Rather I suspected that we had different concepts in mind and wanted to
check.
So to disambiguate I
On 27/04/14 11:42, Christophe Biocca wrote: This seems like splitting
hairs, no? A block isn't a guarantee (it can
get orphaned). And as a user of bitcoin (as opposed to a miner), this
change cannot affect any payment you ever receive.
Disagree. Maybe we just have a fundamental disagreement
That moves us away from a pure trustless system built upon a small
democratic foundation (as something of a necessary evil in an imperfect
world where humans run our computers and use our system) and toward a
democratic system.
You don't have to agree, but I hope you can understand the
On 04/27/2014 05:36 AM, Sergio Lerner wrote:
Without invoking moon math or assumptions of honest peers and
jamming-free networks, the only way to know a chain is valid is to
witness the each and every block. SPV nodes on the other hand,
simply trust that the most-work chain is a valid
Agreed. I'm a pragmatist, certainly not anti-change (or even anti-zero-conf.)
Useful and non-controversial hard forks don't keep me awake at night :) I
support your general position on zero-conf payments (that they're useful and we
should make them as reliable as practical.)
But the very
On Sat, Apr 26, 2014 at 6:08 AM, Thomas Voegtlin thoma...@gmx.de wrote:
Perhaps the only thing that needs to be standardized is the order of
public keys in the redeem script: I think they should be sorted, so that
the p2sh address does not depend on the order of pubkeys.
Yes. That solution is
12 matches
Mail list logo
