devrandom [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-03-12 to 2015-06-16
💬 Posted a total of 16 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-29 16:47:03

- reply

📅 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

2023-06-07 15:31:29

- reply

📅 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

2023-06-07 15:31:28

- reply

📅 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

2023-06-07 15:28:29

- reply

📅 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

2023-06-07 15:16:44

- reply

📅 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