I'm all for funding of Bitcoin development, but I suggest talking to Gavin
to find out what efforts would be the biggest win right now. I don't see
why separating wallet code from the main Bitcoin process would increase
node count, as the cost of running the node is almost all in keeping up
with tr
It would be nice if that modularization effort would first and foremost focus
on defining the protocols and APIs of the various modules (their
responsibilities and patterns of interaction), rather than merely refactoring
existing code.
Such an approach has many benefits.
First, it promotes d
Of course.
My proposal was just for the pruned nodes.
I.e. You would have a majority (maybe not even a majority required) of
nodes storing the whole blockchain and pruned nodes would store
"random" parts of the blockchain, according to the resources they
have, which would be organized as a DHT.
20
On Thu, May 16, 2013 at 7:26 AM, Ricardo Filipe
wrote:
> We would only end up with few copies of the historic data if users
> could choose what parts of the blockchain to store. Simply store
> chunks randomly, according to users available space, and give priority
> to the "N most recent" chunks to
More somewhat improved crypto stuff...
On Thu, May 16, 2013 at 01:32:22PM +0200, Adam Back wrote:
>I suggested fixed size committed coin spends [...]
>
>(blind-sender, auth-tag, encrypted-tx-commit)
>
>(pub key P = xG, G = base point)
>
> blind-sender = cP (public key EC multiplied by consta
On Wed, May 15, 2013 at 07:45:34PM -0700, Gregory Maxwell wrote:
>[committed coins] depending on how its done, at most conceals the
>transactions from people who aren't a party to them... though as time goes
>on eventually everyone becomes a party to a sufficiently old coin, and
>avoiding publicat
We would only end up with few copies of the historic data if users
could choose what parts of the blockchain to store. Simply store
chunks randomly, according to users available space, and give priority
to the "N most recent" chunks to have more replicas in the network.
You don't need bittorrent s
Is the number representing the count for the client nodes?
I was curious of the count myself earlier this week and started to
traverse down the network using getaddr message starting from seed
nodes and found upward to 57k nodes running protocol >= 70001 with
timestamp no older than 24 hours.
On
our estimates: ~8000
- Original Message -
From: Addy Yeow
Sent: 05/16/13 06:27 AM
To: bitcoingr...@gmx.com
Subject: Re: [Bitcoin-development] Modularizing Bitcoin
> Such developments would significantly strengthen the system. Modularization
> would make cancer attacks less likely and incr
> Such developments would significantly strengthen the system. Modularization
> would make cancer attacks less likely and increase the node count, which,
> currently, is fairly low.
Do we know for certain or at least a rough figure of the node count in
the network?
On Thu, May 16, 2013 at 8:02
One of the primary upcoming priorities for bitcoin’s infrastructure, beyond the
bloom filter, will be the continued modularization of the system.
Here at the Bitcoin Grant, we would like to jump start this development with a
financial incentive and initiate an ongoing conversation on how we can w
11 matches
Mail list logo
