Gary Rowe [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2012-01-30 to 2015-03-12
💬 Posted a total of 34 messages
📚 Participated in the following categories: Bitcoin-development, RFC
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1j8mfekhmgtne6ptzxptudrcpwd6wtyxk64qdn3swy2nv46zuledskwpach

Profile Code

nprofile1qqsfra5umta59euaq43rq47x3uqhxa89jrtd2sxecc8z9fk2apw0ukcprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqyt8wumn8ghj7un9d3shjtnwdaehgu3wvfskueq6p9vd6

Publishing to

relay.noswhere.com

relay.nostr.band

Author Public Key

npub1j8mfekhmgtne6ptzxptudrcpwd6wtyxk64qdn3swy2nv46zuledskwpach

Show more details

Last Notes

2023-06-07 15:31:32

- reply

2023-06-07 15:31:32

- 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

- 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

- 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

- 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

- 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:12:25

- reply

📅 Original date posted:2014-01-21
📝 Original message:MultiBit here.
>At least Trezor and bitcoinj (Multibit) seems to be going in this way,
>which is 100% of clients which expressed interest in bip39 :-).
>
>slush
We'll be using the BIP39 implementation present in Bitcoinj as slush says.
>Proper Unicode handling is a serious issue however. You don't want
>someone to move from one input method / machine to another and
>suddenly find that their coins are inaccessible, because of an issue
>of decomposed vs. compatibility forms or whatever.
We generate the word list internally (12,18,24) and confirm it is entered
correctly through a retyping operation. This will allow us to detect
character encoding transpositions (e.g. u0032 vs u00a0) and alert the user
before it becomes an issue.
While English is the language of the first word list to be implemented, we
would definitely integrate alternative non-English word lists to make life
easier for the global community. In general the approach would be for the
user to select their language (implying a locale) and then the word list to
be selected from that locale if available with a fallback to English. This
follows the same approach as resource bundles in Java.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140121/c576faef/attachment.html>

2023-06-07 15:11:43

- 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:11:24

- reply

📅 Original date posted:2014-01-01
📝 Original message:Happy New Year to all the good people out there working hard to make
Bitcoin better than ever before.
Thank you!
On 1 January 2014 19:25, Melvin Carvalho <melvincarvalho at gmail.com> wrote:
>
>
>
> On 1 January 2014 19:33, Mike Hearn <mike at plan99.net> wrote:
>
>> Bitcoin had an incredible year in 2013, and I very much enjoyed working
>> with and meeting you all.
>>
>> I'm very much looking forward to some of the upgrades coming in 2014.
>> Though a lot happened in the general community, last year was kind of quiet
>> with respect to the core software. I'm hoping this year we can pick up the
>> pace a little.
>>
>
> Happy new year! Thanks for your awesome contribution and to all those
> that contributed to development.
>
> "Bitcoin" was one of the 100 most searched for terms in 2013, really
> looking forward to 2014!
>
>
>>
>> Cheers!
>>
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>> Pro!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&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/20140101/089e165d/attachment.html>

2023-06-07 15:10:18

- reply

📅 Original date posted:2013-12-05
📝 Original message:Personally, I would be more inclined to submit and work on a BIP if it was
in GitHub. It's a regular home from home for me now.
On 5 December 2013 14:43, Jeff Garzik <jgarzik at bitpay.com> wrote:
> This entire discussion is recycled. Please review the previous
> discussion, before asking the same questions over again.
>
> Properly done, there are FEWER hurdles. In the previous discussion,
> there was outlined a process whereby the BIPS Editor would receive an
> email, and could take it from there. No wiki login or bitcoin payment
> required. More advanced users may submit pull requests.
>
> Compared with a hash-sealed git repo as primary source, the wiki is
> second class.
>
>
> On Thu, Dec 5, 2013 at 9:27 AM, Luke-Jr <luke at dashjr.org> wrote:
> > On Thursday, December 05, 2013 1:37:10 PM Wladimir wrote:
> >> Hello all,
> >>
> >> A while ago after discussion on the mailing list a repository was set
> up to
> >> store the BIP documents, as this is deemed a more secure solution than
> >> having them on the wiki:
> >>
> >> https://github.com/bitcoin/bips
> >>
> >> To prevent confusion the next step should probably be to replace the
> BIPs
> >> on the wiki with links to the github documents, with a notice that
> changes
> >> should be proposed on github or mailed to the BIP editor (gmaxwell).
> >>
> >> Agreed?
> >
> > I think this would stifle active BIP draft editing. We're already having
> a
> > hard time getting some developers to write BIPs for their proposals - I
> don't
> > think we should be putting up bigger hurdles.
> >
> > Luke
> >
> >
> ------------------------------------------------------------------------------
> > Sponsored by Intel(R) XDK
> > Develop, test and display web and hybrid apps with a single code base.
> > Download it for free now!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&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/20131205/a4e50d00/attachment.html>

