<unnamed>

Public Key

npub1a9uelw8hswrmps0ayl2dzkh625xjznd5glvqrkhpxngdzupjw8kqqlc2j9

Profile Code

nprofile1qqswj7vlhrmc8pasc87j04x3tta92rfpfk6y0kqpmtsnf5x3wqe8rmqpzpmhxue69uhkummnw3ezuamfdejszrthwden5te0dehhxtnvdakqz9rhwden5te0wfjkccte9ejxzmt4wvhxjmct45rcj

Publishing to

nostr.wine

nos.lol

relay.damus.io

Last Notes

2023-06-07 15:31:26 UTC

- reply

📅 Original date posted:2015-03-11
📝 Original message:The wallet words system isn't perfect for sure but it does help the user in two main ways:
1) Assuming wallet devs ensure forward compatibility for _their_ wallet the user knows they can recover their bitcoins using the same wallet software in case of a Bad Thing Happening.
2) To an imperfect degree, they can transfer/ recover their bitcoins that are stored in Wallet X into Wallet Y. We need to give them guidance on how to do this.
I think it is up to each wallet team to explain to their users clearly how they can do this in their help. It's only good manners to show your guests where the fire exits are.
It can be a simple help page saying:
"If you want to transfer your bitcoin out of MultiBit HD to Lighthouse, do this, this and this.
If you want to use the Trezor wallet you created in MultiBit HD on myTrezor.com, do this, this and this."
That way users have clear instructions on how to recover their bitcoins.
Users don't care about BIP this or BIP that but they REALLY DO CARE about keeping their bitcoins.
--
http://bitcoin-solutions.co.uk
On Wed, Mar 11, 2015, at 05:14 PM, Mike Hearn wrote:
> Sigh. The wallet words system is turning into kind of a mess.
>
> I thought the word list is in fact not a fixed part of the spec, because
> the entropy is a hash of the words. But perhaps I'm misunderstanding
> something.
>
> The main problem regular SPV wallets have with BIP39 is that there is no
> birth time included in the data. Therefore we must ask users to write down
> a timestamp as well, so we know where to start rescanning the chain. It
> sounds like the Electrum version doesn't fix this, so now we have at least
> FIVE incompatible results from a 12 word list:
>
> - Electrum v2 with a version number but no date
> - myTREZOR with no version and no date and BIP44 key derivation. Some
> seeds I believe are now being generated with 24 words instead of 12.
> - MultiBit HD with no version and a date in a custom form that creates
> non-date-like codes you are expected to write down. I think BIP32 and BIP44
> are both supported (sorta).
> - GreenAddress with no version, no date and BIP32
> - Other bitcoinj based wallets, with no version and a date written down
> in normal human form, BIP32 only.
>
> I really hope we can recover from this somehow because otherwise all
> wallets will have to provide the user with a complicated matrix of
> possibilities and software combinations, and in practice many won't bother
> so these word combinations will actually end up being wallet specific for
> no particularly good reason, just very minor details like the presence or
> absence of single fields.
>
> It feels like we somehow fell flat on our faces just before the finishing
> line. This is deeply unfortunate. Compatibility and UX consistency is
> important!
>
> Currently, I don't have any bright ideas for how to get everyone back onto
> the same page with a fully compatible system that is acceptable to all. If
> anyone else has suggestions, I'm all ears.
> ------------------------------------------------------------------------------
> 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

2023-06-07 15:31:25 UTC

- reply

📅 Original date posted:2015-03-02
📝 Original message:Great to see Electrum 2.0 tagged !
It's been a long road I know.
Congratulations to ThomasV and all the other Electrum contributors.
:-)
Jim
--
http://bitcoin-solutions.co.uk
On Mon, Mar 2, 2015, at 03:37 PM, Mike Hearn wrote:
> Congrats Thomas! Glad to see Electrum 2 finally launch.
>
>
> > * New seed derivation method (not compatible with BIP39).
>
>
> Does this mean a "12 words" wallet created by Electrum won't work if
> imported into some other wallet that supports BIP39? Vice versa? This seems
> unfortunate. I guess if seeds are being represented with 12 words
> consistently, people will expect them to work everywhere.
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:16:23 UTC

