[Bitcoin-development] Modularizing Bitcoin

[bitcoingrant]

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 work 
together towards developing a smarter, more efficient system of tomorrow, today.
Up for grabs: 500 bitcoins or $500,000; whichever is greater.
Taking on a project of this scope is a highly intensive, technical undertaking 
and we believe excellent developers should be compensated as such, especially 
when it comes to open source projects.
One of the main goals will be to separate the wallet from the node, as we have 
already done with mining. This way, the wallet, which will only hold private 
keys and create transactions, would pass transactions directly to a relay node, 
based on the bloom filter. Meanwhile, the block node will maintain the block 
chain and validate and relay new blocks.
Such developments would significantly strengthen the system. Modularization 
would make cancer attacks less likely and increase the node count, which, 
currently, is fairly low.
This is by no means is a feature request, merely ideas as to initiate a 
discussion. We welcome any feedback or suggestions. And of course, let us know 
if you would like to contribute to this project by submiting a grant proposal.
http://bitcoingrant.org http://bitcoingrant.org/&lang=en
--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Modularizing Bitcoin

[Addy Yeow]

> 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 PM,   wrote:
> 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
> work together towards developing a smarter, more efficient system of
> tomorrow, today.
>
> Up for grabs: 500 bitcoins or $500,000; whichever is greater.
>
> Taking on a project of this scope is a highly intensive, technical
> undertaking and we believe excellent developers should be compensated as
> such, especially when it comes to open source projects.
>
> One of the main goals will be to separate the wallet from the node, as we
> have already done with mining. This way, the wallet, which will only hold
> private keys and create transactions, would pass transactions directly to a
> relay node, based on the bloom filter. Meanwhile, the block node will
> maintain the block chain and validate and relay new blocks.
>
> Such developments would significantly strengthen the system. Modularization
> would make cancer attacks less likely and increase the node count, which,
> currently, is fairly low.
>
> This is by no means is a feature request, merely ideas as to initiate a
> discussion. We welcome any feedback or suggestions. And of course, let us
> know if you would like to contribute to this project by submiting a grant
> proposal.
>
> http://bitcoingrant.org
>
>
>
>
>
> --
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Modularizing Bitcoin

[bitcoingrant]

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 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?
--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Modularizing Bitcoin

[Addy Yeow]

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 Thu, May 16, 2013 at 8:48 PM,   wrote:
> 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 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?
>

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Service bits for pruned nodes

[Ricardo Filipe]

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 specifically for a DHT, if publicity is a
problem. There are many DHT proposals and implementations, and i bet
one of them should be more suitable to the bitcoin network than
bittorrent's.

>On Sun, Apr 28, 2013 at 9:29 AM, Mike Hearn  wrote:
>> I'd imagined that nodes would be able to pick their own ranges to keep
>> rather than have fixed chosen intervals. "Everything or two weeks" is rather
>
>X most recent is special for two reasons:  It meshes well with actual demand,
>and the data is required for reorganization.
>
>So whatever we do for historic data, N most recent should be treated specially.
>
>But I also agree that its important that  be splittable into ranges
>because otherwise when having to choose between serving historic data
>and— say— 40 GB storage, a great many are going to choose not to serve
>historic data... and so nodes may be willing to contribute 4-39 GB storage
>to the network there will be no good way for them to do so and we may end
>up with too few copies of the historic data available.
>
>As can be seen in the graph, once you get past the most recent 4000
>blocks the probability is fairly uniform... so "N most recent" is not a
>good way to divide load for the older blocks. But simple ranges— perhaps
>quantized to groups of 100 or 1000 blocks or something— would work fine.
>
>This doesn't have to come in the first cut, however— and it needs new
>addr messages in any case.

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability)

[Adam Back]

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 publication creates quadratic costs in evaluating a private
>clique's claims  so

I believe the coin size and verification cost is linear not quadratic, but
maybe it depends on the parameter you're measuing in.  The coin size is
linear with the number of committed (uncompacted) spends.  You can view
reveals as committed compaction.  For efficiency a recipient of a committed
coin may as well compact and spend in one transaction so no new messages are
created.

Btw I believe if one were concerned about the committed coin size, I can see
a small tweak that would keep the size of the committed coins small eg
256-bit regardless of number of spends (no longer grows), and let the block
store the encrytped & MACed commitment.  Then compaction is no longer a
concern.  However I think that is SPV -> SPV client unfriendly.  (A full
client -> SPV client should still be workable as the full client could
alternatively send the client the MACed data and key, rather than have him
look at it from his block history.)  (Crypto sketch below).

However I am not sure multi-spend committed coin size is really a concern
because to the extent people hold long commitments without revealing to the
network for the long term, that is a bandwidth saving to the network.

Overall about privacy it would be typically temporary, though the peers have
the technical means to react and defend themselves by using longer committed
chains if dishonest mining is detected on a significant scale.

>instead an implementation would make the identities public but only once
>they're burred a bit.