2023-06-07 15:04:03

- reply

📅 Original date posted:2013-06-30
📝 Original message:I've beefed up the supporting documentation for the website to make it more
accessible for developers who wish to contribute. It's a Java application
serving HTML.
It can be found here: https://github.com/jim618/multibit-website
On 30 June 2013 16:19, Jim <jim618 at fastmail.co.uk> wrote:
> Yeah "email jim' was never going to work so I have
> bumped up MultiBit support (a bit) by:
>
> + having a dedicated Support page on the website
> https://multibit.org/support.html
> It has fixes and support notes for the most common gotchas.
> + the in-app help also now has a 'Support' section with
> "Troubleshooting' and the commonest gotchas.
> I've also written more help to cover as much as possible.
> + Failing that people are directed first to bitcoin.stackchange.com
> (I have a notification set up for the 'multibit' keyword.
> + Then finally users are directed to the github issues to search
> existing or raise a new issue. Gary and Tim often chip in on there to
> close
> issues down as well as me.
>
>
>
> On Sun, Jun 30, 2013, at 12:42 PM, Mike Hearn wrote:
> > Sounds like we have consensus, Saivann, shall we do it?
> >
> > I'm also going to ask Theymos again to relax the newbie restrictions
> > for the alt client forums. It's probably too hard to get support at
> > the moment and "email jim" doesn't scale at all.
> >
> > On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen <gavinandresen at gmail.com
> >
> > wrote:
> > > I vote "yes" to have MultiBit replace Bitcoin-Qt as the recommended
> > > desktop wallet app. I think most users will be happier with it.
> > >
> > > If I'm wrong, it is easy to change back.
> > >
> > >
> ------------------------------------------------------------------------------
> > > 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
> >
> >
> ------------------------------------------------------------------------------
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130630/37790ab0/attachment.html>

2023-06-07 15:04:01

- 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:46:23

- reply

📅 Original date posted:2012-12-05
📝 Original message:I would like to chime on on the user experience of the SPV client (in
particular MultiBit).
Without exception, everyone that I have introduced Bitcoin (which is a lot
of people) have expected an "instant-on" experience. It has to clobber
PayPal and credit cards or people won't give it a second look, let alone a
second chance. SPV clients deliver on that expectation.
Once the user has the great initial "wow!" moment then their interest in
Bitcoin is reinforced and they tend to explore further, particularly into
the economic theory behind it. Many decide to install the full node out of
a sense of community contribution to the security of the network.
Having a hybrid mode of SPV first then full node second should be something
that a user has control over - it is their computing resources we are using
after all and Bitcoin should not be perceived as a drain.
On 5 December 2012 07:50, Wladimir <laanwj at gmail.com> wrote:
> Jim,
>
> Most of those issues don't have to do with the SPV versus non-SPV problem.
>
> First person doesn't understand what Bitcoin is supposed to do (he's
> confusing mining and running a node). An information problem that could be
> solved by explaining what is going on.
>
> Another one seems to have a problem with DEP. That's probably an issue
> with his OS configuration.
>
> The third one is confused about the fees. Again, an information problem.
>
> Only the fourth one is concerned with synchronization. The other ones
> could happen with any client, as they're either based on misconceptions
> about bitcoin as a whole or computer problems.
>
> This doesn't in any way make switching to another, reduced security model
> client preferable. Let's first try to improve the Bitcoin experience with
> full security model, and if that somehow turns out to be impossible it's
> always possible to recommend some other client based on the 'user type'.
>
> I don't agree that this point is now. Anyway, security and stability of
> the network is of utmost importance to do anything in the future, better to
> grow organically than explode.
>
> Many initiatives are underway to improve the Satoshi client (for
> example to have Bitcoin-Qt behave as SPV client during initial block
> download, and as full node after that), but as usual in open source
> development, many of us are doing this basically for fun in our free time
> it does not always go as fast as users would like.
>
> I wish there was a straightforward solution for that, yeah pooling
> together our development on one or two clients instead of a zillion
> different ones could help, but everyone has more fun working on their own
> client that's just how things go :)
>
> Wladimir
>
> On Wed, Dec 5, 2012 at 6:38 AM, Jim Nguyen <jimmy.winn at gmail.com> wrote:
>
>> Gavin's grandma needs to be able to use bitcoin. Here is a real world
>> sampling of the types of people wanting to use bitcoin but are having some
>> difficulty which I have collected from Facebook. Should we listen to the
>> end user? :-P
>>
>> *"what is the intention of Bitcoin? Is it supposed to be - eventually -
>> for dummies like myself or is it just for those individuals who are code
>> and algorithm writers? I downloaded a wallet but how do I know if I need
>> more software or a massive computer system to solve "the problem" for the
>> next block? With all the talk of mathematical problem solving on a world
>> wide network of computers I can't see a small laptop figuring out anything
>> thus not gaining any bitcoins. Why should I be interested in this if it
>> appears it's just for computer scientists?"*
>>
>> *"hi, instaled bitcoin qt, but after it dowladed all the stuff, now i
>> get DEP protecction from windows, and it tells me bitcoinQT need to run
>> with DEP on, dont let me make an exception for it, nor work it i turn DEP
>> only for sys, so hwat i should do?"*
>>
>> *"hi, i'm new to bitcoin, i got a bunch of free bitcoins from a bunch of
>> the free sites. how come when i tried to send my bitcoins to myself, it
>> says the fee exceeds the balance? I thought there was no fees?"*
>>
>> *"Is there a way to speed up the process of synchronisation with the
>> network? It has been taken ages on my MAC.*
>> *Any help would be nice"*
>> *
>> *
>> *and more...*
>>
>> Sorry if this doesn't belong to the bitcoin-development email list. I
>> just see this as end-user/customer data gathering to refine the
>> requirements, since this is software engineering...isn't it?
>>
>> Jim
>>
>> On Tue, Dec 4, 2012 at 6:54 PM, Gregory Maxwell <gmaxwell at gmail.com>wrote:
>>
>>> On Tue, Dec 4, 2012 at 9:08 PM, Alan Reiner <etotheipi at gmail.com> wrote:
>>> > Our divergence is on two points (personal opinions):
>>> >
>>> > (1) I don't think there is any real risk to the centralization of the
>>> > network by promoting a SPV (purely-consuming) node to brand-new users.
>>> > In my opinion (but I'm not as familiar with the networking as you), as
>>> > long as all full nodes are full-validation, the bottleneck will be
>>> > computation and bandwidth, long before a constant 10k nodes would be
>>> > insufficient to support propagating data through the network.
>>>
>>> Not so— a moderately fast multicore desktop machine can keep up with
>>> the maximum possible validation rate of the Bitcoin network and the
>>> bandwidth has a long term maximum rate of about 14kbit/sec— though
>>> you'll want at least ten times that for convergence stability and the
>>> ability feed multiple peers.
>>>
>>> Here are the worst blocks testnet3 (which has some intentionally
>>> constructed maximum sized blocks),E31230 :
>>> (with the new parallel validation code)
>>> - Verify 2166 txins: 250.29ms (0.116ms/txin)
>>> - Verify 3386 txins: 1454.25ms (0.429ms/txin)
>>> - Verify 5801 txins: 575.46ms (0.099ms/txin)
>>> - Verify 6314 txins: 625.05ms (0.099ms/txin)
>>> Even the slowest one _validates_ at 400x realtime. (these measurements
>>> are probably a bit noisy— but the point is that its fast).
>>> (the connecting is fast too, but thats obvious with such a small
>>> database)
>>>
>>> Although I haven't tested leveldb+ultraprune with a really enormous
>>> txout set or generally with sustained maximum load— so there may be
>>> other gaffs in the software that get exposed with sustained load, but
>>> they'd all be correctable. Sounds like some interesting stuff to test
>>> with on testnet fork that has the POW test disabled.
>>>
>>> While syncing up a behind node can take a while— keep in mind that
>>> you're expecting to sync up weeks of network work in hours. Even
>>> 'slow' is quite fast.
>>>
>>> > In fact,
>>> > I was under the impression that "connectedness" was the real metric of
>>> > concern (and resilience of that connectedness to large percentage of
>>> > users disappearing suddenly). If that's true, above a certain number
>>> of
>>> > nodes, the connectedness isn't really going to get any better (I know
>>> > it's not really that simple, but I feel like it is up to 10x the
>>> current
>>> > network size).
>>>
>>> Thats not generally concern for me. There are a number of DOS attack
>>> risks... But attacker linear DOS attacks aren't generally avoidable
>>> and they don't persist.
>>>
>>> Of the class of connectedness concerns I have is that a sybil attacker
>>> could spin up enormous numbers of nodes and then use them to partition
>>> large miners. So, e.g. find BitTaco's node(s) and the nodes for
>>> miners covering 25% hashpower and get them into a separate partition
>>> from the rest of the network. Then they give double spends to that
>>> partition and use them to purchase an unlimited supply of digitally
>>> delivered tacos— allowing their captured miners to build an ill fated
>>> fork— and drop the partition once the goods are delivered.
>>>
>>> But there is no amount of full nodes that removes this concern,
>>> especially if you allow for attackers which have compromised ISPs.
>>> It can be adequately addressed by a healthy darknet of private
>>> authenticated peerings between miners and other likely targets. I've
>>> also thrown out some ideas on using merged mined node IDs to make some
>>> kinds of sybil attacks harder ... but it'll be interesting to see how
>>> the deployment of ASICs influences the concentration of hashpower— it
>>> seems like there has already been a substantial move away from the
>>> largest pools. Less hashpower consolidation makes attacks like this
>>> less worrisome.
>>>
>>> > (2) I think the current experience *is* really poor.
>>>
>>> Yes, I said so specifically. But the fact that people are flapping
>>> their lips here instead of testing the bitcoin-qt git master which is
>>> an 1-2 order of magnitude improvement suggests that perhaps I'm wrong
>>> about that. Certainly the dearth of people testing and making bug
>>> reports suggests people don't actually care that much.
>>>
>>> > You seem to
>>> > suggest that the question for these new users is whether they will use
>>> > full-node-or-lite-node, but I believe it will be a decision between
>>> > lite-node-or-nothing-at-all (losing interest altogether).
>>>
>>> No. The "question" that I'm concerned with is do we promote lite nodes
>>> as equally good option— even for high end systems— remove the
>>> incentive for people to create, improve, and adopt more useful full
>>> node software and forever degrade the security of the system.
>>>
>>> > Waiting a day
>>> > for the full node to synchronize, and then run into issues like
>>> > blkindex.dat corruption when their system crashes for some unrelated
>>> > reason and they have to resync for another day... they'll be gone in a
>>> > heartbeat.
>>>
>>> The current software patches plus parallelism can sync on a fast
>>> system with luck network access (or a local copy of the data) in under
>>> an hour.
>>>
>>> This is no replacement for start as SPV, but nor are handicapped
>>> client programs a replacement for making fully capable ones acceptably
>>> performing.
>>>
>>> > Users need to experience, as quickly and easily as possible, that they
>>> > can move money across the world, without signing up for anything or
>>> > paying any fees.
>>>
>>> Making the all the software painless for users is a great goal— and
>>> one I share. I still maintain that it has nothing to do with
>>> promoting less capable and secure software to users.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>>> Remotely access PCs and mobile devices and provide instant support
>>> Improve your efficiency, and focus on delivering more value-add services
>>> Discover what IT Professionals Know. Rescue delivers
>>> http://p.sf.net/sfu/logmein_12329d2d
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>> Remotely access PCs and mobile devices and provide instant support
>> Improve your efficiency, and focus on delivering more value-add services
>> Discover what IT Professionals Know. Rescue delivers
>> http://p.sf.net/sfu/logmein_12329d2d
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> 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/20121205/5e194147/attachment.html>

