Re: [bitcoin-dev] Building a Bitcoin API and query system.

[Matias Alejo Garcia via bitcoin-dev]

Hi Sumit,

Take a look at https://github.com/bitpay/bitcore/tree/v8.0.0, it is a
bitcoin indexing API server, with several modules, like a block explorer, a
wallet module, etc. It is built using Node.js.

matías

On Tue, Aug 28, 2018 at 12:43 PM Joseph Gleason ⑈ via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> For what it is worth, electrum has a lot or possibly all of what you are
> talking about since the electrum servers are designed to quickly answer the
> queries of light clients.  So right now, you could sync up an electrum
> server or use an existing public one and send queries to it with json-rpc.
>
>
> https://github.com/kyuupichan/electrumx/blob/master/docs/protocol-methods.rst
>
>
> On Tue, Aug 28, 2018 at 5:36 AM Blockchain Group via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hello everyone,
>>
>> I am C++ & Node.js developer. I want to propose making a new Bitcoin API
>> that supports fast quering of Bitcoin blocks and transactions without the
>> need for syncing with all previous nodes.
>>
>> In a typical case where I want to build a full fleged Bitcoin explorer
>> cum wallet system on my end with external APIs, I need to sync my node and
>> then query for the information I need to show separately. I am proposing a
>> unified method of finding/quering the blockchain data with a standardized
>> template containing minimal information about the actual mined block or
>> transaction yet satify the need of what I want to query.
>>
>> I am working on making a template and a support mechanism on Node.js. I
>> want to propose it as an improvement (BIP). It will be a great help to
>> future web developers who want to make something similar.
>>
>> Thanks
>> Sumit Lahiri.
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@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!
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected.

[Matias Alejo Garcia via bitcoin-dev]

Source?

On Fri, Apr 6, 2018 at 4:53 PM, ketamine--- via bitcoin-dev <
bitcoin-dev@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@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!
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Matias Alejo Garcia via bitcoin-dev]

> Let me re-phrase: Is it a known thing for users to actually use it?

yes. Based on language stats from the app stores, roughly 30% to 40% of
Copay users have their backup on a language
other than English, and we constantly get requests to support new languages
in BIP39.

On Mon, Jan 8, 2018 at 11:54 AM, Greg Sanders  wrote:

> Let me re-phrase: Is it a known thing for users to actually use it?
>
> On Mon, Jan 8, 2018 at 9:52 AM, Matias Alejo Garcia 
> wrote:
>
>>
>>
>> On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Has anyone actually used the multilingual support in bip39?
>>>
>>
>>
>> Copay (and all its clones) use it.
>>
>>
>>
>>
>>
>>>
>>> If a feature of the standard has not been(widely?) used in years, and
>>> isn't supported in any major wallet(?), it seems indicative it was a
>>> mistake to add it in the first place, since it's a footgun in the making
>>> for some poor sap who can't even read English letters when almost all
>>> documentation is written in English.
>>>
>>> On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
 On 2018-01-08 at 07:35:52 +, 木ノ下じょな 
 wrote:

