-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, Nov 8, 2013 at 4:21 PM, Goss, Brian C., M.D.
wrote:
> Peter,
>
> What is the propagation time within a pool? If my pool is made up of a ton
> of fancy ASICs connected by 300 baud modems, how does that affect your
> analysis (ie, Q for a min
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> To peer with the public relay nodes, simply select the closest region
> out of us-west (West Coast US), us-east (East Coast US), eu (Western
> Europe), au (Australia), or jpy (Japan) and add
> public.REGION.relay.mattcorallo.com to your addnode lis
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> Last week I posted a writeup: "On the optimal block size and why
> transaction fees are 8 times too low (or transactions 8 times too big)".
>
> Peter Todd made some nice additions to it including different pool sizes
> into the numbers.
Peter clai
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sat, Oct 26, 2013 at 12:25 AM, Gavin Andresen
wrote:
> I feel like there is a lot of "in the weeds" discussion here about
> theoretical, what-if-this-and-that-happens-in-the-future scenarios.
>
> I would just like to point out (again) that this i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sat, Oct 26, 2013 at 3:31 AM, Gregory Maxwell wrote:
> One limitation of the payment protocol as speced is that there is no
> way for a hidden service site to make use of its full authentication
> capability because they are unable to get SSL cer
My apologies, that was for Peter
On Mon, Aug 19, 2013 at 5:00 AM, John Dillon
wrote:
> -BEGIN PGP MESSAGE-
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> hQEMA8xUMVQPvvGFAQf9HL/SN/TZNQuVAjz5ggDzVzpYEzLRkFlgTR2lPURaR28F
> G0SgcvJmt1cvucxZRxzSUDCx58Ub16dzx9IBKQ+GDDUXbHGqE
-BEGIN PGP MESSAGE-
Version: GnuPG v1.4.11 (GNU/Linux)
hQEMA8xUMVQPvvGFAQf9HL/SN/TZNQuVAjz5ggDzVzpYEzLRkFlgTR2lPURaR28F
G0SgcvJmt1cvucxZRxzSUDCx58Ub16dzx9IBKQ+GDDUXbHGqExfbeIFx96okNsSm
GmRRyORm+L7rdpQ3G8HcfKr1R9YufgaAjsa05eXlXl+fgpYrSBgitY6T3IZ9c0Z7
eF6yjogj5iaDUP2m7xLmRyaQvT/0GdRYk+c2JOH0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, Aug 16, 2013 at 2:15 PM, Peter Todd wrote:
> On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote:
>> Doing this also makes it more difficult to sybil the network - for
>> instance right now you can create "SPV honeypots" that allow in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, Aug 19, 2013 at 12:59 AM, Gavin Andresen
wrote:
> Peter said:
> "In any case given that SPV peers don't contribute back to the network
> they should obviously be heavily deprioritized and served only with
> whatever resources a node has spar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, Aug 5, 2013 at 3:30 AM, Peter Vessenes wrote:
> I studied with Jeffrey Hoffstein at Brown, one of the creators of NTRU. He
> told me recently NTRU, which is lattice based, is one of the few (only?)
> NIST-recommended QC-resistant algorithms.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Peter Todd recently came up with two related, and IMO very good, uses for
non-standard transactions to implement both oracles and one-time-password
protection of wallet funds. While the wallet fund case could be implemented as
only a single standard
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sun, Jul 28, 2013 at 1:20 AM, Peter Todd wrote:
> FWIW with some minor scripting language additions such as access to txin
> and txout contents, along with merklized abstract syntax tree (MAST)
> support, we can even implement a version where scr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Wed, Jul 24, 2013 at 11:55 AM, Tier Nolan wrote:
> Distributing headers with 1/64 of the standard POW means that a header would
> be broadcast approximately once every 9 seconds (assuming a 10 minute block
> time). This was picked because sendin
My signature:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Linux distribution packaging and Bitcoin
2013-07-23
This note summarises the dangers inherent in the Linux distribution
packaging model for Bitcoin, and forms a request from upstream
maintainer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
It's been pointed out recently how a fairly cheap attack on the Bitcoin network
would be to take advantage of the fact that we limit the number of incoming
connections, but don't require anything of those connections. This means an
attacker can simpl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sun, Jul 14, 2013 at 7:42 PM, Pieter Wuille wrote:
> On Sun, Jul 14, 2013 at 07:33:06PM +, Luke-Jr wrote:
>> Invalid blocks are rejected by validating clients in all circumstances.
>
> I don't think that's what John means.
>
> If you have has
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sun, Jul 14, 2013 at 7:33 PM, Luke-Jr wrote:
>> Merge mining is very much mining a coin for free. Ask not what the total
>> reward is, ask that the marginal cost of merge mining an additional coin
>> is.
>
> But the total reward is what mining wi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sun, Jul 14, 2013 at 7:28 PM, Pieter Wuille wrote:
> On Sun, Jul 14, 2013 at 07:05:26PM +0000, John Dillon wrote:
>> Long-term we should be using P2SH with an inner OP_CHECKSIG for most
>> addresses
>> as it's a 1 byte
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sun, Jul 14, 2013 at 11:18 AM, Jorge Timón wrote:
> All the arguments in favor of this pegging use zerocoin's point of
> view. Sure it would be much better for it, but are additional costs to
> the bitcoin network and you cannot do it with every
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
As you all know keeping the size of the UTXO set small is critical, and more
recently we've also had problems with distasteful data being added to the UTXO
set. (http://garzikrants.blogspot.se/2013_04_01_archive.html) Gregory Maxwell
has an excellent
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Thu, Jun 27, 2013 at 6:41 PM, Gregory Maxwell wrote:
> On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr wrote:
>> On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote:
>>> * Very real possibility of an overall net reduction of full nodes on P2P
>>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, Jun 28, 2013 at 10:20 AM, Mike Hearn wrote:
> I suspect what you saw is mining nodes restarting and clearing their
> mempools out rather than an explicit policy of replace by fee.
Possibly, but it is a rather short window of opportunity and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> Thinking about this a little more, I guess it does not hurt to build some
> kind of voting system into the clients. But I think it's more useful for
> straw polls. For example a bug fix 100% of people should agree on. A
> protocol optimization p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, Jun 28, 2013 at 9:05 AM, Mike Hearn wrote:
>> I see some of the the other things that were concerning for me at the
>> time are still uncorrected though, e.g. no proxy support (so users
>> can't follow our recommended best practices of using
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, Jun 10, 2013 at 5:43 PM, Peter Todd wrote:
> On Mon, Jun 10, 2013 at 01:25:05PM -0400, Alan Reiner wrote:
>> to sign votes. Not only that, but it would require them to reveal their
>> public key, which while isn't technically so terrible, l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, Jun 10, 2013 at 8:14 AM, Melvin Carvalho
wrote:
> -1
>
> Firstly I appreciate the ingenious thought that went into this post.
>
> However, Bitcoin's fundamental philosophy was one CPU one vote.
Indeed it was. Which is why as GPU's came onto
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, Jun 10, 2013 at 4:44 AM, Edmund Broadley wrote:
> I really like this idea. I also like that users with no clue will leave
> their vote to the default chosen by the software developers, which hopefully
> will be 1MB. I like how coin age is fa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
It has been suggested that we leave the decision of what the blocksize to be
entirely up to miners. However this leaves a parameter that affects every
Bitcoin participant in the control of a small minority. Of course we can not
force miners to increa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> I'm one of the people experimenting in this area. I've long argued
> that a zero-output transaction should be permitted -- 100% miner fee
> -- as an elegant proof of sacrifice. Unfortunately that requires a
> hard fork. Also, for most people, it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> - what about if a pool could lock the reward (rather than receive it or
> destroy it) eg some kind of merkle root instead of a public key hash in
> the reward recipient address field in the coinbase.
Sorry I don't have time for a full reply du
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Peter's "Coinbase TxOut Hashcash" scheme mentions in passing anti-DoS
protection on the P2P flood-fill network for non-transaction messages, and an
application to use those messages, trust-free mixing. I did some review of the
source code and I think
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sat, May 11, 2013 at 10:22 AM, Adam Back wrote:
> I didnt quite understand the writeup and the references were ambiguous.
No you didn't. :)
What is special about what Peter is proposing is that it is *not* merge-mining.
You see, merge-mining is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
After some consultation with affected sites by myself and Peter we have decided
to release an initial replace-by-fee implementation and setup a server using
those rules on testnet. This implementation does not include recursive fee
evaluation, and is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Thu, May 9, 2013 at 1:57 AM, Peter Todd wrote:
> Remember that interpreting the timestamp on a block for the purposes of
> timestamping is a lot more subtle than it appears at first.
I actually just meant how Pieter Wuille was talking about a bl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Thu, May 9, 2013 at 1:13 AM, Pieter Wuille wrote:
> On Wed, May 08, 2013 at 09:08:34PM -0400, Jeff Garzik wrote:
>> Guffaw :) The year 2038 is so far in the future that it is not really
>> relevant, from that angle.
>
> "Meh". I think it's highl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Wed, May 8, 2013 at 11:44 PM, Peter Todd wrote:
> Who knows?
>
> Satoshi used 32-bits and those fields can't be changed now without every
> single Bitcoin user changing all at once. (a "hard-fork" change)
>
> We'll probably need to do one of thos
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> > You mean scam you with a zero-conf transaction that hasn't actually been
> > broadcast?
>
> Yeah. Or just scam you at all. It's hard to imagine an organisation as
> a big as a mobile carrier engaging in financial scamming (roaming fees
> excepted
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Sorry I should have used the word bootstrapping there rather than discovery.
But again I think that shows my point clearly. Centralized methods like DNS
should be used for as little as possible, just simple initial bootstrapping,
and focus the develo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I think you too should ask yourself why you are putting so much effort into
optimizing a centralized service, the DNS seeds, rather than putting effort
into optimizing the P2P peer discovery instead. DNS seeds are a necessary evil,
one that shouldn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, Apr 29, 2013 at 3:36 AM, Gregory Maxwell wrote:
> On Sun, Apr 28, 2013 at 7:57 PM, John Dillon
> wrote:
>> Have we considered just leaving that problem to a different protocol such as
>> BitTorrent? Offering up a few GB o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> But I also agree that its important that be splittable into
> ranges
> because otherwise when having to choose between serving historic data
> and— say— 40 GB storage, a great many are going to choose not to serve
> historic data... and so nodes
Sorry I don't have time to reply more in depth, but I wanted to say to
Jeremy (especially) and Peter I'm very impressed to see such a good
design be created so fast that does not depend on replacement at all.
This is a great example of how often the right approach to a problem
is to accept that the
actly on the
forums: https://bitcointalk.org/index.php?topic=179612.msg1881800#msg1881800
On Thu, Apr 18, 2013 at 8:14 AM, Peter Todd wrote:
> On Thu, Apr 18, 2013 at 06:07:23AM +0000, John Dillon wrote:
>> Gavin do you actually agree with Mike on this stuff like he implies?
>> Becaus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Apr 17, 2013 at 9:48 AM, Mike Hearn wrote:
> So it'd be nice if this ended up not being necessary. Experience indicates
> that rational miners typically don't pursue a short-termist
> profit-at-any-cost agenda - free transactions have always
44 matches
Mail list logo