2023-06-07 10:43:09

- reply

📅 Original date posted:2012-12-17
📝 Original message:I've been following this thread closely, and Mike is correct here -
protocol buffers is definitely the way to go.
On 17 December 2012 09:19, Mike Hearn <mike at plan99.net> wrote:
> Can we please drop the binary vs text issue? We have been around it
> millions of times already. There are no compelling arguments to use
> text here and several obvious problems with it. If you think you've
> found a good argument to use JSON, please research protocol buffers
> more thoroughly and see if it changes your mind.
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> 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/20121217/ac1042fa/attachment.html>

2023-06-07 10:35:01

- 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:33:02

- reply

📅 Original date posted:2012-09-25
📝 Original message:This is definitely worth doing and I wish you every encouragement.
For my part I'm working on a different area of the Bitcoin ecosystem and
that is taking up all my time so I can only cheer you on from the sidelines.
On 25 September 2012 21:49, Daniel F <nanotube at gmail.com> wrote:
> on 09/25/2012 02:32 PM steve said the following:
> > Anyone interested in helping out/reviewing processes? even if it is just
> > some encouragement, it is all greatly appreciated.
>
> not enough time in the day for me to seriously help out, but since you
> asked, here's some encouragement. :) more testing == good.
>
>
>
> ------------------------------------------------------------------------------
> 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/20120925/b170e63a/attachment.html>

