moneybutton / yours-bitcoin Goto Github PK

See: bitpay/bitcore#309 (comment)

• Greg Maxwell's remarks http://permalink.gmane.org/gmane.comp.bitcoin.devel/2734 (mirror: https://www.mail-archive.com/[email protected]/msg02721.html )
• RFC 6979 http://tools.ietf.org/html/rfc6979
• Bitcoin Talk https://bitcointalk.org/index.php?topic=285142

Support assurance contracts as described on the Contracts page:

• https://en.bitcoin.it/wiki/Contracts#Example_3:_Assurance_contracts

We're using "js standard" to enforce style, which I added only recently. We have 2300+ style issues that cannot be resolved with "standard --format" and thus have to be fixed by hand. We need to fix all of these.

https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki

https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki

See also this update for payment protocol: https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki

It should be possible to run bitcoind locally, establish a p2p connection, and exchange ping/pong messages. This is a prerequisite before being able to exchange other types of messages besides ping/pong.

e.g., a bitcoin/litecoin transaction, described on Contracts page:

• https://en.bitcoin.it/wiki/Contracts

The stealth address code is functional and theoretically should be compatible with dark wallet, but it has not been fully tested. It should be tested, and then support should be added for easily finding and building stealth transactions.

BIP70 and related:

• https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki
• https://github.com/bitcoin/bips/blob/master/bip-0071.mediawiki
• https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki
• https://github.com/bitcoin/bips/blob/master/bip-0073.mediawiki

See forge for x.509 certificate support in the browser:

• https://github.com/digitalbazaar/forge

Another option, although it is massive and hard to audit:

• http://kjur.github.io/jsrsasign/

https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki

...note that as of this writing, BIP65 has not yet been accepted as a standard.

See: bitcoin/bitcoin#6871

We don't yet need to implement all p2p messages, but we do need those that are necessary to download blocks from one known peer. i.e., when you run fullnode and connect to one known bitcoind instance.

Support escrow as described on the Contacts page:

• https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation

A more efficient and private form of multisig.

https://bitcointalk.org/index.php?topic=511074.msg5727641#msg5727641

Howdy Ryan,

I'm working on replacing bitcore with fullnode in bitauth and node-bitpay-client, but it appears that the SIN implementation didn't make the cut for the move from bitcore. It seems that the intent was to do so (reading the README):

Any non-standard features (such as SINs and stealth addresses) are placed in the lib/expmt/ folder and are accessible at fullnode.expmt.

Do you expect to port the bitcore SIN implementation?

It is possible the script interpreter is faulty. In fact, any consensus-critical code may be faulty. This could result in lost funds if someone relied on faulty consensus code that put them on a fork. One way to address this issue is through the use of templates. Allow the script interpreter and other consensus-critical code to be disabled for non-standard transactions. Allow a whitelist of template scripts to constitute standard transactions (similar to or perhaps idential to IsStandard in bitcoin core).

This idea comes from Peter Todd: https://twitter.com/petertoddbtc/status/541018246858960897

It needs to be possible to establish a tcp connection. This will require a connection manager. However, at the current time, we only need to establish one tcp connection to a known peer. We do not (yet) need to worry about managing multiple connections at a time. We also do not need this workin in a browser (yet) - only in node.js.

We need to implement bitcoin-style merkle trees for SPV.

See also this article by Rusty Russel on fees on the context of payment channels and lightning network.

Some of the fullnode dependencies are out of date. I tried updating them, however the tests run much slower after the update (15s instead of 3s in node). We need to figure out why the tests run much slower, and then update the dependencies. The reason probably has something to do with the way I'm wrapping Fedor's crypto. Something has probably changed with his big number and elliptic curve code to make my wrapping code much slower. We need to identify the problem and refactor the fullnode BN and Point classes to not be slow. Or, if that is not the issue, identify what the real issue is and fix it.

My attempt to update dependencies: #27

https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki

Bitcoin Core developers are experimenting with new testnets for segregated witness, which are useful for development. It would be nice if fullnode had support for these other networks. They are now on "segnet4" http://lists.linuxfoundation.org/pipermail/lightning-dev/2016-March/000505.html

Right now the way to test for the browser is either to run gulp to build things and then refresh the mocha tests by hand, or run karma once, both of which are slow. We need to add watchify into the build process and keep karma open, so that you can get continuous feedback on broken tests during the development process. Watchify should run both the browser tests and karma tests.

https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki

For recovering a public key from a signature, not all recovery factors are tested. However, libsecp256k1 has test vectors for this, so that can make it possible to test all recovery factors. See:

https://github.com/bitcoin/secp256k1/blob/master/src/tests.c#L1723

We're using Fedor Indutny's pure-js cryptography both in node and browsers. His code is fast for pure-js code, but would be much faster with libsecp256k1 and other C/C++ crypto in node. Additionally, Fedor's crypto is not very well reviewed and probably contains vulnerabilities that better-reviewed C/C++ code doesn't have. We might even want to consider transpiling C/C++ code for the browser.