That was the seed idea.  The more aggressive "spend lots of times in
committed form" is just a technical threat that will keep dishonest mining
in check.  By definition the coin is already irrevocably spent before the
reveal (without the threat of having the dishonest miners endlessly redoing
their own deeply burried work).  The only person who could be punished by
policy by >50% dishonest miner (retroactively) is the recipient, not the
spender, and the punishment is very muted: all he can do is prevent coin
compaction.  If the committed coins are small, compact doesnt even hurt the
committed coin user, just network itself.  Therefore a dishonest miner is
wasting his time his dishonesty cant enforce his dishonest policy.

To store the commitments in the block chain replace:

> (blind-sender, auth-tag, tx-commit)
> 
> blind-sender = SHA1( SHA256( 1, pub ) )
> auth = HMAC-SHA256-128( K, tx-commit )
> tx-commit = SHA-256( tx )
> K = SHA-256( pub )

with:

(blind-sender, auth-tag, encrypted-tx-commit)

blind-sender = SHA1( SHA256( 1, pub ) )
auth = HMAC-SHA256-128( K, encrypted-tx-commit )
encrypted-tx-commit = AES( K, tx-commit )   (*)
K = SHA-256( pub )

then a reveal is just to send the recipient the public key (32 bytes)
per hop, still linear but ~3x smaller.

I suggested fixed size committed coin spends, that also you can do but with
public key crypto needed probably, and so dropping to the verification
efficiency of standard transactions.  Sketch 2:

(blind-sender, auth-tag, encrypted-tx-commit)

(pub key P = xG, G = base point)

blind-sender = cP (public key EC multiplied by constant c)
sig = ECDSA( cx, encrypted-tx-commit )
encrypted-tx-commit = AES( K, tx-commit )
K = random

as K is random, knowledge of P if stored unencrypted does not allow
committed spend-to-junk.  To reveal to a recipient just send them P and K at
each hop.  (Same K each time, anyone on the committed coin spend chain can
already chose to reveal at any time so no loss of security.)

You dont need to verify a second signature inside the tx-commit because you
already signed the encrypted-tx which binds to it (encryption with out MAC
is malleable but you cant change it at all without invalidating the
encryption).  Just need to check the input tx in the tx-commit has P as its
recipient.  P does not even need to go into tx-commit as its already bound
by cP and signature security (cant create a signature with someone elses
key).  So I think the commited coins of this form are the same size and
verification cost for the network.  And small and fixed size to spend
offline.  (32+32=64 bytes fixed).

Adam

(*) You should not as a principle re-use keys across algorithms, I omitted a
second key for simplicity.  Really K1 = SHA256( 1||pub ), K2 = SHA256(
2||pub ) encrypted-tx-commit = AES( K1, tx-commit ), auth = HMAC( K2,
encrypted-tx-committ ).  Or more simply a combined authenticated mode like
CCM or GCM and a single key managed by the mode.

--
AlienVault Unified Secu

Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability)

[Adam Back]

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 constant c)
>   sig = ECDSA( cx, encrypted-tx-commit )
>   encrypted-tx-commit = AES( K, tx-commit )
>   K = random
>
>as K is random, knowledge of P if stored unencrypted does not allow
>committed spend-to-junk.  To reveal to a recipient just send them P and K at
>each hop.  (Same K each time, anyone on the committed coin spend chain can
>already chose to reveal at any time so no loss of security.)

Actually same K every time is not so hot, as then earlier in the committed
spend chain, can force a reveal for someone later.  A clearer requirement is
that each person should only be able to reveal committed coin chains up to
the point of their direct involvement.

So that is easily fixable, just include the K for the input committed coin
in the encrypted-tx-commit, as above but:

encrypted-tx-commit = AES( K_i, K_{i-1} || tx-commit )
K_i = random

(different K for each spend).

And actually for symmetric encrypted variant the coin as specified was
already evaluatable with fixed size committed spend (of the last public key)
- I just didnt realize it in the previous mail: the input public key is
necessarily revealed when processing the decrypted tx-commit, allowing
identification and validation of the txin, and validation recursively back
to the first non-committed coin.  With symmetric verification, the
limitation is one-use coin committed addresses (and inability to remove
spend to committed junk with public validation, though there is the tx fee
as a discouragement, it does bloat a recipients verification and so maybe
frustates SPV->SPV consumption of committed coins).

(blind-sender, auth-tag, encrypted-tx-commit)

 blind-sender = SHA1( SHA256( 1, pub ) )
 auth = HMAC-SHA256-128( K, encrypted-tx-commit )
 encrypted-tx-commit = AES( K, tx-commit )
 K = SHA-256( pub )

Adam

ps and it would be better and clearer to read also in terms of purpose of
hashes, to use a KDF like IEEE P1363 KDF2, or PKCS#5 PBKDF2 with 1
iteration, rather than adhoc hashes for key derivation.

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Service bits for pruned nodes