2023-06-07 10:27:23

- 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:22:50

- reply

📅 Original date posted:2012-07-16
📝 Original message:I'm sure that there are many but my Google Search-Fu is not strong enough
to build a query to identify how widespread they are.
Maybe once we have sufficient evidence to support the suspicion we should
post to the main developer forum asking for a cleanup. After all, a Bitcoin
URI starting bitcoin://<address> doesn't actually make much sense because
there is no hierarchy in Bitcoin - it's flat with only an address being a
mandatory element.
I don't want to be all anal about this, but looking at RFC 3986 #10 (
http://tools.ietf.org/html/rfc3986#page-10) it's pretty clear that
introducing a false hierarchy is breaking the specification since it
presumes the existence of a relative URI.
On 16 July 2012 10:02, Wladimir <laanwj at gmail.com> wrote:
> But is he the only one using the broken URLs? It was my impression that
> they were widespread already.
>
> Wladimir
>
>
> On Mon, Jul 16, 2012 at 10:52 AM, Gary Rowe <g.rowe at froot.co.uk> wrote:
>
>> Is it worth having a few more people email Ben to ask him politely to
>> fall into line with the BIP? No point encouraging broken windows by not
>> speaking out.
>>
>>
>> On 16 July 2012 09:16, Andreas Schildbach <andreas at schildbach.de> wrote:
>>
>>> > I asked Ben to fix this (social networks don't parse QRcodes after
>>> > all), but after explaining that social networks don't parse URLs
>>> > without :// in them, he stopped responding to my emails. So I've gone
>>> > ahead and added support for reading these types of URLs to bitcoinj,
>>> > in the interests of "just works" interoperability.
>>> >
>>> > This mail is just a heads up in case anyone else wants to do the same
>>> > thing. Hopefully at some point, Ben will stop generating such QRcodes
>>> > and we can remove these hacks and get back to BIP compliance.
>>>
>>> The problem with this "accept everything even if broken" approach is
>>> that people will probably never fix the broken stuff. So we likely end
>>> up with a fragmented de-facto standard.
>>>
>>> That does not mean I am totally against accepting broken URLs, but there
>>> should be at least a promise that they will be fixed at the source.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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/20120716/2096e804/attachment.html>

