<unnamed>

Public Key

npub1a9uelw8hswrmps0ayl2dzkh625xjznd5glvqrkhpxngdzupjw8kqqlc2j9

Profile Code

nprofile1qqswj7vlhrmc8pasc87j04x3tta92rfpfk6y0kqpmtsnf5x3wqe8rmqpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgpkft95

Publishing to

relay.primal.net

Last Notes

2023-06-07 17:31:25 CEST

- 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 17:16:23 CEST

- 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 17:10:46 CEST

- 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 17:03:59 CEST

- 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