On Mon, Jan 30, 2012 at 11:33 PM, Michael Hendricks wrote:
> address manager point to the attacker. If a client has 8 connections
> to the network, a Sybil attack would succeed 1.7% of the time.
Meh, careful not to mixup addrman created issues with preexisting ones
simply related to the number o
> Regarding the idea of a signed URI, it is appealing, however, it may not
> work. If I understand it correctly, the main idea appears to be to protect
> a URI from malicious replacement
No. The main idea is to protect the consumer against a malicious seller
pretending that he has not been paid
On Mon, Jan 30, 2012 at 7:05 PM, Gavin Andresen wrote:
> Given the randomness in Pieter's design, that seems extremely unlikely
> / difficult to do. Is it possible to do a back-of-the-envelope
> calculation to figure out what percentage of nodes on the network an
> attacker would have to control t
On Mon, Jan 30, 2012 at 9:05 PM, Gavin Andresen wrote:
> I've also been wondering if it is time to remove the IRC bootstrapping
> mechanism; it would remove a fair bit of code and we'd stop getting
> reports that various ISPs tag bitcoin as malware. When testing the
> list of built-in bootstrappi
On Monday, January 30, 2012 9:05:49 PM Gavin Andresen wrote:
> I've also been wondering if it is time to remove the IRC bootstrapping
> mechanism; it would remove a fair bit of code and we'd stop getting
> reports that various ISPs tag bitcoin as malware. When testing the
> list of built-in bootst
> Cool design. It seems resilient to many attacks. A Sybil attack
> coming from a large botnet (which controls addresses in many ranges)
> can still fill all buckets in both tables, I think. As far as I can
> tell, that wasn't possible with the old design.
Given the randomness in Pieter's desig
This is counted from the current git master on bsd.
The first two are of note and should probably be looked at.
A little more work after those and it might be possible to
use -Wall by default as addressing even some of these
would remove tons of lines from the output :)
1 net.cpp:141: warning:
On Monday, January 30, 2012 2:13:52 PM Gary Rowe wrote:
> Having closely read the BIP20 proposal, I can see your point. As I see it,
> BIP 20 vs BIP 21 is about standardising on a representation of the "amount"
> field. BIP 20 proposes that "amount" can contain alternative
> representations, clearl
Having closely read the BIP20 proposal, I can see your point. As I see it,
BIP 20 vs BIP 21 is about standardising on a representation of the "amount"
field. BIP 20 proposes that "amount" can contain alternative
representations, clearly defined, whereas BIP 21 requires the use of a
single represent
On Monday, January 30, 2012 1:50:03 PM Gary Rowe wrote:
> Speaking on behalf of the MultiBit team (Jim's currently on holiday), we
> will not be supporting Tonal Bitcoins anytime soon. Therefore we back the
> BIP 21 proposal.
It is not correct to imply that BIP 20 requires Tonal Bitcoin support.
I
Hi all,
Speaking on behalf of the MultiBit team (Jim's currently on holiday), we
will not be supporting Tonal Bitcoins anytime soon. Therefore we back the
BIP 21 proposal.
At present MultiBit does not support the "message" or "send" fields but we
would be happy to add this functionality as requir
On Monday, January 30, 2012 1:07:16 PM thoma...@gmx.de wrote:
> I too support BIP21 over BIP20.
BIP 21 is not forwards-compatible, and is intentionally designed to be biased
toward decimal. BIP 20 is neutrally biased, forward-compatible, and has been
implemented for over a year now. If BIP 20 is
I too support BIP21 over BIP20. However, I do not understand the "Sending money
via private key" feature; in which situation would such a URI be useful?
Also, I posted a proposal in the forum, to extend the URI syntax with
signatures. The goal would be to provide a proof of identity of the recip
I've started a discussion on BIP 16/17 support moving forward
(including trying to improve the testing process) here:
https://bitcointalk.org/index.php?topic=61922.0
(please reply there so the discussion stays mostly in one place)
--
--
Gavin Andresen
--
On Sun, Jan 29, 2012 at 7:31 PM, Pieter Wuille wrote:
> wanting to move to IPv6 support in the Satoshi bitcoin client
> somewhere in the future, the way IP addresses were managed is not
> really possible anymore. Right now, basically all addresses ever seen
> are kept - both on-disk and in-memory,
On 2012 January 28 Saturday, Michael Gronager wrote:
> If we want more information in a bitcoin address we could just as well
> cannibalize it from the checksum - today it is 4 bytes (1 to 4mia) it
> could be 2 or 3 bytes (1 to 65k or 16M) and that would not break the
> current meaning of the netw
I agree with BIP 0021
Wladimir
On Mon, Jan 30, 2012 at 12:55 AM, Amir Taaki wrote:
> Matt Corallo posted a modification of BIP 20 in an earlier email and I
> asked him if he wanted to become the champion of that BIP he submitted.
>
> It is a modification of BIP 20 sans the alternative non-decim
17 matches
Mail list logo
