://github.com/OpenBitcoinPrivacyProject/wallet-ratings/blob/master/2015-1/threat%20model.wiki
Please send any suggestions or corrections via a GitHub issue to the
wallet-ratings repository so that we can incorporate it into future
reports.
- --
Justus Ranvier
Open Bitcoin Privacy Project
http
reviewed.
Is there some process to get reviewed I missed? Please add us to
the report.
- --
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
jus...@openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
-BEGIN PGP SIGNATURE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/09/2015 02:02 PM, Andrew wrote:
The nice thing about 1 MB is that you can store ALL bitcoin
transactions relevant to your lifetime (~100 years) on one 5 TB
hard drive (1*6*24*365*100=5256000). Any regular person can run a
full node and store
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2015 09:54 PM, Jeff Garzik wrote:
By the time we get to fee pressure, in your scenario, our network
node count is tiny and highly centralized.
Again, this assertion requires proof.
Simply saying things is not the same as them being true.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2015 05:04 PM, Jeff Garzik wrote:
heh - I tend to think people here want bitcoin to succeed. My
statement refers to picking winners and losers from within the
existing bitcoin community stakeholders.
Success is not a sufficiently
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2015 05:47 PM, Jeff Garzik wrote:
Bitcoin needs to be the best it can be (Layer 1), but all solutions
cannot and should not be implemented at Layer 1.
I can provisionally agree with that statement as long as all
solutions cannot and should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2015 03:35 PM, Jeff Garzik wrote:
Raising the block size limit then becomes a *human decision* to
favor some users over others, a *human decision* to prevent an
active and competitive free fee market developing at 1MB, a *human
decision*
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2015 04:04 PM, Jeff Garzik wrote:
- This is a major change to the economics of a $3.2B system. This
change picks winners and losers. There is attendant moral hazard.
This is exactly true.
There are a number of projects which aren't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2015 04:49 PM, Peter Todd wrote:
I think we'll find an basic assumption of civility to be more
productive, until proven otherwise. (e.g. NSA ties)
I'm not sure why you'd construe my post as having anything to do with
accusations like
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2015 03:27 PM, Jeff Garzik wrote:
On Thu, May 7, 2015 at 11:16 AM, Justus Ranvier
justusranv...@riseup.net wrote:
To be extremely specific: should Bitcoin development
intenionally limit the network's capabilities to leave room
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2015 03:49 AM, Peter Todd wrote:
I'm not sure if you've seen this, but a good paper on this topic
was published recently: The Economics of Bitcoin Transaction
Fees
..for some very strange definitions of good.
That paper may present valid
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/27/2015 02:53 PM, Brian Deery wrote:
1. There will be a 1:1 relationship between a payment code owner
and their identity. Presumably the payment code would be strongly
and publicly tied to the identity. This makes the notification
address
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The notification transactions are a pain point when it comes to
privacy, and yet they must exist in order to to ensure that nobody can
lose their money as long as they back up their wallet seed.
They could be treated as a backup, however, that
-level
censorship more difficult.
- --
Justus Ranvier | Monetas http://monetas.net/
mailto:jus...@monetas.net | Public key ID : C3F7BB2638450DB5
| BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Payment codes establish the identity of the payer and allow for simpler
methods for identifying the payee, and automatically provide the payee with
the information they need to send a refund.
If merchants and customers were using payment codes, they would not need
the BIP70 equivalents.
I think
On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell gmaxw...@gmail.com
wrote:
So this requires making dust payments to a constantly reused address
in order to (ab)use the blockchain as a messaging layer.
Indeed, this is more SPV compatible; but it seems likely to me that
_in practice_ it would
/justusranvier/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dcd1b521
On Sat, Apr 25, 2015 at 12:21 AM, Justus Ranvier justus.ranv...@monetas.net
wrote:
On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell gmaxw...@gmail.com
wrote:
So this requires making dust payments to a constantly reused
On Sat, Apr 25, 2015 at 3:30 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
On Sat, Apr 25, 2015 at 12:22 AM, Justus Ranvier
justus.ranv...@monetas.net wrote:
Taking the hash of the secret would then require an extra step to make
sure
the hash is valid for secp256k1.
The x value may
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki
This link contains an RFC for a new type of Bitcoin address called a
payment code
Payment codes are SPV-friendly alternatives to DarkWallet-style stealth
addresses
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- Forwarded Message
Subject: re [Bitcoin-development] Improving resistance to transaction
origination harvesting
Date: Fri, 20 Mar 2015 14:06:59 +0100
From: Arne Bab. arne_...@web.de
To: justus.ranv...@monetas.net
Hi Justus,
I read
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/13/2015 04:48 PM, Mike Hearn wrote:
That would be rather new and tricky legal territory.
But even putting the legal issues to one side, there are
definitional issues.
For instance if the Chainalysis nodes started following the
protocol
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Given the recent news about Chainanalysis
(https://www.reddit.com/r/Bitcoin/comments/2yvy6b/a_regulatory_compliance_service_is_sybil/),
and other companies who are disrupting the Bitcoin network
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/13/2015 05:08 PM, Mike Hearn wrote:
That definition would include all SPV clients?
Don't SPV clients announce their intentions by the act of uploading a
filter?
I get what you are trying to do. It just seems extremely tricky.
Certainly
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/22/2015 10:17 AM, Natanael wrote:
The problem with this approach is that it is worthless as a
predictor. We aren't dealing with traffic safety and road design -
we are dealing with adaptive attackers and malicious miners and
pools.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/12/2015 07:15 PM, Alan Reiner wrote:
I'll add fuel to the fire here, and express that I believe that
replace-by-fee is good in the long-term. Peter is not breaking
the zero-conf, it was already broken, and not admitting it creates
a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/12/2015 05:24 PM, Oleg Andreev wrote:
I think that is a misdirection on your part. The point of
replace-by-fee is to make 0-confirms reliably unreliable.
Currently people can get away with 0-confirms but it's only
because most people
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/12/2015 07:47 PM, Allen Piscitello wrote:
Nothing will stop that. Bitcoin needs to deal with those issues,
not stick our heads in the sand and pretend they don't exist out of
benevolence. This isn't a pet solution, but the rules of the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/12/2015 07:45 PM, Peter Todd wrote:
None of those solutions are compatible with decentralized networks
for a lot of reasons. Given the inability to prevent sybil attacks
your suggestions lead to people being unfairly punished for poor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/12/2015 03:20 PM, Natanael wrote:
Multisignature notaries need to convince people to select them.
They want to know that even with collateral, their funds won't be
temporarily locked up and unspendable for days at a time.
What services
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/06/2015 03:08 PM, Jeff Garzik wrote:
Yes. You can certainly add additional inputs and outputs -- and as
such you can increase privacy and defrag your wallet at the same
time.
A lot could be done to make regular spends resemble CoinJoin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/04/2015 02:23 PM, Isidor Zeuner wrote:
Hi there,
traditionally, the Bitcoin client strives to hide which output
addresses are change addresses going back to the payer. However,
especially with today's dynamically calculated miner fees,
On 01/17/2015 08:45 PM, Rune Kjær Svendsen wrote:
Hi list
Found this on reddit: http://impulse.is/
PDF: http://impulse.is/impulse.pdf
I'd love to hear this list's thoughts.
/runeks
I'm concerned about the silence that always erupts whenever
privacy-hostile products are proposed.
--
their wallet software from companies/organizations not located in
the same country as them.
- --
Justus Ranvier | Monetas http://monetas.net/
mailto:jus...@monetas.net | Public key ID : C3F7BB2638450DB5
| BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
be lower.
- --
Justus Ranvier | Monetas http://monetas.net/
mailto:jus...@monetas.net | Public key ID : C3F7BB2638450DB5
| BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-BEGIN PGP SIGNATURE-
iQIcBAEBAgAGBQJUvq0CAAoJECpf2nDq2eYjr9kP/RWEg8Az43T
.
- --
Justus Ranvier | Monetas http://monetas.net/
mailto:jus...@monetas.net | Public key ID : C3F7BB2638450DB5
| BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-BEGIN PGP SIGNATURE-
iQEcBAEBCAAGBQJUoqXIAAoJEMP3uyY4RQ21OZUH
in the case the first miner's block
is orphaned.
Inputs to a generation transaction can not be similarly poached.
That difference makes some services possible that would can not be
safely achieved with pay-to-fee transactions.
- --
Justus Ranvier | Monetas http://monetas.net
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/12/2014 01:41 PM, odinn wrote:
I think the Mastercoin devs are doing fine work
I wonder if all the Mastercoin devs would agree with that statement.
- --
Support online privacy by using email encryption whenever possible.
Learn how here:
On 11/06/2014 04:11 PM, Jeff Garzik wrote:
RE soft fork vs. hard fork: It's about this time at Mike Hearn will
chime in, on the side of hard forks. Hard forks are in a sense much
cleaner, and permit solving problems not otherwise solvable with a
hard fork. However, hard forks clearly have
that encourage people to reserve BIP
numbers to avoid namespace collisions even if their work does not
affect any other project.
There should be an efficient process for informational BIPs of this type.
- --
Justus Ranvier | Monetas http://monetas.net/
mailto:jus...@monetas.net
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/10/2014 05:26 PM, Mike Hearn wrote:
I'm sure this suggestion will go down like a lead balloon, but
Bitcoin Core is not the first project that's had issues with Linux
distros silently modifying their software as they package it. In
this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/26/2014 01:53 AM, Gregory Maxwell wrote:
On Tue, Aug 19, 2014 at 10:11 AM, Justus Ranvier
jus...@monetas.net wrote:
Two draft information BIPs are attached.
I've pinged some people privately but also pinging the list… no
commentary
if you'd at least mention our work, since we did share
it with you back in January and have been publicly documenting it ever
since.
Or does the fact that we're implementing it in btcwallet mean what
we're working on is unmentionable here?
- --
Justus Ranvier | Monetas http
on anyone's part (except for not using the same BIP43 purpose
code).
We resolved this by changing the naming scheme for our proposals, and
their associated purpose codes, to not rely on centrally-allocated
numbers.
https://github.com/Open-Transactions/rfc/tree/master/bips
- --
Justus Ranvier
On 09/15/2014 03:08 PM, Jeff Garzik wrote:
Such guidelines are a perfect example of why PGP WoT is useless and
stupid geek wanking.
A person's behavioural signature is what is relevant. We know how
Satoshi coded and wrote. It was the online Satoshi with which we
interacted. The online
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/23/2014 04:17 PM, xor wrote:
On Tuesday, August 19, 2014 07:40:39 PM Jeff Garzik wrote:
Encryption is of little value if you may deduce the same
information by observing packet sizes and timings.
Instead of spawning a discussion whether
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/19/2014 03:30 PM, Richard Moore wrote:
Oh, I see. I misread, thinking you wanted the dev team to have a
private key and share the public key, similar to alerts. But each
peer would have a public/private key pair and use something akin to
generated on the fly.
Two draft information BIPs are attached.
- --
Justus Ranvier | Monetas http://monetas.net/
mailto:jus...@monetas.net | Public key ID : C3F7BB2638450DB5
| BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-BEGIN PGP SIGNATURE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/19/2014 11:38 PM, J Ross Nicoll wrote:
That's not great, certainly, but how many nodes actually require
that level of security
All of them.
While the rest of the 'net is busy deprecating HTTP and all other
unencrypted transport methods,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/30/2014 09:50 PM, Alan Reiner wrote:
(though, in the future, we hope to provide an optional service to
help synchronize the data between parties)
Before rolling your own service, it might be a good idea to add
Bitmessage integration to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/24/2014 09:07 AM, Wladimir wrote:
My main argument for the split is that full nodes and wallets have
completely different usage scenarios:
- A wallet should be online as little as possible, ideally only
when you do transactions or want to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/19/2014 05:11 PM, Kevin wrote:
Why do you want to punish pools?
It's part of a general trend wherein people look at all the things
that can be accomplished in an economy that has a division of labor*,
and see some misbehavior at the edges, and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/16/2014 04:25 PM, Matt Whitlock wrote:
How can there be any kind of lottery that doesn't involve proof of
work or proof of stake? Without some resource-limiting factor,
there is no way to limit the number of lottery tickets any given
There can be multiple independent transport networks for Bitcoin.
There already is: ipv4, ipv6, Tor, and native_i2p (out of tree patch).
As long as multihomed hosts that act as bridges then information will propagate
across all of them.
--
Justus Ranvier
-
sent with R2Mail2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/16/2014 07:00 PM, Justus Ranvier wrote:
There can be multiple independent transport networks for Bitcoin.
There already is: ipv4, ipv6, Tor, and native_i2p (out of tree
patch).
As long as multihomed hosts that act as bridges
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/19/2014 02:21 PM, Mike Hearn wrote:
Submitted with humility and some fear of getting laughed out of
here...
Off topic aside, a bunch of us have lately started to think about
the atmosphere on this list and how to improve it. Nobody
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/19/2014 09:41 PM, Gavin Andresen wrote:
Now I'm really confused.
Why would Mike or I have the authority to write a social contract
to promise anything about future-Bitcoin?
YOU can make promises about YOUR future behavior. So can everyone
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/19/2014 10:06 PM, Mike Hearn wrote:
Sorry. I will never agree to the concept of a relevant idea so
dangerous it cannot be discussed. That's medieval thinking. If you
would like to create a parallel development forum where people have
to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/19/2014 11:07 PM, Gregory Maxwell wrote:
I promise that if bad people show up with a sufficient pointy gun
that I'll do whatever they tell me to do. I'll make bad proposals,
submit backdoors, and argue with querulous folks on mailing lists,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/29/2014 02:13 PM, Mike Hearn wrote:
I do think we need to move beyond this idea of Bitcoin being some
kind of elegant embodiment of natural mathematical law. It just
ain't so.
I think everybody understands that Bitcoin has a positive net
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/24/2014 03:37 PM, Jorge Timón wrote:
The 21 million bitcoin limit is not important because of its exact
value, nor is it important because Satoshi picked it.
The 21 million limit is important because users hold bitcoin based on
the promise
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/23/2014 07:55 AM, Mike Hearn wrote:
2. Miners can vote to reallocate the coinbase value of bad blocks
before they mature. If a majority of blocks leading up to maturity
vote for reallocation, the value goes into a pot that subsequent
blocks
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/23/2014 03:07 PM, Mike Hearn wrote:
On Wed, Apr 23, 2014 at 4:52 PM, Justus Ranvier
justusranv...@gmail.comwrote:
If enough miners don't like a block that has been mined, they can
all work to orphan it without any change to the protocol
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/23/2014 05:47 PM, Gavin Andresen wrote:
And why do you think your blog is more public than this open,
publicly archived mailing list???
Non-developers are more comfortable using social media tools. Blog
posts can be shared, Tweeted, and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/23/2014 06:37 PM, Mike Hearn wrote:
If you want to try and argue that the development list is the wrong
place to discuss development, please do so on another thread (or
your blog). Let's keep this thread for discussion of the original
-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
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/07/2014 05:16 PM, Gregory Maxwell wrote:
When I read resource requirements of a full node are moving
beyond I didn't extract from that that there are implementation
issues that need to be improved to make it work better for low
resource
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/07/2014 05:40 PM, Mike Hearn wrote:
The primary resources it needs are disk space and bandwidth, after
an intensive initial day or two of building the database.
Check out the kind of hardware causal users are running these days.
The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/2014 03:41 PM, Laszlo Hanyecz wrote:
www.githubb.com resolves to addresses announced by AS53665
Some basic info about AS53665 can be seen at
http://bgp.he.net/AS53665 They probably have a dedi or VPS at
Cogent. They didn't even create
On 03/29/2014 01:30 PM, Mike Hearn wrote:
They would just encode the OP_RETURN script into an Output structure. I'm
not sure about the question - you seem to give the answer yourself in the
first paragraph?
I guess what I was asking is whether or not all BIP70 compatible clients
will support
Suppose am m-of-n multisig wallet receives a bunch of dust deposits due
to somebody advertising the Olympics, or any other reason, and the users
of the wallet don't want the few satoshis involved.
What is the best way to allow all these dust outputs to be re-mined in
order to clean up the utxo
On 03/29/2014 07:55 PM, Goss, Brian C., M.D. wrote:
Could you collect the dust into a transaction with no outputs (thus making it
all tx fees) or putting in to an anyone can spend tx?
The large number of signatures (for large n) would make the tx size
large...but, if enough dust were out
The description of the Output message states that the payment request
can specify any standard TxOut script, and that OP_RETURN is a standard
transaction type that would imply the ability to specify OP_RETURN
outputs in BIP 70 payment requests.
If the creator of a payment request wanted the
On 02/28/2014 07:25 PM, Mark Friedenbach wrote:
Transaction fees are a DoS mitigating cost to the person making the
transaction, but they are generally not paid to the people who
actually incur costs in validating the blockchain. Actual transaction
processing costs are an externality that is
One of the areas that isn't as well developed as it could be in terms of
wallet design is fine-grained control over input selection policy.
Coin control is great when a human is manually crafting transactions,
but that's not really a very scalable solution.
The attached image is a possible way
75 matches
Mail list logo