- reply

📅 Original date posted:2014-03-27
📝 Original message:Good to hear the bip32 wallet structure is _so_ close to being standardised.
For MultiBit HD, we have put in support for 12/18/24 words but have the UI 'suggest' to use 12.
You can see this on the wallet creation wizard Gary recently blogged about:
https://multibit.org/blog/2014/03/26/multibit-hd-welcome-wizard.html
There's a little combo for the seed length, with 12 as the default.
@Thomas. You mention gaps. We are creating new addresses on the UI in a panel marked 'Request' where the user also types in a QR code label and a note to themselves. This gets stored away as a first class 'PaymentRequest'. The UI 'suggests' that each address is used once. There will be some gaps (where the payment request is never paid) but we aren't bulk creating addresses. I am hoping this shouldn't cause Electrum a problem.
We are also storing a timestamp (the number of days since the genesis block) to help wallet restore but that is SPV specific.
On Thu, Mar 27, 2014, at 01:49 PM, Thomas Voegtlin wrote:
>
>
> Le 27/03/2014 13:49, Mike Hearn a écrit :
IP32 allows for a range of entropy sizes and it so happens that
> > they picked 256 bits instead of 128 bits.
> >
> > I'd have thought that there is a right answer for this. 2^128 should not
> > be brute forceable, and longer sizes have a cost in terms of making the
> > seeds harder to write down on paper. So should this be a degree of freedom?
> >
>
>
> Here is what I understand:
>
> 2^128 iterations is not brute forcable today, and will not be for the
> foreseeable future.
>
> An EC pubkey of length n can be forced in approximately 2^(n/2)
> iterations (see http://ecc-challenge.info/) Thus, Bitcoin pubkeys, which
> are 256 bits, would require 2^128 iterations. This is why unused
> addresses (160 bits hash) are better protected than already used ones.
>
> However, people tend to believe that a public key of size n requires 2^n
> iterations. This belief might have been spread by this popular image:
> https://bitcointalk.org/index.php?topic=508880.msg5616146#msg5616146
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
http://bitcoin-solutions.co.uk

2023-06-07 15:10:46 UTC

- reply

📅 Original date posted:2013-12-16
📝 Original message:Yes I saw that on reddit too.
I think it applies mainly to custom transactions rather
than where fees are calculated automatically.
Another variant of not understanding change that loses
people's bitcoins I have encountered is:
1) Import a private key of a brainwallet/ paper wallet.
2) Send a small amount of bitcoin from that key.
3) The user then secure deletes all copies of the wallet
'for security'. If they are not careful they can delete
a change address with funds on it.
In MultiBit I have tried to reduce this possibility by:
1) Hiding the ability to delete wallet (in the next version
I am removing it entirely)
2) There is always a single key in a new wallet. When
a user imports a key then that makes two. I always send
the change to the second address, if it is available.
(This is bad for privacy but at least lessens the chances
that the funds become lost).
If users are determined to use a brain wallet and
secure delete every copy of the wallet after they use
them you cannot stop them (it is their machine after all)
But these two options help lessen the chance of bitcoin
loss if they do.
For the HD version of MultiBit we are removing the import
of individual private keys entirely and only supporting HD
addresses, primarily for safety reasons.
Jim
On Mon, Dec 16, 2013, at 10:13 AM, Drak wrote:
> Not sure if this is the right place, but since a few wallet authors
> congregate here I though it might be the best place.
>
> It seems every once in a while you see stories of people accidentally
> paying huge fees. Today I read about a man who paid a 20.14BTC fee for a
> 0.05 BTC transaction[1], oops. There was another recently where someone
> paid a fee of about 200BTC which fortunately the pool operator refunded.
>
> It just occurs to me this kind of sad story could be averted if wallets
> implemented a confirmation box if the fee amount seems crazy - for example,
> if it's >10x what the default fee should be, or if it's greater than x% of
> the sending amount. "the fee seems unusually high, are you really sure you
> want to pay X in fees?"
>
> I realise the exact details of this might need to be fleshed out given we
> want flexible fees, but it should be pretty simple to agree with what looks
> like an unusually large fee according to the going rate.
>
> Drak
>
> [1]
> http://www.reddit.com/r/Bitcoin/comments/1syu3h/i_lost_all_my_bitcoins_in_an_erroneous/
> ------------------------------------------------------------------------------
> 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
--
http://bitcoin-solutions.co.uk

