profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/gmaxwell/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

sipa/minisketch 239

Minisketch: an optimized library for BCH-based set reconciliation

bbuenz/BulletProofLib 136

Library for generating non-interactive zero knowledge proofs without trusted setup (Bulletproofs)

sipa/bitcoin-net-simul 17

Bitcoin network simulator

gmaxwell/safegcd-bounds 0

Bounds on divsteps iterations in safegcd

gmaxwell/secp256k1 0

Optimized C library for EC operations on curve secp256k1

pull request commentbitcoin/bips

New BIP: PoST Datastore for Advanced Cryptography and Higher Efficiency Mining

Hi @MarcoFalke I do apologize if I do sound a bit salty. I will provide a comments summary in this BIP in regards to the concerns on support levels and insight and clarity on that area. I was hoping however, that you would provide comments in regards to which areas you were looking for more expansions on or comments in regards to the tech. Henceforth, my disparaging remarks in the morning. Best regards, Andrew

Mentors4EDU

comment created time in 39 minutes

pull request commentbitcoin/bips

Add Kalle Alm as BIP editor

ACK f5575fb

jnewbery

comment created time in 40 minutes

push eventBlockstream/satellite

Blockstream Satellite

commit sha 9dc275276394c1a457b225729e4383681e81d687

Check documentation links on CI

view details

push time in 6 hours

pull request commentbitcoin/bips

New BIP: PoST Datastore for Advanced Cryptography and Higher Efficiency Mining

Hi, @MacroFalke I'm more then willing to show this has non-zero support. Many of the comments weren't outright disapprovals but rather concerns. Anyways, I will provide some insights quite soon as a more detailed response in regards to the support levels. Hopefully there will be as valuable as the same person telling me I have zero support in three or four different ways as comments to a GitHub pull request.

Best regards, Andrew

Mentors4EDU

comment created time in 6 hours

push eventsipa/minisketch

Pieter Wuille

commit sha bf49d0c31be8f4a9605f049120f8670196527e8e

Improve MinGW building

view details

Pieter Wuille

commit sha 7e056005cf0c4ce17d3094d1a19fbdf89e5f532f

Hide non-API library symbols

view details

push time in 13 hours

pull request commentbitcoin/bips

New BIP: PoST Datastore for Advanced Cryptography and Higher Efficiency Mining

https://github.com/bitcoin/bips/pull/1084#issuecomment-836393398

The burden is on you (as per BIP 2) to show that this has non-zero support. You can't claim that no one understands this and thus it must be a good start.

Mentors4EDU

comment created time in 13 hours

push eventsipa/minisketch

Pieter Wuille

commit sha b62ada558f04e0000cf6e8d43719d033300f3835

Improve MinGW building

view details

Pieter Wuille

commit sha 9db56abc5ad4e8c0f0ec669a6fff8475fab3729f

Hide non-API library symbols

view details

push time in 13 hours

push eventsipa/minisketch

Pieter Wuille

commit sha e21a46bf1cc47482d9599adfaa027619ee9a1be5

Improve MinGW building

view details

Pieter Wuille

commit sha 9d0e188a3c670b819f8e49adffef65a48e8e0bf2

Hide non-API library symbols

view details

push time in 14 hours

push eventsipa/minisketch

Pieter Wuille

commit sha 59050ef8c4871c0d9ef5fbd8bfeb478ca81be57a

Improve MinGW building

view details

Pieter Wuille

commit sha 04a2fe26b17f0fed94b0d34319a3f4893b9ce598

Hide non-API library symbols

view details

push time in 15 hours

push eventsipa/minisketch

Pieter Wuille

commit sha cdd6d6dc0356e5a8fbabb609dd94483b9effe6ab

Hide non-API library symbols

view details

push time in 15 hours

PR opened xiph/flac

C++11 clang-tidy cleanups

This switches libFLAC++ to use C++11 features.

+356 -389

0 comment

21 changed files

pr created time in 16 hours

PR closed bitcoin-core/bitcoin-devwiki

scr
+21 -0

1 comment

1 changed file

PaschaC420

pr closed time in 16 hours

pull request commentbitcoin-core/bitcoin-devwiki

scr

  • [ ]
PaschaC420

comment created time in 16 hours

PR opened bitcoin-core/bitcoin-devwiki

scr
+21 -0