> This is very sad.
>
> The number one problem in Japan with BIP39 seeds is with English words.
>
> I have seen a 60 year old Japanese man writing down his phrase
> (because he kept on failing recovery), and watched him write down "aneter"
> for "amateur"...
>
> [...]
>
> If you understand English and can spell, you read a word, your brain
> processes the word, and you can spell it on your own when writing down.
> Not many Japanese people can do that, so they need to copy letter for
> letter, taking a long time, and still messing up on occasion.
>
> [...]
>
> Defining "everyone should only use English, because ASCII is easier to
> plan for" is not a good way to move forward as a currency.
>

 Well said.  Thank you for telling of these experiences.  Now please,
 let’s put the shoe on the other foot.

 I ask everybody who wants an English-only mnemonic standard to entrust
 *their own money* to their abilities to very, very carefully write this
 down—then later, type it back in:

 すさん たんろ りゆう しもん ていおん しとう
 とこや はやい おうさま ほくろ けちゃっふ たもつ

 (Approximate translation:  “Whatever would you do if Bitcoin had been
 invented by somebody named Satoshi Nakamoto?”)

 No, wait:  That is only a 12-word mnemonic.  We are probably talking
 about a Trezor; so now, hey you there, stake the backup of your life’s
 savings on your ability to handwrite *this*:

 にあう しひょう にんすう ひえる かいこう いのる ねんし はあさん ひこく
 とうく きもためし そなた こなこな にさんかたんそ ろんき めいあん みわく
 へこむ すひょう おやゆひ ふせく けさき めいきょく こんまけ

 Ready to bet your money on *that* as a backup phrase in your own
 hands?  No?  Then please, stop demanding that others risk *their* money on
 the inverse case.

 

 If you cheat here by having studied Japanese, then remember that many
 Japanese people know English and other European languages, too.  Then think
 of how much money would be lost by your non-Japanese-literate family and
 friends—if BIP 39 had only Japanese wordlists, and your folks needed to
 wrestle with the above phrases as their “mnemonics”.

 In such cases, the phrases cannot be called “mnemonics” at all.  A
 “mnemonic” implies aid to memory.  Gibberish in a wholly alien writing
 system is much worse even than transcribing pseudorandom hex strings.  The
 Japanese man in the quoted story, who wrote “aneter” for “amateur”, was not
 dealing with a *mnemonic*:  He was using the world’s most inefficient means
 of making cryptic bitstrings *less* userfriendly.

 

 I began this thread with a quite simple request:  Is “日本語” an
 appropriate string for identifying the Japanese language to Japanese
 users?  And what of the other strings I posted for other languages?

 I asked this as an implementer working on my own instance of the
 greatest guard against vendor lock-in and stale software:  Independent
 implementations.  —  I asked, because obviously, I myself do not speak all
 these different languages; and I want to implement them all.  *All.*

 Some replies have been interesting in their own right; but thus far,
 nobody has squarely addressed the substance of my question.

 Most worrisome is that much of the discussion has veered into criticism
 of multi-language support.  I opened with a question about other languages,
 and I am getting replies which raise a hue and cry of “English only!”

 Though I am fluent and literate in English, I am uninterested in ever
 implementing any standard of 

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Matias Alejo Garcia via bitcoin-dev]

On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Has anyone actually used the multilingual support in bip39?
>


Copay (and all its clones) use it.





