-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2015-06-16 23:32, Gregory Maxwell wrote:
> Is there any discussion thats been had relating to the BIP-drafts at:
>
> https://github.com/Open-Transactions/rfc/tree/master/bips
>
> Fellow Traveler has apparently been waiting 9 months for prog
the other wallets 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 E
https://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
-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 st
-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 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
> decisio
-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 shou
-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
> 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 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 p
-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 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 Bit
-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
-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
> addr
-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 clients
ce to graph analysis and make transaction-level
censorship more difficult.
- --
Justus Ranvier | Monetas <http://monetas.net/>
<mailto:jus...@monetas.net> | Public key ID : C3F7BB2638450DB5
| BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-B
ut how they use bloom filters overall, such as by
connecting to more than one peer, only putting a subset of their
addresses in a single filter, and temporally varying the addresses
which they watch.
- --
Justus Ranvier | Monetas <http://monetas.net/>
<mailto:j
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 t
On Sat, Apr 25, 2015 at 3:30 AM, Gregory Maxwell wrote:
> On Sat, Apr 25, 2015 at 12:22 AM, Justus Ranvier
> 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 not be
he diffie Hellman secret - why do you choose the x
> co-ordinate instead of the hash of the secret which is standard practice
> for stealth addresses
>
> Sent from my iPhone
>
> On 24 Apr 2015, at 21:27, Justus Ranvier
> wrote:
>
> -BEGIN PGP SIGNED MESSA
/justusranvier/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dcd1b521
On Sat, Apr 25, 2015 at 12:21 AM, Justus Ranvier wrote:
>
>
> On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell
> wrote:
>
>> So this requires making dust payments to a constantly reused address
>&
On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell
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 almost comple
-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 w
-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.
To: justus.ranv...@monetas.net
Hi Justus,
I read your proposal f
ransactions
originating from themselves.
SPV peers:
CurveCP connections also can be created between full nodes and SPV
nodes, in which case transactions originating from the SPV peers would
be routed as if they originated from the full node.
[1] https://wiki.freenetproject.org/Darknet
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/13/2015 05:24 PM, Mike Hearn wrote:
> Well they don't set NODE_NETWORK, so they don't claim to be
> providing network services. But then I guess the Chainalysis nodes
> could easily just clear that bit flag too.
If a peer claims to provide netwo
-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 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
> pro
-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
(https://www.reddit.com/r/Bitcoin/comments/2we0d9/in_an_u
-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.
>
> A
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/22/2015 07:50 AM, Matt Whitlock wrote:
> This happened to one of the merchants at the Bitcoin 2013
> conference in San Jose. They sold some T-shirts and accepted
> zero-confirmation transactions. The transactions depended on other
> unconfirmed t
-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
> c
-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 f
-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
-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 servic
-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 f
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 propos
lso be lower.
- --
Justus Ranvier | Monetas <http://monetas.net/>
<mailto:jus...@monetas.net> | Public key ID : C3F7BB2638450DB5
| BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-BEGIN PGP SIGNATURE-
iQIcBAEBAgAGBQJUvq0CAA
the majority of your users.
Or, from the other perspective, users should be strongly encouraged to
get their wallet software from companies/organizations not located in
the same country as them.
- --
Justus Ranvier | Monetas <http://monetas.net/>
<mailto:jus
the services more expensive due to risk premium.
- --
Justus Ranvier | Monetas <http://monetas.net/>
<mailto:jus...@monetas.net> | Public key ID : C3F7BB2638450DB5
| BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-BEGIN PGP SIGN
ner 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
-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: ht
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/06/2014 05:26 PM, Peter Todd wrote:> For the same reason we
don't do hard-forking upgrades of basically every
> protocol on the planet on a regular basis, even when we don't have
> consensus problems to worry about.
>
> Flag days are really rar
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 hav
luable.
You also have things like BIP43 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 <
-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
> wrote:
>> Two draft information BIPs are attached.
>
> I've pinged some people privately but also pinging the list… n
s no
action 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
- --
for this arrangement.
Would be nice 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?
-
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 onli
-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 wh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/20/2014 12:16 AM, Peter Todd wrote:
> The easiest way to do this would be to make the Debian/Ubuntu
> packages depend on Tor, and include a install-time script to setup
> the hidden service. I've verified with the Tor devs that they would
> wel
-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, w
e of being 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 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
-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 pro
-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 wan
-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 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 a
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 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
> in
-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 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 s
-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 ever
-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. Nobo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/19/2014 09:11 AM, Jeff Garzik wrote:
> Meh. I like example configs, perhaps tuned by the distro. If the
> distro (_not_ Bitcoin Core upstream) chooses to install a
> bitcoin.conf in the proper location, that's up to them.
>
>
>> - bitcoind a
-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 ne
-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 tha
-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
> pro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/23/2014 06:15 PM, Peter Todd wrote:
> But I also agree with Gavin that the bitcoin-development email list
> is a perfectly good place to have these types of discussions. I
> myself have used it repeatedly to publish ideas specifically due to
> w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/23/2014 05:57 PM, Mike Hearn wrote:
> I'm not going to bother arguing in replies to a blog post. Suffice
> it to say, miners are already handsomely compensated via both
> inflation and fees for doing their job of preventing double spends.
> Your
-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 c
-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
> wrote:
>
>> If enough miners don't like a block that has been mined, they can
>> all work to orphan it without any change to
-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
> blo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/16/2014 11:06 AM, Adam Back wrote:
> Btw not to reignite the stealth vs reusable address bike shedding,
> but contrarily I was thinking it maybe actually better to try to
> rebrand address as "invoice number". People understand double
> paying a
-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
-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
-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 bottlen
-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
> resourc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/07/2014 11:34 AM, Mike Hearn wrote:
> At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and
> still falling:
>
>http://getaddr.bitnodes.io/dashboard/chart/?days=60
>
> I know all the reasons why people *might* stop run
-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 cre
On 03/29/2014 08:05 PM, Gregory Maxwell wrote:
> Use dust-b-gone and make it someone elses problem to get it relayed. :)
>
That's a sub-optimal solution, as it introduces a third party. What if
his server goes down?
An universal solution is preferable.
--
Support online privacy by using email
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 o
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 set
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 supp
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 sender
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 i
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 to
89 matches
Mail list logo