0 comment

1 changed file

pr created time in 16 hours

pull request commentbitcoin/bips

New BIP: PoST Datastore for Advanced Cryptography and Higher Efficiency Mining

Hi @luke-jr Given that this BIP tackles energy efficiency problems such as the ones seen here, as well as problems related to security from various standpoints that the community is still considering, I feel like as a draft this isn't a bad place to start.

I have already been seeking out feedback from various places. The specifications section has been expanded dramatically as well as other sections.

Please let me know if anything else is needed to otherwise assign a draft number. Thank you for your time.

Mentors4EDU

comment created time in 16 hours

Pull request review commentbitcoin/bips

BIP: Bitcoin Secure Multisig Setup (BSMS)

+<pre>+  BIP: To be determined+  Layer: Applications+  Title: Bitcoin Secure Multisig Setup (BSMS)+  Author: Hugo Nguyen <hugo at nunchuk.io>+          Peter Gray <peter at coinkite.com>+          Marko Bencun <marko at shiftcrypto.ch>+          Aaron Chen <aarondongchen at gmail.com>+          Rodolfo Novak <rodolfo at coinkite.com>+  Comments-Summary: No comments yet.+  Comments-URI:+  Status: Proposed+  Type: Standards Track+  Created: 2020-11-10+  License: BSD-2-Clause+</pre>++==Introduction==++===Abstract===++This document proposes a mechanism to set up multisig wallets securely.++===Copyright===++This BIP is licensed under the 2-clause BSD license.++===Motivation===++The Bitcoin multisig experience has been greatly streamlined under [https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP-0174+(Partially Signed Bitcoin Transaction)]. However, what is still missing is a standardized process for setting up multisig wallets securely across different vendors.++There are a number of concerns when it comes to setting up a multisig wallet:++# Whether the multisig configuration, such as Signer membership, script type, derivation paths and number of signatures required, is correct and not tampered with.+# Whether the keys or the multisig configuration are leaked during the setup.+# Whether the Signer persists the multisig configuration in their respective storage, and under what format.+# Whether the Signer's storage is tamper-proof.+# Whether the Signer subsequently uses the multisig configuration to generate and verify receive and change addresses.++An attacker who can modify the multisig configuration can steal or hold funds for ransom by duping the user into sending funds to the wrong address. An attacker who cannot modify the configuration but can learn about the keys and/or the configuration can monitor transactions in the wallet, resulting in loss of privacy.++This proposal seeks to address concerns #1, #2 and #3: to mitigate the risk of tampering during the initial setup phase, and to define an interoperable multisig configuration format.++Concerns #4 and #5 should be handled by Signers and are out of scope of this proposal.++==Specification==++===Prerequisites===+This proposal assumes the parties in the multisig support [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-0032], [https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki BIP-0322], [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the descriptor language] and [https://tools.ietf.org/html/rfc3686 AES encryption].++===File Extensions===+All descriptor and key records should have a <tt>.bsms</tt> file extension. Encrypted data should have a <tt>.dat</tt> extension.++===Roles===+====Coordinator====++The Coordinator initiates the multisig setup. The Coordinator determines what type of multisig is used and the exact policy script. If encryption is enabled, the Coordinator also distributes a shared secret or shared secrets to the parties involved for secure communication. The Coordinator gathers information from the Signers to generate a descriptor record. The Coordinator distributes the descriptor record back to the Signers.++====Signer====++The Signer is any software or hardware that controls the private keys and can sign using those keys. The Signer is a participating member in the multisig. Its responsibilities include providing its key record -- which contains a public key or an Extended Public Key (XPUB) -- to the Coordinator, verifying that its <tt>KEY</tt> is included in the descriptor record and persisting the descriptor record in its storage.++===Setup Process===++====Round 1====++=====Coordinator=====++* The Coordinator creates a new multisig wallet creation session. The Coordinator constructs the multisig script and its policy parameters, such as the required number of signatures and the total number of Signers (<tt>M</tt> and <tt>N</tt>).+* The session should expire after some time period determined by the Coordinator, e.g., 24 hours. The timeout allows the encryption key to have lower entropy.+* If encryption is enabled, the Coordinator distributes a secret <tt>TOKEN</tt> to each Signer over a secure channel. The Signer can use the <tt>TOKEN</tt> to derive an <tt>ENCRYPTION_KEY</tt>. Refer to the [[#Encryption]] section below for details on the <tt>TOKEN</tt>, the key derivation function and the encryption scheme. Depending on the use case, the Coordinator can decide whether to share one common <tt>TOKEN</tt> for all Signers, or to have one per Signer.+* If encryption is disabled, the <tt>TOKEN</tt> is set to <tt>0x00</tt>, and all the encryption/decryption steps below can be skipped.++=====Signer=====++* The Signer initiates the multisig wallet creation session by setting the <tt>TOKEN</tt>. The Signer derives an <tt>ENCRYPTION_KEY</tt> from the <tt>TOKEN</tt>. The Signer can keep the session open until a different value for the <tt>TOKEN</tt> is set.+* The Signer generates a key record by prompting the user for a multisig derivation path and retrieves the <tt>KEY</tt> at that derivation path. Alternatively, the Signer can choose a path on behalf of the user. If the Signer chooses the path, it should try to avoid reusing <tt>KEY</tt>s for different wallets.+* The first line in the record must be the specification version (<tt>BSMS 1.0</tt> as of this writing). The second line must be the hex-encoded <tt>TOKEN</tt>. The third line must be the <tt>KEY</tt>. The <tt>KEY</tt> is a public key or an XPUB plus the key origin information, written in the descriptor-defined format, i.e.: <tt>[{master key fingerprint}/{derivation path}]{KEY}</tt>. The fourth line is a text description of the key, 80 characters maximum. The fifth line must be a <tt>SIG</tt>, whereas <tt>SIG</tt> is the signature generated by using the private key associated with the public key or XPUB to sign the first four lines. The signature should follow [https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki BIP-0322], legacy format accepted.+* The Signer calculates the Message Authentication Code (<tt>MAC</tt>) for the record. The first 16 bytes of the <tt>MAC</tt> serves as the Initialization Vector (<tt>IV</tt>) for the encryption.+* The Signer encrypts the key record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.+* The Signer encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>.++====Round 2====++=====Coordinator=====++* The Coordinator gathers key records from all participating Signers. The Coordinator verifies that there are exactly <tt>N</tt> unique key records before the wallet setup session expires.+* For each key record, the Coordinator extracts the <tt>MAC</tt> from the data, sets <tt>IV</tt> to the first 16 bytes of the <tt>MAC</tt>, then decrypts the ciphertext using the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.+* The Coordinator verifies that the included <tt>MAC</tt> is valid given the plaintext.+* The Coordinator verifies that the key records have compatible specification versions.+* The Coordinator verifies that the included <tt>SIG</tt> is valid given the <tt>KEY</tt>.+* If all key records look good, the Coordinator fills in all necessary information to generate a descriptor record.+* The first line in the descriptor record must be the specification version (<tt>BSMS 1.0</tt> as of this writing). The second line must be a descriptor or a descriptor template. The third line must be a comma-separated list of derivation path restrictions. The paths must start with <tt>/</tt> and use non-hardened derivation. If there are no template or restrictions, it must say <tt>No path restrictions</tt>. The fourth line must be the wallet's first address. If there are path restrictions, use the first address from the first path restriction.+* The Coordinator calculates the <tt>MAC</tt> for the record. The first 16 bytes of the <tt>MAC</tt> serves as the <tt>IV</tt> for the encryption.. +* The Coordinator encrypts the descriptor record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.+* The Coordinator encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>.+* The Coordinator sends the encrypted descriptor record to all participating Signers.++=====Signer=====++* The Signer imports the descriptor record.+* The Signer extracts the <tt>MAC</tt> from the data, sets <tt>IV</tt> to the first 16 bytes of the <tt>MAC</tt>, then decrypts the ciphertext using the <tt>ENCRYPTION_KEY</tt> (derived from the open session) and <tt>IV</tt>.+* The Signer verifies that the included <tt>MAC</tt> is valid given the plaintext.+* The Signer verifies that it can support the included specification version.+* The Signer verifies that it can support the descriptor or descriptor template.+* The Signer checks that its <tt>KEY</tt> is included in the descriptor or descriptor template, using path and fingerprint information provided. The check must perform an exact match on the <tt>KEY</tt>s and not using shortcuts such as matching fingerprints, which is trivial to spoof.+* The Signer verifies that it is compatible with the derivation path restrictions.+* The Signer verifies that the wallet's first address is valid.+* For confirmation, the Signer must display to the user the wallet's first address and policy parameters, including, but not limited to: the derivation path restrictions, <tt>M</tt>, <tt>N</tt>, and the position(s) of the Signer's own <tt>KEY</tt> in the policy script. The total number of Signers, <tt>N</tt>, is important to prevent a <tt>KEY</tt> insertion attack. The position is important for scripts where <tt>KEY</tt> order matters. When applicable, all positions of the <tt>KEY</tt> must be displayed. The full descriptor or descriptor template must also be available for review upon user request. +* Parties must check with each other that all Signers have the same confirmation (except for the <tt>KEY</tt> positions).+* If all checks pass, the Signer must persist the descriptor record in its storage.++This completes the setup.++===Encryption===++====The Token====+We define three modes of encryption.++# <tt>NO_ENCRYPTION</tt> : the <tt>TOKEN</tt> is set to <tt>0x00</tt>. Encryption is disabled.+# <tt>STANDARD</tt> : the <tt>TOKEN</tt> is a 64-bit nonce.+# <tt>EXTENDED</tt> : the <tt>TOKEN</tt> is a 128-bit nonce.++The <tt>TOKEN</tt> can be converted to one of these formats:+* A decimal number (recommended). The number must not exceed the maximum value of the nonce. +* A mnemonic phrase using [https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP-0039] word list. This would be 6 words in <tt>STANDARD</tt> mode. This encoding is not recommended in <tt>EXTENDED</tt> mode as it can result in potential confusion between seed mnemonics and <tt>TOKEN</tt> mnemonics. +* A QR code.+* Other formats.++The flexibility in the data format allows each Signer to customize the User Experience based on its respective capabilities.++====Key Derivation====+The key derivation function is [https://tools.ietf.org/html/rfc2898 PBKDF2], with PRF = SHA512. Specifically:++<tt>DKey = PBKDF2(PRF, Password, Salt, c, dkLen)</tt>++Whereas:++* PRF = SHA512+* Password = "No SPOF"+* Salt = <tt>TOKEN</tt>+* c = 2048+* dkLen = 256+* DKey = Derived <tt>ENCRYPTION_KEY</tt>++====Encryption Scheme====+The encryption scheme is [https://tools.ietf.org/html/rfc3686 AES-256-CTR].++<tt>MAC = HMAC-SHA256(HMAC_Key, hex-encoded TOKEN || Data)</tt>++<tt>IV = First 16 bytes of MAC</tt>++<tt>Ciphertext = AES-256-CTR-Encrypt(Plaintext, DKey, IV)</tt>++<tt>Plaintext = AES-256-CTR-Decrypt(Ciphertext, DKey, IV)</tt>++Whereas:+* DKey = <tt>ENCRYPTION_KEY</tt>+* HMAC_Key = SHA256(<tt>ENCRYPTION_KEY</tt>)+* Data = the plaintext, e.g. the entire key record in round 1 and the entire descriptor record in round 2++The <tt>MAC</tt> is to be sent along with the key and descriptor record, as specified above. Because it is a <tt>MAC</tt> over the entire plaintext, this is essentially an [https://en.wikipedia.org/wiki/Authenticated_encryption#Encrypt-and-MAC_(E&M) Encrypt-and-MAC] form of authenticated encryption.++===Descriptor Template===+The output descriptor language only supports one-dimensional lists. This proposal introduces a descriptor template to represent multi-dimensional lists:++<tt>XPUB/**</tt>++Whereas <tt>/**</tt> can be replaced by any number of derivation path restrictions.++A descriptor template must be accompanied by derivation path restrictions. Signers should expand the template into concrete descriptors by replacing <tt>/**</tt> with the restrictions.++For example, the following template and derivation path restrictions:+* <tt>wsh(sortedmulti(2,XPUB1/**,XPUB2/**))</tt>+* <tt>/0/*,/1/*</tt>

