damn he was just on the verge of solving the underlaying problem with Bitcoin
and you interrupted his focus.
On Jun 19, 2015, at 3:55 PM, John Bodeen john-bod...@uiowa.edu wrote:
from their website, humorous bits highlighted
October 14, 2014
In latest Hiatus new, the company has taken
Who is actually planning to move to Bitcoin-XT if this happens?
Just Gavin and Mike?
On Jun 15, 2015, at 6:17 PM, Faiz Khan faizkha...@gmail.com wrote:
I'm quite puzzled by the response myself, it doesn't seem to address some of
the (more serious) concerns that Adam put out, the most
That was easy.
On Apr 7, 2015, at 5:49 PM, Jean-Paul Kogelman jeanpaulkogel...@me.com
wrote:
Ok, false alarm. :)
Sorry for the spam.
On Apr 07, 2015, at 02:37 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
On Tue, Apr 7, 2015 at 9:32 PM, Jean-Paul Kogelman
Damn if SPKI had won out we would be parsing S-expressions instead of X.509
certificates. ASN.1 is not fun IMHO.
On Jan 19, 2015, at 3:56 PM, Gavin Andresen ga...@bitcoinfoundation.org
wrote:
On Mon, Jan 19, 2015 at 3:40 PM, Mike Hearn m...@plan99.net wrote:
OK, I guess we can boil this
I would agree that the in person aspect of the WoT is frustrating, but to
dismiss this as geek wanking is the pot calling the kettle.
The value of in person vetting of identity is undeniable. Just because your
risk acceptance is difference doesn't make it wanking. Please go see if you can
get
. _That_ is the relevant fingerprint.
Governmental id is second class, can be forged or simply present a
different individual from that who is online. PGP WoT wanking does
not solve that problem at all.
On Mon, Sep 15, 2014 at 9:32 AM, Brian Hoffman brianchoff...@gmail.com
wrote:
I
So my question to the community is, how invasive is this to bitcoin's
source code?
I'd say not very considering you have regression testing mode.
On Thu, Apr 17, 2014 at 8:25 AM, Jorge Timón jti...@monetize.io wrote:
I'm implementing a new testing mode that produces blocks
periodically. You
This is probably just noise, but what if nodes could compress and store
earlier transaction sets (archive sets) and serve them up conditionally. So
if there were let's say 100 archive sets of (10,000 blocks) you might have
5 open at any time when you're an active archive node while the others sit
Looks like only about ~30% disk space savings so I see your point. Is there
a critical reason why blocks couldn't be formed into superblocks that are
chained together and nodes could serve a specific superblock, which could
be pieced together from different nodes to get the full blockchain? This
Okay...will let myself out now ;P
On Thu, Apr 10, 2014 at 12:54 PM, Ricardo Filipe
ricardojdfil...@gmail.comwrote:
that's what blockchain pruning is all about :)
2014-04-10 17:47 GMT+01:00 Brian Hoffman brianchoff...@gmail.com:
Looks like only about ~30% disk space savings so I see your
*beneficial* thoughts in the future!
On Thu, Apr 10, 2014 at 12:59 PM, Pieter Wuille pieter.wui...@gmail.comwrote:
On Thu, Apr 10, 2014 at 6:47 PM, Brian Hoffman brianchoff...@gmail.com
wrote:
Looks like only about ~30% disk space savings so I see your point. Is
there
a critical reason why blocks
How would this affect the user in terms of disk storage? They're going to
get hammered on space constraints aren't they? If it's not required how
likely are users to enable this?
On Wed, Apr 9, 2014 at 11:29 AM, Wladimir laa...@gmail.com wrote:
Hello,
This is primarily aimed at developers of
12 matches
Mail list logo
