mirrors/bitcoin-bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2024-11-19 01:40:05 +01:00
Code Issues Projects Releases Wiki Activity

BIPs 30, 32, 62, 66, and 103: License under BSD-2-Clause terms

Browse Source 
[Thursday, January 19, 2017] [7:46:36 PM UTC] <luke-jr> sipa: if you get a minute, can you give me at least a text-"verbal" ACK for some copyright license to put on BIPs 30, 32, 62, 66, and 103 please? is BSD-2-Clause okay?
[Thursday, January 19, 2017] [7:47:01 PM UTC] <sipa>    luke-jr: ACK on 2-clause BSD for 30,32,62,66,103
[Thursday, January 19, 2017] [7:47:13 PM UTC] <sipa>    (and for any other BIPs I contributed to)
This commit is contained in:
Luke Dashjr 2017-01-19 19:55:44 +00:00
parent 872bda33b5
commit 855eb22004
5 changed files with 25 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
bip-0030.mediawiki
View File

@ -8,11 +8,16 @@
Status: Final Status: Final
Type: Standards Track Type: Standards Track
Created: 2012-02-22 Created: 2012-02-22
License: BSD-2-Clause
</pre> </pre>
==Abstract== ==Abstract==
This document gives a specification for dealing with duplicate transactions in the block chain, in an attempt to solve certain problems the reference implementations has with them. This document gives a specification for dealing with duplicate transactions in the block chain, in an attempt to solve certain problems the reference implementations has with them.
==Copyright==
This BIP is licensed under the 2-clause BSD license.
==Motivation== ==Motivation==
So far, the Bitcoin reference implementation always assumed duplicate transactions (transactions with the same identifier) didn't exist. This is not true; in particular coinbases are easy to duplicate, and by building on duplicate coinbases, duplicate normal transactions are possible as well. Recently, an attack that exploits the reference implementation's dealing with duplicate transactions was described and demonstrated. It allows reverting fully-confirmed transactions to a single confirmation, making them vulnerable to become unspendable entirely. Another attack is possible that allows forking the block chain for a subset of the network. So far, the Bitcoin reference implementation always assumed duplicate transactions (transactions with the same identifier) didn't exist. This is not true; in particular coinbases are easy to duplicate, and by building on duplicate coinbases, duplicate normal transactions are possible as well. Recently, an attack that exploits the reference implementation's dealing with duplicate transactions was described and demonstrated. It allows reverting fully-confirmed transactions to a single confirmation, making them vulnerable to become unspendable entirely. Another attack is possible that allows forking the block chain for a subset of the network.

5
bip-0032.mediawiki
View File

@ -14,6 +14,7 @@ RECENT CHANGES:
Status: Final Status: Final
Type: Informational Type: Informational
Created: 2012-02-11 Created: 2012-02-11
License: BSD-2-Clause
</pre> </pre>
==Abstract== ==Abstract==
@ -24,6 +25,10 @@ The specification is intended to set a standard for deterministic wallets that c
The specification consists of two parts. In a first part, a system for deriving a tree of keypairs from a single seed is presented. The second part demonstrates how to build a wallet structure on top of such a tree. The specification consists of two parts. In a first part, a system for deriving a tree of keypairs from a single seed is presented. The second part demonstrates how to build a wallet structure on top of such a tree.
==Copyright==
This BIP is licensed under the 2-clause BSD license.
==Motivation== ==Motivation==
The Bitcoin reference client uses randomly generated keys. In order to avoid the necessity for a backup after every transaction, (by default) 100 keys are cached in a pool of reserve keys. Still, these wallets are not intended to be shared and used on several systems simultaneously. They support hiding their private keys by using the wallet encrypt feature and not sharing the password, but such "neutered" wallets lose the power to generate public keys as well. The Bitcoin reference client uses randomly generated keys. In order to avoid the necessity for a backup after every transaction, (by default) 100 keys are cached in a pool of reserve keys. Still, these wallets are not intended to be shared and used on several systems simultaneously. They support hiding their private keys by using the wallet encrypt feature and not sharing the password, but such "neutered" wallets lose the power to generate public keys as well.