Had off-thread discussion wiith @dgpv, since this is mainly aesthetic it really doesn't matter which way we go. Let's stick with the current proposal.

hugohn

comment created time in 18 hours

push eventsipa/minisketch

push time in 18 hours

push eventsipa/minisketch

Pieter Wuille

commit sha f68b034dcc35bc5392677c98095ac7aa24ef0927

Improve MinGW building

view details

Pieter Wuille

commit sha b5ac4e8f8d38e6247bdbf9295f4e508c831ffa07

Hide non-API library symbols

view details

Pieter Wuille

commit sha 63c59852e06635ecd05a401127d1d083ee9cafd6

Try without exceptions

view details

push time in 19 hours

push eventsipa/minisketch

Pieter Wuille

commit sha 74c02962e6fc2f8e49c62008b8e5ea293ec5aa66

Improve MinGW building

view details

Pieter Wuille

commit sha 9a6a20516d8d8fbc49a2d057e85108dbec852391

Hide non-API library symbols

view details

push time in 20 hours

push eventsipa/minisketch

Pieter Wuille

commit sha dbfb14a938de3cef26c98a55585ba0a897ef0e13

Improve MinGW building

view details

Pieter Wuille

commit sha 20716caa534578ce47ec6422a5267c8360f3c6a1

Hide non-API library symbols