2023-06-07 15:03:59 UTC

- reply

📅 Original date posted:2013-06-27
📝 Original message:I missed Greg's point on confirmations.
It is definitely a challenge to explain/ visualize both:
+ has the transaction propagated the network ?
and
+ it it confirmed/ buried in a block ?
when those words probably don't mean much to
the intended audience.
The transaction status icons I *think* do it
(explained here:
https://multibit.org/en/help/v0.5/help_transactions.html).
It basically boils down to:
1) triangle or square : bad.
2) filling circle : good
3) tick mark : great.
On Thu, Jun 27, 2013, at 08:40 PM, Jim wrote:
> RE: 141.101.113.245
>
> http://whois.domaintools.com/141.101.113.245
> gives it as CloudFlare - I suspect it is protecting
> Mt Gox when we make our get for currency ticker info.
>
>
> On Thu, Jun 27, 2013, at 08:18 PM, Jim wrote:
> > A few replies, in order of point raised:
> >
> > Jeff:
> > Arguments against multibit default:
> > * Less testing, field experience on desktop
> >
> > Yes this is true - downloads of multibit have typically been around
> > 1/7th to 1/5th of bitcoin-QT downloads. It helps of course that
> > the bitcoinj networking/ object model is also used by Andreas
> > as you note.
> >
> >
> > Greg:
> > I think Mike has squashed the deadlocking problems with reentrant
> > locks (primarily in the Wallet). I haven't seen one in at least a month.
> >
> > We discussed proxy support on the bitcoinj mailing list a while ago
> > and at the time the stumbling block was the Java library used for
> > the networking (Netty) did not support it. Mike or Miron would
> > know better than I if this is still the case.
> >
> > Change address behaviour will improve significantly when HD
> > wallet support goes into multibit/ bitcoinj (I am hoping to get my
> > bit done over the summer). Matija Mazi has been working on a
> > Java impl of HD wallets so it is coming down the pipe but
> > there is a lot to do yet.
> >
> > Connections out from MultiBit are:
> > + 4 bitcoind nodes on port 8333
> > + multibit.org (188.138.113.201) for help, current version info
> > (and probably more in future)
> > + the currency ticker will make HTTP gets to the source of
> > whichever exchange(s) you have set up e.g MtGox, CampBX.
> > This calls should disappear if you switch the currency conversion
> > and ticker off.
> >
> > I think that is all the connections out I make.
> >
> > Mainly due to the exchanges abruptly changing their APIs and
> > breaking things we are planning to put in intermediate
> > "Exchange Data Provider" servers. Tim Molter is working on this
> > in his XChange project. That will enable us to patch the server
> > when things change and the multibits in the field won't be
> > affected. There will probably be a couple of these initially
> > for redundancy.
> >
> > 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.
> >
> > 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
>
>
> --
> 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
--
https://multibit.org Money, reinvented

2023-06-07 15:03:58 UTC

- reply

