<unnamed>

Public Key

npub1ad7209g90jnu400x74quws0xv8gpxs2fxnjexnpwqnrxwa39exdq5gl2p6

Profile Code

nprofile1qqswkl98j5zhef72hhn02sw8g8nxr5qng9ynfevnfshqf3n8wcjunxspzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqgvcccs

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-07 15:33:00 UTC

- reply

📅 Original date posted:2015-05-06
📝 Original message:I don't have strong opinion @ block size topic.
But if there'll be a fork, PLEASE, include SIGHASH_WITHINPUTVALUE (
https://bitcointalk.org/index.php?topic=181734.0) or its alternative. All
developers of lightweight (blockchain-less) clients will adore you!
slush
On Thu, May 7, 2015 at 12:12 AM, Matt Corallo <bitcoin-list at bluematt.me>
wrote:
> Recently there has been a flurry of posts by Gavin at
> http://gavinandresen.svbtle.com/ which advocate strongly for increasing
> the maximum block size. However, there hasnt been any discussion on this
> mailing list in several years as far as I can tell.
>
> Block size is a question to which there is no answer, but which
> certainly has a LOT of technical tradeoffs to consider. I know a lot of
> people here have varying levels of strong or very strong opinions about
> this, and the fact that it is not being discussed in a technical
> community publicly anywhere is rather disappointing.
>
> So, at the risk of starting a flamewar, I'll provide a little bait to
> get some responses and hope the discussion opens up into an honest
> comparison of the tradeoffs here. Certainly a consensus in this kind of
> technical community should be a basic requirement for any serious
> commitment to blocksize increase.
>
> Personally, I'm rather strongly against any commitment to a block size
> increase in the near future. Long-term incentive compatibility requires
> that there be some fee pressure, and that blocks be relatively
> consistently full or very nearly full. What we see today are
> transactions enjoying next-block confirmations with nearly zero pressure
> to include any fee at all (though many do because it makes wallet code
> simpler).
>
> This allows the well-funded Bitcoin ecosystem to continue building
> systems which rely on transactions moving quickly into blocks while
> pretending these systems scale. Thus, instead of working on technologies
> which bring Bitcoin's trustlessness to systems which scale beyond a
> blockchain's necessarily slow and (compared to updating numbers in a
> database) expensive settlement, the ecosystem as a whole continues to
> focus on building centralized platforms and advocate for changes to
> Bitcoin which allow them to maintain the status quo[1].
>
> Matt
>
> [1] https://twitter.com/coinbase/status/595741967759335426
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/6bdab3de/attachment.html>

2023-06-07 15:31:31 UTC

- reply

📅 Original date posted:2015-03-12
📝 Original message:On Wed, Mar 11, 2015 at 6:14 PM, Mike Hearn <mike at plan99.net> wrote:
>
> - Electrum v2 with a version number but no date
> - myTREZOR with no version and no date and BIP44 key derivation. Some
> seeds I believe are now being generated with 24 words instead of 12.
> - MultiBit HD with no version and a date in a custom form that creates
> non-date-like codes you are expected to write down. I think BIP32 and BIP44
> are both supported (sorta).
> - GreenAddress with no version, no date and BIP32
> - Other bitcoinj based wallets, with no version and a date written
> down in normal human form, BIP32 only.
>
> To my knowledge, myTREZOR, Multibit HD and GreenAddress uses BIP39, just
different scheme for key derivation (myTREZOR uses full BIP44, Multibit HD
uses BIP44 with first account only and GreenAddress uses another scheme
because it's multisig only wallet).
I disagree with the need of some version "magic flags" or creation date
stored in the mnemnonic, for those reasons:
a) If we fail in the way how mnemonic algo is defined, then some magic,
extra version flag won't save our asses, because we'll fail in meaning of
its meaning. Then it will be completely useless, as implementations cannot
rely on it. I know Thomas was sound proponent of this solution, but he was
unable to give any reasonable rules about who/how define meaning of version
flag.
b) "Creation date" is just a short-term hack. Considering that mnemonic
words are kind of cold storage (longterm storage), it *really* does not
make much difference in 2020, if your wallet has been created in 02/2014 or
10/2016. If there's performance issue with scanning of the blockchain,
creation date don't save our asses. We need to find another solution, and
as a bonus, we don't need users to know some weird numbers on top of
mnemonic itself.
> From my interpretation of BIP39, wordlists DO NOT REQUIRE to be fixed
between wallet providers. There is some recommendations regarding the
wordlists to help with things such as predictive text, so mobile apps can
easily predict the word being typed in after a few chars etc.
Exactly! After some community feedback, we changed BIP39 algo to be one-way
only, which means you can use *any* wordlist to create the mnemonic, and
any other implementation can derive BIP32 root node even without knowing
that particular wordlist. Namely this has been changed because of
constructive criticism of ThomasV, and from discussion on the mailing list
I had a feeling that we've found a consensus. I was *very* surprised that
Electrum 2.0 started to use yet another algo "just because".
Shortly said, I think BIP39 does perfect job and there's no need to use
anything else.
Cheers,
Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150312/318ad491/attachment.html>

2023-06-07 15:29:03 UTC

- reply

📅 Original date posted:2015-01-23
📝 Original message:On Fri, Jan 23, 2015 at 5:05 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> I think this is unreasonable. There is a straight-forward soft-fork
> approach which is safe (e.g. no risk of invalidating existing
> transactions). Yes, it means that you need to use newly created
> addresses to get coins that use the new signature type...
Can you send me any reference about this? Of course if that solves the
problem, hard fork would not be necessary anymore. I'm just not aware of
any.
Can you help me understand whats taking 40 minutes here? Thats a
> surprisingly high number, and so I'm wondering if I'm not missing
> something there.
>
>
To sign transaction with hundreds of inputs on device with limited memory
capabilities, I need to stream all previous transactions into device, for
every signed input.
That means roughly 200^2 transaction verifications for 200 inputs to sign.
Very slow, but does not limit the device for any particular size of signed
transaction.
Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150123/26b40164/attachment.html>

2023-06-07 15:29:03 UTC

- reply

📅 Original date posted:2015-01-23
📝 Original message:Yes, the step you're missing is "and build the table". Dynamic memory
allocation is something you want to avoid, as well as any artifical
restrictions to number of inputs or outputs. Current solution is slow, but
there's really no limitation on tx size.
Plus there're significant restrictions to memory in embedded world.
Actually TREZOR uses pretty powerful (and expensive) MCU just because it
needs to do such validations and calculate such hashes. With
SIGHASH_WITHINPUTVALUE or similar we may cut hardware cost significantly.
Marek
On Fri, Jan 23, 2015 at 5:52 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> I'm not sure where the ^2 is coming from. So what I'd understand that
> you'd do is stream in the input txid:vouts which you spend, then you'd
> stream the actual inputs which would just be hashed and value
> extracted (but no other verification), and you'd build a table of
> txid:vout->value, then the actual transaction to be signed.
>
> This should have O(inputs) hashing and communications overhead. Is
> there a step I'm missing?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150123/20ba09ee/attachment.html>

2023-06-07 15:29:02 UTC

- reply

📅 Original date posted:2015-01-23
📝 Original message:> I *strongly* encourage this to be considered for inclusion at some point.
Thanks Alan for a nice summary. I also agree that such stuff should be
implemented at some point. Anyway, I would probably not vote for doing hard
fork *just* for this change, but if I remember well, there're other ideas
flying around in the air and waiting for hardfork...
Marek
On Fri, Jan 23, 2015 at 4:24 PM, Alan Reiner <etotheipi at gmail.com> wrote:
> The SIGHASH_WITHINPUTVALUE proposal is a hardfork, but otherwise
> non-intrusive, doesn't change any TxOut scripts, doesn't change any
> tx/block parsing (besides verification), it works with all existing coins
> in the network, and existing software doesn't have to use it if they don't
> want to upgrade their signers. The proposal simply provides a way to
> optionally sign the input values with the TxOut scripts. In other words a
> signature right now says "I sign this transaction using these inputs,
> whatever value they are." With this SIGHASH type, the signature says "I
> sign this transaction assuming that input 0 is X BTC, input 1 is Y
> BTC,....". If the online computer providing the data to be signed lies
> about the value of any input, the resulting signature will be invalid.
>
> Unfortunately, it seems that there was no soft-fork way to achieve this
> benefit, at least not one that had favorable properties. Most of the
> soft-fork variations of it required the coins being spent to have been
> originated in a special way. In other words, it would only work if the
> coins had entered the wallet with some special, modified TxOut script. So
> it wouldn't work with existing coins, and would require senders to update
> their software to reshape the way they send transactions to be compatible
> with our goals.
>
> I *strongly* encourage this to be considered for inclusion at some
> point. Not only does it simplify HW as Marek suggested, it increases the
> options for online-offline communication channels, which is also a win for
> security. Right now, QR codes don't work because of the possibility of
> having to transfer megabytes over the channel, and no way to for the signer
> to control that size. With this change, it's possible for the signer to
> control the size of each chunk of data to guarantee it fits in, say, a QR
> code (even if it means breaking it up into a couple smaller transactions).
>
> -Alan
>
>
>
>
> On 01/23/2015 09:51 AM, slush wrote:
>
> Hi,
>
> is any progress or even discussion in this area?
>
> https://bitcointalk.org/index.php?topic=181734.0
>
> I don't insist on any specific solution, but this is becoming a real
> issue as hardware wallets are more widespread. I'm sitting next to TREZOR
> for 40 minutes already, because it streams and validate some complex
> transaction. By using proposed solution, such signature would be a matter
> of few seconds.
>
> That's also not just about time/resource/hw cost optimization. I'm
> talking about possibility of huge simplification of the firmware (=security
> FTW), because 50% of actual codebase is solving this particular downside of
> Bitcoin protocol.
>
> So, there's real world problem. On which solution can we as a community
> find a wide agreement?
>
> Best,
> Marek
>
>
> ------------------------------------------------------------------------------
> 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 listBitcoin-development at lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> 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
> T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150123/0b4fa4b3/attachment.html>

2023-06-07 15:29:02 UTC

- reply

📅 Original date posted:2015-01-23
📝 Original message:Hi,
is any progress or even discussion in this area?
https://bitcointalk.org/index.php?topic=181734.0
I don't insist on any specific solution, but this is becoming a real issue
as hardware wallets are more widespread. I'm sitting next to TREZOR for 40
minutes already, because it streams and validate some complex transaction.
By using proposed solution, such signature would be a matter of few seconds.
That's also not just about time/resource/hw cost optimization. I'm talking
about possibility of huge simplification of the firmware (=security FTW),
because 50% of actual codebase is solving this particular downside of
Bitcoin protocol.
So, there's real world problem. On which solution can we as a community
find a wide agreement?
Best,
Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150123/30a6ffb5/attachment.html>

2023-06-07 15:20:37 UTC

- reply