2023-06-07 10:22:43

- reply

📅 Original date posted:2012-07-16
📝 Original message:Is it worth having a few more people email Ben to ask him politely to fall
into line with the BIP? No point encouraging broken windows by not speaking
out.
On 16 July 2012 09:16, Andreas Schildbach <andreas at schildbach.de> wrote:
> > I asked Ben to fix this (social networks don't parse QRcodes after
> > all), but after explaining that social networks don't parse URLs
> > without :// in them, he stopped responding to my emails. So I've gone
> > ahead and added support for reading these types of URLs to bitcoinj,
> > in the interests of "just works" interoperability.
> >
> > This mail is just a heads up in case anyone else wants to do the same
> > thing. Hopefully at some point, Ben will stop generating such QRcodes
> > and we can remove these hacks and get back to BIP compliance.
>
> The problem with this "accept everything even if broken" approach is
> that people will probably never fix the broken stuff. So we likely end
> up with a fragmented de-facto standard.
>
> That does not mean I am totally against accepting broken URLs, but there
> should be at least a promise that they will be fixed at the source.
>
>
>
> ------------------------------------------------------------------------------
> 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/20120716/8f48a16b/attachment.html>

2023-06-07 10:22:18

- reply

📅 Original date posted:2012-07-09
📝 Original message:Although I can only speak for my involvement with MultiBit, the idea of a
randomised client page seems wrong to me, for the reasons given by Alan
earlier.
Equally, in order to further the idea that Bitcoin is more than the
reference client, it is appropriate that other clients are acknowledged and
promoted. Bitcoin.org has by far the most traffic and by directing people
to other clients that may be more suitable to their needs the user
experience is improved considerably. After all, not everyone wants a 2.5Gb+
download before starting out on their Bitcoin adventure.
If the reference client was the best of all possible worlds then there
would be no need for the alternative clients.
On 9 July 2012 20:14, Alan Reiner <etotheipi at gmail.com> wrote:
> I was originaly for the idea of randomization. Because it is the most
> "fair", but "fair" is a relative term. It's fair for client developers who
> argue over whose client should be first, and whose is better for various
> purposes. But it's not fair for users, to have an inconsistent page, that
> sometimes recommends less-developed solutions, or doesn't show what's best
> *for the users in the community*.
>
> I think the premise of having a page that is "fair for developers" is its
> downfall. Once we agree things have to be fair, we must agree on what fair
> means, and then we must accept 30 new recently-started projects that barely
> squeak by the requirements for being on the page, despite having
> substantial issues/bugs. The premise of being fair is the downfall here.
>
> This *has* to be a subjective list. Someone who is trusted to
> understand what is good for users, and who also has familiarity with the
> programs, should be the one to decide. People can try to provide input,
> and make them aware of stuff they didn't know. But it should be *that
> person's* decision, and if it's not "fair" in your world, too bad. At
> least we won't spend the next 3 years arguing on the mailing list about how
> to compare programs that are all great in many different dimensions, and
> failing in the others.
>
> If it's going to go on the main page, give someone the responsibility to
> come up with "what's best for the users of Bitcoin.org", however they
> decide to interpret it, and save our breath arguing over more important
> things.
>
> -Alan
>
>
>
> On Mon, Jul 9, 2012 at 2:57 PM, Gregory Maxwell <gmaxwell at gmail.com>wrote:
>
>> On Mon, Jul 9, 2012 at 2:54 PM, Jim <jim618 at fastmail.co.uk> wrote:
>> > RE: The position randomisation - I have to admit I was secretly pleased
>> > with the original layout, as MultiBit just happened to have the "eye
>> > candy" position of "top and centre". It is only fair to have them
>> > switch around.
>>
>> This ordering wasn't accidental.
>>
>>
>> ------------------------------------------------------------------------------
>> 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/20120709/56da5102/attachment.html>

