Nostr notes by

📅 Original date posted:2018-04-06 📝 Original ...

2023-06-07T18:11:32Z

In reply to nevent1q…qmqh
_________________________

📅 Original date posted:2018-04-06
📝 Original message:Source?

On Fri, Apr 6, 2018 at 4:53 PM, ketamine--- via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> A significant number of past and current cryptocurrency products
> contain a JavaScript class named SecureRandom(), containing both
> entropy collection and a PRNG. The entropy collection and the RNG
> itself are both deficient to the degree that key material can be
> recovered by a third party with medium complexity. There are a
> substantial number of variations of this SecureRandom() class in
> various pieces of software, some with bugs fixed, some with additional
> bugs added. Products that aren't today vulnerable due to moving to
> other libraries may be using old keys that have been previously
> compromised by usage of SecureRandom().
>
>
> The most common variations of the library attempts to collect entropy
> from window.crypto's CSPRNG, but due to a type error in a comparison
> this function is silently stepped over without failing. Entropy is
> subsequently gathered from math.Random (a 48bit linear congruential
> generator, seeded by the time in some browsers), and a single
> execution of a medium resolution timer. In some known configurations
> this system has substantially less than 48 bits of entropy.
>
> The core of the RNG is an implementation of RC4 ("arcfour random"),
> and the output is often directly used for the creation of private key
> material as well as cryptographic nonces for ECDSA signatures. RC4 is
> publicly known to have biases of several bits, which are likely
> sufficient for a lattice solver to recover a ECDSA private key given a
> number of signatures. One popular Bitcoin web wallet re-initialized
> the RC4 state for every signature which makes the biases bit-aligned,
> but in other cases the Special K would be manifest itself over
> multiple transactions.
>
>
> Necessary action:
>
> * identify and move all funds stored using SecureRandom()
>
> * rotate all key material generated by, or has come into contact
> with any piece of software using SecureRandom()
>
> * do not write cryptographic tools in non-type safe languages
>
> * don't take the output of a CSPRNG and pass it through RC4
>
> -
> 3CJ99vSipFi9z11UdbdZWfNKjywJnY8sT8
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--
Matías Alejo Garcia
@ematiu
Roads? Where we're going, we don't need roads!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180406/7cdc248c/attachment-0001.html>;

📅 Original date posted:2015-10-05 📝 Original message:Hi, ...

2023-06-07T17:42:22Z

In reply to nevent1q…3uen
_________________________

📅 Original date posted:2015-10-05
📝 Original message:Hi,

Sorry the late response. Going back to the original message:

> > On 03/10/15 13:42, Jean-Pierre Rupp via bitcoin-dev wrote:
> >> I have been reviewing BIP-45 today. There is a privacy problem with it
> >> that should at least be mentioned in the document.
> >>
> >> When using the same extended public key for all multisig activity, and
> >> dealing with different cosigners in separate multisig accounts, reuse of
> >> the same set of public keys means that all cosigners from all accounts
> >> will be able to monitor multisig activity from every other cosigner, in
> >> every other account.
>

I am not completely sure what you mean by 'account' and 'mutisig activity'.
You seem to imply
that the same set of extended public keys will be used in more that one
wallet, which it is
not required (and certainly not recommended) by BIP45.

According to BIP45, a singing party, in order to generate a wallet address,
needs the extended public keys of all the other parties, so each party will
be able to see the transaction history of the wallet they are sharing, but
if the party has other wallets with other copayers the xpub should be
completely different.

matías

--
BitPay.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/d1abcff0/attachment-0001.html>;

📅 Original date posted:2015-03-13 📝 Original message:> ...

2023-06-07T15:31:50Z

In reply to nevent1q…h42v
_________________________

📅 Original date posted:2015-03-13
📝 Original message:> Could you describe what exactly BWS does?

Sure. BWS tasks are:

* Coordinate Transaction proposals in multisignature wallets: provide
an 'always connected' node to distribute pending transaction proposals
and receive the signatures from peers.
* Coordinate and store BIP32 derivation indexes. (If the BWS
disappear, peer can still access the funds by scanning the blockchain,
but having the index in a common accessable point in useful).
* Access the blockchain and provide functions like: `getBalance` and
`getTxHistory` to peers.
* Allow agents to notify incoming funds / or transaction proposals to peers.

