📅 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
Jim [ARCHIVE] /
npub1a9…lc2j9
2023-06-07 15:03:58
in reply to nevent1q…xdae
Author Public Key
npub1a9uelw8hswrmps0ayl2dzkh625xjznd5glvqrkhpxngdzupjw8kqqlc2j9Published at
2023-06-07 15:03:58Event JSON
{
"id": "16e07c15a170d6eab91dc1053a79327e16cc15792c44b3b1783bd038751bfdf9",
"pubkey": "e9799fb8f78387b0c1fd27d4d15afa550d214db447d801dae134d0d1703271ec",
"created_at": 1686150238,
"kind": 1,
"tags": [
[
"e",
"5ec662796ac6f7c2f8d4618ee0bafe23cd8003de44ad7e1121634fb73b588358",
"",
"root"
],
[
"e",
"3e432e5a025a5cb471b044b3a9aa393bffd8dcfdca7f5c12208787cca780e942",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2013-06-27\n📝 Original message:A few replies, in order of point raised:\n\nJeff:\nArguments against multibit default:\n* Less testing, field experience on desktop\n\nYes this is true - downloads of multibit have typically been around\n1/7th to 1/5th of bitcoin-QT downloads. It helps of course that\nthe bitcoinj networking/ object model is also used by Andreas \nas you note.\n\n\nGreg:\nI think Mike has squashed the deadlocking problems with reentrant \nlocks (primarily in the Wallet). I haven't seen one in at least a month.\n\nWe discussed proxy support on the bitcoinj mailing list a while ago \nand at the time the stumbling block was the Java library used for \nthe networking (Netty) did not support it. Mike or Miron would \nknow better than I if this is still the case.\n\nChange address behaviour will improve significantly when HD\nwallet support goes into multibit/ bitcoinj (I am hoping to get my\nbit done over the summer). Matija Mazi has been working on a \nJava impl of HD wallets so it is coming down the pipe but\nthere is a lot to do yet.\n\nConnections out from MultiBit are:\n+ 4 bitcoind nodes on port 8333\n+ multibit.org (188.138.113.201) for help, current version info\n (and probably more in future)\n+ the currency ticker will make HTTP gets to the source of\n whichever exchange(s) you have set up e.g MtGox, CampBX.\n This calls should disappear if you switch the currency conversion\n and ticker off.\n\nI think that is all the connections out I make.\n\nMainly due to the exchanges abruptly changing their APIs and\nbreaking things we are planning to put in intermediate \n\"Exchange Data Provider\" servers. Tim Molter is working on this\nin his XChange project. That will enable us to patch the server\nwhen things change and the multibits in the field won't be\naffected. There will probably be a couple of these initially\nfor redundancy.\n\nAlex: Yes I think most users migrate to blockchain.info or,\nmore recently coinbase.com. They are both good wallets\nbut I'd like to keep Bitcoin as P2P as possible.\n\nLuke-Jr\nI think you are right here on the number of full nodes versus\nSPV nodes.\nI don't think we even know yet what are the working ratios of\nfull nodes to SPV nodes. I haven't seen anybody do any \nanalysis on this.\n\nI doubt multibit will ever participate in the Bitcoin network \nother than as an SPV client. All the optimisation is to reduce\ndata traffic - it is effectively a mobile wallet that happens to\nlive on a desktop. It is not really intended to be more than\n\"a wallet for regular people to store and spend their bitcoin\".\n\nIn English the nomenclature for direction of the transactions\nis: \"Sent to\" and \"Received with\". To be honest I \nhaven't transliterated the localisation files to check other\nlanguage packs but the localisers are pretty good in my\nexperience.\n\n\n\n\n\nOn Thu, Jun 27, 2013, at 07:41 PM, Gregory Maxwell wrote:\n\u003e On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr \u003cluke at dashjr.org\u003e wrote:\n\u003e \u003e On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote:\n\u003e \u003e\u003e * Very real possibility of an overall net reduction of full nodes on P2P\n\u003e \u003e\u003e network\n\u003e \u003e Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or\n\u003e \u003e MultiBit node. :/\n\u003e \u003e Jim, will MultiBit be adding p2p listening support?\n\u003e \n\u003e Without validation listening isn't currently very useful. :( Maybe it\n\u003e could be somewhat more with some protocol additions.\n\u003e \n\u003e ------------------------------------------------------------------------------\n\u003e This SF.net email is sponsored by Windows:\n\u003e \n\u003e Build for Windows Store.\n\u003e \n\u003e http://p.sf.net/sfu/windows-dev2dev\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\n\n-- \nhttps://multibit.org Money, reinvented",
"sig": "7656cd00ca4536ff9b099aa521162a5c93f0e2f02323b86c2a751a2565c2998e92ce99c1075ca5453ed99daa2de43ba024bef0132d329f799b3302c8564787e1"
}