view details

push time in 21 hours

push eventsipa/minisketch

Pieter Wuille

commit sha c8b335a60eccd113a6620079e544a8d8da1947d5

Hide non-API library symbols

view details

push time in 21 hours

push eventBlockstream/satellite

Blockstream Satellite

commit sha 4008f14e4222725cbc4cc9ef84e1ee962087bd96

Fix broken github page links due to line breaks Some links are breaking on the github page because they span multiple lines. This restriction applies specifically to links referring to other local Markdown pages, which is likely due to some limitation on the page/theme's link parser. For example, anchor links such as "[link](#anchor)" and URL links such as "[link](https://link)" both work normally if broken over multiple lines. In contrast, cross-links to local Markdown pages such as "[link](page.md)" fail if broken over multiple lines. This patch makes sure that the referred internal links are always written on a single line, so that they can be parsed correctly.

view details

Blockstream Satellite

commit sha adf4119e4a35bc98552485e7370a0e04b9d73794

Fix broken/outdated documentation links - Fix some links to pages that don't exist anymore. - Fix links to pages that are not necessarily added to github page or the pdf compilation.

view details

push time in a day

push eventBlockstream/satellite

Blockstream Satellite

commit sha a5ebd5b2ceed0dfded307622bf6bc429235ca12b

Fix broken links on github page Some links are breaking on the github page because they span multiple lines. This restriction applies specifically to links referring to other local Markdown pages, which is likely due to some limitation on the page/theme's link parser. For example, anchor links such as "[link](#anchor)" and URL links such as "[link](https://link)" both work normally if broken over multiple lines. In contrast, cross-links to local Markdown pages such as "[link](page.md)" fail if broken over multiple lines. This patch makes sure that the referred internal links are always written on a single line, so that they can be parsed correctly.