2023-06-07 10:06:55

- 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

- 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

- 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

- 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 10:04:44

- reply

📅 Original date posted:2012-04-13
📝 Original message:Hi Walter,
This could be of interest to the XChange project. See GitHub:
https://github.com/timmolter/XChange
The aim of this project is to provide a unifed API for applications to
access financial exchanges. At present it supports Bitcoin exchanges (MtGox
and Intersango are the primary focus with others to follow). It is in the
very early stages of development, but is likely to be integrated into the
MultiBit Bitcoin client (see http://multibit.org) in the near future (early
prototypes are available directly from sources).
One problem that the XChange development team faces is that each exchange
rolls its own data model and uses its own protocol (web socket, socket IO,
direct socket and so on). To provide a reference implementation of how an
exchange should publish its data would be beneficial.
Kind regards,
Gary
On 13 April 2012 10:34, Walter Stanish <walter at stani.sh> wrote:
> The Internet Financial EXchange (IFEX) Project is an open body for the
> discussion and development of financial standards for the internet
> community. The project seeks to focus on enhancing interoperability
> between financial settlement systems of all types, including
> conventional financial systems, emerging digital currencies,
> alternative financial communities, and financial service providers.
>
> Interested parties are invited to review the proposals on the website
> at http://www.ifex-project.org/ and join the mailing list at
> http://group.ifex-project.org/
>
> Two items on the site that may be of particular interest:
>
> (1) The latest version of the IIBAN Proposal (v1) for financial
> endpoint identification at
> http://www.ifex-project.org/our-proposals/iiban. This latest version
> includes initial IANA registry contents and a reference mechanism for
> financial endpoint transcription error correction. (Relevance: In
> contrast to settlement system-specific financial endpoint identifiers,
> IIBAN provides a democratically allocated, 13 character identifier
> that is already familiar in format to users in Europe and other
> countries and is theoretically compatible with conventional banking
> infrastructure in those regions. In addition, IIBAN is not tied to
> any specific financial commodity or settlement system, and provides
> strong protection against identifier transcription errors.)
>
> (2) The IFEX Protocol is a *work in progress* that hopes to bridge the
> gap between conventional financial systems, emerging digital
> currencies, alternative financial communities, and financial service
> providers by providing a standard protocol for transaction and
> settlement path negotiation with arbitrary financial instruments,
> currencies or assets. (Relevance: better connectivity, lower
> settlement fees, real time redundant financial routing, arbitrary
> instrument/currency/asset handling)
>
> How IFEX's proposed infrastructure differs from existing projects:
> - Not a currency, not a settlement-network, but a mechanism for bridging
> them.
> - Broader and more inclusive scope than existing vendor-specific APIs
> and conventional finance industry networking protocols. Global focus.
> No legacy 'features'. No artificial barriers to innovators.
>
> The hope is to move towards an open source implementation of the (work
> in progress) IFEX protocol that interoperates with major and emerging
> settlement networks for the benefit of all parts of the community. We
> have already had expressions of interest from representatives in a
> range of communities (Bitcoin, CES, Ripple, W3C Web Payments, digital
> currency exchange developers, etc.), and look forward your input on
> the mailing list.
>
> Happy Friday the 13th!
>
> Regards,
> Walter Stanish
> The IFEX Project
> http://www.ifex-project.org/
>
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> 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/20120413/af7ebaac/attachment.html>

