Nostr notes by devrandom [ARCHIVE]

📅 Original date posted:2023-06-28 🗒️ Summary of this ...

2023-06-29T16:47:03Z

In reply to nevent1q…rpue
_________________________

📅 Original date posted:2023-06-28
🗒️ Summary of this message: The validating lightning signer has released its beta version, offering security against fund loss and malicious nodes. Developers can join the Matrix room and try out the CLN or LDK nodes. The beta version is secure but not foolproof, so it is recommended to use it with limited funds until the production release. The release includes features like encrypted cloud state backup, disaster recovery, validation rules, and more. Planned updates include running in a no-std environment and improving performance for embedded processors. Future releases will include routing, BOLT-12 support, VSS integration, and multisig. Developers are encouraged to contribute to the project.
📝 Original message:
The VLS team is pleased to announce the [Beta release](https://gitlab.com/lightning-signer/validating-lightning-signer/-/releases/v0.9.1) of the validating lightning signer. This is our MVP2 release, designed to be secure against accidental fund loss and malicious nodes.

We encourage LN application developers to join our [Matrix room](https://matrix.to/#/#vls:matrix.org), submit a [feature request](https://gitlab.com/lightning-signer/validating-lightning-signer/-/issues/new?issuable_template=Feature%20Request), or take VLS for a spin with sample [CLN](https://gitlab.com/lightning-signer/vls-hsmd) or [LDK nodes](https://gitlab.com/lightning-signer/lnrod).

While the VLS beta is secure against the most common ways a malicious node may steal user funds, it does not yet capture all scenarios in which a user might lose funds. We recommend running VLS in testnet or with limited funds in production until we reach our production release milestone and you are comfortable it adequately protects against all scenarios relevant to your use case.

Highlights for developers:

* Works with CLN and LDK
* Encrypted cloud state backup
* Disaster recovery from signer and node failure
* Complete set of layer-2 [validation rules](https://gitlab.com/lightning-signer/validating-lightning-signer/-/blob/main/docs/policy-controls.md)
* Optional validation rules (e.g. velocity, approval)
* A complete set of layer-1 validation rules (on-chain channel state tracking)
* Heartbeat generation
* Allowlist for approved destinations
* UTXO set oracle guarantees safe on-chain state
* [See here](https://gitlab.com/lightning-signer/validating-lightning-signer/-/blob/main/CHANGELOG.md) for a full changelog

[Click here](https://vls.tech/posts/vls-beta/) to learn more.

Planned for the next release:

* Signer runs in `no-std` environment without a standard library
* Signer can run on modest amounts of RAM and ROM
* Tuning performance for embedded processors

Planned for later releases:

* Routing
* BOLT-12 Support
* VSS Integration
* Multisig

What’s that you say? You’re a dev looking for a fun and impactful FOSS project to contribute to? Look no further, we could use your help. Get in touch with us on [Matrix](https://matrix.to/#/#vls:matrix.org) to see how you can get involved.

--
Devrandom

📅 Original date posted:2015-06-16 📝 Original message:On ...

2023-06-07T15:38:08Z

In reply to nevent1q…hhpn
_________________________

📅 Original date posted:2015-06-16
📝 Original message:On 2015-06-16 12:55 AM, Aaron Voisine wrote:
>> Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who
>> would provide the nodes they would need connect to?
>
> The SPV wallet author would if they wanted their wallet to function.

I would also guess that the cost to provide service to SPV wallets is
less than $0.01/mo per wallet and in any case less than long-term
transaction fees. This can either be taken up by the wallet author or
transparently through a payment channel by the user.

>
>
> Aaron Voisine
> co-founder and CEO
> breadwallet.com <http://breadwallet.com>;

--
devrandom / Miron

📅 Original date posted:2015-03-11 📝 Original message:ACK. ...

2023-06-07T15:31:47Z

In reply to nevent1q…9jf3
_________________________

📅 Original date posted:2015-03-11
📝 Original message:ACK. CryptoCorp uses this method for our external signer service.

On 2015-03-11 04:45 AM, Thomas Kerin wrote:
>
> Hi all,
>
> I just created a PR on bitcoin/bips for a proposed standard for creating
> standard multisignature P2SH addresses given m, and a set of public keys.
>
> https://github.com/bitcoin/bips/pull/146
>
> I used BIP0090 as a place-holder, but I would like to request a BIP
> number for this now.
>
> All the best,
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>

--
devrandom / Miron

--
devrandom / Miron

📅 Original date posted:2015-03-12 📝 Original message:On ...

2023-06-07T15:31:38Z

In reply to nevent1q…3590
_________________________

📅 Original date posted:2015-03-12
📝 Original message:On 2015-03-12 04:51 AM, Neill Miller wrote:
>
> Ok, I see your point here, and I was referring to rebuilding from
> entropy -- which as you noted is not a real world usage. It is a
> useful implementation test though and at the very least the existing
> test vectors would need to be regenerated with each word list change.
>
> I recently added BIP39 to libbitcoin and our implementation would fail
> with an arbitrarily new word list because we validate the user
> provided word list before converting it to a seed (i.e. we check that
> the encoded entropy/checksum line up and warn the user if that's not
> the case to distinguish a rubbish word list from a BIP39 mnemonic --
> as referenced in the BIP). You're correct that we could use rubbish
> words, but at the moment it's not allowed there. By removing that
> validating 'restriction', I agree with you that word lists have no
> need to be fixed. But realistically, we still don't allow completely
> arbitrary words to be used because I don't see the word lists changing
> too often, nor implementations storing word lists of all words and
> languages.

A good way to go about this from a UX point of view is warn the user
that their "phrase is non-standard", but allow them to insist.

>
> Thanks for clarifying,
> -Neill.
>
> On Thu, Mar 12, 2015 at 04:21:59AM +0000, Thy Shizzle wrote:
>> "I agree that it's true that a static wordlist is
>> required once people have started using BIP39 for anything real and
>> changing the word lists will invalidate any existing mnemonics"
>> ^ This is incorrect I think Neill, the reason is that the only thing that happens when you change the wordlist is that entropy points to different words. But remember, entropy is disposed. Yes in my code I allow for the keeping of entropy etc, it also lets me "hot swap" between different language wordlists etc but in real world implementation the entropy is forgotten and not stored. So changing the wordlist merely allows new mnemonic phrases to be generated but it has a nil impact on previously generated mnemonics UNLESS you are trying to rebuild from entropy but you wouldn't do that. You would be rebuilding from the Mnemonic in real world scenario. You really can have a word list of total rubbish in BIP39 as long as it is 2048 words long that is all! If you input the mnemonic made out of rubbish words so for e.g "uyuy jkjasd sdsd sdsdd yuuyu sdsds iooioi sdasds uyuyuy sdsdsd tyyty rwetrtr" and no matter what BIP39 implementation you put it in, it will always generate the same seed
bytes thus allowing for complete and universal seed derivation without any reliance on word list. The word list is merely to generate a mnemonic, after that it has no role in seed generation so you can change it at anytime and it will never effect future mnemonics.
>>
>> On Thu, Mar 12, 2015 at 02:16:38AM +0000, Thy Shizzle wrote:
>>> That's disappointing the Electrum 2.0 doesn't use BIP39.
>>
>> Agreed, but I don't know the full background on this.
>>
>>> Changing the wordlist in the future has ZERO effect on derived seed, whatever mnemonic you provide will always generate the same seed, BIP39 is not mapping the words back to numbers etc to derive seed.
>>
>> That's true for generating new mnemonics (i.e. same entropy can
>> generate any combinations of words), but not for converting a mnemonic
>> to a seed (i.e. a specific wordlist/passphrase should always generate
>> the same seed). I agree that it's true that a static wordlist is
>> required once people have started using BIP39 for anything real and
>> changing the word lists will invalidate any existing mnemonics (unless
>> your 'new' wordlist simply substitutes one word for another and the
>> index mapping is made public ... which means it's not really an
>> arbitrary word list).
>>
>>> Version is something that can be dealt with after the fact, hopefully standardised (curious why didn't you work with the BIP39 to insert version instead of do something different to BIP39?)
>>> So most of what you are suggesting as problems are not.
>>
>> I don't see how this can work given the BIP39 spec as it is today
>> (there's simply no room for a version in the bits). I do think
>> versioning would be nice, but as of now, I'm in the camp that thinks
>> complete wallet interoperability is a bit of a myth -- so long as you
>> can fundamentally move into/out of wallets at will.
>>
>> -Neill.
>>
>>> As for the common words between languages, I have discussed this with the provider of the Chinese wordlists as they shared some words between simplified and traditional, but I found it easy to look for a word in the mnemonic that is unique to that language/wordlist and so straight away you can determine the language, remembering you get minimum 12 goes at doing that :)
>>> Also then I asked myself, do we really care about detecting the language? Probably not because we don't need to use the wordlist ever again after creation, we literally accept the mnemonic, normalise it then hash it into a seed. From what I'm reading, Electrum 2.0 really should have BIP39, it would take almost no effort to put it in and I think you should do that :) I don't have any interest in BIP39 other than it being a standard. I think TREZOR may have an interest in it?
>>> Thomas V:
>>> "Thanks Mike, and sorry to answer a bit late; it has been a busy couple
>>> of weeks.
>>>
>>> You are correct, a BIP39 seed phrase will not work in Electrum, and vice
>>> versa. It is indeed unfortunate. However, I believe BIP39 should not be
>>> followed, because it reproduces two mistakes I did when I designed the
>>> older Electrum seed system. Let me explain.
>>>
>>> The first problem I have with BIP39 is that the seed phrase does not
>>> include a version number.
>>>
>>> Wallet development is still in an exploratory phase, and we should
>>> expect even more innovation in this domain. In this context, it is
>>> unwise to make decisions that prevent future innovation.
>>>
>>> However, when we give a seed phrase to users, we have a moral obligation
>>> to keep supporting this seed phrase in future versions. We cannot simply
>>> announce to Electrum users that their old seed phrase is not supported
>>> anymore, because we created a new version of the software that uses a
>>> different derivation. This could lead to financial losses for users who
>>> are unaware of these technicalities. Well, at least, that is how I feel
>>> about it.
>>>
>>> BIP39 and Electrum v2 have a very different ways of handling future
>>> innovation. Electrum v2 seed phrases include an explicit version number,
>>> that indicates how the wallet addresses should be derived. In contrast,
>>> BIP39 seed phrases do not include a version number at all. BIP39 is
>>> meant to be combined with BIP43, which stipulates that the wallet
>>> structure should depend on the BIP32 derivation path used for the wallet
>>> (although BIP43 is not followed by all BIP39 compatible wallets). Thus,
>>> innovation in BIP43 is allowed only within the framework of BIP32. In
>>> addition, having to explore the branches of the BIP32 tree in order to
>>> determine the type of wallet attached to a seed might be somewhat
>>> inefficient.
>>>
>>> The second problem I see with BIP39 is that it requires a fixed
>>> wordlist. Of course, this forbids innovation in the wordlist itself, but
>>> that's not the main problem. When you write a new standard, it is
>>> important to keep this standard minimal, given the goal you want to
>>> achieve. I believe BIP39 could (and should) have been written without
>>> including the wordlist in the standard.
>>>
>>> There are two ways to derive a master key from a mnemonic phrase:
>>> 1. A bidirectional mapping between words and numbers, as in old
>>> Electrum versions. Pros: bidirectional means that you can do Shamir
>>> secret sharing of your seed. Cons: It requires a fixed wordlist.
>>> 2. Use a hash of the seed phrase (pbkdf). Pros: a fixed wordlist is not
>>> required. Cons: the mapping isn't bidirectional.
>>>
>>> Electrum v1 uses (1). Electrum v2 uses (2).
>>>
>>> Early versions of BIP39 used (1), and later they switched to (2).
>>> However, BIP39 uses (2) only in order to derive the wallet keys, not for
>>> its checksum. The BIP39 checksum uses (1), and it does requires a fixed
>>> wordlist. This is just plainly inconsistent. As a result, you have
>>> neither wordlist flexibility, nor Shamir secret sharing.
>>>
>>> Having a fixed wordlist is very unfortunate. First, it means that BIP39
>>> will probably never leave the 'draft' stage, until all languages of the
>>> world have been added. Second, once you add a wordlist for a new
>>> language, you cannot change it anymore, because it will break existing
>>> seed phrases; therefore you have to be extremely careful in the way you
>>> design these wordlists. Third, languages often have words in common.
>>> When you add a new language to the list, you should not use words
>>> already used by existing wordlists, in order to ensure that the language
>>> can be detected. It leads to a first come first served situation, that
>>> might not be sustainable in the future.
>>>
>>> In order to support the old Electrum v1 seeds, all future versions of
>>> Electrum will have to include the old wordlist. In addition, when
>>> generating new seed phrases, Electrum now has to avoid collisions with
>>> old seed phrases, because the old ones did not have a version number.
>>> This is painful enough, I will not repeat the same errors twice.
>>>
>>> Electrum v2 derives both its private keys and its checksum/version
>>> number using a hash of the seed phrase. This means that wordlists can be
>>> added and modified in the future, without breaking existing seed
>>> phrases. It also means that it will be very easy for other wallets to
>>> support Electrum seedphrases: it requires about 20 lines of code, and no
>>> wordlist is required."
>>>
>>>
>>> Thomas
>>>
>>>
>>> Le 02/03/2015 16:37, Mike Hearn a écrit :
>>>> Congrats Thomas! Glad to see Electrum 2 finally launch.
>>>>
>>>>
>>>>> * New seed derivation method (not compatible with BIP39).
>>>>
>>>>
>>>> Does this mean a "12 words" wallet created by Electrum won't work if
>>>> imported into some other wallet that supports BIP39? Vice versa? This seems
>>>> unfortunate. I guess if seeds are being represented with 12 words
>>>> consistently, people will expect them to work everywhere.
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>> Bitcoin-development --
>>> | |
>>> | | | | | |
>>> | Bitcoin-development --To see the collection of prior postings to the list, visit the Bitcoin-development Archives. |
>>> | |
>>> | View on lists.sourceforge.net | Preview by Yahoo |
>>> | |
>>> | |
>>>
>>>
>>>
>>>
>>>
>>
>>> ------------------------------------------------------------------------------
>>> 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
>
> ------------------------------------------------------------------------------
> 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
>

--
devrandom / Miron

📅 Original date posted:2015-03-12 📝 Original message:On ...

2023-06-07T15:31:35Z

In reply to nevent1q…zmh4
_________________________

📅 Original date posted:2015-03-12
📝 Original message:On 2015-03-11 06:21 PM, Thy Shizzle wrote:
> Hmmmm I don't think it's fair to say that there has been a failure to
> standardise. From what I read earlier among the wallets, mostly it came
> down to if a version was noted and the date. Assuming no date is
> provided, it just means you are scanning the block chain from day 0 for
> transactions right? Hardly a big deal as you will still recover funds right?

Unfortunately there's more incompatibility than just the date issue:

* seed: some follow BIP39, and some roll their own
* HD structure: some follow BIP44, some BIP32 derivation, and some roll
their own

So actually very few wallets are seed-compatible, even ignoring the date
question.

>
> Version right now is irrelevant as there is only one version of BIP39
> currently, probably this will change as 2048 iterations of HMACSHA512
> will likely need to be up scaled in the future, I thought about adding
> one extra word into the mnemonic to signify version, so if you have a 12
> word mnemonic then you have 12 words + 1 word version. Version 1 has no
> extra word, version 2 uses the first word on the list, version 3 uses
> the second word on the wordlist, so on and so forth. Least that's what I
> was thinking of doing if I ever had to record a version, won't effect
> anything because entropy increases in blocks of 3 words so one extra
> word can simply be thrown on the end.

That's a reasonable solution.

>
> So in summary I feel that date can be handled by assuming day 0, and
> version is not an issue yet but may become one and probably it is a good
> idea to think about standardising a version into BIP39, I have
> provided a seed idea for discussion.
>
> I don't think it is quite the doom and gloom I'm reading :)
>
>
> devrandom:
> "I'd like to offer that the best practice for the shared wallet use case
> should be multi-device multi-sig. The mobile has a key, the desktop has
> a key and a third-party security oracle has a third key. The oracle
> would have different security thresholds for countersigning the mobile.
>
> This way you can have the same overall wallet on all devices, but
> different security profiles on different keys.
>
> That said, I do agree that mnemonic phrases should be portable, and find
> it unfortunate that the ecosystem is failing to standardize on phrase
> handling."

--
devrandom / Miron

📅 Original date posted:2015-03-18 📝 Original message:On ...

2023-06-07T15:31:31Z

In reply to nevent1q…2qhd
_________________________

📅 Original date posted:2015-03-18
📝 Original message:On 2015-03-12 03:28 AM, Andreas Schildbach wrote:
> That doesn't work for mobile wallets, because we need to consider the
> offline case. To fix this, we'd need to extend BIP70 to tell the
> merchant where to forward the half-signed transaction to. Then again I'm
> not sure if we want that, for privacy reasons. In any case, practical

Telling the merchant who my security provider is not that different from
a privacy point of view from using their wifi. In both cases they would
see us connect to the provider. The connection / payload would be
encrypted of course.

In the mean time, we can un-multisig some of the coins for daily use, up
to a defined velocity limit. (credit to Mike Hearn's for this idea)

> multisig is still a looong way off.

Let's bring it closer. p2sh.info shows an exponential increase,
currently at 8%. At this rate, the majority of the coins will be
multisig near the end of the year.

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

--
devrandom / Miron

📅 Original date posted:2015-03-12 📝 Original message:On ...

2023-06-07T15:31:29Z

In reply to nevent1q…tgtp
_________________________

📅 Original date posted:2015-03-12
📝 Original message:On 2015-03-11 05:11 PM, Gregory Maxwell wrote:
> On Wed, Mar 11, 2015 at 11:50 PM, devrandom <c1.sf-bitcoin at niftybox.net> wrote:
>> That said, I do agree that mnemonic phrases should be portable, and find
>> it unfortunate that the ecosystem is failing to standardize on phrase
>> handling.
>
> The fact remains that there are several apparently unresolvable
> well-principled perspectives on this subject.
>
> (And I can speak to this personally: There are several BIPs in this
> space that I'd rather not see in product with my name on it.)
>
> Unless two wallets have exactly the same feature set, cross importing
> keys is going to confuse or break something. Even if you're trying to
> be fairly generic the testing overhead for all possible strategies and
> structures is large. Expecting compatibility here would be like
> expecting two large commercial accounting packages to support the same
> internal file formats. Compatibility is only straight forward when the
> feature set is as limited as possible.

You make some good points. However, I still hope for standardization by
"profile". E.g. a "consumer profile" for wallets with just one account,
a "business profile" for small business wallets. If an application
falls outside of the standardized profiles, they can roll their own or
try to promote a new standard.

I think there are some important advantages to not being forced to use
the old wallet to send coins when switching wallets. The three I can
think of right now are: maintaining transaction history, emergency
transition when a wallet has a serious (e.g. money losing) bug and web
wallet with server down.

Another important reason to standardize is to reduce the "roll your own
crypto" temptation on the wallet creator part, where the wallet-specific
algorithm is more likely to contain weaknesses.

I do agree that trying to come up with one uber standard will likely
fail and is probably counter productive.

>
> The space for weird behavior to harm users is pretty large... e.g. you
> could load a key into two wallets, such that one can see all the funds
> by the other, but not vice versa and and up losing funds by
> incorrectly assuming you had no coins; or inadvertently rip of your
> business partners by accounting for things incorrectly.
>
> Even ignoring compatibility, most demanded use cases here are ones
> that create concurrent read/write use of single wallet without some
> coordinating service is inherently somewhat broken because you can
> double spend yourself, and end up with stalled and stuck transactions
> and causing people to think you tried ripping them off.
>
> I certainly recognize the desirable aspects of just being able to load
> a common wallet, and that inexperienced users expect it to just work.
> But I don't think that expectation is currently very realistic except
> within limited domains. It may be more realistic in the future when
> the role of wallets is better established. I don't see any _harm_ in
> trying to standardize what can be, I just don't expect to see a lot of
> success.
>
> Ultimately, the most fundamental compatibility is guaranteed: you can
> always send your funds to another wallet. This always works and
> guarantees that you are never locked in to a single wallet. It is well
> tested and cannot drive any software in to weird or confused states.
>

--
devrandom / Miron

📅 Original date posted:2015-03-11 📝 Original ...

2023-06-07T15:31:28Z

In reply to nevent1q…g5zj
_________________________

📅 Original date posted:2015-03-11
📝 Original message:I'd like to offer that the best practice for the shared wallet use case
should be multi-device multi-sig. The mobile has a key, the desktop has
a key and a third-party security oracle has a third key. The oracle
would have different security thresholds for countersigning the mobile.

This way you can have the same overall wallet on all devices, but
different security profiles on different keys.

That said, I do agree that mnemonic phrases should be portable, and find
it unfortunate that the ecosystem is failing to standardize on phrase
handling.

On 2015-03-11 04:22 PM, Mike Hearn wrote:
> Users will want to have wallets shared between devices, it's as simple
> as that, especially for mobile/desktop wallets. Trying to stop them from
> doing that by making things gratuitously incompatible isn't the right
> approach: they'll just find workarounds or wallet apps will learn how
> to import seeds from other apps. Better to just explain the risks and
> help people mitigate them.
>
> On Wed, Mar 11, 2015 at 3:57 PM, Aaron Voisine <voisine at gmail.com
> <mailto:voisine at gmail.com>> wrote:
>
> I'm not convinced that wallet seed interoperability is such a great
> thing. There is a wide variability in the quality and security level
> of wallet implementations and platforms. Each new device and wallet
> software a user types their seed into increases their attack surface
> and exposure to flaws. Their security level is reduced to the lowest
> common denominator. I see the need for a "fire exit", certainly, but
> we must also remember that fire exits are potential entrances for
> intruders.
>
> Aaron Voisine
> co-founder and CEO
> breadwallet.com <http://breadwallet.com>;
>
> On Wed, Mar 11, 2015 at 12:46 PM, Gregory Maxwell
> <gmaxwell at gmail.com <mailto:gmaxwell at gmail.com>> wrote:
>
> On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe
> <ricardojdfilipe at gmail.com <mailto:ricardojdfilipe at gmail.com>>
> wrote:
> > i guess you look at the glass half full :)
> > even though what you say is true, we should aim for wallets not to
> > require those instructions, by standardizing these things in BIPs.
> > let's hope bitcoin doesn't fail in standards as our industries have in
> > the past...
>
> There are genuine principled disagreements on how some things should
> be done. There are genuine differences in functionality.
>
> We cannot expect and should not expect complete compatibility.
> If you
> must have complete compatibility: use the same software (or
> maybe not
> even then, considering how poor the forward compatibility of some
> things has been..).
>
> What we can hope to do, and I think the best we can hope to do,
> is to
> minimize the amount of gratuitous incompatibility and reduce the
> amount of outright flawed constructions (so if there are choices
> which
> must be made, they're at least choices among relatively good
> options).
>
> ------------------------------------------------------------------------------
> 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
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> 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
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>

--
devrandom / Miron

📅 Original date posted:2015-02-02 📝 Original message:There ...

2023-06-07T15:29:19Z

In reply to nevent1q…rmu9
_________________________

📅 Original date posted:2015-02-02
📝 Original message:There are a couple of attack vectors to consider:

* The recipient's machine is compromised
* The sender's machine is compromised

BIP-70 and other ways of having the sender verify the destination on a
second device will help protect against sender compromise. For a
person-to-person situation, you could verify the address by voice.

For the case where the recipient is compromised, you would want to
verify the address with the recipient's multisig security service.
Extending BIP-70 to allow multiple signatures would be one way to go
about this. You would at least want to have a web page controlled by
the security service where you can verify addresses.

On 2015-02-02 01:09 PM, Pedro Worcel wrote:
> Where would you verify that?
>
> On 2/3/2015 10:03 AM, Brian Erdelyi wrote:
>> Joel,
>>
>> The mobile device should show you the details of the transaction (i.e.
>> amount and bitcoin address). Once you verify this is the intended
>> recipient and amount you approve it on the mobile device. If the
>> address was replaced, you should see this on the mobile device as it
>> won’t match where you were intending to send it. You can then not
>> provide the second signature.
>>
>> Brian Erdelyi
>>
>>> On Feb 2, 2015, at 4:57 PM, Joel Joonatan Kaartinen
>>> <joel.kaartinen at gmail.com <mailto:joel.kaartinen at gmail.com>> wrote:
>>>
>>> If the attacker has your desktop computer but not the mobile that's
>>> acting as an independent second factor, how are you then supposed to
>>> be able to tell you're not signing the correct transaction on the
>>> mobile? If the address was replaced with the attacker's address,
>>> it'll look like everything is ok.
>>>
>>> - Joel
>>>
>>> On Mon, Feb 2, 2015 at 9:58 PM, Brian Erdelyi
>>> <brian.erdelyi at gmail.com <mailto:brian.erdelyi at gmail.com>> wrote:
>>>
>>>
>>> > Confusing or not, the reliance on multiple signatures as
>>> offering greater security than single relies on the independence
>>> of multiple secrets. If the secrets cannot be shown to retain
>>> independence in the envisioned threat scenario (e.g. a user's
>>> compromised operating system) then the benefit reduces to making
>>> the exploit more difficult to write, which, once written, reduces
>>> to no benefit. Yet the user still suffers the reduced utility
>>> arising from greater complexity, while being led to believe in a
>>> false promise.
>>>
>>> Just trying to make sure I understand what you’re saying. Are
>>> you eluding to that if two of the three private keys get
>>> compromised there is no gain in security? Although the
>>> likelihood of this occurring is lower, it is possible.
>>>
>>> As more malware targets bitcoins I think the utility is evident.
>>> Given how final Bitcoin transactions are, I think it’s worth
>>> trying to find methods to help verify those transactions (if a
>>> user deems it to be high-risk enough) before the transaction is
>>> completed. The balance is trying to devise something that users
>>> do not find too burdensome.
>>>
>>> Brian Erdelyi
>>> ------------------------------------------------------------------------------
>>> 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
>>> <mailto:Bitcoin-development at lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>
>
>
> ------------------------------------------------------------------------------
> 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
>

--
devrandom / Miron

📅 Original date posted:2015-01-14 📝 Original message:At ...

2023-06-07T15:28:29Z

In reply to nevent1q…uatz
_________________________

📅 Original date posted:2015-01-14
📝 Original message:At CryptoCorp we recommend to our customers that they sort
lexicographically by the public key bytes of the leaf public keys. i.e.
the same as BitPay.

On Wed, 2015-01-14 at 17:37 +0100, Ruben de Vries wrote:
> For p2sh multisig TXs the order of the public keys affect the hash and
> there doesn't seem to be an agreed upon way of sorting the public
> keys.
>
>
> If there would be a standard (recommended) way of sorting the public
> keys that would make it easier for services that implement some form
> of multisig to be compatible with each other without much hassle and
> making it possible to import keys from one service to another.
>
>
> I'm not suggesting forcing the order, just setting a standard to
> recommend, there doesn't seem to be much reason for (new) services to
> not follow that recommendation.
>
>
> Ryan from BitPay broad this up before
> (https://sourceforge.net/p/bitcoin/mailman/message/32092958/) and in
> bitcore they've implemented lexicographical sorting on the hex of the
> public key.
> In a short search I can't find any other library that has a sorting
> function, let alone using it by default, so bitcore is currently my
> only reference.
>
>
>
>
> Ruben de Vries
> CTO, BlockTrail
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________ Bitcoin-development mailing list Bitcoin-development at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Miron / devrandom

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

2023-06-07T15:17:05Z

In reply to nevent1q…99rx
_________________________

📅 Original date posted:2014-04-03
📝 Original message:On Thu, 2014-04-03 at 07:51 +0200, Wladimir wrote:
>
> On Thu, Apr 3, 2014 at 6:47 AM, devrandom <c1.sf-bitcoin at niftybox.net>
> wrote:
> Nice!
>
> I wonder how much of this could be scripted.
>
>
> Everything, probably, using vmbuilder (and/or vagrant as Nick Simpson
> suggests). But that's not the point here. It is to provide exact steps
> that people can follow to get a basic (virtual) machine that they can
> use to do gitian builds.

Understood.
>
> I didn't want to end up with a
> gitian-builder-that-builds-a-gitian-builder :-) The host machine may
> not even have any scripting languages installed (in the case of
> Windows).

Yes, I can see the turtles there.
>
>
> It may be possible to script *some* parts (most of the quoted bash
> script is runnable as script) without automating the entire process,
> but I hope that over time we can make Gitian itself easier to
> use/setup, so that less steps are needed in the first place.

Understood. :) I would definitely like to see in Gitian any
improvements that make it easier for newcomers to get started.
>
>
> Wladimir
>
>
>

--
Miron / devrandom

📅 Original date posted:2014-04-03 📝 Original message:Nice! ...

2023-06-07T15:17:04Z

In reply to nevent1q…p2l6
_________________________

📅 Original date posted:2014-04-03
📝 Original message:Nice!

I wonder how much of this could be scripted.

On Wed, 2014-04-02 at 14:27 +0200, Wladimir wrote:
> Hello all,
>
>
> I'm working on a detailed guide on how to install and set up a Debian
> VM for gitian building. As this guide can be used on any operating
> system that has VirtualBox, hopefully this will make it easier for
> people to get started with gitian builds.
>
>
> See https://github.com/bitcoin/bitcoin/pull/3994
>
>
> Rendered version is here:
> https://github.com/laanwj/bitcoin/blob/2014_04_debian_gitian_build_doc/doc/gitian-building.md
>
>
>
> Comments and patches are welcome.
>
> If you bump into problems while following the guide please let me
> know.
>
>
>
> Wladimir
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Miron / devrandom

📅 Original date posted:2014-03-30 📝 Original message:I ...

2023-06-07T15:16:46Z

In reply to nevent1q…2sh8
_________________________

📅 Original date posted:2014-03-30
📝 Original message:I would like to solicit feedback on a whitepaper I wrote about securing
hardware wallets even if the hardware or software is compromised. Let's
consider turning this into a BIP.

Abstract: With wide adoption hardware wallets present a very tempting
target. Once enough wealth is controlled by a specific hardware wallet
model, attacking the supply chain of the wallet becomes attractive.
Malware could be inserted in hardware or software. The random seed could
be generated in a way that is predictable to the attacker or the seed
could be leaked.

The paper describes a way for a "Warden" computer to manage a hardware
wallet in a way that protects the resulting private keys from
compromise.

https://github.com/devrandom/btc-papers/blob/master/hardware-wallet-security.md

--
Miron / devrandom

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

2023-06-07T15:16:44Z

In reply to nevent1q…4wyu
_________________________

📅 Original date posted:2014-03-29
📝 Original message:On Sat, 2014-03-29 at 13:51 -0400, Matt Whitlock wrote:
> On Saturday, 29 March 2014, at 10:48 am, devrandom wrote:
> > On Sat, 2014-03-29 at 13:38 -0400, Matt Whitlock wrote:
> > > Threshold ECDSA certainly sounds nice, but is anyone working on a BIP
> > > for it? I would take it on myself, but I don't understand it well
> > > enough yet, and publicly available information on it seems lacking. I
> > > proposed this Shamir Secret Sharing BIP as an easily understood, easily
> > > implemented measure that we can use today, with no changes to existing
> > > Bitcoin software. It's low-hanging fruit.
> >
> > Good points, although multisig is catching on quickly in the ecosystem.
> > AFAIK, all production wallets can send to p2sh addresses.
>
> As far as I know, Blockchain.info wallets still can't send to P2SH
> addresses. This was a *major* roadblock in the Bitcoin project that
> I've been working on for the past several months, and it was the
> impetus for my creating this Shamir Secret Sharing implementation in
> the first place.

That was true until they merged in my pull request a month ago ;)

https://github.com/blockchain/My-Wallet/pull/59

--
Miron / devrandom

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

2023-06-07T15:16:44Z

In reply to nevent1q…flyn
_________________________

📅 Original date posted:2014-03-29
📝 Original message:On Sat, 2014-03-29 at 13:38 -0400, Matt Whitlock wrote:
> On Saturday, 29 March 2014, at 10:25 am, Dev Random wrote:
> > On Sat, 2014-03-29 at 11:44 -0400, Matt Whitlock wrote:
> > > On Saturday, 29 March 2014, at 11:08 am, Watson Ladd wrote:
> > > > https://freedom-to-tinker.com/blog/stevenag/new-research-better-wallet-security-for-bitcoin/
> > >
> > > Thanks. This is great, although it makes some critical references to an
> > > ACM paper for which no URL is provided, and thus I cannot implement it.
> > >
> > > A distributed ECDSA notwithstanding, we still need a way to decompose a
> > > BIP32 master seed into shares. I am envisioning a scenario in which I
> >
> > It would seem that threshold ECDSA with keys derived from separate seeds
> > has better security properties than one seed that is then split up. The
> > main thing is that there is no single point of attack in the generation
> > or signing.
>
> No contest here. But can threshold ECDSA work with BIP32? In other
> words, can a threshold ECDSA public key be generated from separate,
> precomputed private keys, or can it only be generated interactively?
> Maybe the BIP32 master seeds have to be generated interactively, and
> then all sets of corresponding derived keys are valid signing groups?

That's a good point. In the paper, they have a deterministic wallet
scheme in section 3.3. It is non-interactive, so that's good. On the
other hand, it's not BIP32, so that adds complexity.

>
> Threshold ECDSA certainly sounds nice, but is anyone working on a BIP
> for it? I would take it on myself, but I don't understand it well
> enough yet, and publicly available information on it seems lacking. I
> proposed this Shamir Secret Sharing BIP as an easily understood, easily
> implemented measure that we can use today, with no changes to existing
> Bitcoin software. It's low-hanging fruit.

Good points, although multisig is catching on quickly in the ecosystem.
AFAIK, all production wallets can send to p2sh addresses.

--
Miron / devrandom

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

2023-06-07T15:16:43Z

In reply to nevent1q…7lyj
_________________________

📅 Original date posted:2014-03-29
📝 Original message:On Sat, 2014-03-29 at 11:44 -0400, Matt Whitlock wrote:
> On Saturday, 29 March 2014, at 11:08 am, Watson Ladd wrote:
> > https://freedom-to-tinker.com/blog/stevenag/new-research-better-wallet-security-for-bitcoin/
>
> Thanks. This is great, although it makes some critical references to an
> ACM paper for which no URL is provided, and thus I cannot implement it.
>
> A distributed ECDSA notwithstanding, we still need a way to decompose a
> BIP32 master seed into shares. I am envisioning a scenario in which I

It would seem that threshold ECDSA with keys derived from separate seeds
has better security properties than one seed that is then split up. The
main thing is that there is no single point of attack in the generation
or signing.

> might meet my sudden and untimely demise, and I wish to allow my
> beneficiaries to reconstruct my wallet's master seed after my death. I
> would like to distribute seed shares to each of my beneficiaries and
> some close friends, such that some subset of the shares must be joined
> together to reconstitute my master seed. Shamir's Secret Sharing Scheme
> is perfect for this use case. I am presently working on extending my
> draft BIP so that it also applies to BIP32 master seeds of various
> sizes.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
--
Miron / devrandom

--
--
Miron / devrandom

📅 Original date posted:2014-03-12 📝 Original message:Hi ...

2023-06-07T15:15:18Z

In reply to nevent1q…qe9t
_________________________

📅 Original date posted:2014-03-12
📝 Original message:Hi Ryan,

Probably the most neutral way to go about this is to lexicographically
sort by encoded representation bytes. In java, that would be
ECPoint.getEncoded.

This is what we currently do in our watchdog Oracle.

On Wed, 2014-03-12 at 13:10 -0400, Ryan X. Charles wrote:
> For a p2sh multisig transaction, the serialized script looks like this:
>
> m [pubkey] ... [pubkey] n OP_CHECKMULTISIG
>
> The p2sh address is the hash of this script. The public keys can come in
> any order, but the hash depends on the order. If you have a list of
> public keys, to which address do you send your money? We need a standard
> way of sorting the public keys so that the address generated is always
> the same for the same public keys and m.
>
> There are two kinds of public keys: compressed and uncompressed.
> Uncompressed are longer than compressed.
>
> There are a few obvious ways we could sort the public keys: as strings,
> as big endian numbers, as little endian numbers.
>
> The difference is this. Suppose one public key is 59234 (uncompressed),
> and the other is 6903 (compressed). If we sort these as strings, then
> 6903 > 59234. But if we sort them as big endian numbers, then 6903 is
> really 06903, and then 06903 < 59234. So it makes a critical difference.
> Sorting as little endian is yet another option that is not the same as
> the other two.
>
> I noticed Alan Reiner's comment in an earlier message:
>
> "Just like Jean-Pierre mentioned, we'll be using parallel
> trees to generate P2SH addresses after sorting the keys
> lexicographically."
>
> It sounds like "lexicographically" probably means sorting as strings. I
> have made an implementation of public key sorting in javascript where I
> sort them as big endian numbers and fill in the 0s. IMO, the simpler
> method is to sort them as strings, which has a simpler implementation
> since it doesn't require filling in 0s first. However, I don't actually
> care what method we use so long as everyone in the bitcoin world uses
> the same standard. Which is the best way to sort public keys?
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development