view details

push time in a day

delete branch xiph/opus

delete branch : cmake-android-merge

delete time in a day

push eventxiph/opus

Marcus Asteborg

commit sha dfd6c88aaa54a03a61434c413e30c217eb98f1d5

cmake - add support to run ctest on android #2347 Signed-off-by: Ralph Giles <giles@thaumas.net>

view details

push time in a day

create barnchxiph/opus

branch : cmake-android-merge

created branch time in a day

delete branch xiph/opus

delete branch : whitespace

delete time in a day

push eventxiph/opus

Ralph Giles

commit sha 2985a40afee560dbbbc8dcf63c9eea09b3e2b733

Fix trailing whitespace. This was introduced in February, and fails the corresponding check in gitlab ci runs. Also indent the subsequent lines to match and correct typos. Signed-off-by: Mark Harris <mark.hsj@gmail.com>

view details

push time in a day

push eventxiph/opus

Ralph Giles

commit sha 2985a40afee560dbbbc8dcf63c9eea09b3e2b733

Fix trailing whitespace. This was introduced in February, and fails the corresponding check in gitlab ci runs. Also indent the subsequent lines to match and correct typos. Signed-off-by: Mark Harris <mark.hsj@gmail.com>

view details

push time in a day

push eventxiph/opus

Ralph Giles

commit sha d30d4237bb5595afb9369972cc247892eb11288b

Fix trailing whitespace. This was introduced in February, and fails the corresponding check in gitlab ci runs. Also indent the subsequent lines to match and correct a typo.

view details

push time in a day