3593 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
Tim Ruffing	63a19990fd	Clarify nonce generation ... - Separate nonce generation into getting a random byte string and converting it to a suitable scalar ... - ... to make clear that the byte string can be generated differently. - Make the warning a little bit more prominent and improve writing	2020-01-03 12:36:25 +01:00
Luke Dashjr	24eddbb48a	Merge pull request #869 from benthecarman/patch-2 ... BIP 174: Specify that separator only appears at end of the map	2020-01-03 04:31:58 +00:00
Luke Dashjr	ed3b31c136	Merge pull request #870 from dgpv/patch-10 ... BIP-174: add missing types to Appendix A; fix proprietary type names	2020-01-03 04:31:45 +00:00
Pieter Wuille	1d2166edc9	Merge pull request #183 from sipa/201912_authors ... Update authors	2019-12-19 12:41:43 -05:00
Pieter Wuille	ded38826ce	Merge pull request #167 from stefanwouldgo/patch-4 ... more precise wording: limits on tx+block size -> block weight limit	2019-12-19 12:41:25 -05:00
stefanwouldgo	3318d707e1	more precise wording on limits ... there are no tx or block size limits (post-Segwit), just block weight limit better wording	2019-12-19 12:10:56 +01:00
Pieter Wuille	17b3f9e01a	Update Post-History field for taproot/tapscript	2019-12-17 17:27:36 -08:00
Pieter Wuille	b90b53cd17	Update authors	2019-12-17 17:27:22 -08:00
Pieter Wuille	cb187012b6	Merge pull request #181 from sipa/201912_reorder_motivation ... Restructure motivation/design and add informal summary	2019-12-17 14:31:28 -05:00
Pieter Wuille	b979c47893	Merge pull request #182 from pinheadmz/example1 ... bip-taproot: Explain example from script-tree diagram	2019-12-17 14:30:56 -05:00
Pieter Wuille	882e46350d	Add rationale on security assumptions	2019-12-16 10:52:43 -08:00
Matthew Zipkin	6b42461f8e	bip-taproot: example from diagram	2019-12-16 11:26:54 -05:00
Pieter Wuille	1c163188ee	Add an informal summary of the design	2019-12-15 22:37:22 -08:00
Pieter Wuille	01e5bfbf19	Improve and restructure motivation and design	2019-12-15 13:28:58 -08:00
Pieter Wuille	cb1cec770b	Merge pull request #176 from sipa/201912_linear_is_easy ... Linearity makes sign-for-sum-of-keys easier, not possible entirely.	2019-12-14 16:25:11 -05:00
Pieter Wuille	7c7aead1c1	Merge pull request #179 from real-or-random/patch-14 ... Mention that we don't change the hash function	2019-12-14 16:24:52 -05:00
Pieter Wuille	6b50893798	Merge pull request #178 from sipa/201912_schnorr_consensus_exact ... Consistent validity	2019-12-14 16:24:32 -05:00
Tim Ruffing	ad1eba008c	Update bip-schnorr.mediawiki	2019-12-14 22:11:47 +01:00
Dmitry Petukhov	8faf97e720	BIP-174: add missing types to Appendix A; fix proprietary type names ... PSBT_INPUT_PROPRIETARY -> PSBT_IN_PROPRIETARY PSBT_OUTPUT_PROPRIETARY -> PSBT_OUT_PROPRIETARY to be consistent with other in/out type names that use shortened `IN` and `OUT`	2019-12-14 20:39:40 +05:00
Pieter Wuille	83adab4af9	Update bip-schnorr.mediawiki ... Co-Authored-By: Tim Ruffing <crypto@timruffing.de>	2019-12-13 15:38:15 -08:00
Pieter Wuille	a8ebb65eb1	Linearity makes sign-for-sum-of-keys easier, not possible entirely. ... I'm sure it's possible to construct a complex MPC that can sign for the sum of keys under ECDSA as well.	2019-12-13 15:37:50 -08:00
Pieter Wuille	431ebd2f44	Merge pull request #177 from sipa/201912_lows_ecdsa_nonmalleable ... Low-S ECDSA is non-malleable under nonstandard assumptions	2019-12-13 18:34:31 -05:00
Pieter Wuille	f1380bdc11	Completely specified	2019-12-13 15:31:18 -08:00
Pieter Wuille	40eccd5d3c	Merge pull request #180 from jonasnick/secret-key ... Replace private key with secret key	2019-12-13 17:09:18 -05:00
Luke Dashjr	0a388fac46	Merge pull request #860 from azuchi/fix-wrong-description-bip174 ... BIP174: Fix wrong description about Proprietary Use Type	2019-12-13 16:07:25 +00:00
Luke Dashjr	56fe789358	Merge pull request #866 from dgpv/patch-6 ... BIP174: remove 'first byte is the type' comment for key data	2019-12-13 16:06:41 +00:00
Luke Dashjr	feb5395fe0	Merge pull request #867 from dgpv/patch-7 ... BIP-174: test data: fix value length	2019-12-13 16:06:26 +00:00
Luke Dashjr	675a14b23c	Merge pull request #865 from benthecarman/patch-1 ... BIP 174: Specifiy that the 32 bit ints are unsigned	2019-12-13 16:05:26 +00:00
Jonas Nick	633cca9b1c	Replace private key with secret key	2019-12-13 13:25:16 +00:00
Tim Ruffing	ff2b53737c	Mention that we don't change the hash function	2019-12-13 12:11:50 +01:00
Pieter Wuille	aa18fdb07e	Low-S ECDSA is non-malleable under nonstandard assumptions	2019-12-12 16:26:50 -08:00
Pieter Wuille	993a1ccdf1	Merge pull request #175 from real-or-random/patch-13 ... Clarify why we don't want short hashes	2019-12-12 17:34:53 -05:00
Tim Ruffing	92582c2a33	Clarify why we don't want short hashes ... This is supposed to supersede https://github.com/sipa/bips/pull/158. I tried to say this carefully. I don't think that multiparty signing is in general broken with short hashes. For example the attack in #158 could be avoided by letting everybody not only commit to the nonce but also to the message. It's just that using a collision-resistant hash just eliminates the problem entirely...	2019-12-12 22:49:21 +01:00
Pieter Wuille	b1d93cdd2c	Merge pull request #174 from hebasto/patch-1 ... Fix reference formatting	2019-12-11 20:25:49 -05:00
Pieter Wuille	2d68aea170	Merge pull request #161 from OrfeasLitos/max-sig-unhashed-bytes ... Typo: max bytes hashed for sig is 210	2019-12-11 20:00:02 -05:00
Pieter Wuille	2a2d4231ff	Merge pull request #154 from OrfeasLitos/replace-66-with-146 ... Replace BIP66 link with BIP146	2019-12-11 19:59:33 -05:00
Pieter Wuille	16d34fafa1	Merge pull request #166 from stefanwouldgo/patch-3 ... fix singular/plural ambiguity	2019-12-11 19:59:06 -05:00
Pieter Wuille	4b4c656790	Merge pull request #162 from OrfeasLitos/signing-validation ... Replace signing with signature before validation	2019-12-11 19:58:52 -05:00
Ben Carman	e097b1d38a	BIP 174: Specify that separator only appears at end of the map	2019-12-11 15:53:06 -06:00
Hennadii Stepanov	2e0c9435a8	Fix reference formatting	2019-12-11 15:33:39 +02:00
stefanwouldgo	cc6fa25c79	fix singular/plural ambiguity	2019-12-11 10:30:01 +01:00
Pieter Wuille	4b25ff7b92	Merge pull request #148 from OrfeasLitos/link-implicit-y-proof-sketch ... Link to proof sketch of security of implicit Y	2019-12-10 18:58:28 -05:00
Pieter Wuille	2a738c6956	Merge pull request #165 from OrfeasLitos/wtxid-malleability ... Mention hash_type malleability would change wtxid	2019-12-10 18:54:17 -05:00
Pieter Wuille	9194a7b582	Merge pull request #171 from jonasnick/footnote16 ... Clarify bip-taproot digest difference to bip143 regarding sub-hashes	2019-12-10 18:46:51 -05:00
Pieter Wuille	a9190ff92b	Merge pull request #172 from jonasnick/footnote9 ... Improve clarity of footnotes for lift_x	2019-12-10 18:45:19 -05:00
Pieter Wuille	034e97bd6e	Merge pull request #170 from jonasnick/footnote7 ... Fix footnote 7 and remove references to Euler's criterion	2019-12-10 17:20:22 -05:00
Pieter Wuille	017ca0c69b	Merge pull request #173 from kallerosenbaum/bip-schnorr ... Nits	2019-12-10 17:11:53 -05:00
Kalle Rosenbaum	fd898f118a	Fix @jonasnick's comment	2019-12-10 22:01:43 +01:00
Kalle Rosenbaum	adf4d78e6c	Nits	2019-12-09 21:20:40 +01:00
Dmitry Petukhov	65f0b3dd62	BIP-174: test data: fix value length ... In the test case "Case: PSBT With invalid output witnessScript typed key", after PSBT_OUT_WITNESS_SCRIPT key with garbage data (which ends with `...478ef51309d`, follows value `2b` which would denote the length of the data value of the key. But the length of actual remaining data is only 7 bytes. Thus, an implementation that reads key-value pairs and checks for validity of the key data after it has read the current key-value pair, will not be able to hit the exact condition intended for this test case: extra data within the key itself. This is because such implementation will hit serialization error when it will try to read the data of the value and will get the short read. Reading full key-value pair and then checking key format afterwards is fairly normal thing to do, as the format of the keys with all their meaning is an abstraction of higher level than just the simple key-value serialization format. The proposed change is to replace byte `2b` after the key data to `06` and thus make the value length in the key-value pair valid (not going beyond the end of the data). base64 encoding has been changed accordingly.	2019-12-09 17:30:47 +05:00