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 20: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 20: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 20: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 20: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 19: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 19: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 17: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 17: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!