📅 Original date posted:2014-05-03
📝 Original message:Excellent points Christophe!
Although moving to 1e-6 units is fine for me and I see advantages of doing
this, I don't get that people on this mailing list are fine with calling
such unit "bit". It's geeky as hell, ambiguous and confusing.
slush
On Sat, May 3, 2014 at 5:48 PM, Christophe Biocca <
christophe.biocca at gmail.com> wrote:
> Context as a disambiguator works fine when the interlocutors
> understand the topics they're talking about.
> Not a day goes by without me seeing "neurotypical people" get horribly
> confused between RAM and Hard Drive sizes, because they share the same
> units (not that that can be helped, as the units are supposed to be
> the same, base 1000 vs 1024 notwithstanding).
>
> Bit (as a unit) is already really confusing for anyone who doesn't
> deal with it on a regular basis. I think people who don't see an issue
> are making an assumption based on their own lack of confusion. We
> understand computer science AND Bitcoin. Most people have zero
> understanding of either.
>
> Bitcoin already has a ton of issues with terrible names for things:
>
> - Mining (for transaction validation).
> - Addresses (which are meant to be one-time use, and don't even really
> exist at the network level).
> - Wallets (which don't hold your bitcoins, can be copied, and all
> backups can be stolen from equally).
>
> I end up having to make the distinctions obvious every time I explain
> Bitcoin to someone new to it. There's an acceptable tradeoff here,
> because there were arguably no better words to assign to these
> concepts (although I'd argue mining is a really awful metaphor, and is
> the one that prompts the most questions from people). Then add to the
> pile a bunch of third parties naming themselves after parts of the
> protocol (Coinbase,Blockchain.info). Not blaming them for it, but I've
> definitiely seen average people get confused between "the blockchain"
> and "blockchain.info" (not so much Coinbase, because that name doesn't
> come up in beginner explanations).
>
> It seems downright masochistic to add
> yet-another-word-that-doesn't-mean-what-you-think-it-means to the pile
> for no reason other than aesthetics. Are we actively trying to confuse
> people?
>
> On Sat, May 3, 2014 at 1:41 AM, Aaron Voisine <voisine at gmail.com> wrote:
> > I have to agree with Mike. Human language is surprisingly tolerant of
> > overloading and inference from context. Neurotypical people have no
> > problem with it and perceive a software engineer's aversion to it as
> > being pedantic and strange. Note that "bits" was a term for a unit of
> > money long before the invention of digital computers.
> >
> > Aaron
> >
> > There's no trick to being a humorist when you have the whole
> > government working for you -- Will Rodgers
> >
> >
> > On Fri, May 2, 2014 at 7:06 PM, Gordon Mohr <gojomo at gmail.com> wrote:
> >> [resend - apologies if duplicate]
> >>
> >> Microbitcoin is a good-sized unit, workable for everyday transaction
> >> values, with room-to-grow, and a nice relationship to satoshis as
> 'cents'.
> >>
> >> But "bits" has problems as a unit name.
> >>
> >> "Bits" will be especially problematic whenever people try to graduate
> >> from informal use to understanding the system internals - that is, when
> >> the real "bits" of key sizes, hash sizes, and storage/bandwidth needs
> >> become important. The "bit" as "binary digit" was important enough that
> >> Satoshi named the system after it; that homage gets lost if the word is
> >> muddied with a new retconned meaning that's quite different.
> >>
> >> Some examples of possible problems:
> >>
> >> * If "bit" equals "100 satoshis", then the natural-language unpacking of
> >> "bit-coin" is "100 satoshi coin", which runs against all prior usage.
> >>
> >> * If people are informed that a "256-bit private key" is what ultimately
> >> controls their balances, it could prompt confusion like, "if each key
> >> has 256-bits, will I need 40 keys to hold 10,000.00 bits?"
> >>
> >> * When people learn that there are 8 bits to a byte, they may think,
> >> "OK, my wallet holding my 80,000.00 bits will then take up 10
> kilobytes".
> >>
> >> * When people naturally extend "bit" into "kilobits" to mean "1000
> >> bits", then the new coinage "kilobits" will mean the exact same amount
> >> (100,000 satoshi) as many have already been calling "millibits".
> >>
> >> I believe it'd be best to pick a new made-up single-syllable word as a
> >> synonym for "microbitcoin", and I've laid out the case for "zib" as that
> >> word at <http://zibcoin.org>.
> >>
> >> 'Zib' also lends itself to an expressive unicode symbol, 'Ƶ'
> >> (Z-with-stroke), that remains distinctive even if it loses its stroke or
> >> gets case-reversed. (Comparatively, all 'b'-derived symbols for
> >> data-bits, bitcoins, or '100 satoshi bits' risk collision in contexts
> >> where subtleties of casing/stroking are lost.)
> >>
> >> (There's summary of more problems with "bit" in the zibcoin.org FAQ
> at:
> >> <http://zibcoin.org/faq#why-not-bits-to-mean-microbitcoins>.)
> >>
> >> - Gordon
> >>
> >> On 5/1/14, 3:35 PM, Aaron Voisine wrote:
> >>> I'm also a big fan of standardizing on microBTC as the standard unit.
> >>> I didn't like the name "bits" at first, but the more I think about it,
> >>> the more I like it. The main thing going for it is the fact that it's
> >>> part of the name bitcoin. If Bitcoin is the protocol and network, bits
> >>> are an obvious choice for the currency unit.
> >>>
> >>> I would like to propose using Unicode character U+0180, lowercase b
> >>> with stroke, as the symbol to represent the microBTC denomination,
> >>> whether we call bits or something else:
> >>> http://www.fileformat.info/info/unicode/char/0180/index.htm
> >>>
> >>> Another candidate is Unicode character U+2422, the blank symbol, but I
> >>> prefer stroke b.
> >>> http://www.fileformat.info/info/unicode/char/2422/index.htm
> >>>
> >>> Aaron
> >>>
> >>> There's no trick to being a humorist when you have the whole
> >>> government working for you -- Will Rodgers
> >>>
> >>>> On Apr 21, 2014 5:41 AM, "Pieter Wuille" <pieter.wuille at gm...> wrote:
> >>>>
> >>>>> On Apr 21, 2014 3:37 AM, "Un Ix" <slashdevnull at ...> wrote:
> >>>>>
> >>>>> Something tells me this would be reduced to a single syllable in
> common
> >>>>> usage I.e. bit.
> >>>>
> >>>> What units will be called colloquially is not something developers
> will
> >>>> determine. It will vary, depend on language and culture, and is not
> >>>> relevant to this discussion in my opinion.
> >>>>
> >>>> It may well be that people in some geographic or language area will
> end up
> >>>> (or for a while) calling 1e-06 BTC "bits". That's fine, but using
> that as
> >>>> "official" name in software would be very strange and potentially
> confusing
> >>>> in my opinion. As mentioned by others, that would seem to me like
> calling
> >>>> dollars "bucks" in bank software. Nobody seems to have a problem with
> >>>> having colloquial names, but "US dollar" or "euro" are far less
> ambiguous
> >>>> than "bit". I think we need a more distinctive name.
> >>>>
> >>>> --
> >>>> Pieter
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> >>> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> >>> unparalleled scalability from the best Selenium testing platform
> available.
> >>> Simple to use. Nothing to install. Get started now for free."
> >>> http://p.sf.net/sfu/SauceLabs
> >>> _______________________________________________
> >>> Bitcoin-development mailing list
> >>> Bitcoin-development at lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>
> >>
> >>
> ------------------------------------------------------------------------------
> >> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> >> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> >> unparalleled scalability from the best Selenium testing platform
> available.
> >> Simple to use. Nothing to install. Get started now for free."
> >> http://p.sf.net/sfu/SauceLabs
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
> ------------------------------------------------------------------------------
> > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> > Instantly run your Selenium tests across 300+ browser/OS combos. Get
> > unparalleled scalability from the best Selenium testing platform
> available.
> > Simple to use. Nothing to install. Get started now for free."
> > http://p.sf.net/sfu/SauceLabs
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140503/0822abf5/attachment.html>

2023-06-07 15:18:20 UTC

- reply

📅 Original date posted:2014-04-09
📝 Original message:We definitely *need* lightweight bitcoin router / "core" which can be
easily deployed anywhere. No disagreement here.
I just wanted to remind that there're actually much more running nodes
*already* and maybe converting those hidden nodes to publicly reachable
nodes may be way easier than attracting fresh instances.
To the idea of bundled core with SPV clients - it won't improve anything,
in my opinion. SPV wallets are not running long-term (maybe Multibit team
has any better stats) so blockchain catching will turn the computer to be
unusable everytime user starts the wallet; that's exactly the reason why
people choose SPV wallets over full blockchain wallets.
Not saying that SPV clients usually aren't reachable from outside, which
turns the topic back to my ideas about motivating users to expose their
existing instances over Internet.
Marek
On Wed, Apr 9, 2014 at 10:35 PM, Wladimir <laanwj at gmail.com> wrote:
>
>
> On Wed, Apr 9, 2014 at 10:12 PM, slush <slush at centrum.cz> wrote:
>
>> Maybe there're other ideas how to improve current situation without needs
>> of reworking the architecture.
>>
>
> Nothing I've proposed here would require larger changes to the
> architecture then were already planned. After SPV lands we are going to
> split off the wallet, and that will need an interface to an bitcoind to
> allow 'running with full node'. If that can be generalized to be useful for
> other (SPV) clients as well, that would be useful, hence I asked for input.
>
> It of course doesn't preclude also looking for other solutions.
>
> Wladimir
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140409/a49a8414/attachment.html>

2023-06-07 15:18:18 UTC

- reply

📅 Original date posted:2014-04-09
📝 Original message:Another idea: Integrate torrent download of bootstrap.dat into bitcoind.
Normal user (especially a beginner) won't learn how to download bootstrap
separately and import it into bitcoind; he simply give up the
synchronization once he realize it takes too much time. From my experience
downloading the bootstrap significantly improves catching the blockchain,
which may attract some more users to run bitcoind.
Not sure about C++, but simple torrent client in python is like 30 lines of
code (using libtorrent).
Marek
On Wed, Apr 9, 2014 at 10:12 PM, slush <slush at centrum.cz> wrote:
> I believe there're plenty bitcoind instances running, but they don't have
> configured port forwarding properly.There's uPNP support in bitcoind, but
> it works only on simple setups.
>
> Maybe there're some not yet considered way how to expose these *existing*
> instances to Internet, to strenghten the network. Maybe just self-test
> indicating the node is not reachable from outside (together with short
> howto like in some torrent clients).
>
> These days IPv6 is slowly deploying to server environments, but maybe
> there's some simple way how to bundle ipv6 tunnelling into bitcoind so any
> instance will become ipv6-reachable automatically?
>
> Maybe there're other ideas how to improve current situation without needs
> of reworking the architecture.
>
> Marek
>
>
> On Wed, Apr 9, 2014 at 9:33 PM, Gregory Maxwell <gmaxwell at gmail.com>wrote:
>
>> On Wed, Apr 9, 2014 at 11:58 AM, Justus Ranvier <justusranvier at gmail.com>
>> wrote:
>> > Anyone reading the archives of the list will see about triple the
>> > number of people independently confirming the resource usage problem
>> > than they will see denying it, so I'm not particularly worried.
>>
>> The list has open membership, there is no particular qualification or
>> background required to post here. Optimal use of an information source
>> requires critical reading and understanding the limitations of the
>> medium. Counting comments is usually not a great way to assess
>> technical considerations on an open public forum. Doubly so because
>> those comments were not actually talking about the same thing I am
>> talking about.
>>
>> Existing implementations are inefficient in many known ways (and, no
>> doubt, some unknown ones). This list is about developing protocol and
>> implementations including improving their efficiency. When talking
>> about incentives the costs you need to consider are the costs of the
>> best realistic option. As far as I know there is no doubt from anyone
>> technically experienced that under the current network rules full
>> nodes can be operated with vastly less resources than current
>> implementations use, it's just a question of the relatively modest
>> implementation improvements.
>>
>> When you argue that Bitcoin doesn't have the right incentives (and
>> thus something??) I retort that the actual resource _requirements_ are
>> for the protocol very low. I gave specific example numbers to enable
>> correction or clarification if I've said something wrong or
>> controversial. Pointing out that existing implementations are not that
>> currently as efficient as the underlying requirements and that some
>> large number of users do not like the efficiency of existing
>> implementations doesn't tell me anything I disagree with or didn't
>> already know. Whats being discussed around here contributes to
>> prioritizing improvements over the existing implementations.
>>
>> I hope this clarifies something.
>>
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140409/e99a782c/attachment.html>