2023-06-07 03:05:36

- reply

📅 Original date posted:2012-02-04
📝 Original message:Seems reasonable to me.
On 4 Feb 2012 14:03, <thomasV1 at gmx.de> wrote:
> Just another question concerning BIP21:
>
> On the wiki, the description of the "message" parameter reads:
> "message that shown to the user after scanning the QR code"
>
> I believe that the purpose of this parameter is to contain a description
> of the transaction. This has use cases that go beyond QR codes.
>
> If I am right, then I would say that naming it "message" is misleading. In
> fact, "message" suggests that a message will be sent to someone (the
> recipient of the funds? a third party?), which is not the case here. That
> parameter should probably be called "description".
>
> --
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
>
>
> ------------------------------------------------------------------------------
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120204/018b4fbb/attachment.html>

2023-06-07 03:05:30

- reply

📅 Original date posted:2012-02-02
📝 Original message:OK - I've added a comment to the pull request.
On 2 February 2012 17:39, Matt Corallo <bitcoin-list at bluematt.me> wrote:
> Not yet, its up to genjix (Amir) to do that. See
> https://github.com/genjix/bips/pull/2
>
> Matt
>
> On Thu, 2012-02-02 at 17:07 +0000, Gary Rowe wrote:
> > 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:"
> >
> ------------------------------------------------------------------------------
> > 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/20120202/4db373e4/attachment.html>

2023-06-07 03:05:24

- 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 03:02:14

- reply

📅 Original date posted:2012-01-31
📝 Original message:Regarding the decimal vs satoshi notation I see a few problems with satoshi:
* readability - humans reading the URI would expect it to accurately
reflect what is being displayed (subject to internationalisation issues)
For example, amount=1.234 is more human readable than amount=123400000 (ish)
* backwards compatibility - existing software already uses the decimal
notation
* forwards compatibility - Bitcoin needs to move beyond the satoshi to 20
dps for some reason, this remains OK within the existing schema, but forces
decimals into the satoshi scheme
* simplicity - dual decimal/satoshi variants should be discouraged under
the "single representation" approach
It's relatively straightforward to convert a string encoded decimal into an
internal integer for currency calculations just by applying a multiplying
factor. One never uses doubles or floats for money.
On 31 January 2012 14:33, slush <slush at centrum.cz> wrote:
> Hi Amir,
>
> > All the HTML, URI and everything uses decimal numbers alone. I see no
> reason for breaking with tradition.
>
> excuse me if it was already discussed, but maybe using satoshis instead of
> decimal bitcoin would be better choice? We all know about pains with proper
> handling decimal numbers across of all implementations - and it's not only
> about json-rpc.
>
> Otherwise I agree, BIP 21 is better than BIP 20 because it's easier to
> implement all points of the standard.
>
> Best,
> slush
>
> On Tue, Jan 31, 2012 at 3:27 PM, Amir Taaki <zgenjix at yahoo.com> wrote:
>
>> BIP 20 really has no support among implementations such as Bitcoin-Qt,
>> Electrum, MultiBit or Bitcoin-JS. As the most active and visible user
>> facing GUI projects (all with some form of URI Scheme), their opinion
>> carries the most weight. To a lesser degree Bitcoin-Qt has the large
>> majority of users too (although that's a line of reasoning I'd discourage).
>>
>> Normally we should probably Reject BIP 21 and re-submit a new standard
>> (for history's sake), but as a) BIP 21 is largely a copy paste of BIP 20
>> sans some sections b) it is still a draft, probably the best thing here is
>> if you all agree on something to run it by BlueMatt and then we'll make it
>> the new BIP 21.
>>
>> I can see a consensus forming on most parts. Just the send private key is
>> contentious, and there's the topic of adding a time to expire field for
>> merchants (this is a very good idea IMO).
>>
>> Also BIP 20 is problematic because it is incompatible with about every
>> standard on the web. All the HTML, URI and everything uses decimal numbers
>> alone. I see no reason for breaking with tradition. Note that everytime I
>> have to write Color or Vectorize (as a British speaker) in my code, I die a
>> little inside. But it's convention and American English = International
>> English. Also it would be cool if all code used a *real* international
>> language (like Esperanto) but the world ain't perfect! We live in a
>> decimal-counting English-speaking Windows-using God-worshipping world!
>>
>> (no offense to decimal-counting English-speaking Windows-using
>> God-worshipping world- I do half those things too :)
>>
>>
>> ------------------------------------------------------------------------------
>> 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/fbee5852/attachment.html>