5
bip-0062.mediawiki
View File

@ -10,12 +10,17 @@
Status: Withdrawn Status: Withdrawn
Type: Standards Track Type: Standards Track
Created: 2014-03-12 Created: 2014-03-12
License: BSD-2-Clause
</pre> </pre>
==Abstract== ==Abstract==
This document specifies proposed changes to the Bitcoin transaction validity rules in order to make malleability of transactions impossible (at least when the sender doesn't choose to avoid it). This document specifies proposed changes to the Bitcoin transaction validity rules in order to make malleability of transactions impossible (at least when the sender doesn't choose to avoid it).
==Copyright==
This BIP is licensed under the 2-clause BSD license.
==Motivation== ==Motivation==
As of february 2014, Bitcoin transactions are malleable in multiple ways. This means a (valid) transaction can be modified in-flight, without invalidating it, but without access to the relevant private keys. As of february 2014, Bitcoin transactions are malleable in multiple ways. This means a (valid) transaction can be modified in-flight, without invalidating it, but without access to the relevant private keys.

5
bip-0066.mediawiki
View File

@ -8,12 +8,17 @@
Status: Final Status: Final
Type: Standards Track Type: Standards Track
Created: 2015-01-10 Created: 2015-01-10
License: BSD-2-Clause
</pre> </pre>
==Abstract== ==Abstract==
This document specifies proposed changes to the Bitcoin transaction validity rules to restrict signatures to strict DER encoding. This document specifies proposed changes to the Bitcoin transaction validity rules to restrict signatures to strict DER encoding.
==Copyright==
This BIP is licensed under the 2-clause BSD license.
==Motivation== ==Motivation==
Bitcoin's reference implementation currently relies on OpenSSL for signature validation, which means it is implicitly defining Bitcoin's block validity rules. Unfortunately, OpenSSL is not designed for consensus-critical behaviour (it does not guarantee bug-for-bug compatibility between versions), and thus changes to it can - and have - affected Bitcoin software. Bitcoin's reference implementation currently relies on OpenSSL for signature validation, which means it is implicitly defining Bitcoin's block validity rules. Unfortunately, OpenSSL is not designed for consensus-critical behaviour (it does not guarantee bug-for-bug compatibility between versions), and thus changes to it can - and have - affected Bitcoin software.

5
bip-0103.mediawiki
View File

@ -8,12 +8,17 @@
Status: Draft Status: Draft
Type: Standards Track Type: Standards Track
Created: 2015-07-21 Created: 2015-07-21
License: BSD-2-Clause
</pre> </pre>
==Abstract== ==Abstract==
This BIP proposes a block size growth intended to accommodate for hardware and other technological improvements for the foreseeable future. This BIP proposes a block size growth intended to accommodate for hardware and other technological improvements for the foreseeable future.
==Copyright==
This BIP is licensed under the 2-clause BSD license.
==Motivation== ==Motivation==
Many people want to see Bitcoin scale over time, allowing an increasing number of transactions on the block chain. It would come at an increased cost for the ecosystem (bandwidth, processing, and storage for relay nodes, as well as an impact on propagation speed of blocks on the network), but technology also improves over time. When all technologies depended on have improved as well as their availability on the market, there is no reason why Bitcoin's fundamental transaction rate cannot improve proportionally. Many people want to see Bitcoin scale over time, allowing an increasing number of transactions on the block chain. It would come at an increased cost for the ecosystem (bandwidth, processing, and storage for relay nodes, as well as an impact on propagation speed of blocks on the network), but technology also improves over time. When all technologies depended on have improved as well as their availability on the market, there is no reason why Bitcoin's fundamental transaction rate cannot improve proportionally.