2023-06-07 15:18:18 UTC

- reply

📅 Original date posted:2014-04-09
📝 Original message:I believe there're plenty bitcoind instances running, but they don't have
configured port forwarding properly.There's uPNP support in bitcoind, but
it works only on simple setups.
Maybe there're some not yet considered way how to expose these *existing*
instances to Internet, to strenghten the network. Maybe just self-test
indicating the node is not reachable from outside (together with short
howto like in some torrent clients).
These days IPv6 is slowly deploying to server environments, but maybe
there's some simple way how to bundle ipv6 tunnelling into bitcoind so any
instance will become ipv6-reachable automatically?
Maybe there're other ideas how to improve current situation without needs
of reworking the architecture.
Marek
On Wed, Apr 9, 2014 at 9:33 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Wed, Apr 9, 2014 at 11:58 AM, Justus Ranvier <justusranvier at gmail.com>
> wrote:
> > Anyone reading the archives of the list will see about triple the
> > number of people independently confirming the resource usage problem
> > than they will see denying it, so I'm not particularly worried.
>
> The list has open membership, there is no particular qualification or
> background required to post here. Optimal use of an information source
> requires critical reading and understanding the limitations of the
> medium. Counting comments is usually not a great way to assess
> technical considerations on an open public forum. Doubly so because
> those comments were not actually talking about the same thing I am
> talking about.
>
> Existing implementations are inefficient in many known ways (and, no
> doubt, some unknown ones). This list is about developing protocol and
> implementations including improving their efficiency. When talking
> about incentives the costs you need to consider are the costs of the
> best realistic option. As far as I know there is no doubt from anyone
> technically experienced that under the current network rules full
> nodes can be operated with vastly less resources than current
> implementations use, it's just a question of the relatively modest
> implementation improvements.
>
> When you argue that Bitcoin doesn't have the right incentives (and
> thus something??) I retort that the actual resource _requirements_ are
> for the protocol very low. I gave specific example numbers to enable
> correction or clarification if I've said something wrong or
> controversial. Pointing out that existing implementations are not that
> currently as efficient as the underlying requirements and that some
> large number of users do not like the efficiency of existing
> implementations doesn't tell me anything I disagree with or didn't
> already know. Whats being discussed around here contributes to
> prioritizing improvements over the existing implementations.
>
> I hope this clarifies something.
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140409/477817a3/attachment.html>

2023-06-07 15:18:01 UTC

- reply

📅 Original date posted:2014-04-23
📝 Original message:On Wed, Apr 23, 2014 at 10:54 PM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
>
> Would you consider software which scans all accounts as specified by
> BIP64, but has no user interface option to distinguish them in any
> way, view them independently, and has no ability to keep the coins
> apart... compatible with BIP64?
>
>
No, because one of requirement of BIP64 is to do not mix addressess between
accounts. Without handling those accounts fully, it won't pass this
requirement.
("This level [accounts] splits the key space into independent user
identities, so the wallet never mixes the coins across different accounts.")
Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/a6be1997/attachment.html>

2023-06-07 15:17:56 UTC

- reply

📅 Original date posted:2014-04-23
📝 Original message:On Wed, Apr 23, 2014 at 9:55 PM, Luke-Jr <luke at dashjr.org> wrote:
> Any wallet should import all the coins just fine, it just wouldn't *use*
> any
> account other than 0. Remember addresses are used to receive bitcoins; once
> the UTXOs are in the wallet, they are no longer associated with the
> address or
> any other details of how they were received.
>
Wallet don't see UTXO until it scans all branches/accounts on HD node
import.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/d88cb7b2/attachment.html>

2023-06-07 15:17:55 UTC

- reply

📅 Original date posted:2014-04-23
📝 Original message:We do not want BIP64 to be incompatible with BIP32 in any way. BIP64 is
just set of some recommendations for wallet developers how to browse bip32
tree.
Modifying serialization format would break the compatibility.
However we have our solution for storing wallet birth time, which is out of
scope of BIP64, but we'll communicate it as soon as we'll write down that
idea to some more specific format.
Marek
On Wed, Apr 23, 2014 at 9:36 PM, Tamas Blummer <tamas at bitsofproof.com>wrote:
> Pieter suggested in IRC couple of months ago to append key birth to key
> serialization in xprv.... at unixtime format.
>
> What about picking this idea up in BIP64? It would greatly help the
> importing client.
>
> Regards,
>
> Tamas Blummer
> http://bitsofproof.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/db8776a4/attachment.html>

2023-06-07 15:17:54 UTC

- reply

📅 Original date posted:2014-04-23
📝 Original message:Using higher gap limit in the software is not prohibited, but then it
breaks the standard "as is", in mean that importing such wallet to another
BIP64 wallet won't recover the funds properly, without proper settings of
gap limit...
Gap limit 20 is the most sane defaults for majority of users (actually I
think it is a bit higher than is really necessary for 99% users) and
majority of users won't need to change it at any time.
Marek
On Wed, Apr 23, 2014 at 9:00 PM, Tier Nolan <tier.nolan at gmail.com> wrote:
> On Wed, Apr 23, 2014 at 7:46 PM, Pavol Rusnak <stick at gk2.sk> wrote:
>
>>
>> > Setting the gap limit to high is just a small extra cost in that case.
>>
>> Not if you have 100 accounts on 10 different devices.
>>
>
> I meant for a merchant with a server that is handing out hundreds of
> addresses.
>
> The point is to have a single system that is compatible over a large
> number of systems.
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/73fa1ccd/attachment.html>

2023-06-07 15:17:53 UTC

- reply

📅 Original date posted:2014-04-23
📝 Original message:For those who don't follow github pull requests regularly; there's pull
request for BIP64 defining HD wallet structure as discussed in this thread:
https://github.com/bitcoin/bips/pull/52
On Wed, Apr 23, 2014 at 8:01 PM, slush <slush at centrum.cz> wrote:
>
>
>
> On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
>>
>> Storing the seed is superior to storing the master node already
>> (whether coin specific or not), as it is smaller.
>>
>>
> ...Except that you're loosing flexibility (serialization, deserialization)
> which gives you BIP32 node.
>
> I see "bip32 seed" as some transitional, internal state from raw entropy
> to bip32 master node and this seed should not be handled by the end user in
> any form. In the oposite, well-serialized bip32 node (in xpriv, or even in
> mnemonic format) can be used very widely and have no downsides against
> using raw "bip32 seed".
>
>
>>
>> Fair enough, it would break strictly BIP32. Then again, BIP32 is a
>> *Bitcoin* improvement proposal, and not something that necessarily
>> applies to other coins (they can adopt it of course, I don't care).
>>
>>
> I also don't care too much about altcoins, but people want them so me, as
> infrastructure developer, need to think about it. And I don't see any
> reason for breaking compatibility between Bitcoin and other altcoins. I
> would be happier if there will be another sentence than "Bitcoin seed", but
> honestly, who cares. It is just some magic string for hashing the raw
> seed...
>
>
>> What I dislike is that this removes the ability of using the magic in
>> the serialization to prevent importing a chain from the wrong coin.
>>
>
> The truth is that even existing software which handle bip32 don't care
> about 'version' at all. I think that "xpub/xprv" distinction is the only
> useful feature of version, so user se if it stores public or private
> information.
>
> But using prefixes which doesn't enforce anything is even more dangerous.
> If somebody exports node "dogeblablabla", it creates false exceptations
> that there's only dogecoin stored.
>
> Marek
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/ffd687fd/attachment.html>

2023-06-07 15:17:52 UTC

- reply

📅 Original date posted:2014-04-23
📝 Original message:On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
>
> Storing the seed is superior to storing the master node already
> (whether coin specific or not), as it is smaller.
>
>
...Except that you're loosing flexibility (serialization, deserialization)
which gives you BIP32 node.
I see "bip32 seed" as some transitional, internal state from raw entropy to
bip32 master node and this seed should not be handled by the end user in
any form. In the oposite, well-serialized bip32 node (in xpriv, or even in
mnemonic format) can be used very widely and have no downsides against
using raw "bip32 seed".
>
> Fair enough, it would break strictly BIP32. Then again, BIP32 is a
> *Bitcoin* improvement proposal, and not something that necessarily
> applies to other coins (they can adopt it of course, I don't care).
>
>
I also don't care too much about altcoins, but people want them so me, as
infrastructure developer, need to think about it. And I don't see any
reason for breaking compatibility between Bitcoin and other altcoins. I
would be happier if there will be another sentence than "Bitcoin seed", but
honestly, who cares. It is just some magic string for hashing the raw
seed...
> What I dislike is that this removes the ability of using the magic in
> the serialization to prevent importing a chain from the wrong coin.
>
The truth is that even existing software which handle bip32 don't care
about 'version' at all. I think that "xpub/xprv" distinction is the only
useful feature of version, so user se if it stores public or private
information.
But using prefixes which doesn't enforce anything is even more dangerous.
If somebody exports node "dogeblablabla", it creates false exceptations
that there's only dogecoin stored.
Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/8d56414d/attachment.html>

2023-06-07 15:17:52 UTC

- reply

📅 Original date posted:2014-04-08
📝 Original message:On Tue, Apr 8, 2014 at 3:53 PM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
> I see the cause of our disagreement now.
>
> You actually want to share a single BIP32 tree across different
> currency types, but do it in a way that guarantees that they never use
> the same keys.
>
> I would have expected that different chains would use independent
> chains, and have serializations encode which chain they belong to.
>
> Let me offer an alternative suggestion, which is compatible with the
> original default BIP32 structure:
> * You can use one seed across different chains, but the master nodes
> are separate.
> * To derive the master node from the seed, the key string "Bitcoin
> seed" is replaced by something chain-specific.
>
I've discussed the solution of "Litecoin seed" in BIP32 HMAC with Litecoin
devs already, and after long discussion we've concluded that it is
generally bad idea.
When changing "Bitcoin seed" constant to something different, same
*entropy* will produce different *master node*. That's actually the
opposite what's requested, because xprv serialization format stores *node*,
not *entropy*. By changing HMAC constant, you still won't be able to store
one node and derive wallets for multiple coins at same time.
> * Every encoded node (including master nodes) has a chain-specific
> serialization magic.
>
This is in practice almost the same as your suggestion, except that
> the m/cointype' in m/cointype'/account'/change/n is replaced by
> different masters. The only disadvantage I see is that you do not have
> a way to encode the "super master" that is the parent of all
> chain-specific masters. You can - and with the same security
> properties - encode the seed, though.
>
>
Actually I don't understand why there's such disagreement about "cointype"
level here, what it breaks? I see it as the cleanest solution so far. It is
forward and backward compatible, does need any special extension to bip32
(to be strict, bip32 says "Bitcoin seed", so client using "Litecoin seed"
cannot be "bip32 compatible").
Of course, the problem of "cointype" can be solved in zillion ways, but
still using cointype in bip32 path seem to be the most elegant way so far,
because it fullfill all requirements for single backup, for separating
pubkeys and for handling all coins by one master...
Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140408/5da80ea7/attachment.html>

2023-06-07 15:17:50 UTC

- reply

📅 Original date posted:2014-04-08
📝 Original message:On Tue, Apr 8, 2014 at 3:18 PM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
> I still don't understand the purpose of cointype. If you don't want to
> risk reusing the same keys across different currencies, just don't use
> the same seed or the same account? That is purely a client-side issue.
>
>
Of course it is purely client-side issue, but it matters.
There's actually no reason to generate, backup and store individual seeds
for various coins and purposes. User can handle all his identities and
altcoins with single seed, avoiding potential issues with using wrong seed
for other purposes.
Actually with accounts and cointypes in the path, you can have all your
crypto funds stored on single seed, which I see as very comfortable
solution.
But to gain advantages of such solution and avoid reusing the same path
across blockchains, we need to separate the space, which is achieved by
cointype.
> If the consensus is to add the cointype anyway, can we fix it to be
> equal to the 4-byte magic in the serialization (after setting the high
> bit to true)? That way there aren't two 4-byte magic codes that need
> to be defined for each, and at the same time make it obvious from the
> serialized form what it is for.
>
>
Serialization magic of bip32 seed is in my opinion completely unnecessary.
Most of software does not care about it anyway; You can use xprv/xpub pair
for main net, testnet, litecoin, dogecoin, whatevercoin.
Instead using the same seed (xprv) and then separate the chains *inside*
the bip32 path seems more useful to me.
Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140408/1e5227bc/attachment.html>

2023-06-07 15:17:50 UTC

- reply

📅 Original date posted:2014-04-08
📝 Original message:tl;dr;
It is dangerous to expect that other seed than "xprv" does not contain
bitcoins or that "xprv" contains only bitcoins, because technically are
both situations possible. It is still safer to do the lookup; the magic
itself is ambiguous.
Marek
On Tue, Apr 8, 2014 at 3:40 PM, slush <slush at centrum.cz> wrote:
>
> Serialization magic of bip32 seed is in my opinion completely unnecessary.
> Most of software does not care about it anyway; You can use xprv/xpub pair
> for main net, testnet, litecoin, dogecoin, whatevercoin.
>
> Instead using the same seed (xprv) and then separate the chains *inside*
> the bip32 path seems more useful to me.
>
> Marek
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140408/8f510949/attachment.html>

2023-06-07 15:17:49 UTC

- reply

📅 Original date posted:2014-04-08
📝 Original message:After some off-list discussion about details with wallet developers, it
seems that structure
m/<cointype>'/<account>'/<change>/<n>
fulfill requirements of all wallet developers around, including myTrezor,
Electrum, Multibit, Wallet32 and other software is willing to adapt once
anything will be standardized (i.e. they don't care).
Because I think that everybody told their comments to the topic already and
because it seems that there's quite wide agreement on that, I would like to
close the discussion and finally implement these paths into our software.
Cheers,
Marek
On Fri, Mar 28, 2014 at 3:59 PM, slush <slush at centrum.cz> wrote:
> I agree that 'version' field of bip32 is not necessary and xpriv/xpub
> should be enough for all cases; there's actually no need to use different
> BIP32 roots for different altcoins.
>
> I'm happily using one xpub for Bitcoin/Testnet/Litecoin at once, and by
> having the "cointype" distinction in the bip32 path itself, I'm sure that I
> don't reuse the same pubkey across blockchains which may be a privacy issue
> otherwise.
>
> Marek
>
>
> On Thu, Mar 27, 2014 at 5:28 PM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
>
>> On Thu, Mar 27, 2014 at 5:21 PM, Pavol Rusnak <stick at gk2.sk> wrote:
>> > Cointype in path is for separation purposes, not for identification.
>>
>> I don't understand what that gains you.
>>
>> --
>> Pieter
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140408/3409249a/attachment.html>

2023-06-07 15:16:20 UTC

- reply

📅 Original date posted:2014-03-28
📝 Original message:I agree that 'version' field of bip32 is not necessary and xpriv/xpub
should be enough for all cases; there's actually no need to use different
BIP32 roots for different altcoins.
I'm happily using one xpub for Bitcoin/Testnet/Litecoin at once, and by
having the "cointype" distinction in the bip32 path itself, I'm sure that I
don't reuse the same pubkey across blockchains which may be a privacy issue
otherwise.
Marek
On Thu, Mar 27, 2014 at 5:28 PM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
> On Thu, Mar 27, 2014 at 5:21 PM, Pavol Rusnak <stick at gk2.sk> wrote:
> > Cointype in path is for separation purposes, not for identification.
>
> I don't understand what that gains you.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140328/8b081833/attachment.html>

2023-06-07 15:16:05 UTC

- reply

📅 Original date posted:2014-03-25
📝 Original message:I fully agree, please keep friendly environment on this list. Btw I also
met people who were making fun about Peter's reactions on bitcoin-dev.
slush
On Tue, Mar 25, 2014 at 7:02 PM, Alan Reiner <etotheipi at gmail.com> wrote:
> I would echo the need for some kind of moderation.
>
> I believe Peter Todd is an extremely intelligent individual, who has a
> lot to offer the Bitcoin community. He has a firm grasp of a lot of
> really deep Bitcoin concepts and his *technical* insight is generally
> positive. Technically. But the way he communicates on this list is
> *extremely* corrosive and breeds hostility. It makes it a scary place
> to discuss things, with frequent, public ridicule of everything posted.
>
> I agree that I would rather have a friendly environment to discuss
> technicals, even if it means losing additional technical insight.
> People who would explicitly insult other contributors intelligence and
> character on a public list should be subject to some kind of negative
> reinforcement. Maybe there's solutions other than outright banning.
>
> -Alan
>
>
>
> On 03/25/2014 01:37 PM, Jeff Garzik wrote:
> > On Tue, Mar 25, 2014 at 9:49 AM, Peter Todd <pete at petertodd.org> wrote:
> >> For someone with 'Chief Scientist' as their job title, I'm surprised you
> >> think so little of hard evidence and so much of idol worshipping.
> > Peter, take this unprofessional, personal crap off-list.
> >
> > Mike's anecdote of hostility is not an isolated one. Just today, a
> > bitcore developer commented on "Peter Todd's ..apocalyptic vision
> > and... negative view on bitcoin" which turned off some other
> > developers from participating more interactively.
> >
> > As I commented on IRC, open source projects are no strangers to people
> > who simultaneously (a) make useful contributions and (b) turn
> > potential contributors away with an abrasive or hostile attitude
> > toward others. It's an unsolved problem in OSS, that I saw for 15+
> > years in the Linux kernel community.
> >
> > For this list, as Mike suggested on IRC, introducing an openly stated
> > moderation policy may be the one route.
> >
>
>
>
> ------------------------------------------------------------------------------
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140325/5e203215/attachment.html>

2023-06-07 15:15:38 UTC

- reply

📅 Original date posted:2014-03-13
📝 Original message:Internal accounting in satoshis.
Display based on locale.
Problem solved.
On Thu, Mar 13, 2014 at 5:30 PM, Tamas Blummer <tamas at bitsofproof.com>wrote:
> BTW, its not like this would be the first time this was raised, instead
> the "ship left" while ignoring arguments.
>
> The idea of is up there for votes since March 2013
> https://bitcointalk.org/index.php?topic=149150.0
> and received the most votes.
>
> I remembered this last time on this list here:
>
> http://sourceforge.net/p/bitcoin/mailman/message/31640769/
>
> Regards,
>
> Tamas Blummer
> Founder, CEO
> Bits of Proof
> http://bitsofproof.com
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140313/bdd70ddb/attachment.html>

2023-06-07 15:12:23 UTC

- reply

📅 Original date posted:2014-01-20
📝 Original message:On Tue, Jan 21, 2014 at 12:06 AM, Christophe Biocca <
christophe.biocca at gmail.com> wrote:
> I remember the wordlist choice getting bikeshedded to death a month ago.
>
> I would just include the wordlist as part of the standard (as a
> recommendation) so that fully compliant implementations can correct a
> user's typos regardless of the original generator.
>
>
That's exactly our attitude. We realized that have a community-wide
agreement on the wordlist itself is simply imposible, so to reach at least
some consensus we split the proposal to two parts - one what is essential
to call itself a "bip39 compatible", i.e. converting the mnemonic to bip32
node and second which is optional, including our proposed wordlist, which
has some advanced features like checksums etc. Now it is up to client
developers to decide if they really insist on their superior wordlist or if
they'll implement checksums following the full specification.
> Those who don't like it will have to deal with the compatibility
> concerns themselves, or get an alternate wordlist approved as a BIP.
Odds are no one will go that route.
>
>
At least Trezor and bitcoinj (Multibit) seems to be going in this way,
which is 100% of clients which expressed interest in bip39 :-).
slush
> On Mon, Jan 20, 2014 at 5:35 PM, Peter Todd <pete at petertodd.org> wrote:
> > On Mon, Jan 20, 2014 at 04:05:14PM -0600, Brooks Boyd wrote:
> >> On Mon, Jan 20, 2014 at 11:42 AM, slush <slush at centrum.cz> wrote:
> >>
> >> > Hi all,
> >> >
> >> > during recent months we've reconsidered all comments which we received
> >> > from the community about our BIP39 proposal and we tried to meet all
> >> > requirements for such standard. Specifically the proposal now doesn't
> >> > require any specific wordlist, so every client can use its very own
> list of
> >> > preferred words. Generated mnemonic can be then applied to any other
> >> > BIP39-compatible client. Please follow current draft at
> >> > https://github.com/trezor/bips/blob/master/bip-0039.mediawiki.
> >>
> >> So, because the [mnemonic]->[bip32 root] is just hashing, you've
> >> effectively made your "mnemonic sentence" into a brainwallet? Since
> every
> >> mnemonic sentence can now lead to a bip32 root, and only the client that
> >> created the mnemonic can verify the mnemonic passes its checksum
> (assuming
> >> all clients use different wordlists, the only client that can help you
> if
> >> you fat-finger the sentence is the client that created it)?
> >
> > That issue is more than enough to get a NACK from me on making the
> > current BIP39 draft a standard - I can easily see that leading to users
> > losing a lot of money.
> >
> > Have any wallets implemented BIP39 this way already in released code?
> >
> > --
> > 'peter'[:-1]@petertodd.org
> > 00000000000000009c3092c0b245722363df8b29cfbb86368f4f7303e655983a
> >
> >
> ------------------------------------------------------------------------------
> > CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> > Learn Why More Businesses Are Choosing CenturyLink Cloud For
> > Critical Workloads, Development Environments & Everything In Between.
> > Get a Quote or Start a Free Trial Today.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140121/c4e498fc/attachment.html>

2023-06-07 15:12:21 UTC

- reply

📅 Original date posted:2014-01-20
📝 Original message:Hi all,
during recent months we've reconsidered all comments which we received from
the community about our BIP39 proposal and we tried to meet all
requirements for such standard. Specifically the proposal now doesn't
require any specific wordlist, so every client can use its very own list of
preferred words. Generated mnemonic can be then applied to any other
BIP39-compatible client. Please follow current draft at
https://github.com/trezor/bips/blob/master/bip-0039.mediawiki.
Because we're quickly moving towards release of Trezor firmware and we need
to finalize this part of the firmware, we're asking for the last comments
to current BIP39 draft.
Thanks,
slush
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140120/bd7b8cb2/attachment.html>

2023-06-07 15:12:21 UTC

- reply

📅 Original date posted:2014-01-20
📝 Original message:On Mon, Jan 20, 2014 at 9:02 PM, Luke-Jr <luke at dashjr.org> wrote:
>
> How are they compatible if they could be using entirely different word
> lists??
>
>
Wordlist is necessary for the step [seed]->[mnemonic]. Step
[mnemonic]->[bip32 root] doesn't need any wordlist, there's just hashing
involved.
For this reason client can generate whatever mnemonic and unless all
clients use the same process [mnemonic]->[bip32 root], the result is the
same.
> Maybe I'm missing something, but shouldn't this be a client-side thing, not
> implemented in the Trezor firmware at all?? O.o;;
>
>
Trezor generates the seed and transforms it to mnemonic (which is then
shown on internal display). Generating the mnemonic outside the client-side
(computer) is one of main functionality of Trezor.
slush
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140120/1c516e00/attachment.html>

2023-06-07 15:08:05 UTC

- reply

📅 Original date posted:2013-10-24
📝 Original message:On Thu, Oct 24, 2013 at 9:32 PM, Jorge Timón <jtimon at monetize.io> wrote:
> This will probably sound stupid to most of you, but I'll say it anyway.
>
> The aim of mnemonics is to easily remember, isn't it?
>
Well, I would say more "retype" than "remember". I really don't think that
common user will memorize it. But of course, it is still an option.
> But the approach of removing "offensive words" is probably
> counterproductive to achieving that end. These words cause a greater
> emotional impact in our human moral psyches.
>
No, I dont' think it is stupid! Actually it was my concern as well.
Unfortunately I don't think it is "politically correct" to include all
bitches, assholes and motherfuckers in end user product :-).
> If we were willing to use that fact in our advantage to optimize the
> "maximum unforgettableness" criterion, we should actually prefer the
> most generally offensive words in that list. Specially if they can
> combine with each other to produce more offensive results, basically
> the opposite of what we're doing.
> Isn't "legalize murder dirty jew" much easier to remember for most
> people than "sandwich house yellow cauliflower"?
>
>
Well, bip39 can have more dictionaries and *maybe* swearword dictionary
would gain some popularity ;).
slush
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131024/af3f3b9b/attachment.html>

2023-06-07 15:08:04 UTC

- reply

📅 Original date posted:2013-10-24
📝 Original message:On Thu, Oct 24, 2013 at 9:23 PM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
>
> This is a proposal I wrote a year ago, but never spent enough work to
> push it as a standard:
> https://bitcointalk.org/index.php?topic=102349.0
>
>
I think that PoW concept in your proposal is quite smart! However the
problem that it isn't bidirectional; it don't allow to convert back and
forth between mnemonic and seed, which was one of basic requirement for
such algorithm.
slush
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131024/c0ec8fb3/attachment.html>

2023-06-07 15:08:03 UTC

- reply

📅 Original date posted:2013-10-24
📝 Original message:We've reflected many comments about BIP39 wordlist from the community and I
think the wordlist is much better now. Specifically we removed many of
theoretically offensive words as well as we implemented algorithm for
detecting words with similar characters (cat/eat) and we resolved these
duplicities. I'm now quite happy with the wordlist and I want to ask you
for next (final?) round of comments.
>From other features, we added password protection of seed and seed
hardening (against bruteforcing) using Rijndael cipher. This has been
chosen because its blocksize can be 128, 192 or 256 bits, so it fits length
of desired seeds. Also there are Rijndael implementations in every
language. Btw password protection has one interesting feature - plausible
deniability. It allows user to have one mnemonic and by using it with
different passwords, it will generate different BIP32 wallets.... (wink
wink)
I want to be pretty clear that we need to close this topic somehow, because
we want to use such algorithm in Trezor (which deadline is coming quick)
and also other wallet developers want to implement such algorithm into
clients to be compatible with Trezor. There were quite strict requirements
for such algorithm (like the possibility to convert mnemonic to seed as
well as seed to mnemonic) and I think we found a good solution. I'm wildly
asking you for constructive comments, but saying "it's a crap, I don't like
it" won't help anything.
Thanks,
slush
On Thu, Sep 12, 2013 at 6:02 PM, Matthew Mitchell <
matthewmitchell at godofgod.co.uk> wrote:
> I removed some more but I haven't added enough back in. It was taking far
> longer than expected so I gave up, but maybe someone else can try to add
> some more:
>
>
> https://github.com/MatthewLM/python-mnemonic/blob/master/mnemonic/wordlist/english.txt
>
> On 12 Sep 2013, at 13:11, Pavol Rusnak <stick at gk2.sk> wrote:
>
> > On 10/09/13 23:03, Matthew Mitchell wrote:
> >> Maybe it would have been better without the aggressive words?
> >
> > I revisited the wordlist and replaced around 67 words that can be
> > found offensive in some context.
> >
> > --
> > Best Regards / S pozdravom,
> >
> > Pavol Rusnak <stick at gk2.sk>
> >
> >
> ------------------------------------------------------------------------------
> > How ServiceNow helps IT people transform IT departments:
> > 1. Consolidate legacy IT systems to a single system of record for IT
> > 2. Standardize and globalize service processes across IT
> > 3. Implement zero-touch automation to replace manual, redundant tasks
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. Consolidate legacy IT systems to a single system of record for IT
> 2. Standardize and globalize service processes across IT
> 3. Implement zero-touch automation to replace manual, redundant tasks
> http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131024/c69dcea3/attachment.html>

2023-06-07 15:08:02 UTC

- reply

📅 Original date posted:2013-10-31
📝 Original message:Strange, I didn't receive the response from sipa in separate message, so
I'll respond to him at first place.
Le 26/10/2013 23:30, Pieter Wuille a écrit :
> I'm not sure whether we're ready to standardize on something like that
> yet, not having established best practices regarding different wallet
> structures. I do think we first need to see what possibilities and
> developments are possible related to it.
Although many strange practices how to use whole bip32 space are possible,
I think that we may (should?) agree on some "good enough" way how to
discover already used addresses in bip32 space. I read Electrum sources
about bip32 and I see that Electrum still uses quite flat structure (fixed
amount of branches, indexes from 0 to n), which is of course very sane way.
So if I migrate seed to another (non-Electrum) software, I only need to
discover close neighbourhood of the path "0", similarly like Electrum is
doing with "gap limit" in plain old Electrum algorithm, except in two
dimensions (paths 0, 1, 2, 3, 4, 5, 0/0, 0/1, 0/2, 0/3, 0/4, 0/5, 1/0, 1/1,
...5/5 for gap limit "5"). I don't say such operation is cheap, but this
discovery needs to be done only during the import.
For the reason that I think this is the only sane algorithm of general use
of bip32 space, I still don't see why we do need some extra metadata. I
would understand this if Electrum will use for some strange reason
addresses in higher address space like 2^32-1 or so, but this is not going
to happen at least in Electrum.
> I understand that in
> the case of Electrum, there is a strong reason to want this
> encapsulated together with the seed, but it's not really a requirement
> for most wallets.
Well, I can imagine that the bip32 compatible software will do full scan of
address space using some gap factor (actually I think "5" is too low by
default) or it can ask for wallet metadata like which software used such
tree before, to speedup scanning process.
I see that Thomas wants to make this automatic and hidden to user and
generally I agree that hiding the compexity to user is a good practice, but
actually this particular situation sounds to me as an exact oposite of
original statement "no metadata in mnemonic".
> Regarding other requirements, I wonder why we want the transformation
> to be bidirectional? If it is just about generating master seeds, one
> direction should be enough, and allows far nicer properties w.r.t.
> security. If we do settle on a standard for 'brainwallets',
ECDSA has one very nice option - (almost) any random data can be used as a
private key. There are very nice schemas possible by using this feature and
requiring private key to be specially crafted just because the user wanted
to use mnemonic schema is very strong limitation to me.
To be specific, we (in cooperation with / inspired by Timo Hanke) developed
method how to prove that the seed generated by Trezor has been created
using combination of computer-provided entropy and device-provided entropy,
without leaking full private information to other computer, just because we
want Trezor to be blackbox-testable and fully deterministic (seed
generation is currently the only operation which uses any source of RNG).
To limit the complexity of such algorithm it is better to produce plain
seed (128, 192 or 256 bits, depends on settings) and then transform the
result of such "deterministic seed" to mnemonic, so for us the
bi-directionality is quite strong requirement. *Maybe* it would be possible
to combine such algorithm and one-way mnemonic together, but it would
complicate the design and I'm sure you understand that we want to keep
things as clear and simple as possible, especially while handling with seed
generation.
> I would strongly prefer if it had at least some strengthening built-in, to
> decrease the impact of worst-case situations.
Agree (hardening is default in bip39).
Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131031/35ff057a/attachment.html>

2023-06-07 15:08:01 UTC

- reply

📅 Original date posted:2013-10-26
📝 Original message:Hi Thomas,
can you more elaborate on that "version" bits? What is exact meaning of it?
I still think this is more an implementation problem. What stops Electrum
to do the same algorithm for searching branches as it is now for used
addresses?
These "version bits" need to be covered by the specification as well,
because if any client will use them differently (or won't use them at all),
it will break cross-compatibility between clients, which was another goal
of bip39.
Marek
On Sat, Oct 26, 2013 at 5:24 PM, Thomas Voegtlin <thomasv1 at gmx.de> wrote:
> here is a simple implementation, with some ideas on how to format the
> metadata:
> https://en.bitcoin.it/wiki/Talk:BIP_0039
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131026/0bdf1770/attachment.html>

2023-06-07 15:08:00 UTC

- reply

📅 Original date posted:2013-10-24
📝 Original message:On Thu, Oct 24, 2013 at 7:29 PM, <thomasV1 at gmx.de> wrote:
>
> My initial problem was that BIP0039 is not backward compatible with
> Electrum. When trying to solve that, I realized that the seed encoding used
> in Electrum does not help, because it does not contain a version number
> information. However, BIP0039 suffers the same shortcoming: it does nothing
> to help a future replacement, it wants to be final. My first recommendation
> is to allocate a few bits of the mnemonic, in order to encode a "version
> number" along with the checksum bits.
>
>
On topic of "it wants to be final" and "it is incompatible with Electrum":
None of this is true. Firstly, it *is* possible to implement both algorithm
into the client at the same time, so user will be able to recover wallet
using Electrum or bip39 mnemonic and - what is worse - you already *know*
about this solution. Still you're spreading FUD about it on IRC, on emails
behind my back and here on mailing list.
The solution for Electrum client - as we discussed two weeks ago on IRC -
is that:
a) User type down the mnemonic (created with Electrum or BIP39)
b1) Only if *all* words are presented in both dictionaries and it has valid
BIP39 checksum (which is quite rare situation itself!), the mnemonic can be
consider to be both Electrum or BIP39.
b2) In most of cases we end up here, because the most common situation is
that with given words, only Electrum *or* BIP39 seed can be recovered.
----
c) Consider the mnemonic as Electrum. Create first few addresses and do a
lookup. If there are transactions in address history, this is Electrum
mnemonic.
d) If there were no used address in c), build seed using BIP39 and do the
same lookup. If there's history, this is BIP39 mnemonic.
e) If there are no history on both algorithm, then pick prefered one for
given client (it should not hurt which one, because first use of given
mnemonic will "freeze" given algorithm for next time of mnemonic recovery).
Well, because only Electrum uses some mnemonic algorithm to this date, such
decision tree need to be implemented only in Electrum. You cannot tell that
"it is too complicated" or "ambiguous", because you're using the same
algorithm of deciding between Electrum deterministic / BIP32.
I must admit that I'm quite annoyed of such discussion, because we already
discussed all this privately, you didn't tell me any reason why this should
not work and still I see that this is coming back as a boomerang.
slush
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131024/d8ba8bd2/attachment.html>

2023-06-07 15:07:59 UTC

- reply

📅 Original date posted:2013-10-24
📝 Original message:On Thu, Oct 24, 2013 at 7:29 PM, <thomasV1 at gmx.de> wrote:
>
> My initial problem was that BIP0039 is not backward compatible with
> Electrum. When trying to solve that, I realized that the seed encoding used
> in Electrum does not help, because it does not contain a version number
> information. However, BIP0039 suffers the same shortcoming: it does nothing
> to help a future replacement, it wants to be final. My first recommendation
> is to allocate a few bits of the mnemonic, in order to encode a "version
> number" along with the checksum bits.
>
>
Two years ago I proposed exactly this and you refused to add extra
information to mnemonic, because "it isn't necessary" and "it makes it
longer to mnemonization". What changed since then?
> The second problem is the wallet structure. There are multiple ways to use
> a BIP32 tree, and each client will certainly handle this differently. For
> Electrum, it is important to be able to recover an entire wallet from its
> mnemonic, using no extra information. Thus, the client needs to know which
> branches of the BIP32 tree are populated by default. This means that the
> "version number" I mentioned will not only be about the seed encoding, but
> it should also give some information about the wallet structure, at least
> in the case of Electrum.
>
>
Hm, what exactly do you need to store about wallet structure? I lived in
opinion that everything is able to recover using CKD function to generate
new addresses and blockchain lookups for their balances.
> The third problem is the dictionary. I do not like the dictionary proposed
> in BIP0039, because it contains too many short words, which are bad for
> memorization (I explained here how I designed the dictionary used by
> Electrum:
> https://bitcointalk.org/index.php?topic=153990.msg2167909#msg2167909). I
> had some discussions with slush about this, but I do not think it will ever
> be possible to find a consensus on that topic.
>
>
Yes, that's true. It isn't possible to make everybody 100% happy. At least
I wanted to be constructive and asked you to replace the most problematic
words. No pull request from you so far.
> BIP0039 also suggests to use localized dictionaries, with non-colliding
> word lists, but it is not clear how that will be achieved; it seems to be
> difficult, because languages often have words in common. It looks like a
> first-come-first-served aproach will be used.
>
>
Yes, it was original idea. So far I don't think this is a problem. Of
course some words may have some meaning across languages, but it should be
easy to avoid them. There are tens of thousands words in every language and
we need to pick "only" 2048 words to wordlist.
> For these reasons, I believe that we need a dictionary-independent
> solution. This will allow developers to use the dictionary they like, and
> localization will be easy.
>
I would like to suggest the following solution:
>
>
If I understand this well, it is basically one-way algorithm "mnemonic ->
seed", right? Seed cannot be printed out as mnemonic, because there's
hashing involved, but the bi-directionality has been the original
requirement for such algorithm (at least in Electrum and bip39).
Then, how is this different to picking 12 random words from dictionary and
hashing them together? I don't see any benefit in that "mining" part of the
proposal (except that it is lowering the entropy for given length of
mnemonic).
> This solution makes it possible for developers to define new dictionaries,
> localized or adapted to a particular need.
>
Are your worries about overlapping words across languages a real issue?
slush
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131024/05ebacd9/attachment.html>

2023-06-07 15:07:31 UTC

- reply

📅 Original date posted:2013-10-24
📝 Original message:I've just pushed updated wordlist which is filtered to similar characters
taken from this matrix.
BIP39 now consider following character pairs as similar:
similar = (
('a', 'c'), ('a', 'e'), ('a', 'o'),
('b', 'd'), ('b', 'h'), ('b', 'p'), ('b', 'q'), ('b', 'r'),
('c', 'e'), ('c', 'g'), ('c', 'n'), ('c', 'o'), ('c', 'q'),
('c', 'u'),
('d', 'g'), ('d', 'h'), ('d', 'o'), ('d', 'p'), ('d', 'q'),
('e', 'f'), ('e', 'o'),
('f', 'i'), ('f', 'j'), ('f', 'l'), ('f', 'p'), ('f', 't'),
('g', 'j'), ('g', 'o'), ('g', 'p'), ('g', 'q'), ('g', 'y'),
('h', 'k'), ('h', 'l'), ('h', 'm'), ('h', 'n'), ('h', 'r'),
('i', 'j'), ('i', 'l'), ('i', 't'), ('i', 'y'),
('j', 'l'), ('j', 'p'), ('j', 'q'), ('j', 'y'),
('k', 'x'),
('l', 't'),
('m', 'n'), ('m', 'w'),
('n', 'u'), ('n', 'z'),
('o', 'p'), ('o', 'q'), ('o', 'u'), ('o', 'v'),
('p', 'q'), ('p', 'r'),
('q', 'y'),
('s', 'z'),
('u', 'v'), ('u', 'w'), ('u', 'y'),
('v', 'w'), ('v', 'y')
)
Feel free to review and comment current wordlist, but I think we're slowly
moving forward final list.
slush
On Sat, Oct 19, 2013 at 1:58 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> some fairly old wordlist solver code of mine:
>
> https://people.xiph.org/~greg/wordlist.visual.py
>
> it has a 52x52 letter visual similarity matrix in it (along with a
> citation)
>
> On Fri, Oct 18, 2013 at 4:52 PM, jan <jan.marecek at gmail.com> wrote:
> >
> > The words 'public', 'private' and 'secret' could be confusing when
> > encoding public and private keys. eg. a private key that begins with
> > the word 'public'.
> >
> > I think avoiding words that could look similar when written down would
> > be a good idea aswell. I searched for words that only differ by the
> > letters c & e, g & y, u & v and found the following:
> >
> > car ear
> > cat eat
> > gear year
> > value valve
> >
> > Other combinations could potentially be problematic depending on the
> > handwriting style: ft, ao, ij, vy, possibly even lt and il?
> >
> > I've included the search utility I used below.
> >
> >
> > #include <stdbool.h>
> > #include <string.h>
> > #include <stdio.h>
> >
> > char *similar_char_pairs[] = { "ce", "gy", "uv", NULL };
> >
> > bool is_similar_char(char c1, char c2)
> > {
> > char **pairs = similar_char_pairs;
> > do {
> > char *p = *pairs;
> > if ((c1 == p[0] && c2 == p[1]) ||
> > (c1 == p[1] && c2 == p[0]))
> > return true;
> > } while (*++pairs);
> >
> > return false;
> > }
> >
> > bool print_words_if_similar(char *word1, char *word2)
> > {
> > /* reject words of different lengths */
> > if (strlen(word1) != strlen(word2))
> > return false;
> >
> > size_t i, similarcount = 0;
> >
> > for (i = 0; i < strlen(word1); i++) {
> > /* skip identical letters */
> > if (word1[i] == word2[i])
> > continue;
> >
> > /* reject words that don't match */
> > if (is_similar_char(word1[i], word2[i]) == false)
> > return false;
> >
> > similarcount++;
> > }
> >
> > /* reject words with more than 1 different letter */
> > //if (similarcount > 1)
> > // return false;
> >
> > printf("%s %s\n", word1, word2);
> >
> > return true;
> > }
> >
> > int main(void)
> > {
> > /* english.txt is assumed to exist in the working directory
> > download from:
> >
> https://github.com/trezor/python-mnemonic/blob/master/mnemonic/wordlist/english.txt*/
> > FILE* f = fopen("english.txt", "r");
> > if (!f) {
> > fprintf(stderr, "failed to open english.txt\n");
> > return 1;
> > }
> >
> > /* read in word list, assumes one word per line */
> > #define MAXWORD 16
> > char wordlist[2048][MAXWORD];
> > int word = 0;
> > while (fgets(wordlist[word], MAXWORD, f)) {
> > /* strip trailing whitespace, assumes no leading whitespace */
> > char *ch = strpbrk(wordlist[word], " \n\t");
> > if (ch)
> > *ch = '\0';
> > word++;
> > }
> >
> > if (word != 2048) {
> > fprintf(stderr, "word list incorrect length\n");
> > return 1;
> > }
> >
> > /* check each word for similarity against every other word */
> > int i, j, count = 0;
> > for (i = 0; i < 2048; i++) {
> > for (j = i+1; j < 2048; j++) {
> > if (print_words_if_similar(wordlist[i], wordlist[j]))
> > count++;
> > }
> > }
> >
> > printf("%d matches\n", count);
> >
> > return 0;
> > }
> >
> >
> ------------------------------------------------------------------------------
> > October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> > the latest Intel processors and coprocessors. See abstracts and register
> >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131024/a07dd6b6/attachment.html>

2023-06-07 11:38:42 UTC

- reply

📅 Original date posted:2013-03-13
📝 Original message:Agree. I quite like Mark's proposal. Yes, formally it is hard fork. But the
step 4) can come very far in the future, when the penetration of <0.8
clients will be mininimal.
slush
On Wed, Mar 13, 2013 at 7:27 PM, Mark Friedenbach <mark at monetize.io> wrote:
> This problem is very clearly a *bug* in the old codebase. So let's be
> forward thinking and do what we would do in any other situation: fix the
> bug, responsibly notify people and give them time to react, then move on.
> Let's not codify the bug in the protocol.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130313/b9c1b3c2/attachment.html>

2023-06-07 10:41:54 UTC

- reply

📅 Original date posted:2012-11-29
📝 Original message:Hi,
not sure if you already noticed, but I and my friends are actively working
on bitcoin hardware wallet. This should be pocket size device with
something like 256kB flash and 80 MHz CPU, talking with the computer over
USB. User will prepare transaction on the machine, send it to the device,
device shows target address on the display and user confirms it by pressing
the button.
We're trying to make bitcoin payments safe even on hacked computer. For
this reason we're also implementing SPV so device don't need to trust
computer with any kind of information. The biggest existing problem is that
user cannot be sure that the address displayed on computer screen is
correct and he's confirming valid address.
I don't have any solution for this problem yet. I just appreciate an
activity in payment protocol area, because it can (with some care) solve
this problem and my appeal si to keep all this simple. I'd be very happy
with simple payment protocol which can be implemented even on devices like
I'm working on, so device with few widely used certificates stored in the
memory will be able to display origin of the invoice and confirm its
validity.
slush
On Thu, Nov 29, 2012 at 1:30 AM, Watson Ladd <wbl at uchicago.edu> wrote:
> After doing more thinking, what about letting a spend sign more
> information associated with the transaction, such as a transaction ID
> provided by the merchant? This seems to solve a lot of the problems being
> put forward, with much less complexity.
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> VERIFY Test and improve your parallel project with help from experts
> and peers. http://goparallel.sourceforge.net
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121129/fe7ebf3e/attachment.html>

2023-06-07 03:03:12 UTC

- reply

📅 Original date posted:2012-02-01
📝 Original message:Very interesting. Do you have any plans to push your refactored code into
Bitcoin upstream for future releases someday?
slush
On Wed, Feb 1, 2012 at 3:18 PM, Michael Grønager <gronager at ceptacle.com>wrote:
> Dear Bitcoiners,
>
> libcoin is now in a state ready for its first release, which I would like
> to share with you!
>
> === libcoin is a crypto currency library based on the bitcoin/bitcoin
> "Satoshi" client. ===
>
> Copenhagen, Denmark - 1st February 2012 Ceptacle announces the release of
> the first version of the crypto currency library "libcoin" based on the
> bitcoin/bitcoin "Satoshi" client.
>
> libcoin also maintains a version of bitcoind that is a 100% compatible
> drop-in replacement of the bitcoin/bitcoind client: You can use it on the
> same computer on the same files and you can call it with the same scripts.
> And you can easily extend it without touching the basic bitcoin source
> files.
>
> The libcoin/bitcoind client downloads the entire block chain 3.5 times
> faster than the bitcoin/bitcoind client. This is less than 90 minutes on a
> modern laptop!
>
> In libcoin, the Satoshi client code has been completely refactored,
> properly encapsulating classes, removing all globals, moving from threads
> and mutexes to a pure asynchronous approach. Functionalities have been
> divided into logical units and libraries, minimizing dependencies for e.g.
> thin clients.
>
> libcoin is chain agnostic, all chain (bitcoin, testnet, namecoin,
> litecoin, ...) specific settings are maintained from a single class (Chain)
> and hence experiments with chain settings, mining, security and digital
> currencies for research and educational purposes are easily accessible. See
> the ponzicoin example for how you define your own chain.
>
> The build system of libcoin is based on CMake and supports builds of
> static and dynamic libraries on Linux, Mac OS X, and Windows.
>
> The libcoin license is LGPL v. 3. This mean that you can use it in open
> source as well as in commercial projects, but improvements should go back
> into the libcoin library.
>
> ======
>
> Read more on libcoin on: http://github.com/ceptacle/libcoin/wiki
>
> Join libcoin on twitter: http://twitter.com/libcoin
>
> Download "libcoin Satoshi release":
> http://github.com/ceptacle/libcoin/zipball/v0.4.0.1
>
> Best regards,
>
> Michael Gronager, PhD
> Director, Ceptacle
> Jens Juels Gade 33
> 2100 Copenhagen E
> Mobile: +45 31 45 14 01
> E-mail: gronager at ceptacle.com
> Web: http://www.ceptacle.com/
>
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120201/da513105/attachment.html>

2023-06-07 02:56:17 UTC

- reply

📅 Original date posted:2012-01-16
📝 Original message:> I agree Bitcoin should avoid making any bold political stands.
I agree on this. Please don't turn Bitcoin project/homepage into some
political agitation. Not everybody care about political attitude of main
project developers.
slush
On Tue, Jan 17, 2012 at 1:46 AM, Alan Reiner <etotheipi at gmail.com> wrote:
> **
> You guys are representing both extremes of the issue. In response to Jeff
> and Luke-Jr, I don't see how this is *just any other poltical issue*. It
> strikes at the heart of everything Bitcoin is about. Barring
> Bitcoin-specific legislation, I don't see how any legislation could be more
> relevant to Bitcoin and the community around it.
>
> On the other hand, Bitcoin is still a non-entity, and shouldn't get in the
> business of making statements. A central voice for Bitcoin gives the
> impression that it is actually centralized, and one that has opinions.
> Plus I wouldn't be surprised if some, heavily-invested Bitcoin users were
> of the opinion that SOPA/PIPA/whatever could be a huge profit for
> themselves: once SOPA kicks in and businesses around the world start
> getting cut off for legit or illegitimate purposes, a lot of them could
> potentially switch to Bitcoin to keep their business going. That could be
> a huge boon for Bitcoin. You may not agree it's worth the tradeoff, but
> people are selfish and may not actually understand or even care about SOPA
> legislation itself.
>
> I think it's *not inappropriate* for something to be mentioned on the
> website about Bitcoin's philosophy being threatened by SOPA, but I agree
> Bitcoin should avoid making any bold political stands. Users could be
> reminded that SOPA affects yet another thing they care about, but it might
> be better to avoid it altogether. If any response is made, it should be a
> very light one.
>
> -Alan
>
>
>
> On 01/16/2012 07:30 PM, Amir Taaki wrote:
>
> Bunk argument. This is an issue that affects bitcoin directly.
>
> Wikipedia has far more need to remain neutral and apolitical than bitcoin ever does- you've read Satoshi's politically charged whitepaper or seen the genesis block quote.
> http://en.wikipedia.org/wiki/Wikipedia:SOPA_initiative/Action
>
> The Wikipedia community decided on a full and global blackout. Bitcoin should do the same in unison with the rest of the web- sites like Reddit, 4chan and Wikipedia.
>
> It's funny / almost comical how you consign this to being just another issue or case of moral alarm. Sad.
>
>
>
> ----- Original Message -----
> From: Jeff Garzik <jgarzik at exmulti.com> <jgarzik at exmulti.com>
> To: Amir Taaki <zgenjix at yahoo.com> <zgenjix at yahoo.com>
> Cc: "bitcoin-development at lists.sourceforge.net" <bitcoin-development at lists.sourceforge.net> <bitcoin-development at lists.sourceforge.net> <bitcoin-development at lists.sourceforge.net>
> Sent: Sunday, January 15, 2012 10:37 PM
> Subject: Re: [Bitcoin-development] bitcoin.org SOPA/PIPA blackout
>
> On Sun, Jan 15, 2012 at 5:09 PM, Amir Taaki <zgenjix at yahoo.com> <zgenjix at yahoo.com> wrote:
>
> How is this not the most important world issue right now?
>
> EVERYTHING is under threat. Go nuclear to show our nerd-rage.
>
> Everybody blank your personal sites too. Americans, take to the streets. World, go scream at the US embassy.
>
> There are always issues that raise ire and moral outrage. I would
> rather that bitcoin.org stay apolitical -- our users will appreciate
> this in the long run.
>
>
>
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120117/61e06bb7/attachment.html>

2023-06-07 02:47:51 UTC

- reply

📅 Original date posted:2011-12-16
🗒️ Summary of this message: Slush supports the KISS attitude of using standard URLs, opposed to over-engineering aliases, and sees no serious issue with URL proposals.
📝 Original message:OK, I'm ignoring your sarcastic style, I just wanted to support the URL
idea, which is KISS attitude, in the oposite of everything else proposed
here. I'm really affraid of over-engineering the aliases, which will make
it hard to implement in clients. Somebody noticed account implementation in
standard client - yes, it's good example of fail.
I still don't see any serious issue with the URL proposals. And sipa's idea
of posting back the transaction ID is also interesting, prividing yet
another flexibility in implementation and possible usage.
Btw, Rick, feel free to provide me some relevant RFCs which are solving
similar problems like BIP 15. And no, it's not sarcasm, I really want to
learn something new. Until now I just feel we're reinventing wheel or
raping some stuff which we should not touch at all (DNS).
slush
On Fri, Dec 16, 2011 at 4:52 PM, Rick Wesson
<rick at support-intelligence.com>wrote:
> On Thu, Dec 15, 2011 at 4:07 PM, slush <slush at centrum.cz> wrote:
> > I really like this proposal with standard URLs. All other proposals like
> DNS
> > mapping or email aliases converted to URLs with some weird logic looks
> > strange to me.
>
> wow, really. Maybe you could review some RFCs, there are thousands of
> examples where some really smart engineers chose the exact opposite
> path which you propose below.
>
> -rick
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111216/97352afb/attachment.html>

2023-06-07 02:47:44 UTC

- reply

📅 Original date posted:2011-12-15
🗒️ Summary of this message: Slush supports using standard URLs for Bitcoin addresses, finding them easy to implement and understand, and flexible for personal or business use.
📝 Original message:I really like this proposal with standard URLs. All other proposals like
DNS mapping or email aliases converted to URLs with some weird logic looks
strange to me.
Plain URLs (returning address in response body, redirecting to URI
"bitcoin:<address>" or anything else) are very clear solution, easy to
implement in clients and very easy to understand by people. It's also
extremely flexible - almost everybody can somewhere setup static file
containing his "personal" addresses or it's very easy to integrate such
solution with eshops (providing custom address for given order) etc. I'm
definitely for this solution.
Best,
slush
On Tue, Dec 13, 2011 at 5:22 PM, Andy Parkins <andyparkins at gmail.com> wrote:
> On 2011 December 13 Tuesday, Amir Taaki wrote:
>
> > Maybe I wasn't clear enough in the document, but this is the intent with
> > the HTTPS proposal.
>
> I don't like the idea of a hard-coded mapping at all. We shouldn't be
> making
> choices on behalf of server operators. It's up to them how they arrange
> their
> domain names and paths.
>
> I also agree that DNS is not the technology to use. DNS is a nightmare.
>
> > genjix at foo.org
> >
> > Contacts https://foo.org/bitcoin-alias/?handle=genjix and the system
> > responds with a bitcoin address. Whether the system gives you a new
> > address from a pool of addresses, or contacts the merchant behind the
> > scenes is implementation defined.
> >
> > I'll clarify it later. This is the relevant line:
> >
> > string strRequestUrl = strDomain + "/bitcoin-alias/?handle=" +
> > pszEncodedNick;
> >
> > Between HTTPS service and server service, I lean slightly towards HTTPS
> > (automatic encrypted connection, CAs + all benefits of DNS). But still
> > interested in arguments in favour of a server service (daemon answering
> > queries).
>
> Why bother with an encoding scheme at all? If the address
>
> genjix at foo.org
>
> always maps to
>
> https://foo.org/bitcoin-alias/?handle=genjix
>
> Then forget the hardcoding of "https" the hardcoding of "bitcoin-alias" and
> "?handle=" and the original email-looking "genjix at foo.org". Just use the
> URL.
> Then the author of the service can use whatever they want.
>
> "Can I pay you 10 BTC?"
> "Sure, send it to 'https://bitcoinalias.foo.org/genjix/'"
>
> While I might implement my alias server like this:
>
> "Sure, send it to 'https://google.com/bitcoin/?andyparkins'"
> "Sure, send it to 'https://parkins.co.uk/"
>
> ... or any other URL they want -- any of which suit might suit me and my
> webserver better than whatever mapping would otherwise be hard-coded. The
> world is already very familiar with URLs so this is no more scary than the
> email address. What's more, the email address form looks _too much_ like
> an
> email address, and will only lead to confusion ... "send it to
> genjix at foo.org"
> "so I use outlook express for that, right?" "erm, no, you put it in your
> bitcoin client".
>
> The URL form could easily be made to detect a browser connecting rather
> than a
> bitcoin client (and this is an area that would benefit from a standards
> document -- define the headers and user agent triggers that an alias server
> expects) and give them better instructions.
>
> https can be specified as the default, so "https://" can be optional when
> they're typing. If, in the future, bitcoin gets a distributed peer-to-peer
> alias system, then a new URL type can be added easily
> "bcalias://andyparkins"
> might automatically find my node in the network and query it for an address
> (or whatever).
>
> All of the above is exactly why OpenID chose to use URLs for ID.
>
>
>
> Andy
>
> --
> Dr Andy Parkins
> andyparkins at gmail.com
>
>
> ------------------------------------------------------------------------------
> Systems Optimization Self Assessment
> Improve efficiency and utilization of IT resources. Drive out cost and
> improve service delivery. Take 5 minutes to use this Systems Optimization
> Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111216/c1446aa4/attachment.html>

2023-06-07 02:44:49 UTC

- reply

📅 Original date posted:2011-12-19
🗒️ Summary of this message: Slush suggests that there is no need for a payload format like JSON or XML, and all that is required is an address in response.
📝 Original message:In my opinion, there's not necessary any payload format (json, xml,
multipart). In keeping stuff KISS, everything we need is just an address in
response + potentially some stuff like HTTP redirects (for providing
additional compatibility for proposal of bitcoin URIs with "amount",
"label" and other parts). I don't see reason why we need some extra payload
yet.
slush
On Mon, Dec 19, 2011 at 7:13 PM, Jordan Mack <jordanmack at parhelic.com>wrote:
> If the idea is to "KISS", and provide a method that is both quick and
> easy to implement for the average developer, then JSON is a stand out
> option. Using HTTP for the data interchange will make things difficult
> for a lot of developers if multipart responses are used. JSON will be
> greeted with open arms.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111219/33ea8eb3/attachment.html>

2023-06-07 02:44:42 UTC

- reply

📅 Original date posted:2011-12-19
🗒️ Summary of this message: HTTP standard is sufficient, and bloating payload with JSON/XML is unnecessary. The argument for using JSON in server RPC is flawed.
📝 Original message:I agree with Luke that HTTP standard has everything necessary and bloating
payload with json/xml is not necessary.
Btw that argument "we have json in client already" seems pretty wrong,
because json in server rpc solves another problem (and solve it in wrong
way, because of data type issues, but it's another story).
slush
On Mon, Dec 19, 2011 at 6:04 PM, Jordan Mack <jordanmack at parhelic.com>wrote:
> I thought that JSON support was fairly common these days. I personally
> prefer XML in most cases, but since JSON is already used with the RPC,
> it seemed like a natural fit here. Binary data can be base64 encoded,
> although I'm not sure why you would need to send back binary in an alias
> response.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111219/fabde08e/attachment.html>

2023-06-07 02:44:13 UTC

- reply

📅 Original date posted:2011-12-18
🗒️ Summary of this message: The author expresses concern about the lack of an easy and secure solution for using aliases in Bitcoin transactions, and suggests using SSL communication authenticated with a bitcoin address as a potential solution.
📝 Original message:Pieter, it was more rhetorical question than asking for explanation, but
thanks anyway. As an Internet application developer, I of course understand
security issues while using HTTPS and CA.
I have a gut feeling that there simply does not exist any single solution
which is both easy to use and secure enough. At least nobody mentioned it
yet. And if I need to choose between easy solution or secure solution for
aliases, I'll pick that easy one. I mean - we need some solution which will
be easy enough for daily use; it is something what we currently don't have.
But if I want to be really really sure I'm using correct destination for
paying $1mil for a house, I can every time ask for real bitcoin addresses,
this is that secure way which we currently have.
slush
On Mon, Dec 19, 2011 at 2:14 AM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
> On Mon, Dec 19, 2011 at 12:58:37AM +0100, slush wrote:
> > Maybe I'm retarded, but where's the point in providing alliases
> containing
> > yet another hash in URL?
>
> Any DNS-based alias system is vulnerable to spoofing. If I can make
> people's
> DNS server believe that mining.cz points to my IP, I'll receive payments
> to
> you...
>
> If no trusted CA is used to authenticate the communication, there is no way
> to be sure the one you are asking how to pay, is the person you want to
> pay.
> Therefore, one solution is to put a bitcoin address in the identification
> string itself, and requiring SSL communication authenticated using the
> respective key.
>
> This makes the identification strings obviously less useful as aliases,
> but pure aliases in the sense of human-typable strings have imho
> limited usefulness anyway - in most cases these identification strings
> will be communicated through other electronic means anyway.
>
> Furthermore, the embedded bitcoin address could be hidden from the user:
> retrieved when first connecting, and stored together with the URI in
> an address book. Like ssh, it could warn the user if the key changes
> (which wil be ignored by most users anyway, but what do you do about
> that?)
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live! Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111219/d492945b/attachment.html>

2023-06-07 02:44:01 UTC

- reply

📅 Original date posted:2011-12-18
🗒️ Summary of this message: A discussion on the authentication of hosts and the need for a proper protocol to negotiate payment in Bitcoin development.
📝 Original message:Maybe I'm retarded, but where's the point in providing alliases containing
yet another hash in URL?
slush
On Sun, Dec 18, 2011 at 10:44 PM, Luke-Jr <luke at dashjr.org> wrote:
> On Sunday, December 18, 2011 4:05:11 PM Jorge Timón wrote:
> > If we chose the simple URI proposal namecoin can still be integrated
> > to map the IP of the server by those who want to.
> > Does it removes the necessity of the certificates?
> > If so, we should let people decide between HTTP, HTTPS, namecoin or
> > whatever they trust.
>
> How are you going to authenticate the host? Certificates from CAs are how
> HTTPS does it. HTTP is vulnerable. If the URI contains an address (eg,
> bitcoin://remotehost/base58key), the remote host could sign its
> (self-signed)
> SSL key with the ECDSA key to prove authenticity. DNSSEC/namecoin
> presumably
> has some way to do this as well.
>
> > Shouldn't we be also discussing the valid format of the answered
> > message? I mean fields like "amount", "concept" and such.
>
> At some point, a proper protocol to negotiate payment is needed for
> anything
> like this.
>
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live! Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111219/b86751c7/attachment.html>

2023-06-07 02:43:35 UTC

- reply

📅 Original date posted:2011-12-16
🗒️ Summary of this message: Slush believes using Namecoin for aliases is over-engineering and prefers a simpler solution like HTTPS lookup for addresses.
📝 Original message:Khalahan, honestly, using namecoin for aliases is (for me) clean example of
over-engineering. I mean - it will definitely work if implemented properly.
I played with a namecoin a bit (as my pool was the first 'big' pool
supporting merged mining), but I think there's really long way to provide
such alias system in namecoin and *cleanly integrate it with bitcoin*.
Don't forget that people who want to do lookup need to maintain also
namecoin blockchain with their bitcoin client. It goes against my instinct
of keeping stuff easy.
For example, yesterday I implemented HTTPS lookup for addresses into my
fork of Electrum client. I did it in 15 minutes, it works as expected, it
does the job and the implementation is really transparent, becuase
implementation is 20 lines of code. There's no magic transformation, no
forced "?handle=" parameters or whatever. And I don't care if somebody
provide URL
https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True
And everybody can do the same in their clients, in their merchant
solutions, websites or whatever. Everybody can do HTTPS lookup. But try to
explain DNS, Namecoin, IIBAN, email aliases to other programmers...
Those IIBAN - well, why not. At least I see the potential in PR. So far I
understand it as some teoretic concept which is not supported by anything
else right now. Give it few years until it matures and then add IIBAN alias
to Bitcoin client too.
Maybe I'm repeating myself already, but the way to go is to make aliases as
easy as possible, so everybody can implement it in their own solution and
thus practially remove the need of using standard bitcoin addresses for
normal users. Using some superior technology, which is hard to implement or
even understand won't solve the situation, because it will ends up with
some reference implementation in standard client only and nobody else will
use it.
slush
On Fri, Dec 16, 2011 at 6:23 PM, Khalahan <khal at dot-bit.org> wrote:
> **
> Namecoin is a peer-to-peer generic name/value datastore system.
> Don't forget it's not limited to .bit usage ! So, directly mapping things
> to .bit url would not be the optimal way of using namecoin.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111216/d08d98b2/attachment.html>