> I appreciate the thought :) I think where we differ is on where we believe
> the
> trade offs should be on perceived privacy versus censorship resistance and
> centralization.
>
> By having a limited number of proxies people need to go through to easily
> implement, be it the 4 you recommend, o
I picked up the next available number myself, but can be changed to
anything, the 74 is unimportant to the proposal.
David Barnes
On 7/17/2015 2:54 PM, Micha Bailey wrote:
Did Greg assign this number? He didn't do it here on the ML. You're
not supposed to use arbitrary numbers, certainly not n
On Wed, Jul 15, 2015 at 05:08:05PM -0700, Matthieu Riou via bitcoin-dev wrote:
> On Wed, Jul 15, 2015 at 12:32 PM, Peter Todd wrote:
>
> >
> > "In a Sybil attack the attacker subverts the reputation system of a
> > peer-to-peer network by creating a large number of pseudonymous
> > identities, us
You should rename your file to something like "bip-draft-dynamic-rate-lookup".
Using an arbitrary BIP number will cause confusion when that BIP number is
actually assigned later.
On Friday, 17 July 2015, at 3:50 pm, David Barnes | Bitcoin Co. Ltd. via
bitcoin-dev wrote:
> I picked up the next
BIP has now been renamed:
https://github.com/bitcoincoltd/bips/blob/master/bip-00xx-dynamic-rate-lookup.mediawiki
David Barnes
On 7/17/2015 7:24 PM, Matt Whitlock
wrote:
You should rename your file to something like "bip-draft-dynamic-rate-l
My "relationships" are nothing more than people
being willing to talk to me, ask me for advice, and warn me about
possible threats. They're not legal contracts.
Your actions make it appear as if you attack companies with the hope of
landing consulting fees. I assume if companies hire you as a
Thomas,
Let me answer your questions below; but let me give you a little preface
about how I envision the full cycle working.
My company has setup a service here: https://coinpay.in.th/services/print/
The service will work as follows:
- Merchants print out a QR code with address (and hopefully
Opening a mailing list thread on this BIP:
BIP PR: https://github.com/bitcoin/bips/pull/173
Code PR: https://github.com/bitcoin/bitcoin/pull/6451
The general intent of this BIP is as a minimum viable alternative plan to
my preferred proposal (BIP 100).
If agreement is not reached on a more compr
What are you trying to do? Break the ice with a hard fork so that later it
becomes easier to do so, with people more complacent towards it? There are
many solutions to the scaling problem that do not require a hard fork and
are quite simple to implement actually, and don't come with the
complicatio
Transaction sizes are still limited to 1MB with this patch. While this
isn't technically a change, it does mean that both are no longer linked
together.
Since this has no voting step, I assume the intention is that as a
compromise suggestion, it would have full support.
It establishes a preceden
On Fri, Jul 17, 2015 at 5:12 PM, Tier Nolan wrote:
> While this isn't technically a change, it does mean that both are no
> longer linked together.
>
I meant both block and transaction sizes are no longer linked together.
___
bitcoin-dev mailing list
b
I'd back this if we can't find a permanent solution - 2MB gives us a lot
more wiggle room in the interim at least; one of my concerns with block
size is 3 transactions per second is absolutely tiny, and we need space
for the network to search for an equilibrium between volume and pricing
withou
I would prefer a dynamic solution that did not necessitate a second hard
fork down the road.
I propose doubling the block size every 100k blocks (~2 years)
block 400,000 = 2MB (2016)
block 500,000 = 4MB (2017)
block 600,000 = 8MB (2018)
Chris
On Fri, Jul 17, 2015 at 1:57 PM, Ross Nicoll via bi
I'll leave others to comment on whether we can get consensus on that,
but your years listed are inconsistent with everything else you've
written. Should be:
block 400,000 = 2MB (2016)
block 500,000 = 4MB (2018)
block 600,000 = 8MB (2020)
On 17/07/2015 20:06, Chris Wardell via bitcoin-dev wrote
On Friday, July 17, 2015 3:55:19 PM Jeff Garzik via bitcoin-dev wrote:
> BIP PR: https://github.com/bitcoin/bips/pull/173
I'm concerned that miners are prematurely bumping their soft limit to 1 MB
lately. The only reason block size limit lifting is remotely reasonable is if
we can trust miners t
When blocks are found under or over the 10 minute threshold, hashing
difficulty is raised or reduced dinamically to keep a balance. This
intelligent measure has avoided us having discussions and kept a balance.
The same way you can't assume how much hashpower there will be to find the
next blocks,
On Fri, Jul 17, 2015 at 9:29 PM, Luke Dashjr wrote:
> Hardforks are not something where voting makes sense. They need consensus
> among /nodes/, not majority among /miners/. No hardfork has ever had such a
> vote.
>
Agreed.
I meant that since some of the new hard fork proposals use a voting sys
> I'm concerned that miners are prematurely bumping their soft limit to 1 MB lately.
By what measure do you call this premature?
On 17 Jul 2015 1:30 pm, Luke Dashjr via bitcoin-dev wrote:
On Friday, July 17, 2015 3:55:19 PM Jeff Garzik via bitcoin-dev wrote:
> BIP PR: https://github.com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As an alternative to the preferred BIP100 this proposal is good
because it establishes a plan of action for dealing with the recent
ramp-up (100% increase) in number of transactions and transaction
size. Arguably, a transitory spam attack, yes, but wit
19 matches
Mail list logo