📅 Original date posted:2013-06-27
📝 Original message:RE: 141.101.113.245
http://whois.domaintools.com/141.101.113.245
gives it as CloudFlare - I suspect it is protecting
Mt Gox when we make our get for currency ticker info.
On Thu, Jun 27, 2013, at 08:18 PM, Jim wrote:
> A few replies, in order of point raised:
>
> Jeff:
> Arguments against multibit default:
> * Less testing, field experience on desktop
>
> Yes this is true - downloads of multibit have typically been around
> 1/7th to 1/5th of bitcoin-QT downloads. It helps of course that
> the bitcoinj networking/ object model is also used by Andreas
> as you note.
>
>
> Greg:
> I think Mike has squashed the deadlocking problems with reentrant
> locks (primarily in the Wallet). I haven't seen one in at least a month.
>
> We discussed proxy support on the bitcoinj mailing list a while ago
> and at the time the stumbling block was the Java library used for
> the networking (Netty) did not support it. Mike or Miron would
> know better than I if this is still the case.
>
> Change address behaviour will improve significantly when HD
> wallet support goes into multibit/ bitcoinj (I am hoping to get my
> bit done over the summer). Matija Mazi has been working on a
> Java impl of HD wallets so it is coming down the pipe but
> there is a lot to do yet.
>
> Connections out from MultiBit are:
> + 4 bitcoind nodes on port 8333
> + multibit.org (188.138.113.201) for help, current version info
> (and probably more in future)
> + the currency ticker will make HTTP gets to the source of
> whichever exchange(s) you have set up e.g MtGox, CampBX.
> This calls should disappear if you switch the currency conversion
> and ticker off.
>
> I think that is all the connections out I make.
>
> Mainly due to the exchanges abruptly changing their APIs and
> breaking things we are planning to put in intermediate
> "Exchange Data Provider" servers. Tim Molter is working on this
> in his XChange project. That will enable us to patch the server
> when things change and the multibits in the field won't be
> affected. There will probably be a couple of these initially
> for redundancy.
>
> 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.
>
> 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
--
https://multibit.org Money, reinvented

2023-06-07 15:03:58 UTC

- reply

📅 Original date posted:2013-06-27
📝 Original message:A few replies, in order of point raised:
Jeff:
Arguments against multibit default:
* Less testing, field experience on desktop
Yes this is true - downloads of multibit have typically been around
1/7th to 1/5th of bitcoin-QT downloads. It helps of course that
the bitcoinj networking/ object model is also used by Andreas
as you note.
Greg:
I think Mike has squashed the deadlocking problems with reentrant
locks (primarily in the Wallet). I haven't seen one in at least a month.
We discussed proxy support on the bitcoinj mailing list a while ago
and at the time the stumbling block was the Java library used for
the networking (Netty) did not support it. Mike or Miron would
know better than I if this is still the case.
Change address behaviour will improve significantly when HD
wallet support goes into multibit/ bitcoinj (I am hoping to get my
bit done over the summer). Matija Mazi has been working on a
Java impl of HD wallets so it is coming down the pipe but
there is a lot to do yet.
Connections out from MultiBit are:
+ 4 bitcoind nodes on port 8333
+ multibit.org (188.138.113.201) for help, current version info
(and probably more in future)
+ the currency ticker will make HTTP gets to the source of
whichever exchange(s) you have set up e.g MtGox, CampBX.
This calls should disappear if you switch the currency conversion
and ticker off.
I think that is all the connections out I make.
Mainly due to the exchanges abruptly changing their APIs and
breaking things we are planning to put in intermediate
"Exchange Data Provider" servers. Tim Molter is working on this
in his XChange project. That will enable us to patch the server
when things change and the multibits in the field won't be
affected. There will probably be a couple of these initially
for redundancy.
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.
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

2023-06-07 15:03:57 UTC

- reply

📅 Original date posted:2013-06-27
📝 Original message:Hello Everybody,
Over the last few months we have been steadily adding
functionality to MultiBit including:
+ encrypted wallets
+ sign and verify message
+ stability improvements and bug fixes.
As a result of these efforts I think MultiBit is now
suitable for the entry level Bitcoin user. I propose
that we put MultiBit as the default desktop client
on the bitcoin.org "Choose your wallet" page.
I think a typical new user comes to bitcoin.org from a
google search or a Bitcoin news article. We want them to
peruse the bitcoin.org site and try out a wallet. They
should be able to get MultiBit up and running in a tea break.
Then perhaps they get a colleague to send them some bitcoin
from an Android phone by zapping a QR code.
We say: "Welcome to the Bitcoin economy !"
There is plenty MultiBit cannot do of course. However if
in the first ten minutes we get the new user interested
there is a good chance they will go on to explore other
Bitcoin wallets and solutions.
Let me know if you think this is a good idea (or not!)
and if you have any questions.
Jim
https://multibit.org