Matias Alejo Garcia [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-02-16 to 2018-08-28
💬 Posted a total of 12 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev, BIP-45
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:14:11

- reply

📅 Original date posted:2018-08-28
📝 Original message: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 at 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 at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> 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/20180828/b50caacc/attachment.html>

2023-06-07 18:11:32

- reply

📅 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>

2023-06-07 18:09:22

- reply

📅 Original date posted:2018-01-08
📝 Original message:> 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 <gsanders87 at gmail.com> 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 <ematiu at gmail.com>
> wrote:
>
>>
>>
>> On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
>> bitcoin-dev at 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 at lists.linuxfoundation.org> wrote:
>>>
>>>> On 2018-01-08 at 07:35:52 +0000, 木ノ下じょな <kinoshitajona at gmail.com>
>>>> 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!)
>>>>
>>>>
>>>> --
>>>> nullius at nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
>>>> Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
>>>> 3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
>>>> “‘If you’re not doing anything wrong, you have nothing to hide.’
>>>> No! Because I do nothing wrong, I have nothing to show.” — nullius
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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!
>>
>
>
--
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/20180108/6928a411/attachment-0001.html>

2023-06-07 18:09:18

- reply

📅 Original date posted:2018-01-08
📝 Original message:On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
bitcoin-dev at 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 at lists.linuxfoundation.org> wrote:
>
>> On 2018-01-08 at 07:35:52 +0000, 木ノ下じょな <kinoshitajona at gmail.com> 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!)
>>
>>
>> --
>> nullius at nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
>> Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
>> 3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
>> “‘If you’re not doing anything wrong, you have nothing to hide.’
>> No! Because I do nothing wrong, I have nothing to show.” — nullius
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> 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/20180108/eaa842ab/attachment.html>

2023-06-07 17:42:23

- reply

📅 Original date posted:2015-10-05
📝 Original message:On Mon, Oct 5, 2015 at 9:18 AM, Jean-Pierre Rupp <root at haskoin.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/62a9eebf/attachment.html>

2023-06-07 17:42:22

- reply

📅 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>

2023-06-07 15:31:50

- reply

📅 Original date posted:2015-03-13
📝 Original message:> It sounds like the main issue is this is a web wallet server of some kind.
> If the clients were SPV then they'd be checking their own balances and
> downloading their own tx history, which would mean the coordination tasks
> could be done by storing encrypted blobs on the server rather than the
> server itself having insight into what's going on (see: Subspace).
You are killing us Mike! :) We really don't like to think that BWS is
a webwallet. Note
that private keys are not stored (not even encrypted) at the server. Addresses
can be generated offline, funds received and transferred by the peers
without accessing
BWS.
Currently Copay uses the encrypted blob idea (checks balances and tx
history thought Insight), but after working with Copay for ~6 months
we think having some visibility of the wallet by the multisig
facilitator will make the user experience much better (e.g: mobile
notifications).
Thanks for the Subspace reference, we will definitely check it.
> So whilst you might be able to use some scheme to avoid the server knowing
> the xpubkey, if the server still knows all addresses and all transactions
> because the clients are web wallets ..... is there any point? It seems like
> maybe going from server knows everything to server knows 95% of everything:
> maybe not worth the engineering cost.
Interesting point. IMO, if we can prevent the server from having the xpubs keys
it would be valuable: It will give us more flexibility for future
features, and if the server is compromised future addresses will not
be known by the attacker, but of course we need to evaluate the cost.
matías
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
BitPay.com

2023-06-07 15:31:50

- reply

📅 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.

2023-06-07 15:31:49

- reply

📅 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>

2023-06-07 15:20:47

- reply

📅 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!

2023-06-07 15:16:24

- reply

📅 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!

2023-06-07 15:13:44

- reply

📅 Original date posted:2014-02-16
📝 Original message:Hi Melvin / Mike,
Ive been working on Bitcore and Insight next to a BitPay team for the last
few weeks. We are happy to receive patches, suggestions and bug reports
from you guys at:
https://github.com/bitpay/insight
Insight also provides some blockchain query capabilities at its
REST/Websockets API described on the Readme document.
Please note that Insight is meant as a software package that you can
download, install and use next to a trusted bitcoind instance.
live.bitcore.io / test.bitcore.io are just demo installations.
best,
matías
On Sun, Feb 16, 2014 at 10:45 AM, Melvin Carvalho
<melvincarvalho at gmail.com>wrote:
>
>
>
> On 27 December 2013 19:05, Mike Hearn <mike at plan99.net> wrote:
>
>> For a long time the only block explorer for testnet has been the original
>> blockexplorer.com, which is unfortunately often broken / behind / slow
>> and not really maintained any more.
>>
>> There is now a new one, here:
>>
>> https://www.biteasy.com/testnet/blocks
>>
>> There's also a REST/JSON API for it.
>>
>> Please note one curiosity of this block explorer is that the coinbase tx
>> doesn't necessarily come first in the listing (it's sorted by "time
>> received", see).
>>
>> Other interesting thing to note: this site is built using bitcoinj. The
>> author can be contacted on IRC sometimes using the nick damethos.
>>
>
> Some more information on testnet3 explorers ...
>
> Here is a free software testnet explorer based on javascript/node
>
> http://test.bitcore.io/
>
> I've been working on a testnet explorer, but I think I will fork this and
> add semantic web style markup attributes to the HTML.
>
> Also a message I got from blockr.io "yes testnet will be added. I cannot
> give you an estimate on when, but it'll probably happen in couple of weeks
> (hopefully sooner)."
>
>
>>
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>> Pro!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Matías Alejo Garcia
CinemaKi.com
Skype/Twitter: @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/20140216/20ac0eef/attachment.html>