BWS is designed to be extremely easy to setup and run. BitPay will
provide a public BWS instance, but companies and individuals can run
their own for privacy and security reasons.

> It sounds like the server doesn't have to actually derive the keys itself for any particular purpose
> beyond knowing the addresses are a part of the wallet. Could the server work if it didn't even
> know that, and was just a bucket of arbitrary addresses with the clients themselves deriving the
> addresses?

We have evaluated BWS not having the extended public keys (and it is
still an open possibility) but the main drawback we found is that BWS
will have no way to verify addresses sent by the peers (*).

A peer could send a fake address to BWS and then functions like
'getBalance' or 'txHistory' will be broken. Of course, the peers could
verify the addresses on getTxHistory or getBalance (by Address) but we
also want to allow thin-clients and agents with lower level of trust
(than the server) that can notify the wallet balance and incoming
transaction to peers using, for example, mobile push notifications.

(*): Gregory Maxwell proposed an schema for doing this with the "not
extended" pubkeys, that we need to evaluate. That could be the best
solution.

📅 Original date posted:2015-03-13 📝 Original message:Hello ...

2023-06-07T15:31:49Z

In reply to nevent1q…t8xf
_________________________

📅 Original date posted:2015-03-13
📝 Original message:Hello everyone,

We are working on bitcore-wallet-server (BWS), a HD multisig wallet
'facilitator'. We have a couple of questions regarding BIP32 path usage,
and we would love to have feedback from you before moving forward.

Currently the BWS instances hold the set of extended public keys of the
wallet's peers to be able to derive addresses.

Since this is a problem from the privacy point of view, we thought using
pseudo-random BIP32 paths, with a seed only known be the peers, so the
server will be able to verify that addresses submitted by peers belong to
the wallet, but will not be able to derive future wallet addresses.

The workflow would be something like:

```
Peer > getCurrentIndex

< Server [index]

Peer:
pathSeed = PRNG(seed, index);

Peer > createAddress(index, pathSeed);

Server:
derives the address and add it to the wallet.

< Server new address

Peer: Verifies the address and inform it the user.
```

This way, accessing server data won't reveal future wallet addresses. The
seed (only known by the peers) could
be derived from hashes of their xprivs, so wallet funds can still be
recover with:
1) The complete set of xprivs
2) The quorum of xprivs + the complete set of xpubs + the address seed.

Thanks a lot in advance for any comment on this schema.

matías

--
BitPay.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150313/af2f95d0/attachment.html>;

📅 Original date posted:2014-05-02 📝 Original message:I live ...

2023-06-07T15:20:47Z

In reply to nevent1q…z7n8
_________________________

📅 Original date posted:2014-05-02
📝 Original message:I live in Argentina. Here, 1BTC is around half of a monthly average
wage (net), so, as you
can imagine, the value of 1 BTC is *very* inconvenient for everyday
transactions.

Also it presents an important entry barrier for new adopters: It would be
easier to accept buying thousands of "bits" than buying a tiny fraction
of a Bitcoin, for the same amount of pesos.

Changing to 1e-6 "bits" will solve both problems. Changing to 1e-6
"microbitcoins" will
solve the first one, but not sure about the second one. Buying (or
earning) mili or micro
something isn't that sexy either.

Finally, against "micro" and in favor of "bits", micro is noted "μ",
which is also
inconvenient (I had to copy and paste it from an other site). Many
different notations will be used like: μBTC, uBTC, "microBTC" and
even "mBTC".
Please prevent that.

