>From https://en.bitcoin.it/wiki/Protocol_specification#version, is the
relay field (bool/1 byte) required in all version packets coming from
client with protocol version >= 70001?
--
Introducing AppDynamics Lite, a free t
You are welcome to optimise P2P addr broadcasts or develop better bootstrap
mechanisms.
On Sun, May 5, 2013 at 3:12 PM, John Dillon
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Sorry I should have used the word bootstrapping there rather than
> discovery.
> But again I think th
It's expected to be there, yes.
On Mon, May 6, 2013 at 9:56 AM, Addy Yeow wrote:
> >From https://en.bitcoin.it/wiki/Protocol_specification#version, is the
> relay field (bool/1 byte) required in all version packets coming from
> client with protocol version >= 70001?
>
>
> -
On Mon, May 06, 2013 at 10:19:35AM +0200, Mike Hearn wrote:
> You are welcome to optimise P2P addr broadcasts or develop better bootstrap
> mechanisms.
I think John's actually has a point here. If we're judging the quality of a
protocol change by how compatible it is with DNS seeding, then we're c
Subject change to reflect that this is off-topic for the old thread.
Eventually, I think it makes sense to move to a system where you get seeds
> from
> a DNS (or other mechanism), connect to one or a few of the results, do a
> getaddr,
> fill your peer IP database with it, and disconnect from the
On Mon, May 06, 2013 at 04:58:56PM +0200, Mike Hearn wrote:
More generally, I think this shows clearly how SPV nodes have weaker
security than constantly operating full nodes, which we knew already, so
why not build a better SPV-specific system instead?
I've noticed on my Android phone how it oft
On Mon, May 6, 2013 at 12:12 PM, Peter Todd wrote:
> I've noticed on my Android phone how it often takes quite awhile to find
> a peer that will actually accept an incoming connection, which isn't
> surprising really: why should a regular node care about responding to
> SPV nodes quickly?
>
> For
> > I've noticed on my Android phone how it often takes quite awhile to find
> > a peer that will actually accept an incoming connection, which isn't
> > surprising really: why should a regular node care about responding to
> > SPV nodes quickly?
I haven't seen that - remote nodes don't have any s
On Mon, May 06, 2013 at 12:20:12PM -0400, Jeff Garzik wrote:
> > Security will be no worse than before - if any one server/seed is honest
> > you're ok - and hopefully better due to the accountability. Obviously
>
> Indeed, the DNS seeds are just servers run by trusted individuals anyway.
Yup, an
> Speaking of, off-topic for this discussion, but in the future
> node-to-node communicate should be encrypted and signed
Yes, I'd like to do this. The threat isn't really ISPs which are
mostly trustable (the worst they normally do outside of places like
China is dick about with ads), the big thre
On Mon, May 06, 2013 at 06:47:22PM +0200, Mike Hearn wrote:
> Iteration 1) Make it clear in the UI that if the phone is connected to
> WiFi, payments from untrusted people should not be accepted. Currently
> the Android app merely says the money won't be spendable for a few
> minutes. It needs to c
On Mon, May 6, 2013 at 1:19 PM, Peter Todd wrote:
> For phone stuff you should work with The Guardian Project - they've
> implemented Tor on Android among other things and want to find easier
> ways for apps to use it.
You know my feelings about Java ;p but for hidden services, there
really does
On Mon, May 6, 2013 at 10:19 AM, Peter Todd wrote:
>> running hash of all messages sent on a connection so far. Add a new
>> protocol message that asks the node to sign the current accumulated
>> hash.
> We already depend on OpenSSL, why not just use standard SSL?
SSL doesn't actually provide non
On Mon, May 06, 2013 at 10:42:19AM -0700, Gregory Maxwell wrote:
> On Mon, May 6, 2013 at 10:19 AM, Peter Todd wrote:
> >> running hash of all messages sent on a connection so far. Add a new
> >> protocol message that asks the node to sign the current accumulated
> >> hash.
> > We already depend o
On Mon, May 6, 2013 at 10:53 AM, Peter Todd wrote:
> We don't have non-repudiation now, why make that a requirement for the
> first version? Adding non-repudiation is something that has to happen at
> the Bitcoin protocol level,(1) so it's orthogonal to using SSL to make sure
> you're connection i
Bitcoin p2p seeding requirements hav some ToR similarities, and we went
through the same security considerations with Zero-Knowledge systems freedom
network. Though bitcoins attacker profile and motivation is different - so
the defense maybe even more demanding. At least you have no shortage of
n
On Mon, May 06, 2013 at 11:01:22AM -0700, Gregory Maxwell wrote:
> On Mon, May 6, 2013 at 10:53 AM, Peter Todd wrote:
> > We don't have non-repudiation now, why make that a requirement for the
> > first version? Adding non-repudiation is something that has to happen at
> > the Bitcoin protocol lev
On Mon, May 6, 2013 at 11:04 AM, Adam Back wrote:
> bitcoins primary
> vulnerability IMO (so far) is network attacks to induce network splits,
> local lower difficulty to a point that a local and artificially isolated
> area of the network can be fooled into accepting an orphan branch as the
> one
btw with nodes for transport security you might use self-certifying keys.
Referring to Zooko's triangle, then the key is the node identity. Similar
to a bitcion address. So then just another ECDSA key and use emphemeral
ECDH for transport authenticated with the nodes key.
Maybe there can be som
On Mon, May 06, 2013 at 08:32:22PM +0200, Adam Back wrote:
> But what exactly could you prove about a node? You dont really know if a
> node is an originator for a double spend, it could be relay. And for
> privacy and security you cant expect the node to use its coin address
> private key.
re:
On Mon, May 06, 2013 at 03:08:57PM -0400, Peter Todd wrote:
>> Hmm: maybe one could use a Brands private credential with offline double
>> spend detection, with the reputation but not coin address of the node
>> disclosed, and the nodes coin address embedded in the proof. Each node
>> could be is
On Mon, May 06, 2013 at 09:50:03PM +0200, Adam Back wrote:
> Of course you'd probably need zerocoin to stand much chance of proving an
> address private key of an unlinked coin was in the double-spend disclosed
> attribute in the first place, and as we know zerocoin is not that efficient.
Sounds l
On Tue, Apr 30, 2013 at 10:17:23AM -0700, Jeremy Spilman wrote:
> [Aside] I was reading Peter's fidelitybond writeup for his idea on contract
> value accounting, and he points to Stephan's post from last September on
> payer-encoded metadata (
> https://bitcointalk.org/index.php?topic=108423.msg117
On Mon, May 06, 2013 at 11:25:50AM -0700, Gregory Maxwell wrote:
>On Mon, May 6, 2013 at 11:04 AM, Adam Back wrote:
>> bitcoins primaryvulnerability IMO (so far) is network attacks to induce
>> network splits, local lower difficulty to a point that a local and
>> artificially isolated area of the
On Mon, May 6, 2013 at 3:51 PM, Adam Back wrote:
> Maybe I could hack a pool to co-opt it into my netsplit and do the work for
> me, or segment enough of the network to have some miners in it, and they do
> the work.
Or you can just let it mine honestly and take the Bitcoins. This is
fast (doesn'
On Mon, May 06, 2013 at 04:43:07PM -0400, Peter Todd wrote:
> Now determining the value of D has a nice compact proof: B1, BP and M
> and B2. Taking the minimum of the difficulties of B1 and B2 (in case
> they cross a retarget boundry; don't want to create strange incentives)
> determine the expect
I think it's worth noting that quite a large portion of Linux users
probably get the mainline Bitcoin client from the packages. I think Bitcoin
package maintainers are doing mostly a pretty good job :)
On 6 May 2013 18:13, Gregory Maxwell wrote:
> On Mon, May 6, 2013 at 3:51 PM, Adam Back wrot
27 matches
Mail list logo