Each object should have the ability to perform its operations in a worker. e.g., object.asyncFromBuffer(buf). This would be a better interface that the current form which requires passing in string names of classes. It would also be extremely useful for Datt, because it would allow reusing the worker interface.

Support encrypting and decrypting private keys with BIP38.

https://github.com/bitcoin/bips/blob/master/bip-0038.mediawiki

PeerJS is too large and cumbersome of a dependency that creates problems integrating fullnode into other packages. We should replace PeerJS with simplepeer for Web RTC connections.

https://github.com/feross/simple-peer

https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki

Timing attacks, in a worst case scenario, can be used to recover private keys. See, for instance, this relevant article on timing attacks:

• https://eprint.iacr.org/2011/232.pdf

I have not always had timing attacks in mind when implementing cryptography in fullnode. We should audit all the crypto, most especially ECDSA to ensure the code is resistant to timing attacks.

• Big number comparisons should be constant time.
• Hash number comparisons should be constant time.
• Signing operation should be constant time.

...correctly solving all timing vulnerabilities may require importing and rewriting the elliptic curve code because I have no control over the speed of, say, point multiplication when we use an external library.

Support deposits as described on the Contracts page:

• https://en.bitcoin.it/wiki/Contracts#Example_1:_Providing_a_deposit

There was recently a serious error discovered in one of fullnode's dependencies. See this commit for information:

dbeab00

This reminds us that the cryptography in fullnode, both in the depencies and in the library itself, largely consist of recently-written cryptography that has not been properly audited. This issue is to contain the problem of "auditing the cryptography" and keep track of the progress made on this goal.

First, let's just list the dependencies that need to be audited:

• bn.js
• elliptic (particularly the secp256k1 code)
• hash.js
• aes
• bs58
• pbkdf2-compat
• node-crypto
• browserify-crypto

Second, all of the cryptography in fullnode needs to be audited.

"Auditing" is a somewhat vague goal, but I will propose two passes:

Pass 1: Review every line of source code, identify edge cases, confirm that test vectors exist that test the edge cases, or write new test vectors that test the edge cases. Furthermore, identify all standard test vectors and include those.

Pass 2: Re-implement all of the cryptography a second time, identify edge cases in the new implementation, write tests for them, then confirm that the old code passes the new tests (or fix any issues that arise). If there is reason to believe the new cryptography is better, then replace the old cryptography with the new cryptography.

Both passes should be performed on all cryptography dependencies and for all cryptography directly contained in the library.

We need to be able to verify/validate a transaction in a worker.

See: https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki

BIP62 is about eliminating transaction malleability. Support BIP62 when creating transactions, and also allow transactions to be validated against BIP62.

https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki

PBKDF2 is deliberately designed to be a slow algorithm in order to make password cracking infeasible. However, we have every reason to make our implementation as fast as possible since we have to run it to generate keys and and even more so to run the tests.

There are three elements of slowness in our PBKDF2 algorithm: the PBKDF2 function itself, the HMAC function, and our implementation of SHA512. I made some minor improvements to HMAC which ever so slightly increased the speed. We are currently using the package sha512 for SHA512, so I've also experimented with using different packages for implementing SHA512 which might be faster:

• js-sha512
• sha512crypt-node

Both of those are slightly faster than the sha512 algorithm we're using, but they require minor modifications to work with buffers instead of strings. Another option is to bring the SHA2 family of hash functions, or even all the hash functions, into fullnode so we can control that the interfaces are optimal for this library (particularly using buffers instead of arrays).

See (PDF): http://www.cs.princeton.edu/~stevenag/threshold_sigs.pdf

Blog post: https://freedom-to-tinker.com/blog/stevenag/threshold-signatures-for-bitcoin-wallets-are-finally-here/

https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki

Hello,

This repository is listed on the Awesome Bitcoin list, which is a collection of useful Bitcoin projects. However, it seems that the 'bitcoin' topic is missing from this repository's topics.

Adding the 'bitcoin' topic will help users discover your project more easily and recognize its relevance to the Bitcoin ecosystem. To add the topic, please follow these steps:

1. Navigate to the main page of the repository.
2. Click on the gear icon next to "About" on the right side of the page.
3. In the "Topics" section, type 'bitcoin' and press Enter.
4. Click "Save changes."

Thank you for your attention and for contributing to the Bitcoin community!

Described in example 7 on the Contracts page:

• https://en.bitcoin.it/wiki/Contracts

See also Peter Todd's suggestion of how to do multi-party payment channels:

• http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/20141213023458.GA961%40muck/#msg33144746

Merge avoidance could be supported by both the transaction builder and BIP70 for increased privacy.

See:

• http://bitcoinism.blogspot.com/2013/07/reclaiming-financial-privacy-with-hd.html
• https://medium.com/@octskyward/merge-avoidance-7f95a386692f