2023-06-07 03:02:09

- reply

📅 Original date posted:2012-01-31
📝 Original message:Shudder.
:-)
On 31 January 2012 15:02, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Tue, Jan 31, 2012 at 9:53 AM, Gary Rowe <g.rowe at froot.co.uk> wrote:
> > One never uses doubles or floats for money.
>
> Lots and lots of people do. Go place a sell order on mtgox for
>
> $999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
> per BTC and look at the awesome doublemax trade it actually stores for
> you.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120131/c0674004/attachment.html>

2023-06-07 03:01:57

- reply

📅 Original date posted:2012-01-31
📝 Original message:Andreas has a good point. See RFC 3986 on URI schemes:
http://tools.ietf.org/html/rfc3986#page-12
The colon is a reserved general delimiter (similar in use to the / in a
typical URL, but applies to URNs etc). As suggested, we get req:something
being changed to one of the unreserved characters that do not have to be
URL encoded. Again, from the RFC these are
* Option A: req_something (underscore)
* Option B: req-something (hyphen)
* Option C: req~something (tilde)
* Option D: req.something (period)
Personally, my eye likes Option B, the hyphen.
On 31 January 2012 22:14, Andreas Schildbach <andreas at schildbach.de> wrote:
> On 01/31/2012 07:22 PM, Matt Corallo wrote:
>
> > that "It is recommended that additional variables prefixed with
> > mustimplement: not be used in a mission-critical way until a grace
>
> Is the ':' sign actually allowed in URL parameter names
> (unescaped/unencoded)? If not, I'd propose an unrestricted char instead,
> maybe '_'.
>
>
>
>
> ------------------------------------------------------------------------------
> 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/682b40e3/attachment.html>

2023-06-07 03:01:12

- reply

📅 Original date posted:2012-01-30
📝 Original message:Hi all,
Speaking on behalf of the MultiBit team (Jim's currently on holiday), we
will not be supporting Tonal Bitcoins anytime soon. Therefore we back the
BIP 21 proposal.
At present MultiBit does not support the "message" or "send" fields but we
would be happy to add this functionality as required.
Regarding the idea of a signed URI, it is appealing, however, it may not
work. If I understand it correctly, the main idea appears to be to protect
a URI from malicious replacement (at MultiBit we were concerned that a
Bitcoin "swatch" would be subjected to the same attack vector and we came
up with the term "swatch swabbing"). If a Bitcoin URI is served up from a
trusted source (e.g. a merchant site over HTTPS) then there is no need for
signing. It should be assumed that the merchant will offer a clean room
payment area so that no untrusted JavaScript will creep into the final page
and wreak havoc.
It would seem that in any situation where the attacker has complete control
over the content of the URI they will be able to successfully swab it to
match their own fraudulent address. Imagine attempting to protect a QR code
posted against a pole attempting to get BTC donations for a charity. How
long before that was replaced by a different version operated by the
thieves with good signatures all round?
Of course, I may have misunderstood so I would welcome further discussion.
One field that the MultiBit team would like to add to the BIP 21 proposal
is "expires" which would contain an ISO8601 formatted date/time in UTC
(e.g. "2000-01-01T23:59:59Z"). This would allow merchants to issue Bitcoin
URIs that would expose them to a currency/inventory risk for a defined
period of time.
Kind regards,
Gary Rowe
PS First post to this list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120130/17b4bede/attachment.html>

2023-06-07 03:00:05

- reply

📅 Original date posted:2012-01-30
📝 Original message:Having closely read the BIP20 proposal, I can see your point. As I see it,
BIP 20 vs BIP 21 is about standardising on a representation of the "amount"
field. BIP 20 proposes that "amount" can contain alternative
representations, clearly defined, whereas BIP 21 requires the use of a
single representation in decimal notation.
In my view, BIP 21 still wins since it reduces complexity for the end
client both at the human and machine level.
On 30 January 2012 18:56, Luke-Jr <luke at dashjr.org> wrote:
> On Monday, January 30, 2012 1:50:03 PM Gary Rowe wrote:
> > Speaking on behalf of the MultiBit team (Jim's currently on holiday), we
> > will not be supporting Tonal Bitcoins anytime soon. Therefore we back the
> > BIP 21 proposal.
>
> It is not correct to imply that BIP 20 requires Tonal Bitcoin support.
> In fact, the exact opposite is true; it states that even if one unit (eg,
> TBC)
> would be a more rational way to display a specified amount, clients should
> still interpret it in the way that is deemed to be most intuitive to the
> user
> (eg, BTC).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120130/cb417acb/attachment.html>

2023-06-07 02:59:40

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