* [Bitcoin-development] BIP 33 - Stratized Nodes
@ 2012-05-16 16:34 Amir Taaki
2012-05-16 16:46 ` Mike Hearn
2012-05-16 16:49 ` Peter Vessenes
0 siblings, 2 replies; 6+ messages in thread
From: Amir Taaki @ 2012-05-16 16:34 UTC (permalink / raw)
To: bitcoin-development
Hi,
Please check out my proposal,
https://en.bitcoin.it/wiki/BIP_0033
I want to use the existing Bitcoin protocol to provide this functionality in order to maintain compatibility. This proposal does not affect current Bitcoin clients, but allows the parallel system to operate alongside and sometimes intersect with the main Bitcoin network in a positive way.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] BIP 33 - Stratized Nodes
2012-05-16 16:34 [Bitcoin-development] BIP 33 - Stratized Nodes Amir Taaki
@ 2012-05-16 16:46 ` Mike Hearn
2012-05-16 17:32 ` Amir Taaki
2012-05-16 18:22 ` Jeff Garzik
2012-05-16 16:49 ` Peter Vessenes
1 sibling, 2 replies; 6+ messages in thread
From: Mike Hearn @ 2012-05-16 16:46 UTC (permalink / raw)
To: Amir Taaki; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1684 bytes --]
Thanks for getting this started.
With regards to the specific proposal, I don't believe it's the best option
and still plan to eventually implement the original design outlined more
than a year ago in this thread:
https://bitcointalk.org/index.php?topic=7972.msg116285#msg116285
Namely that you use a new protocol command to set a Bloom filter on a
connection. Only transactions matching that filter will appear in relayed
inventory. Blocks that are requested will arrive as a header plus
transaction/merkle branch pairs. Clients are expected to maintain and track
the block chain as per usual, but instead of downloading the whole chain
and then dropping the irrelevant transactions, that filtering is done
server side. By strengthening or weakening the Bloom filters you can choose
your preferred point on the privacy/bandwidth-usage spectrum. It is a
fairly simple change to the Satoshi and BitcoinJ codebases but still allows
clients to gain confidence in their balance by examining the chain, and
this is true even in the presence of a hijacked internet connection (you
can't trust pending transactions that way, but you can still trust
confirmed transactions).
The filters would be applied to each data block in each script rather than
having a specific knowledge of addresses. In this way you can select for
things like multisig outputs or outputs which don't use addresses / pubkeys
to authenticate.
I could write a BIP for this alternative protocol if somebody else wants to
implement it. I was going to wait until I had time to do both BIP and
implementation, but I think some simple optimizations to BitcoinJ can keep
its performance good enough for the short term.
[-- Attachment #2: Type: text/html, Size: 1910 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] BIP 33 - Stratized Nodes
2012-05-16 16:34 [Bitcoin-development] BIP 33 - Stratized Nodes Amir Taaki
2012-05-16 16:46 ` Mike Hearn
@ 2012-05-16 16:49 ` Peter Vessenes
2012-05-16 17:37 ` Amir Taaki
1 sibling, 1 reply; 6+ messages in thread
From: Peter Vessenes @ 2012-05-16 16:49 UTC (permalink / raw)
To: Amir Taaki; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]
Thanks for this, Amir.
My initial reactions:
1) This is cool and useful (but see 3)
2) This is significantly less secure than validating an entire blockchain;
it's certainly worth working out some use cases here in more detail than
just a sample conversation. More on this below
3) What about discovery? Will a client now have the chance to look for
NODE_STRATIZED clients on IRC? How do you envision a stratized server
decides which transactions to relay/store? Or is it just a caching layer in
front of a high quality blockchain service? If it is just a caching
service, the question of cache hits / misses is an interesting one as well.
4) What are the economic motivations to run a stratized server? Other than
cheating people of course.
5) Seems like a 'send me everything for this source address' is going to
save a lot of roundtrip conversations for what I imagine the most common
request will be.
Inre: majority agreement on transactions, and even balances, it would be
nice to work out some theoretical security / cost / value calculations for
the following scenarios:
Likely value and cost to someone of subverting / lying about
1) An n-confirmation transaction, n > 0
2) A 0 confirmation transaction
3) A NODE_STRATIZED transaction chain for a client with m connections to
NODE_STRATIZED servers
4) An address balance request for a client with m connections to
NODE_BALANCE_INFO (I made this name up) servers
Peter
[-- Attachment #2: Type: text/html, Size: 1681 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] BIP 33 - Stratized Nodes
2012-05-16 16:46 ` Mike Hearn
@ 2012-05-16 17:32 ` Amir Taaki
2012-05-16 18:22 ` Jeff Garzik
1 sibling, 0 replies; 6+ messages in thread
From: Amir Taaki @ 2012-05-16 17:32 UTC (permalink / raw)
To: bitcoin-development
A bloom filter seems like an interesting idea. However this proposal is concerned mainly with the initialisation stage, whereas this bloom filter is for pushed blocks.
This proposal still updates new transactions and blocks in the same way, and it's not inconceivable to later use a bloom filter to make that part more efficient (although it's questionable if pushing this server side would be a good idea as it would now need to track an additional client state).
________________________________
From: Mike Hearn <mike@plan99•net>
To: Amir Taaki <zgenjix@yahoo•com>
Cc: "bitcoin-development@lists•sourceforge.net" <bitcoin-development@lists•sourceforge.net>
Sent: Wednesday, May 16, 2012 5:46 PM
Subject: Re: [Bitcoin-development] BIP 33 - Stratized Nodes
Thanks for getting this started.
With regards to the specific proposal, I don't believe it's the best option and still plan to eventually implement the original design outlined more than a year ago in this thread:
https://bitcointalk.org/index.php?topic=7972.msg116285#msg116285
Namely that you use a new protocol command to set a Bloom filter on a connection. Only transactions matching that filter will appear in relayed inventory. Blocks that are requested will arrive as a header plus transaction/merkle branch pairs. Clients are expected to maintain and track the block chain as per usual, but instead of downloading the whole chain and then dropping the irrelevant transactions, that filtering is done server side. By strengthening or weakening the Bloom filters you can choose your preferred point on the privacy/bandwidth-usage spectrum. It is a fairly simple change to the Satoshi and BitcoinJ codebases but still allows clients to gain confidence in their balance by examining the chain, and this is true even in the presence of a hijacked internet connection (you can't trust pending transactions that way, but you can still trust confirmed transactions).
The filters would be applied to each data block in each script rather than having a specific knowledge of addresses. In this way you can select for things like multisig outputs or outputs which don't use addresses / pubkeys to authenticate.
I could write a BIP for this alternative protocol if somebody else wants to implement it. I was going to wait until I had time to do both BIP and implementation, but I think some simple optimizations to BitcoinJ can keep its performance good enough for the short term.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] BIP 33 - Stratized Nodes
2012-05-16 16:49 ` Peter Vessenes
@ 2012-05-16 17:37 ` Amir Taaki
0 siblings, 0 replies; 6+ messages in thread
From: Amir Taaki @ 2012-05-16 17:37 UTC (permalink / raw)
To: bitcoin-development
> 1) This is cool and useful (but see 3)
> 2) This is significantly less secure than validating an entire blockchain; it's certainly worth working out some use cases here in more detail than just a sample conversation. More on this below
> 3) What about discovery? Will a client now have the chance to look for NODE_STRATIZED clients on IRC? How do you envision a stratized server decides which transactions to relay/store? Or is it just a caching layer in front of a high quality blockchain service? If it is just a caching service, the question of cache hits / misses is an interesting one as well.
Stratized nodes do discovery as normal. Service nodes are explicitly chosen like IRC servers are for IRC clients.
> 4) What are the economic motivations to run a stratized server? Other than cheating people of course.
None. Same as BitTorrent super-nodes, Tor relays or email servers. People don't need economic motivation for everything.
> 5) Seems like a 'send me everything for this source address' is going to save a lot of roundtrip conversations for what I imagine the most common request will be.
That's a bad idea. I prefer to keep each request minimal to prevent resource starvation and simplify the protocol (while shifting the onus onto the client). Also the history can be resolved with multiple services while the data is being downloaded and sorted.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] BIP 33 - Stratized Nodes
2012-05-16 16:46 ` Mike Hearn
2012-05-16 17:32 ` Amir Taaki
@ 2012-05-16 18:22 ` Jeff Garzik
1 sibling, 0 replies; 6+ messages in thread
From: Jeff Garzik @ 2012-05-16 18:22 UTC (permalink / raw)
To: Mike Hearn; +Cc: bitcoin-development
On Wed, May 16, 2012 at 12:46 PM, Mike Hearn <mike@plan99•net> wrote:
> Thanks for getting this started.
>
> With regards to the specific proposal, I don't believe it's the best option
> and still plan to eventually implement the original design outlined more
> than a year ago in this thread:
>
> https://bitcointalk.org/index.php?topic=7972.msg116285#msg116285
>
> Namely that you use a new protocol command to set a Bloom filter on a
> connection. Only transactions matching that filter will appear in relayed
> inventory. Blocks that are requested will arrive as a header plus
> transaction/merkle branch pairs. Clients are expected to maintain and track
> the block chain as per usual, but instead of downloading the whole chain and
> then dropping the irrelevant transactions, that filtering is done server
> side. By strengthening or weakening the Bloom filters you can choose your
> preferred point on the privacy/bandwidth-usage spectrum. It is a fairly
> simple change to the Satoshi and BitcoinJ codebases but still allows clients
> to gain confidence in their balance by examining the chain, and this is true
> even in the presence of a hijacked internet connection (you can't trust
> pending transactions that way, but you can still trust confirmed
> transactions).
Makes sense.
In an idealized model of a client as a set of private keys, they will
want to (a) notice new activity on these keys, (b) notice increased
confidence on existing transactions with those keys [confirmations],
and (c) be able to submit to the network new transactions. Your
proposal covers those bases, I believe.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-05-16 18:22 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-05-16 16:34 [Bitcoin-development] BIP 33 - Stratized Nodes Amir Taaki
2012-05-16 16:46 ` Mike Hearn
2012-05-16 17:32 ` Amir Taaki
2012-05-16 18:22 ` Jeff Garzik
2012-05-16 16:49 ` Peter Vessenes
2012-05-16 17:37 ` Amir Taaki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox