<unnamed>

Public Key

npub1j8mfekhmgtne6ptzxptudrcpwd6wtyxk64qdn3swy2nv46zuledskwpach

Profile Code

nprofile1qqsfra5umta59euaq43rq47x3uqhxa89jrtd2sxecc8z9fk2apw0ukcpzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mq79nnhh

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-07 15:31:32 UTC

- reply

2023-06-07 15:31:32 UTC

- reply

📅 Original date posted:2015-03-12
📝 Original message:When Jim and I were selecting which combination of HD wallet structures to
support we noted the following:
* BIP39 is a good standard list to select from that mandates words that do
not look similar to each other, a certain spelling (no English US/UK
confusion) and possible foreign language variants provided by experts later
* BIP32 (m/0h/0/0) and BIP44 (m/44h/0h/0h/0/0) allow for maximum
compatibility with other wallets
* including a date in the "wallet words" themselves is open to spoofing
since the generator cannot be sure the date is correct (local time drift,
provided externally by untrusted third party etc)
* a timestamp as optional external metadata is useful to reduce sync times
in SPV
* our experience verified that users will very often enter a timestamp
incorrectly (locale, fat fingers, bad memory etc) so we opted for "number
of days elapsed since Bitcoin genesis block with a modulo 97 checksum
appended" (e.g. 1850/07) to mitigate this
* if a user has no timestamp then blank is the only alternative (no
guessing) which is interpreted as "earliest possible BIP32 date"
* if restoring the user has to select where the "wallet words" came from
(e.g. MultiBit HD, Trezor, Mycelium etc)
Users will naturally assume that they can type their "wallet words" (a more
mainstream-friendly term than "seed phrase") into any wallet and with a bit
of fiddling about get their bitcoins back. As wallet developers it is
within our capability to make that happen and I think we're quite close
already.
On 12 March 2015 at 16:47, Mike Hearn <mike at plan99.net> wrote:
> b) "Creation date" is just a short-term hack.
>>
>
> I agree, but we need things to be easy in the short term as well as the
> long term :)
>
> The long term solution is clearly to have the 12 word seed be an
> encryption key for a wallet backup with all associated metadata. We're
> heading in that direction one step at a time. Unfortunately it will take
> time for wallets to start working this way, and all the pieces to fall into
> place. Restoring from the block chain will be a semi regular operation for
> users until then.
>
> WRT version number I have no real strong feelings about this. But
> representing short pieces of binary data as words is so convenient, it
> seems likely that it could be similar to addresses: people find other uses
> for this mechanism beyond just storing a raw private key. Bitcoin addresses
> have versions and that's proven to be useful several times, even though in
> theory an address is "just" a hash of a pubkey.
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Bitcoin Solutions Ltd provides bespoke software and consultancy. Find us at
bitcoin-solutions.co.uk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150312/cb5f3188/attachment.html>

2023-06-07 15:15:20 UTC

- reply

📅 Original date posted:2014-03-13
📝 Original message:The MultiBit HD view is that this is a locale-sensitive presentation issue.
As a result we offer a simple configuration panel giving pretty much every
possible combination: icon, m+icon, μ+icon, BTC, mBTC, μBTC, XBT,
mXBT, μXBT, sat along
with settings for leading/trailing symbol, commas, spaces and points. This
allows anyone to customise to meet their own needs beyond the offered
default.
We apply the NIST guidelines for representation of SI unit symbols (i.e no
conversion to native language, no RTL giving icon+m etc).
Right now MultiBit HD is configured to use m+icon taken from the Font
Awesome icon set. However reading earlier posts it seems that μ+icon is
more sensible.
Let us know what you'd like.
Links:
m+icon screenshot: http://imgur.com/a/WCDoG
Font Awesome icon: http://fortawesome.github.io/Font-Awesome/icon/btc/
NIST SI guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
On 13 March 2014 12:56, Jeff Garzik <jgarzik at bitpay.com> wrote:
> Resurrecting this topic. Bitcoin Wallet moved to mBTC several weeks
> ago, which was disappointing -- it sounded like the consensus was
> uBTC, and moving to uBTC later --which will happen-- may result in
> additional user confusion, thanks to yet another decimal place
> transition.
>
>
>
> On Sun, Nov 17, 2013 at 9:28 PM, Wendell <w at grabhive.com> wrote:
> > We're with uBTC too. Been waiting for the signal to do this, let's do it
> right after the fee system is improved.
> >
> > -wendell
> >
> > grabhive.com | twitter.com/hivewallet | gpg: 6C0C9411
> >
> > On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:
> >
> >> Go straight to uBTC. Humans and existing computer systems handle
> numbers to
> >> the left of the decimals just fine (HK Dollars, Yen). The opposite is
> >> untrue (QuickBooks really does not like 3+ decimal places).
> >
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.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/1eeb631f/attachment.html>

2023-06-07 15:15:14 UTC

- reply

📅 Original date posted:2014-03-12
📝 Original message:This is purely a MultiBit HD thing. Nothing to do with the BIP, unless the
wider community felt that it would be generally useful.
It has nothing to do with internal word list checking and is purely an
additional check to reduce the blockchain search load for SPV clients when
restoring wallets.
On 12 March 2014 19:35, Jean-Paul Kogelman <jeanpaulkogelman at me.com> wrote:
>
>
> On Mar 12, 2014, at 09:49 AM, Gary Rowe <g.rowe at froot.co.uk> wrote:
>
> Jean-Paul, it may be worth noting that the BIP39 word list is integrated
> into Bitcoinj so will likely become the de facto standard for Android,
> Trezor web and several desktop wallets. Anyone deviating from that word
> list would likely find themselves in an isolated pocket.
>
> Regarding the timestamp, MultiBit HD uses a simple timestamp of "number of
> days since midnight of Bitcoin genesis block in UTC with modulo 97 checksum
> appended". Thus a new seed generated on 27 January 2014 would have
> "1850/01" as its checksum.
>
>
> I'm a bit confused, are you changing the way the checksum is calculated,
> or fudging the input seed to produce a specific checksum? Or is checksum in
> this case another value calculated over the mnemonic list?
>
>
> When creating a new wallet the users are tested that they have written the
> timestamp down along with the associated 12/18/24 words.
>
>
> So this is specific to MultiBit HD? Wouldn't it be better to include this
> into the BIP?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140312/389055f9/attachment.html>

2023-06-07 15:15:13 UTC

- reply

📅 Original date posted:2014-03-12
📝 Original message:Jean-Paul, it may be worth noting that the BIP39 word list is integrated
into Bitcoinj so will likely become the de facto standard for Android,
Trezor web and several desktop wallets. Anyone deviating from that word
list would likely find themselves in an isolated pocket.
Regarding the timestamp, MultiBit HD uses a simple timestamp of "number of
days since midnight of Bitcoin genesis block in UTC with modulo 97 checksum
appended". Thus a new seed generated on 27 January 2014 would have
"1850/01" as its checksum. When creating a new wallet the users are tested
that they have written the timestamp down along with the associated
12/18/24 words.
Modulo 97 was chosen since it catches about 99% of errors.
On 12 March 2014 15:55, Pavol Rusnak <stick at gk2.sk> wrote:
> On 03/12/2014 04:45 PM, Jean-Paul Kogelman wrote:
> > Yes I am. There are some differences between BIP 39 and my proposal
> though.
> >
> > - BIP 39 offers an easy list of words, no gnarly string of case
> sensitive letters and numbers.
>
> Which is better IMO. I can't imagine anyone writing down a long Base58
> encoded string.
>
> > - BIP 39 only offers one fixed length of entropy, always 12 words, no
> option to increase or decrease the length.
>
> Not true, BIP39 supports 12/18/24 words (= 128/192/256 bits of entropy).
>
> > - BIP 39 doesn't have a genesis date field, so no optimization during
> blockchain rescan.
>
> This is nice addition, indeed. But we needed to limit the data as
> possible in order not to increase the number of words needed to be noted
> down.
>
> > - BIP 39 doesn't have password typo detection. No easy way to recover a
> password if you know most of it.
>
> It has a detection. Not correction though.
>
> > - BIP 39 does not have a user selectable KDF, only 2048 round
> PBKDF2-HMAC-SHA512.
> > - BIP 39 can't outsource the KDF computation to a 3rd party.
>
> True, but having one or two solid options are better than having
> gazillions of possible options.
>
> > - BIP 39 wallet implementors can use their own word lists, breaking
> cross wallet compatibility.
>
> True, but they are encouraged to use the list provided. Possibility to
> outsource KDF outside of your "standard" breaks much more compatibility
> than this.
>
> --
> Best Regards / S pozdravom,
>
> Pavol Rusnak <stick at gk2.sk>
>
>
> ------------------------------------------------------------------------------
> 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/20140312/f5fb6f0d/attachment.html>

2023-06-07 15:15:06 UTC

- reply

📅 Original date posted:2014-03-11
📝 Original message:Speaking from the MultiBit perspective, all future protocol development
(with the exception of critical security and network compatibility fixes)
will be put into a HD wallet. Over time we want to see "MultiBit Classic"
gracefully retire and be fully superseded.
Right now, HD is not out there but there is a lot of work going on between
wallet developers to harmonise on HD implementation through BIP32/39. The
result of that work should see a significant migration away from random
private keys.
Thus it would appear likely that by the time this protocol sees widespread
use the presence of HD is likely to be rising fast or possibly dominant.
At MultiBit we anticipate a release of HD code within 2 months, with
private beta occurring within weeks. Trezor and Electrum may be earlier
than this. As far as I am aware both Hive and Haskoin are committed to HD.
If anyone wants early access to the alpha code, let me know and I'll make
the arrangements.
On 11 March 2014 14:44, Jeff Garzik <jgarzik at bitpay.com> wrote:
> (#include <rant.h>)
>
> Right now, HD is hot air. Let us end the pie-in-the-sky assumptions
> about how HD will save the day, with zero code to back it up. Bitcoin
> Wallet purportedly fails to rotate addresses, a privacy ugly, because
> of this Waiting For Godot situation. An attempt to add a simple,
> stateless RPC stalled because we are all Waiting For Godot, also:
> https://github.com/bitcoin/bitcoin/pull/3520
>
> Until the major user wallets and bitcoind have -basic- HD support, it
> is premature to build anything on top of HD. We really have no clue
> at this juncture how difficult will be the HD rollout.
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.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/20140311/bc37f8d9/attachment.html>

2023-06-07 15:11:43 UTC

- reply

📅 Original date posted:2014-01-16
📝 Original message:I like "reusable address".
It is very clear what the intended purpose is and gives a subtle hint that
other types of address should not be re-used.
On 16 January 2014 00:44, Eric Martindale <eric at ericmartindale.com> wrote:
> One variation of this, "recycled address", might avert misconceptions that
> the "re-use" is exclusive to one's own identity.
>
>
> Eric Martindale, relentless maker.
> http://www.ericmartindale.com
> +1 (919) 374-2020 | *BitMessage: *BM-2cWCmYBpV64FRSJpHHKWi1Cfc9W52jydwe
> *Note:* Beginning December 11th, 2013, I will only be intermittently
> available via email, SMS, and BitMessage. As a courtesy, please leave a
> detailed message so that I can respond in kind. Thanks!
>
>
> On Wed, Jan 15, 2014 at 7:05 PM, Jeremy Spilman <jeremy at taplink.co> wrote:
>
>> Might I propose "reusable address".
>>
>> I think that describes it best to any non-programmer, and even more so
>> encourages wallets to present options as 'one time use' vs 'reusable'.
>>
>> It definitely packs a marketing punch which could help drive adoption.
>> The feature is only useful if/when broadly adopted.
>>
>> I think it meets all the criteria required:
>>
>> - Communication between parties is a single message from the payee,
>> which may be public
>> - Multiple payments to the same address are not publicly linkable on
>> the blockchain
>> - The payee has explicitly designated they expect to receive more than
>> one payment at that address
>> - Payer can publicly prove they made a payment to the reusable address
>> by revealing a secret
>>
>> I have high hopes for this feature. The war *against* address reuse may
>> soon be a distant memory.
>>
>> On Wed, 15 Jan 2014 12:44:17 -0800, Jeff Garzik <jgarzik at bitpay.com>
>> wrote:
>>
>> "static address" seems like a reasonable attempt at describing intended
>> use/direction.
>>
>> On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell <gmaxwell at gmail.com>wrote:
>>
>>> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport <bendavenport at gmail.com>
>>> wrote:
>>> > But may I suggest we consider changing the name "stealth address" to
>>> > something more neutral?
>>>
>>> ACK. Regardless of the 'political' overtones, I think stealth is a
>>> little cringe-worthy.
>>>
>>> "Private address" would be fine if not for confusion with private-keys.
>>>
>>> "Static address" is perhaps the best in my view. (also helps improve
>>> awareness that normal addresses are intended to be more one-use-ness)
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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/20140116/73f3769a/attachment.html>

2023-06-07 15:04:01 UTC

- reply

📅 Original date posted:2013-06-27
📝 Original message:Many people that I have introduced Bitcoin to have balked at the massive
blockchain download. When I showed them MultiBit (and Bitcoin Wallet) they
breathed a sigh of relief and got on with it.
A currency lives or dies by network effects. If we can provide the average
low-tech user with a great client experience right from the word go then we
can win them over quickly. Once that is accomplished then more techie users
will likely go on to use a full node which will continue to strengthen the
network overall.
On 27 June 2013 22:12, Alex Kravets <kravets at gmail.com> wrote:
> Hi Jim,
>
> On Thu, Jun 27, 2013 at 12:18 PM, Jim <jim618 at fastmail.co.uk> wrote:
>
>>
>> Alex: Yes I think most users migrate to blockchain.info or,
>> more recently coinbase.com. They are both good wallets
>> but I'd like to keep Bitcoin as P2P as possible.
>>
>
> Guys, being a late comer/outsider (I got into bitcoin in early 2012), I
> can tell you that this particular asylum is definitely run by its inmates.
>
> What all the nerdy devs (and I am one so I know) seem unable to
> comprehend, is that regular people out there don't wanna learn all this new
> stuff and new terminology they simply have no attention span for it.
>
> Simply channelling them to a decent client that
>
> 1. Just works (no blockchain downloads and no re-sync)
> 2. Allows to retain control of the private keys
>
> Would be HUGE for mass adoption.
>
> Old tired argument about "Bitcoin needs your nodes", so we'll channel you
> to get bitcoin-qt client is both manipulative and unnecessary (there's
> plenty of nodes and NAT'ed home nodes which don't mine are mostly useless
> anyways)
>
> P.S. coinbase.com is just another trust-me setup takes your coins in
> exchange for IOUs, whereas blockchain.info does let you to retain control
> of your private keys.
>
> P.P.S. The reason why coinbase has gotten so big is precisely because they
> don't trouble regular lawyers and doctors with all the nonsense but simply
> give them a
> "buy" and a "sell" button.
>
>
>
>
>
>> Luke-Jr
>> I think you are right here on the number of full nodes versus
>> SPV nodes.
>> I don't think we even know yet what are the working ratios of
>> full nodes to SPV nodes. I haven't seen anybody do any
>> analysis on this.
>>
>> I doubt multibit will ever participate in the Bitcoin network
>> other than as an SPV client. All the optimisation is to reduce
>> data traffic - it is effectively a mobile wallet that happens to
>> live on a desktop. It is not really intended to be more than
>> "a wallet for regular people to store and spend their bitcoin".
>>
>> In English the nomenclature for direction of the transactions
>> is: "Sent to" and "Received with". To be honest I
>> haven't transliterated the localisation files to check other
>> language packs but the localisers are pretty good in my
>> experience.
>>
>>
>>
>>
>>
>> On Thu, Jun 27, 2013, at 07:41 PM, Gregory Maxwell wrote:
>> > On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr <luke at dashjr.org> wrote:
>> > > On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote:
>> > >> * Very real possibility of an overall net reduction of full nodes on
>> P2P
>> > >> network
>> > > Even a reduction of *nodes at all*, as I've never seen a listening
>> bitcoinj or
>> > > MultiBit node. :/
>> > > Jim, will MultiBit be adding p2p listening support?
>> >
>> > Without validation listening isn't currently very useful. :( Maybe it
>> > could be somewhat more with some protocol additions.
>> >
>> >
>> ------------------------------------------------------------------------------
>> > This SF.net email is sponsored by Windows:
>> >
>> > Build for Windows Store.
>> >
>> > http://p.sf.net/sfu/windows-dev2dev
>> > _______________________________________________
>> > Bitcoin-development mailing list
>> > Bitcoin-development at lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>> --
>> https://multibit.org Money, reinvented
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> --
> Alex Kravets <http://www.linkedin.com/in/akravets> def redPill = '
> Scala <http://www.scala-lang.org/>
> [[ brutal honesty <http://goo.gl/vwydt> is the best policy ]]
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> 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/20130627/18284bb8/attachment.html>

2023-06-07 10:35:01 UTC

- reply

📅 Original date posted:2012-10-10
📝 Original message:Just to chime in on the MultiBit Merchant aspect. The architecture is that
MBM is a Java backend, but executes as a simple command line:
java -jar mbm.jar server config.yml
As Mike expects, MBM offers a RESTful API using HAL+JSON. It provides a
comprehensive set of order and invoice processing, accounting,
inventory/delivery management and customer account handling facilities for
use with a wide variety of online business models.
There will be a variety of front ends, one of which is an online shop. They
also have the same startup command structure.
Since most folks are shy of using any technology, it is likely that MBM+<x
client> will be offered as part of a SaaS type solution. This allows anyone
who doesn't have the knowledge to configure it for themselves to make use
of it.
MBM will use BitcoinJ and will depend on a bucket of public keys for
transactions until the HD support is in place to allow generation of public
keys without private keys being present. This removes the need for private
keys to be present on the servers, and allows consumers of the SaaS model
to provide their own transaction keys.
The code is released under MIT license so anyone, anywhere can use it to
build the Bitcoin economy.
More info:
https://github.com/gary-rowe/MultiBitMerchant/wiki/Introduction
http://gary-rowe.com/agilestack/2012/06/06/multibit-merchant-genesis/
On 10 October 2012 12:19, Mike Hearn <mike at plan99.net> wrote:
> +gary
>
> > Electrum also has a daemon for merchants.
>
> Well, I suggest taking it up with Thomas directly. A thread here won't do
> much.
>
> > Considering the dislike of
> > Java that exist reflexively in much of the non-java community and the
> > greater ease of deployment and the integration of type-2 split key
> > management
>
> I'm hoping that MultiBit Merchant will provide something similar based
> on bcj, ie, you don't have to actually be a Java developer to use it,
> it can just talk to your app via POSTs and GETs.
>
> WRT deterministic wallets, yes, right now that's indeed a competitive
> advantage of Electrum. So much code to write, so little time.
>
> > Generally for thin clients— a lying server can make clients think
> > they've received confirmed payments they haven't, and unless the
> > client is constructed to be a bit less thin a lying server can lie
> > about input values and cause thin clients to spend large values to
> > fees.
>
> Yes indeed. This also gives [hacked] server operators a way to steal
> money from users without private keys, they can get clients to create
> some very high fee transactions and then provide them directly to a
> miner who promises to cut them in (or they can mine themselves, of
> course).
>
> > Beyond that the protocol between the clients and servers is
> > unauthenticated cleartext JSON in TCP.
>
> I thought it used SSL. Maybe I'm thinking of BCCAPI which is a similar
> approach.
>
> > that the payment is unconfirmed. There is a "pro" mode, that shows
> > 'processing' for unconfirmed transactions
>
> I think communicating transaction confidence to users is something of
> an open UI design problem right now. I agree that hiding it entirely
> seems suboptimal, but in reality explaining what the risks are for a
> given number confirmations is difficult. Given the lack of actually
> reported double-spends against unconfirmed transactions, I can
> understand this choice, even if I wouldn't recommend it.
>
> > My only question is will they know this because we as a community and
> > the authors of the thin clients provided clear explanations and
> > appropriate caution
>
> Well, I pushed for English-text explanations of clients on bitcoin.org
> rather than a feature matrix, for this kind of reason :) Unfortunately
> the current texts are too small to really give a detailed explanation
> of the security models involved. It may be worth adding one-liners
> that link to a page explaining different security models (full, SPV,
> superlight).
>
> One thing I'm really hoping we can find and get agreement on is
> somebody clueful and trustworthy to work on the bitcoin.org website.
> Bitcoin, the project, needs a stronger voice than it currently has,
> partly to speak about such issues. For instance, an FAQ that isn't on
> the wiki would be good. And a simple "Welcome to Bitcoin" flow on the
> bitcoin.org website that guides people to appropriate clients, teaches
> them the security basics, etc, would be excellent.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121010/57eb786a/attachment.html>

2023-06-07 10:27:23 UTC

- reply

📅 Original date posted:2012-08-02
📝 Original message:Hi Steve,
This looks like a good idea to me. The test suites could act similarly to
the 100% Pure Java approach that successfully fended off a lot of
corrupting influences to Java over the years.
Maybe it's worth putting together a small starter suite of tests and
showing them to the community then providing a suitable process, perhaps
through BIPs, to allow tests to be created, reviewed and updated before
getting incorporated into a reference. I imagine a BIP would cover an
aspect of the blockchain rather than a single test or test suite since
having that many BIPs would get onerous fast.
Kind regards,
Gary
On 1 August 2012 12:38, steve <steve at mistfpga.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all,
>
> I know most of you have more important things to do, and not enough
> time as it is, but I would really like your feedback on the testing
> project.
>
> Bettermeans seemed ideal, it allowed for leaderless leadership with
> people being able to dip in and out of what they wanted to do.
> however it seems that bettermeans is in no way a finished product and
> is rotting fast.
>
> I would like to move away from bettermeans - whilst retaining the
> voting and sub workstream style of working. I would like to set
> something up around MantisBT (Mantis Bug Tracker) - this is an
> exceptionally versatile bit of software with plugins and interaction
> with other testing products (everything from test setups and plans to
> test runs and results) I would go as far as saying it is industry
> standard (yeah, i know about bugzilla, etc. mantis beats them all
> hands down.) obviously we would need a wiki and other software - this
> is not a problem.
>
> I am happpy to pay for the VPS' to host this stuff and set it all up.
>
> I have quite a bit of experience with mantis and other opensource
> testing stuff.
>
> I see the testing of bitcoin to be very similar to the testing process
> in the games industry. for those that do not know how this works it
> is like this:-
>
> A company comes up with a device (xbox/ps),
> They then publish a set of dos and donts for this device (TRC for sony
> and TCRs for microsoft. - I wrote quite a few of the MS TCR's for the
> original xbox.)
> They (ms/sony) then test your game against these rules and depending
> on how many you pass/fail your game can be released or not.
>
> I see this as mapping to bitcoin very well, the device is the
> blockchain, and the TRC/TCR _tests_ are published so third party
> developers can see how they fair [look at gavins recent blockchain
> edge cases for an example] (ms/sony do not publish their testcases
> only the requirements)
>
> I believe that this will allow the bitcoin testing project to be able
> to cope with the stable builds, bleeding edge builds and 3rd party
> implementations all at the same time.
>
> It doesnt matter what the app is, it is its interaction with the
> blockchain, the safe guarding of the blockchain and compatibility with
> the previous/future versions that are tested.
>
> [for the bitcoin dev list]
> A little about me:-
> The below is more or less a cut and paste of some of the stuff I sent
> gavin in my initial email about wanting to be in on the project.
>
> I can back all of this up with references. I can go into more detail if
> needed.
>
> I was heavily involved with setting up the microsoft xbox european cert
> department
> I set up qa department for europes largest independant games developer
> (although they are no longer)
>
> worked for microsoft secure science designing security automation tools
>
> setup the internal pentest for thales e-security (now TITS [Thales
> Information Technology Solutions (or Trotters Independant Traders ;),
> on thier datacryptors (fpga, crypto and product) - have done full test
> cycles on hsm 8000, payshield 9000, dc2k and thier latest line of
> military spec comms equipment.
>
> Setup and pentested Thales and nCiphers credit control software (to
> fips level 4 standard - This shit bitcoin exchanges need!! I know bank
> is a dirty word in the bitcoin world, but we should be at least as
> secure as them)
>
> I currently find exploits in stuff like office, quicktime, ie, ff, etc
> and sell them to companies like ZDI (3com) iDefense (verisgn) and some
> pentest companies that require zero day exploits.
>
> however I would like to ditch this and get my bitcoin related stuff
> off the ground - with the BTP being top of the list.
>
> my spelling is rubbish, and sometimes i forget to spellcheck before i
> hit send. sorry about that.
>
> any feedback would be really appreciated. please! I feel that this has
> stagnated enough and I want to get my work out there and I want it to
> be useful. (I lost 60 or so testcases because Kev left himself logged
> into bettermeans and I added them under his account... none appeared
> on the wiki, none appeared anywhere...)
>
> There is already lots of stuff on the wiki that outlines how i see
> things holding together - but you cant see who posted what because of
> a bug that has appeared recently [meta info is just displayed as its
> meta tag, {name} on {date} wrote.]
>
> as apposed to Mistfpga on 30/8/2012 wrote...
>
> so the tl;dr
> 1 - I want to use something other than bettermeans
> 2 - I can admin opensource software to do the same
> 3 - I want to take the voting/hiearachy style from bettermeans and
> apply it to mantis and test workflow.
> 4 - I want to get some testing done asap.
> 5 - I have a full msdn and technet licence
> 6 - I have a vast array of machines [nearly 100 cores] that I can use
> to automate testing and to test different setups.
> 7 - been mining for 18 months or so.
>
> cheers,
>
> steve
>
> I do not belive this to be related, but I am not ashamed and feel no
> stigma. I have posted this on a public forum. I suffer from fast
> cycling (withing a day) type two bipolar disorder. This has been and
> is being managed very well by my meds (300mg quetiapine fumerate and
> 30mg mirtrazipine at night) I have been well for over a year now. [and
> yes, even with these mental health problems I still hold SCE clearance]
>
> - --
> my PGP public key is at pgp.mit.edu id: 0x5016FB50
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJQGRU7AAoJEFvEB9dQFvtQY9oH/RiNBeWDs+tz0NQgkgtXmxcs
> tDtlLWB91gRtmxvXv+yYHE0WXS/qQ5gwaor8Vek61Cvnhij4AQBf7JVYLj03/7fy
> cMAFJ5k7ZQmH9URo8Jx8xzQ2tLgZ5BqLbP6fTzDstpExNGJlkZvsC6hTx9OFCubU
> bzWuWmcIRzBiMhdz7DPoskOgie5sQRzzO0zrK7NvS1P2hyEhM3eFYFcYecpS8jq9
> SbkH77qnc5pZD2JULq38htVwtI16vxmg/s4GIs3OpEPaMk5xtVc5XHf6gwBZQtYw
> fErwZpNDEAmGidRCB4LAqdSx1Xi0ix7GOyvTxBLWTnfB7wIAQNQpBHB9zN8diiA=
> =am8B
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> 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/20120802/c2e5121e/attachment.html>

2023-06-07 10:06:55 UTC

- reply

📅 Original date posted:2012-05-02
📝 Original message:Now that I've seen and read through the forum thread on this, I think I'll
step back and let others get on with it. As Amir notes, we could be "Bike
Shedding" this for years.
On 2 May 2012 21:25, Luke-Jr <luke at dashjr.org> wrote:
> On Wednesday, May 02, 2012 3:34:35 PM Gary Rowe wrote:
> > Bitcoin-Qt
> > * Developed in C
>
> This is far less relevant than license...
>
> > Armory
> > * Requires the entire blockchain
> > * Dependent client of Bitcoin-Qt
>
> Or bitcoind?
>
> > Electrum
> > * Dependent client of Bitcoin-Qt (on server)
>
> Dependent on centralized server, not any particular client
>
> > Bitcoin Wallet (Android client)
>
> There are multiple Android clients. There is (or was) an OS selection to
> the
> left of the client choices...
>
> On Wednesday, May 02, 2012 3:43:23 PM Alan Reiner wrote:
> > I'm not sure what "designed for occasional use" means. Many users of
> > other clients use them exclusively without touching other clients.
> Armory
> > is designed to be your only wallet (if bitcoind[d/-qt] is running in
> bkgd).
> > I'm sure the other clients are the same.
>
> Pretty sure it means "not running continuously".
>
> > Btw, Armory now has full installers for both Windows and Linux
> > (Ubuntu/Debian), with uninstallers and automatic URI registration
>
> Would be awesome if it took after Spesmilo and managed bitcoind itself in
> the
> background...
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120502/ec23d93e/attachment.html>

2023-06-07 10:06:44 UTC

- reply

📅 Original date posted:2012-05-02
📝 Original message:Alan, apologies about the installer - I was just using your website info to
infer how it all fitted together.
On 2 May 2012 20:43, Amir Taaki <zgenjix at yahoo.com> wrote:
> This discussion about ordering is absolutely retarded. Once the list fills
> up, then it won't matter. For now I'm deciding the ordering with Bitcoin-Qt
> first and the others ordered however. That was nobody can try to game the
> system (it remains unexploitable).
>
> If there are no objections, then I am going to merge this branch. The
> forum thread is divulging into a mess all over the place, and this
> conversation can go on forever discussing the silly fine details:
>
> http://hackerspaces.org/wiki/The_Bikeshed_Anti-PatternProblem:
> You suggest creating something new for your hackerspace, like a
> bikeshed. But now all anyone will discuss is its colour. No bikeshed
> will be built.
>
> Armory & MultiBit, are you OK with that description? I will check with
> ThomasV about Electrum.
>
>
> ________________________________
> From: Gary Rowe <g.rowe at froot.co.uk>
> To: "bitcoin-development at lists.sourceforge.net" <
> bitcoin-development at lists.sourceforge.net>
> Sent: Wednesday, May 2, 2012 8:34 PM
> Subject: Re: [Bitcoin-development] new bitcoin.org clients page
>
>
> How about keeping it simple?
>
> Bitcoin-Qt
> * Requires the entire blockchain
> * Standalone client
> * Designed for continuous operation
> * Available for Windows, Mac, Linux with installer
> * Developed in C
> * Website: https://bitcoin.org
>
> MultiBit
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use
> * Available for Windows, Mac, Linux with installer
> * Developed in Java
> * Website: http://multibit.org
>
> Armory
> * Requires the entire blockchain
> * Dependent client of Bitcoin-Qt
> * Designed for occasional use
> * Available for Windows (64-bit only), Mac, Linux (self-build)
> * Developed in Python
> * Website: http://bitcoinarmory.com/
>
> Electrum
> * Requires no blockchain
> * Dependent client of Bitcoin-Qt (on server)
> * Designed for occasional use
> * Available for Windows, Linux (self-build)
> * Developed in Python
> * Website: http://ecdsa.org/electrum/
>
> Bitcoin Wallet (Android client)
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use on mobile
> * Available for Android only
> * Developed in Java
> * Website:
> https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en
>
>
> On 2 May 2012 20:25, Amir Taaki <zgenjix at yahoo.com> wrote:
>
> This is like the most annoying thing about email. Often with group emails,
> we'll be having a conversation then someone will click reply instead of
> group reply and the convo will go on for a while. Eventually I'll realise
> the persons are missing and add them back in.
> >
> >On Yahoo mail (which I use for spam/mailing lists), to do reply all
> involves clicking a tab, scrolling down and clicking Reply All. Normally I
> instead go through the steps of reply, delete To, re-enter bitco... select
> drop down, click send.
> >
> >Anyone know how to make reply all the default in mutt? And how can I
> exclude it from re-including my own email when I do a group reply so I
> don't get the same email again.
> >
> >
> >
> >
> >----- Original Message -----
> >From: Jeff Garzik <jgarzik at exmulti.com>
> >To: grarpamp <grarpamp at gmail.com>
> >Cc: bitcoin-development at lists.sourceforge.net
> >Sent: Wednesday, May 2, 2012 7:29 PM
> >Subject: Re: [Bitcoin-development] new bitcoin.org clients page
> >
> >
> >On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp at gmail.com> wrote:
> >>> Try "Reply to All"
> >>
> >> That puts the sender in 'to' and list in 'cc',
> >> which dupes to the sender and eventually
> >> blows out the to and cc lines as everyone
> >> chimes in and doesn't trim. 'reply to' solves
> >> most of that. assuming the list sw can do it.
> >
> >"Reply-To" Munging Considered Harmful
> >http://www.unicom.com/pw/reply-to-harmful.html
> >
> >
> >
> >--
> >Jeff Garzik
> >exMULTI, Inc.
> >jgarzik at exmulti.com
> >
>
> >------------------------------------------------------------------------------
> >Live Security Virtual Conference
> >Exclusive live event will cover all the ways today's security and
> >threat landscape has changed and how IT managers can respond. Discussions
> >will include endpoint security, mobile security and the latest in malware
> >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >_______________________________________________
> >Bitcoin-development mailing list
> >Bitcoin-development at lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
>
> >------------------------------------------------------------------------------
> >Live Security Virtual Conference
> >Exclusive live event will cover all the ways today's security and
> >threat landscape has changed and how IT managers can respond. Discussions
> >will include endpoint security, mobile security and the latest in malware
> >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >_______________________________________________
> >Bitcoin-development mailing list
> >Bitcoin-development at lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> 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/20120502/624997b5/attachment.html>

2023-06-07 10:06:34 UTC

- reply

📅 Original date posted:2012-05-02
📝 Original message:Or we could just point everyone here:
http://lovebitcoins.org/getStarted.html
:-)
On 2 May 2012 20:40, Raphael NICOLLE <raphbot at gmail.com> wrote:
> Too technical if you ask me. We want a webpage for the dumbest end-user I
> think.
>
> Java? C? What the heck is this? Blockchain? Qt?
>
> Regards,
> Raphael
>
>
> On 05/02/2012 09:34 PM, Gary Rowe wrote:
>
> How about keeping it simple?
>
> Bitcoin-Qt
> * Requires the entire blockchain
> * Standalone client
> * Designed for continuous operation
> * Available for Windows, Mac, Linux with installer
> * Developed in C
> * Website: https://bitcoin.org
>
> MultiBit
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use
> * Available for Windows, Mac, Linux with installer
> * Developed in Java
> * Website: http://multibit.org
>
> Armory
> * Requires the entire blockchain
> * Dependent client of Bitcoin-Qt
> * Designed for occasional use
> * Available for Windows (64-bit only), Mac, Linux (self-build)
> * Developed in Python
> * Website: http://bitcoinarmory.com/
>
> Electrum
> * Requires no blockchain
> * Dependent client of Bitcoin-Qt (on server)
> * Designed for occasional use
> * Available for Windows, Linux (self-build)
> * Developed in Python
> * Website: http://ecdsa.org/electrum/
>
> Bitcoin Wallet (Android client)
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use on mobile
> * Available for Android only
> * Developed in Java
> * Website:
> https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en
>
>
> On 2 May 2012 20:25, Amir Taaki <zgenjix at yahoo.com> wrote:
>
>> This is like the most annoying thing about email. Often with group
>> emails, we'll be having a conversation then someone will click reply
>> instead of group reply and the convo will go on for a while. Eventually
>> I'll realise the persons are missing and add them back in.
>>
>> On Yahoo mail (which I use for spam/mailing lists), to do reply all
>> involves clicking a tab, scrolling down and clicking Reply All. Normally I
>> instead go through the steps of reply, delete To, re-enter bitco... select
>> drop down, click send.
>>
>> Anyone know how to make reply all the default in mutt? And how can I
>> exclude it from re-including my own email when I do a group reply so I
>> don't get the same email again.
>>
>>
>>
>> ----- Original Message -----
>> From: Jeff Garzik <jgarzik at exmulti.com>
>> To: grarpamp <grarpamp at gmail.com>
>> Cc: bitcoin-development at lists.sourceforge.net
>> Sent: Wednesday, May 2, 2012 7:29 PM
>> Subject: Re: [Bitcoin-development] new bitcoin.org clients page
>>
>> On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp at gmail.com> wrote:
>> >> Try "Reply to All"
>> >
>> > That puts the sender in 'to' and list in 'cc',
>> > which dupes to the sender and eventually
>> > blows out the to and cc lines as everyone
>> > chimes in and doesn't trim. 'reply to' solves
>> > most of that. assuming the list sw can do it.
>>
>> "Reply-To" Munging Considered Harmful
>> http://www.unicom.com/pw/reply-to-harmful.html
>>
>>
>>
>> --
>> Jeff Garzik
>> exMULTI, Inc.
>> jgarzik at exmulti.com
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> Bitcoin-development mailing listBitcoin-development at lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120502/288406b8/attachment.html>

2023-06-07 10:06:27 UTC

- reply

📅 Original date posted:2012-05-02
📝 Original message:How about keeping it simple?
Bitcoin-Qt
* Requires the entire blockchain
* Standalone client
* Designed for continuous operation
* Available for Windows, Mac, Linux with installer
* Developed in C
* Website: https://bitcoin.org
MultiBit
* Requires a reduced blockchain
* Standalone client
* Designed for occasional use
* Available for Windows, Mac, Linux with installer
* Developed in Java
* Website: http://multibit.org
Armory
* Requires the entire blockchain
* Dependent client of Bitcoin-Qt
* Designed for occasional use
* Available for Windows (64-bit only), Mac, Linux (self-build)
* Developed in Python
* Website: http://bitcoinarmory.com/
Electrum
* Requires no blockchain
* Dependent client of Bitcoin-Qt (on server)
* Designed for occasional use
* Available for Windows, Linux (self-build)
* Developed in Python
* Website: http://ecdsa.org/electrum/
Bitcoin Wallet (Android client)
* Requires a reduced blockchain
* Standalone client
* Designed for occasional use on mobile
* Available for Android only
* Developed in Java
* Website:
https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en
On 2 May 2012 20:25, Amir Taaki <zgenjix at yahoo.com> wrote:
> This is like the most annoying thing about email. Often with group emails,
> we'll be having a conversation then someone will click reply instead of
> group reply and the convo will go on for a while. Eventually I'll realise
> the persons are missing and add them back in.
>
> On Yahoo mail (which I use for spam/mailing lists), to do reply all
> involves clicking a tab, scrolling down and clicking Reply All. Normally I
> instead go through the steps of reply, delete To, re-enter bitco... select
> drop down, click send.
>
> Anyone know how to make reply all the default in mutt? And how can I
> exclude it from re-including my own email when I do a group reply so I
> don't get the same email again.
>
>
>
> ----- Original Message -----
> From: Jeff Garzik <jgarzik at exmulti.com>
> To: grarpamp <grarpamp at gmail.com>
> Cc: bitcoin-development at lists.sourceforge.net
> Sent: Wednesday, May 2, 2012 7:29 PM
> Subject: Re: [Bitcoin-development] new bitcoin.org clients page
>
> On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp at gmail.com> wrote:
> >> Try "Reply to All"
> >
> > That puts the sender in 'to' and list in 'cc',
> > which dupes to the sender and eventually
> > blows out the to and cc lines as everyone
> > chimes in and doesn't trim. 'reply to' solves
> > most of that. assuming the list sw can do it.
>
> "Reply-To" Munging Considered Harmful
> http://www.unicom.com/pw/reply-to-harmful.html
>
>
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik at exmulti.com
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> 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/20120502/8726da8a/attachment.html>

2023-06-07 03:05:24 UTC

- reply

📅 Original date posted:2012-02-02
📝 Original message:BlueMatt, did the BIP0021 Wiki entry for "req:" to "req-" get updated? I'm
looking there now and it seems to be still at "req:"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120202/754589f8/attachment.html>

2023-06-07 02:59:40 UTC

- reply

📅 Original date posted:2012-01-31
📝 Original message:I think that the "send to private address" field will require more effort
to implement than the simpler "expires" and "message" fields and should be
deferred to a later BIP. There is a pressing need for expires and the only
point of contention I see is the inclusion of a dual representation (block
or timestamp).
Personally, I feel that simple is best and while a block number represents
Bitcoin's pulse, there is no guarantee that a block will be discovered at
any particular moment. From a merchant perspective the main point of the
expires field is to limit risk against currency movement (immediate cash
out) or inventory movement (time limited offer). I have difficulty seeing a
good use case that would need a block. People have been co-ordinating
events based on a UTC timestamp for decades and I think we should stick
with it.
Regarding the "version" field I again think it adds unnecessary complexity.
Pretty much everything that is needed within the Bitcoin URI scheme can be
encoded with suitable optional fields (as query params) making the whole
structure forward compatible. Having a version field seems redundant.
Finally, the URI signing mechanism. Apologies for the earlier
misunderstanding, I was reading from a limited description and it didn't
make the purpose clear. I've since used
https://bitcointalk.org/index.php?topic=58534.msg689190#msg689190 as my
reference which is a lot clearer. I think it's a good idea, and I'll
definitely support it in my MulitBit Merchant project, but it currently
seems to need more work so I think should be deferred into a dedicated BIP.
On 31 January 2012 08:35, Wladimir <laanwj at gmail.com> wrote:
>
> I also wonder whether the "send to private address" should be part of this
> BIP, or a future one.
>
> IMO (but your mileage may vary) this BIP should only define the bare-bones
> URL scheme, AND provide room for future extensions such
> as send-to-private-address, send-multiple-signers, and so on. These should
> be forwards-compatible (as Luke-Jr says) in the sense that older clients
> can detect schemes they don't understand and give the user an appropriate
> error message.
>
> Maybe we need a send-type parameter to define the scheme?
>
> Good point on the version parameter. How are clients supposed to handle
> this? Refuse to handle the request if their URL scheme parser version is
> older than in the URL? This should be in the BIP.
>
> Wladimir
>
> On Tue, Jan 31, 2012 at 9:23 AM, Andreas Schildbach <andreas at schildbach.de
> > wrote:
>
>> Generally I prefer BIP 21 over BIP 20.
>>
>> I'm neutral on the 'send' parameter - present in both BIPs - which I
>> don't understand. I think a practical usecase should be given in the BIP.
>>
>> Also, the 'version' parameter is unclear. What does it mean? Is an oder
>> defined on versions (1.0b > 1.0)? Why is it an ";" parameter rather than
>> a normal "&" parameter?
>>
>>
>> On 01/30/2012 12:55 AM, Amir Taaki wrote:
>> > Matt Corallo posted a modification of BIP 20 in an earlier email and I
>> > asked him if he wanted to become the champion of that BIP he submitted.
>> >
>> > It is a modification of BIP 20 sans the alternative non-decimal number
>> > stuff.
>> >
>> > https://en.bitcoin.it/wiki/BIP_0021
>> >
>> > Right now, I will ask the GUI client implementations like MultiBit or
>> > Bitcoin-Qt, not different codebases like BitCoinJ or libbitcoin if they
>> > support BIP 20 or BIP 21. Feel free to raise any objections.
>> >
>> > More weight will be given to GUIs with actual URI sche me
>> > implementations and it's good to have a general consensus.
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Try before you buy = See our experts in action!
>> > 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-dev2
>> >
>> >
>> >
>> > _______________________________________________
>> > Bitcoin-development mailing list
>> > Bitcoin-development at lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>
>
>
> ------------------------------------------------------------------------------
> 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/20120131/16ac1108/attachment.html>