On Fri, Nov 28, 2014 at 12:45 AM, Mistr Bigs wrote:
> That's what I was trying to say... The researchers are deanonymizing
> transactions from non-Tor connected hosts. So why are we talking about Tor
> limitations in response to this? Shouldn't we be discussing how to address
> the issues in Bitco
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 27 November 2014 18:46:23 GMT-05:00, Gregory Maxwell
wrote:
>The things you're suggesting were all carefully designed out of the
>proposal, perhaps the BIP text needs some more clarification to make
>this more clear.
It does; it is still a
That's what I was trying to say... The researchers are deanonymizing
transactions from non-Tor connected hosts. So why are we talking about Tor
limitations in response to this? Shouldn't we be discussing how to address
the issues in Bitcoin proper?
M
On 11/27/2014 9:30 PM, Gregory Maxwell wrote:
On Thu, Nov 27, 2014 at 10:56 PM, Richard Moore wrote:
> Heya,
>
> I was wondering about BIP 65 regarding the OP_CHECKLOCKTIMEVERIFY, and
> thought it might make more sense to instead have a OP_CHECKLOCKTIME which
> would simply push an OP_TRUE or OP_FALSE onto the stack?
Updating the stack is no
Heya,
I was wondering about BIP 65 regarding the OP_CHECKLOCKTIMEVERIFY, and thought
it might make more sense to instead have a OP_CHECKLOCKTIME which would simply
push an OP_TRUE or OP_FALSE onto the stack?
That way someone could include multiple OP_CHECKLOCKTIME conditions in a single
script
On Thu, Nov 27, 2014 at 5:44 PM, Mistr Bigs wrote:
> I might be mistaken, but it seems to me this paper discusses unintended ways
> of obtaining the IP addresses of clients involved in transactions on the
> core Bitcoin network.
You're mistaken. :)
If a node is used exclusively via tor it effect
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
A recent comment on this (I think)...
https://github.com/bitcoin/bitcoin/issues/4564#issuecomment-49558760
Reflecting on an approach from a different but related project, as a
result of an issue discussion in DW, stealth and coinjoin from that
pr
On Thu, Nov 27, 2014 at 5:27 PM, Mem Wallet wrote:
> Is there an intention that the various internal libraries could/should
> be strengthened and heirachicalized such that they would be suitable for
> 3rd party development of bitcoin related services and tools, or is that not
> a goal, and some o
I might be mistaken, but it seems to me this paper discusses unintended
ways of obtaining the IP addresses of clients involved in transactions on
the core Bitcoin network.
Tor was mentioned only insofar as it might be one's first thought of how to
mitigate this risk, yet Bitcoin over Tor has its ow
Two minor observations:
DecodeBase58Check is listed as inline, but isnt actually inlined in the
header.
This makes it both non-present in libbitcoin_common.a and unavailable
to other code that would use libbitcoin_common.a as a library. (bug?)
In general, the hierarchy of tools is poor/weak. for
On Thu, Nov 27, 2014 at 2:22 AM, Gregory Maxwell wrote:
>> Since this attack vector has been discussed, I started making some
>> measurements on how effective it is to connect to Bitcoin using Tor,
>> and I found that the number of connections dropping to near-zero is
>> a situation which occurs r
>
> [As an aside I agree that there are lots of things to improve here,
> but the fact that users can in theory be forced off of tor via DOS
> attacks is not immediately concerning to me because its a conscious
> choice users would make to abandon their privacy
Bitcoin already has a large populat
12 matches
Mail list logo
