<unnamed>

Public Key

npub1a04k8w0sg5trcey0tkz04maryv3q76yre2vqj8yrr4lfmf3m999qtyuuph

Profile Code

nprofile1qqswh6mrh8cy293uvj84mp86a73jxgs0dzpu4xqfrjp36l5a5cajjjspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsv7kvzg

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 15:31:38 UTC

- reply

📅 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

2023-06-07 15:31:35 UTC

- reply

📅 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

2023-06-07 15:31:31 UTC

- reply

📅 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

2023-06-07 15:31:29 UTC

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

- 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:29:19 UTC

- reply

📅 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

2023-06-07 15:17:05 UTC

- reply

📅 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

2023-06-07 15:17:04 UTC

- reply

📅 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

2023-06-07 15:16:43 UTC

- reply

📅 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