On Thu, Apr 10, 2014 at 8:38 AM, Mike Hearn wrote:
> I tend to agree with slush here - counting the IPs in addr broadcasts
> often gives a number like 100,000 vs just 10,000 for actually reachable
> nodes (or less). It seems like optimising the NAT tunneling code would
> help. Starting by adding
I tend to agree with slush here - counting the IPs in addr broadcasts often
gives a number like 100,000 vs just 10,000 for actually reachable nodes (or
less). It seems like optimising the NAT tunneling code would help. Starting
by adding more diagnostic stuff to the GUI. STUN support may also help.
Hi Wladimir,
If the motivation of the SPV wallet is to radically extend functionality, as in
my case, then the index is specific to the added features and the subset of the
blockchain that is of interest for the wallet.
As you also point out, adding huge generic purpose indices to core would rat
On Wed, Apr 9, 2014 at 1:36 PM, Mark Friedenbach wrote:
> (2) there's a reasonable pathway to doing this all in-protocol, so there's
> no reason to introduce external dependencies.
Not just a speculative pathway. Pieter implemented headers first:
https://github.com/sipa/bitcoin/tree/headersfirst
I've advocated for this in the past, and reasonable counter-arguments I
was presented with are: (1) bittorrent is horribly insecure - it would
be easy to DoS the initial block download if that were the goal, and (2)
there's a reasonable pathway to doing this all in-protocol, so there's
no reason to
On Apr 9, 2014, at 8:12 PM, slush wrote:
>
> These days IPv6 is slowly deploying to server environments, but maybe there's
> some simple way how to bundle ipv6 tunnelling into bitcoind so any instance
> will become ipv6-reachable automatically?
>
Teredo is available by default on Microsoft
We definitely *need* lightweight bitcoin router / "core" which can be
easily deployed anywhere. No disagreement here.
I just wanted to remind that there're actually much more running nodes
*already* and maybe converting those hidden nodes to publicly reachable
nodes may be way easier than attracti
On Wed, Apr 9, 2014 at 10:31 PM, slush wrote:
> Another idea: Integrate torrent download of bootstrap.dat into bitcoind.
> Normal user (especially a beginner) won't learn how to download bootstrap
> separately and import it into bitcoind; he simply give up the
> synchronization once he realize it
On Wed, Apr 9, 2014 at 10:12 PM, slush wrote:
> Maybe there're other ideas how to improve current situation without needs
> of reworking the architecture.
>
Nothing I've proposed here would require larger changes to the architecture
then were already planned. After SPV lands we are going to spli
Another idea: Integrate torrent download of bootstrap.dat into bitcoind.
Normal user (especially a beginner) won't learn how to download bootstrap
separately and import it into bitcoind; he simply give up the
synchronization once he realize it takes too much time. From my experience
downloading the
I believe there're plenty bitcoind instances running, but they don't have
configured port forwarding properly.There's uPNP support in bitcoind, but
it works only on simple setups.
Maybe there're some not yet considered way how to expose these *existing*
instances to Internet, to strenghten the net
On Wed, Apr 9, 2014 at 11:58 AM, Justus Ranvier wrote:
> Anyone reading the archives of the list will see about triple the
> number of people independently confirming the resource usage problem
> than they will see denying it, so I'm not particularly worried.
The list has open membership, there i
On Wed, Apr 9, 2014 at 6:09 PM, Thomas Voegtlin wrote:
> Le 09/04/2014 17:54, Gregory Maxwell a écrit :
>
> > Sadly today Electrum requires more than a full node, it requires a
> > number of large additional indexes over what a full node has and
> > pruning is precluded. I don't think that increa
I would like to set up my own bitcoin pull-tester on Jenkins. Are there any
instructions or guidance written anywhere?
Drak
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuous
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/09/2014 06:50 PM, Gregory Maxwell wrote:
> Who says anything about a broken incentive model. You've made past
> claims about resource requirements that I think made no sense and
> then failed to defend them when they were challenge.
Anyone read
On Wed, Apr 9, 2014 at 11:35 AM, Justus Ranvier wrote:
> If the security of the network depends on a broken incentive model,
> then fix the design of the network so that economics works for you
> instead of against you.
Who says anything about a broken incentive model. You've made past
claims abo
On Wed, Apr 9, 2014 at 8:35 PM, Justus Ranvier wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/09/2014 06:19 PM, Wladimir wrote:
> > If no one wants to volunteer resources to support the network
> > anymore, we'll have failed.
>
> If the security of the network depends on a brok
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/09/2014 06:19 PM, Wladimir wrote:
> If no one wants to volunteer resources to support the network
> anymore, we'll have failed.
If the security of the network depends on a broken incentive model,
then fix the design of the network so that econom
On 4/9/2014 11:29 AM, Wladimir wrote:
Hello,
This is primarily aimed at developers of SPV wallets.
The recently reported decrease in number of full nodes could have
several reasons, one of them that less people are running Bitcoin Core
for the wallet because the other wallets are getting ahea
On Wed, Apr 9, 2014 at 8:00 PM, Mike Hearn wrote:
> The right way to start with this, if anyone cares, is to add
> instrumentation to existing SPV wallet apps to report back to home base how
> long they are running for, how much disk space / RAM they have, and
> possibly what kind of hardware.
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 9 April 2014 13:50:03 GMT-04:00, Tamas Blummer wrote:
>Block header has to be available in SPV and also in an UTXO only
>storing core node, so why not serve it if bandwith allows.
>
>Serving any additional information like known peer adresses o
The right way to start with this, if anyone cares, is to add
instrumentation to existing SPV wallet apps to report back to home base how
long they are running for, how much disk space / RAM they have, and
possibly what kind of hardware.
I *strongly* suspect that the vast majority of SPV wallets ar
Block header has to be available in SPV and also in an UTXO only storing core
node, so why not serve it if bandwith allows.
Serving any additional information like known peer adresses or known full
blocks is certainly beneficial and should be offered if at hand.
Regards,
Tamas Blummer
http://b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 9 April 2014 12:27:13 GMT-04:00, Tamas Blummer wrote:
>A border router that is not able to serve blocks is still protecting
>consensus rules, that SPVs do not.
>If the network would only consist of SPV nodes only then e.g. a
>majority coalition
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 9 April 2014 13:33:19 GMT-04:00, Alex Mizrahi wrote:
>>
>> 1) It's more private. Bloom filters gives away quite accurate
>statistical
>> information about what coins you own to whom ever you happen to be
>> connected too. An attacker can easily
On Wed, Apr 9, 2014 at 7:33 PM, Alex Mizrahi wrote:
> 1) It's more private. Bloom filters gives away quite accurate statistical
>> information about what coins you own to whom ever you happen to be
>> connected too. An attacker can easily use this to deanonymize you even if
>> you don't reuse add
On Wed, Apr 9, 2014 at 5:42 PM, Brian Hoffman wrote:
> How would this affect the user in terms of disk storage? They're going to
> get hammered on space constraints aren't they? If it's not required how
> likely are users to enable this?
>
If they make the (conscious) choice to run a full node th
>
> 1) It's more private. Bloom filters gives away quite accurate statistical
> information about what coins you own to whom ever you happen to be
> connected too. An attacker can easily use this to deanonymize you even if
> you don't reuse addresses; Tor does not help much against this attack.
>
On Wed, Apr 9, 2014 at 5:41 PM, Natanael wrote:
> This could probably be done fairly easily by bundling Stratum (it's
> not just for pools!) and allowing SPV wallets to ask Bitcoind to start
> it (if you don't use it, there's no need to waste the resources), and
> then connect to it. The point of
A border router that is not able to serve blocks is still protecting consensus
rules, that SPVs do not.
If the network would only consist of SPV nodes only then e.g. a majority
coalition of miner could increase their reward at will.
Archives need a different solution.
Regards,
Tamas Blummer
ht
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Two talking points for said developers yo their user re: "Why use a full node?":
1) It's more private. Bloom filters gives away quite accurate statistical
information about what coins you own to whom ever you happen to be connected
too. An attacke
On 04/09/2014 09:09 AM, Tamas Blummer wrote:
> Yes, SPV is a sufficient API to a trusted node to build sophisticated
> features not offered by the core.
> SPV clients of the border router will build their own archive and
> indices based on their interest of the chain therefore the
> border router c
I am glad that SPV wallets are discussed outside the scope of mobile devices!
Yes, SPV is a sufficient API to a trusted node to build sophisticated features
not offered by the core.
SPV clients of the border router will build their own archive and indices based
on their interest of the chain the
Le 09/04/2014 17:54, Gregory Maxwell a écrit :
> Sadly today Electrum requires more than a full node, it requires a
> number of large additional indexes over what a full node has and
> pruning is precluded. I don't think that increasing the resource
> utilization of the node is a good way to go th
On Wed, Apr 9, 2014 at 8:41 AM, Natanael wrote:
> This could probably be done fairly easily by bundling Stratum (it's
> not just for pools!) and allowing SPV wallets to ask Bitcoind to start
> it (if you don't use it, there's no need to waste the resources), and
> then connect to it. The point of
On Wed, Apr 9, 2014 at 8:42 AM, Brian Hoffman wrote:
> How would this affect the user in terms of disk storage? They're going to
> get hammered on space constraints aren't they? If it's not required how
> likely are users to enable this?
If Bitcoin core activates pruning a full node can be suppor
This could probably be done fairly easily by bundling Stratum (it's
not just for pools!) and allowing SPV wallets to ask Bitcoind to start
it (if you don't use it, there's no need to waste the resources), and
then connect to it. The point of using Stratum is that it already is
being used by Electru
How would this affect the user in terms of disk storage? They're going to
get hammered on space constraints aren't they? If it's not required how
likely are users to enable this?
On Wed, Apr 9, 2014 at 11:29 AM, Wladimir wrote:
> Hello,
>
> This is primarily aimed at developers of SPV wallets.
YES
Such a bitcoind is what I called border router in a previous mail.
Yes, SPV wallets are getting ahead of features, so people will use them also
because on size just does not fit all, but all want to ensure being on the same
trunk of the chain.
Therefore serious user of Bitcoin run a bitcoi
Hello,
This is primarily aimed at developers of SPV wallets.
The recently reported decrease in number of full nodes could have several
reasons, one of them that less people are running Bitcoin Core for the
wallet because the other wallets are getting ahead in both features and
useability.
It's g
On Wed, Apr 9, 2014 at 12:38 PM, Wendell wrote:
> On that note, I think we have every possibility to make desktop and mobile
> wallets mind-numbingly simple -- and perhaps even do one better. Is this
> now a community priority? If so, I would really appreciate some additional
> contributors to Hi
On that note, I think we have every possibility to make desktop and mobile
wallets mind-numbingly simple -- and perhaps even do one better. Is this now a
community priority? If so, I would really appreciate some additional
contributors to Hive!
https://github.com/hivewallet/hive-osx
https://git
42 matches
Mail list logo