These arguments also applies to many places in the world (Argentina
is 40 out of 72 listed countries in
http://en.wikipedia.org/wiki/List_of_countries_by_average_wage).

matías

On Fri, May 2, 2014 at 10:13 PM, Alan Reiner <etotheipi at gmail.com> wrote:
> I've been a strong supporter of the 1e-6 unit switch since the beginning and
> ready to do whatever I can with Armory to help ease that transition. I'm
> happy to prioritize a release that updates the Armory interface to make
> "bits" the default unit, when the time is right. I think it makes sense to
> get as many apps and services to upgrade nearly simultaneously.
>
> My plan is to have a popup on the first load of the new version that briefly
> introduces the change, and mentions that they can go back to the old way in
> the settings, but make them work to do it. For the transient period (6
> months?) all input boxes will auto-update nearby labels with the
> converted-to-BTC value as they type, so that they don't have to do any math
> in their head. Similarly, all displayed BTC values will show both. But the
> 1e-6 unit will always be default or first unless they explicitly change it
> in the interface.
>
>
>
>
>
> On 5/2/2014 8:54 PM, Ben Davenport wrote:
>
> I fully support this (it's what I suggested over a year ago), but what it
> comes down to is BitPay, Coinbase, Blockchain and Bitstamp getting together,
> agreeing what they're going to use, and doing a little joint customer
> education campaign around it. If there's community momentum around "bits",
> great.
>
> My only addition is that I think we should all stop trying to attach SI
> prefixes to the currency unit. Name me another world currency that uses SI
> prefixes. No one quotes amounts as 63 k$ or 3 M$. The accepted standard at
> least in the US is <currency-symbol><amount><modifier>, i.e. $63k or $3M.
> That may not be accepted form everywhere, but in any case it's an informal
> format, not a formal one. The important point is there should be one base
> unit that is not modified with SI prefixes. And I think the arguments are
> strong for that unit being = 100 satoshi.
>
> Ben
>
>
>
>
> On Fri, May 2, 2014 at 12:17 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>>
>> <vendor hat: on>
>>
>> Related:
>> http://blog.bitpay.com/2014/05/02/bitpay-bitcoin-and-where-to-put-that-decimal-point.html
>>
>> --
>> Jeff Garzik
>> Bitcoin core developer and open source evangelist
>> BitPay, Inc. https://bitpay.com/
>>
>>
>> ------------------------------------------------------------------------------
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos. Get
>> unparalleled scalability from the best Selenium testing platform
>> available.
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--
Matías Alejo Garcia
Skype/Twitter: @ematiu
Roads? Where we're going, we don't need roads!

📅 Original date posted:2014-03-27 📝 Original message:On ...

2023-06-07T15:16:24Z

In reply to nevent1q…4c4a
_________________________

📅 Original date posted:2014-03-27
📝 Original message:On Thu, Mar 27, 2014 at 9:28 AM, Mike Hearn <mike at plan99.net> wrote:
> By the way, I just noticed that greenaddress.it is creating seeds that have 24
> words instead of 12. Does anyone know what's up with that? They claim to be
> using BIP32 wallets so I wanted to see if they were using the default structure
> and if so, whether bitcoinj was compatible with it (before I switch to the one
> discussed here). But it seems we fall at the first hurdle ...
>

They replied this on reddit: "Good question! We use 256-bit BIP39
seeds for our 512-bit extended HD wallet keypairs, as advised by
BIP32. We are aware that 128 is considered ok in Electrum but we
wanted to follow BIP32 spec, in particular because we are working with
hardware wallets that have been design with BIP32 in mind and wanted
to avoid any incompatibility issue."

http://www.reddit.com/r/Bitcoin/comments/20puhg/while_blockchaininfo_is_down_what_about_testing/cg5mr54

BTW, thanks for starting this thread. I am with the bitcore team,
working on a new multisig only wallet (Cosign).

The schema originally proposed be Mike (/m/cointype/reserved'/account'/change/n
) seems flexible enough for our needs. I wonder, tough, if we can
agree also on a format to exchange the tips (n) of each branch on the
tree when the user export/backup the wallet, as Allen suggested.

On Wed, Mar 26, 2014 at 8:37 PM, Andreas Schildbach
<andreas at schildbach.de> wrote:
> For me, the most important thing is either we're 100% interoperable or
> 0%. There should not be anything inbetween, as users will delete seeds
> without knowing there is still money in them on another implementation.

Is the ideal schema that the user should be able to use two different
wallets at the same time? Does a wallet need to assume that derivate
keys could had been used already? That seems complicated. Maybe we
could add a /(hash of the wallet name)/ on the BIP32 path.

--
matias

--
Matías Alejo Garcia
Skype/Twitter: @ematiu
Roads? Where we're going, we don't need roads!