[Jeff Garzik]

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 have more replicas in the network.
>
> You don't need bittorrent specifically for a DHT, if publicity is a
> problem. There are many DHT proposals and implementations, and i bet
> one of them should be more suitable to the bitcoin network than
> bittorrent's.

That's just about the worst thing you could do for bitcoin.  DoS one
part of the DHT, you DoS the entire blockchain by breaking the chain.

-- 
Jeff Garzik
exMULTI, Inc.
jgar...@exmulti.com

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Service bits for pruned nodes

[Ricardo Filipe]

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.

2013/5/16 Jeff Garzik :
> 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 have more replicas in the network.
>>
>> You don't need bittorrent specifically for a DHT, if publicity is a
>> problem. There are many DHT proposals and implementations, and i bet
>> one of them should be more suitable to the bitcoin network than
>> bittorrent's.
>
> That's just about the worst thing you could do for bitcoin.  DoS one
> part of the DHT, you DoS the entire blockchain by breaking the chain.
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgar...@exmulti.com

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Modularizing Bitcoin

[Brenton Camac]

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 diversity of implementations.  Diverse implementations are 
now possible because the correctness of an implementation is now determined 
entirely by the compliance of its external behavior with the stated protocols 
and not its internal design. Thus this approach allows for equivalent but 
alternate implementations. Consequently, this approach -

1. increases the available pool of developers
2. reduces the impact any one implementation defect can have on the overall 
Bitcoin infrastructure
3. allows enhancement/optimization work of modules to proceed more easily as 
coupling with external modules is reduced

Second, and just as important, it allows analysis and critiquing of Bitcoin's 
infrastructure to be undertaken at a higher level than source code: i.e. 
abstract entities of the protocols and APIs.  Such scrutiny is important to 
being able to effectively manage the evolution of a system's architecture.

Its been my first-hand experience across many projects that this strategy 
contributes directly to significant improvements to quality when developing 
large, distributed, complex software systems.  Indeed, its considered a best 
practice when developing enterprise-grade software.

I would be happy to collaborate with others in such an undertaking.

- Brenton



On May 16, 2013, at 3:02 AM, bitcoingr...@gmx.com wrote:

> 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 work 
> together towards developing a smarter, more efficient system of tomorrow, 
> today.
> Up for grabs: 500 bitcoins or $500,000; whichever is greater.
> Taking on a project of this scope is a highly intensive, technical 
> undertaking and we believe excellent developers should be compensated as 
> such, especially when it comes to open source projects.
> One of the main goals will be to separate the wallet from the node, as we 
> have already done with mining. This way, the wallet, which will only hold 
> private keys and create transactions, would pass transactions directly to a 
> relay node, based on the bloom filter. Meanwhile, the block node will 
> maintain the block chain and validate and relay new blocks.
> Such developments would significantly strengthen the system. Modularization 
> would make cancer attacks less likely and increase the node count, which, 
> currently, is fairly low.
> This is by no means is a feature request, merely ideas as to initiate a 
> discussion. We welcome any feedback or suggestions. And of course, let us 
> know if you would like to contribute to this project by submiting a grant 
> proposal.
> http://bitcoingrant.org
>  
> 
>   
> --
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Modularizing Bitcoin

[Mike Hearn]

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 transaction traffic and time spent in the wallet is likely to dominate
only for large merchants or exchanges.

That said, you can already do this today - just run an SPV wallet like
bitcoinj connected to your personal node. The wallet code in bitcoind won't
be used for anything.

There are lots of things that can be done, but the best way to approach
this is to get tightly written technical requirements from people in the
know, and then contract with developers. Bounty style development has the
risk of uncoordinated development that duplicates work and puts pressure on
Gavin or other maintainers to accept shoddy code due to the "first past the
post" winning criteria. Finding developers you trust and contracting with
them for well specified improvements minimises risk for everyone.


On Thu, May 16, 2013 at 3:02 AM,  wrote:

> 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 work together towards developing a smarter, more efficient system of
> tomorrow, today.
>
> Up for grabs: 500 bitcoins or $500,000; whichever is greater.
>
> Taking on a project of this scope is a highly intensive, technical
> undertaking and we believe excellent developers should be compensated as
> such, especially when it comes to open source projects.
>
> One of the main goals will be to separate the wallet from the node, as we
> have already done with mining. This way, the wallet, which will only hold
> private keys and create transactions, would pass transactions directly to a
> relay node, based on the bloom filter. Meanwhile, the block node will
> maintain the block chain and validate and relay new blocks.
>
> Such developments would significantly strengthen the system.
> Modularization would make cancer attacks less likely and increase the node
> count, which, currently, is fairly low.
>
> This is by no means is a feature request, merely ideas as to initiate a
> discussion. We welcome any feedback or suggestions. And of course, let us
> know if you would like to contribute to this project by submiting a grant
> proposal.
>
> http://bitcoingrant.org 
>
>
>
>
>
> --
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development