>
> If a feature of the standard has not been(widely?) used in years, and
> isn't supported in any major wallet(?), it seems indicative it was a
> mistake to add it in the first place, since it's a footgun in the making
> for some poor sap who can't even read English letters when almost all
> documentation is written in English.
>
> On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On 2018-01-08 at 07:35:52 +, 木ノ下じょな  wrote:
>>
>>> This is very sad.
>>>
>>> The number one problem in Japan with BIP39 seeds is with English words.
>>>
>>> I have seen a 60 year old Japanese man writing down his phrase (because
>>> he kept on failing recovery), and watched him write down "aneter" for
>>> "amateur"...
>>>
>>> [...]
>>>
>>> If you understand English and can spell, you read a word, your brain
>>> processes the word, and you can spell it on your own when writing down.
>>> Not many Japanese people can do that, so they need to copy letter for
>>> letter, taking a long time, and still messing up on occasion.
>>>
>>> [...]
>>>
>>> Defining "everyone should only use English, because ASCII is easier to
>>> plan for" is not a good way to move forward as a currency.
>>>
>>
>> Well said.  Thank you for telling of these experiences.  Now please,
>> let’s put the shoe on the other foot.
>>
>> I ask everybody who wants an English-only mnemonic standard to entrust
>> *their own money* to their abilities to very, very carefully write this
>> down—then later, type it back in:
>>
>> すさん たんろ りゆう しもん ていおん しとう
>> とこや はやい おうさま ほくろ けちゃっふ たもつ
>>
>> (Approximate translation:  “Whatever would you do if Bitcoin had been
>> invented by somebody named Satoshi Nakamoto?”)
>>
>> No, wait:  That is only a 12-word mnemonic.  We are probably talking
>> about a Trezor; so now, hey you there, stake the backup of your life’s
>> savings on your ability to handwrite *this*:
>>
>> にあう しひょう にんすう ひえる かいこう いのる ねんし はあさん ひこく
>> とうく きもためし そなた こなこな にさんかたんそ ろんき めいあん みわく
>> へこむ すひょう おやゆひ ふせく けさき めいきょく こんまけ
>>
>> Ready to bet your money on *that* as a backup phrase in your own hands?
>> No?  Then please, stop demanding that others risk *their* money on the
>> inverse case.
>>
>> 
>>
>> If you cheat here by having studied Japanese, then remember that many
>> Japanese people know English and other European languages, too.  Then think
>> of how much money would be lost by your non-Japanese-literate family and
>> friends—if BIP 39 had only Japanese wordlists, and your folks needed to
>> wrestle with the above phrases as their “mnemonics”.
>>
>> In such cases, the phrases cannot be called “mnemonics” at all.  A
>> “mnemonic” implies aid to memory.  Gibberish in a wholly alien writing
>> system is much worse even than transcribing pseudorandom hex strings.  The
>> Japanese man in the quoted story, who wrote “aneter” for “amateur”, was not
>> dealing with a *mnemonic*:  He was using the world’s most inefficient means
>> of making cryptic bitstrings *less* userfriendly.
>>
>> 
>>
>> I began this thread with a quite simple request:  Is “日本語” an appropriate
>> string for identifying the Japanese language to Japanese users?  And what
>> of the other strings I posted for other languages?
>>
>> I asked this as an implementer working on my own instance of the greatest
>> guard against vendor lock-in and stale software:  Independent
>> implementations.  —  I asked, because obviously, I myself do not speak all
>> these different languages; and I want to implement them all.  *All.*
>>
>> Some replies have been interesting in their own right; but thus far,
>> nobody has squarely addressed the substance of my question.
>>
>> Most worrisome is that much of the discussion has veered into criticism
>> of multi-language support.  I opened with a question about other languages,
>> and I am getting replies which raise a hue and cry of “English only!”
>>
>> Though I am fluent and literate in English, I am uninterested in ever
>> implementing any standard of this nature which is artificially restricted
>> to English.  I am fortunate; for as of this moment, we have a standard
>> called “BIP 39” which has seven non-English wordlists, and four more
>> pending in open pull requests (#432, #442, #493, #621).
>>
>> I request discussion of language identification strings appropriate for
>> use with that standard.
>>
>> (P.S., I hope that my system did not mangle anything in the foregoing.  I
>> have seen weird copypaste behaviour mess up decomposed characters.  I
>> thought of this after I searched for and collected some visually
>> fascinating phrases; so I tried to normalize these to NFC...  It should go
>> without saying, easyseed output the Japanese perfectly!)
>>
>>
>> --
>> 

Re: [bitcoin-dev] [Bitcoin-development] New BIP32 structure for P2SH multisig wallets [BIP-45]

[Matias Alejo Garcia via bitcoin-dev]

On Mon, Oct 5, 2015 at 9:18 AM, Jean-Pierre Rupp  wrote:
>
> Perhaps Pedro wants to also participate in a 2-of-2 cosigning
> arrangement with a merchant that will deliver a laptop to him, so Pedro
> provides this merchant with the same extended public key derived from
> path m/45', and the merchant provides Pedro with his own:
>
> Pedro: xpub456...
> ElCheapoPC: xpub987...
>


Thanks for the explanation. OK, maybe that should be stated on BIP45, but
it was never the idea that you reuse your xpub for different wallet, as I
mention
on the original reply. The only implementation of BIP45 I am aware of
(Copay),
use completely different xprivs for each wallet.



>
> On 05/10/15 07:57, Matias Alejo Garcia wrote:
> >
> > 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
>



-- 
BitPay.com
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev