BIP 0033 - Revision history

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/c134a853a9fc0657/bip-0033.mediawiki

2020-08-02T07:56:21Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/c134a853a9fc0657/bip-0033.mediawiki

← Older revision		Revision as of 07:56, 2 August 2020
Line 9:		Line 9:
	Comments-Summary: No comments yet.		Comments-Summary: No comments yet.
	Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0033		Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0033
	Status: ~~Draft~~		Status: Rejected
	Type: Standards Track		Type: Standards Track
	Created: 2012-05-15		Created: 2012-05-15

2019-09-24T18:00:24Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/b5723035e23896d0/bip-0033.mediawiki

2015-12-29T13:45:37Z

Removing redundant parameter.

2013-12-06T07:50:47Z

Move to github

2013-07-23T13:50:10Z

Abstract

← Older revision		Revision as of 13:50, 23 July 2013
Line 16:		Line 16:
	Bitcoin's blockchain becomes more unwieldy for end users over time, negatively affecting the usability of Bitcoin clients. As it grows, it becomes ever more impractical to deal with on portable devices or low end machines. Several proposals have been put forward to deal with this such as lightweight (headers-only) clients and skipping validation for blocks before the last checkpoint. However these measures are at best stop-gap workarounds to stave off a growing problem.		Bitcoin's blockchain becomes more unwieldy for end users over time, negatively affecting the usability of Bitcoin clients. As it grows, it becomes ever more impractical to deal with on portable devices or low end machines. Several proposals have been put forward to deal with this such as lightweight (headers-only) clients and skipping validation for blocks before the last checkpoint. However these measures are at best stop-gap workarounds to stave off a growing problem.

	This document will examine a proposal which will be termed ''stratized nodes'', a modification ~~off~~ an earlier concept termed ''blockchain service''.		This document will examine a proposal which will be termed ''stratized nodes'', a modification of an earlier concept termed ''blockchain service''.

	== History ==		== History ==

2012-06-29T11:08:50Z

← Older revision		Revision as of 11:08, 29 June 2012
Line 1:		Line 1:
	~~--[[User:Hunter\|Hunter]] ([[User talk:Hunter\|talk]]) 11:07, 29 June 2012 (GMT)~~{{bip}}		{{bip}}

	<pre>		<pre>

2012-06-29T11:07:49Z

Correct BIP number in proposal

← Older revision		Revision as of 11:07, 29 June 2012
Line 1:		Line 1:
	{{bip}}		--[[User:Hunter\|Hunter]] ([[User talk:Hunter\|talk]]) 11:07, 29 June 2012 (GMT){{bip}}

	<pre>		<pre>
	BIP: 31		BIP: 33
	Title: Stratized Nodes		Title: Stratized Nodes
	Author: Amir Taaki <genjix@riseup.net>		Author: Amir Taaki <genjix@riseup.net>

2012-05-16T23:37:36Z

Security

← Older revision		Revision as of 23:37, 16 May 2012
Line 122:		Line 122:
	The concern here is that stratized nodes are at the mercy of blockchain services. This proposal deals with that issue by designing this protocol in such a way that the implementation can resolve the common history between multiple services.		The concern here is that stratized nodes are at the mercy of blockchain services. This proposal deals with that issue by designing this protocol in such a way that the implementation can resolve the common history between multiple services.

	A stratized node will typically connect to 8 blockchain services. It will only accept a output, spend or inventory vector that has been sent by a common subset of all those services (6 in our example). This spreads the risk between all services, and does not make a node vulnerable to any one rogue blockchain service.		A stratized node will typically connect to 8 blockchain services. It will only accept an output, spend or inventory vector that has been sent by a common subset of all those services (6 in our example). This spreads the risk between all services, and does not make a node vulnerable to any one rogue blockchain service.

	== Privacy ==		== Privacy ==

2012-05-15T22:02:01Z

Backwards Compatibility

← Older revision		Revision as of 22:02, 15 May 2012
Line 135:		Line 135:

	== Backwards Compatibility ==		== Backwards Compatibility ==

			This proposal is an addon to the current Bitcoin network, and is completely backwards compatible.

2012-05-15T21:59:50Z

Rationale

← Older revision		Revision as of 21:59, 15 May 2012
Line 129:		Line 129:

	== Rationale ==		== Rationale ==

			NODE_SERVICE does not respond to "getdata" requests by itself (unless used in conjunction with NODE_NETWORK) to prevent starvation attacks. This allows a single trusted NODE_SERVICE architecture (possibly acting as a front-end to multiple backends) to service very many nodes while externalising the costs to the Bitcoin network.

			NODE_STRATIZED tries its best to maintain the facade and help upkeep the Bitcoin network (see relaying), but cannot support "getblocks" as it does not have the entire blockchain.

	== Backwards Compatibility ==		== Backwards Compatibility ==