Eric Voskuil via bitcoin-dev schreef op zo 29-01-2017 om 11:37 [-0800]:
> > On Jan 29, 2017, at 11:15 AM, Tom Harding via bitcoin-dev
> > wrote:
> >
> >> On 1/28/2017 10:29 AM, Peter Todd via bitcoin-dev wrote:
> >> a world of nodes in large datacenters is a world where it's very easy
> >> to fo
The semantics of a necessarily secure and private client-server protocol differ
from that of a necessarily distributed and public P2P protocol. I realize you
refer to the C/S as a distinct API, but this point is worthy of clarification
and emphasis.
The introduction of client-server sub-protoco
On 27.01.2017 20:03, Luke Dashjr via bitcoin-dev wrote:
Assume as a premise (despite your apparent disagreement below) that for
Bitcoin to function, a supermajority of economic activity needs to be
verified
using full nodes operated by the recipient. Evidence suggests that at
this
current time,
> On Jan 29, 2017, at 11:15 AM, Tom Harding via bitcoin-dev
> wrote:
>
>> On 1/28/2017 10:29 AM, Peter Todd via bitcoin-dev wrote:
>> a world of nodes in large datacenters is a world where it's very easy
>> to force the few Bitcoin nodes remaining to follow AML/KYC rules
>
> If that's true, wh
On Jan 29, 2017 2:28 PM, "Tom Harding via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
If that's true, why haven't we already seen AML/KYC required of mining
pools? That would be comparatively trivial.
Some regulators are already looking into it. Even at this point you'd
either
On 1/28/2017 10:29 AM, Peter Todd via bitcoin-dev wrote:
> a world of nodes in large datacenters is a world where it's very easy
> to force the few Bitcoin nodes remaining to follow AML/KYC rules
If that's true, why haven't we already seen AML/KYC required of mining
pools? That would be comparati
On Sat, Jan 28, 2017 at 07:43:48PM +, Luke Dashjr via bitcoin-dev wrote:
> On Saturday, January 28, 2017 10:36:16 AM Natanael wrote:
> > There aren't all that many cases where fraud proofs are unreasonably large
> > for a networked system like in Bitcoin. If Zero-knowledge proofs can be
> > ap
On Saturday, January 28, 2017 10:36:16 AM Natanael wrote:
> Den 28 jan. 2017 05:04 skrev "Luke Dashjr via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org>:
> > Satoshi envisioned a system where full nodes could publish proofs of
> > invalid blocks that would be automatically verified by SPV
On 27 January 2017 15:53:02 GMT-08:00, Andrew Johnson via bitcoin-dev
wrote:
>I'd also like to point out to Luke that Satoshi envisioned most full
>nodes
>running in data centers in the white paper, not every single user needs
>to
>run a full node to use bitcoin. Not to present this as an argu
On 28 January 2017 02:36:16 GMT-08:00, Natanael via bitcoin-dev
wrote:
>Den 28 jan. 2017 05:04 skrev "Luke Dashjr via bitcoin-dev" <
>bitcoin-dev@lists.linuxfoundation.org>:
>
>Satoshi envisioned a system where full nodes could publish proofs of
>invalid
>blocks that would be automatically veri
Den 28 jan. 2017 05:04 skrev "Luke Dashjr via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
Satoshi envisioned a system where full nodes could publish proofs of invalid
blocks that would be automatically verified by SPV nodes and used to ensure
even they maintained the equivalent of full
On Friday, January 27, 2017 11:53:02 PM Andrew Johnson via bitcoin-dev wrote:
> I don't think that the 17% yearly increase is too far off base considering
> current global trends(although I still don't particularly like the idea of
> centrally planning the limit, especially not that far into the fu
Thanks for replying, I'd be interested to see what you would come up with
today using the same methodology, seeing as max single hard drive capacity
has roughly doubled, global average internet bandwidth has increased 31%
from 4.8Mbps to 6.3Mbps(sourced from Akamai State of the Internet reports
201
On Fri, Jan 27, 2017 at 03:47:20PM -0500, Greg Sanders via bitcoin-dev wrote:
> Note that the 4MB number comes from a single network metric.
>
> Quotes directly from the paper in question:
> http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf
>
> >Our results hinge on the key metric of effective throug
Note that the 4MB number comes from a single network metric.
Quotes directly from the paper in question:
http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf
>Our results hinge on the key metric of effective throughput in the overlay
network, which we define here as which blocks propagate within an aver
On Jan 27, 2017 03:03, "Andrew Johnson via bitcoin-dev" wrote:
Other researchers have come to the conservative conclusion that we could
handle 4MB blocks today.
I believe this is a mischaracterization of the research conclusions. The
actual conclusion was that the maximum value for the blocksi
Regarding #1, I agree with Johnson Lau and others who have responded since
then—this proposal is not appropriate and should not be adopted for the
following reasons:
1. Miners will view it as way too little, delivered way too late. And as
soon as you say 300kb blocks, you've lost them all.
2. "Sp
Your BIP implementation should stress the capacity to softfork the rate of
blocksize increase if necessary. You briefly mention that:
*If over time, this growth factor is beyond what the actual technology
offers, the intention should be to soft fork a tighter limit.*
However this can work both wa
On Jan 26, 2017 10:15 PM, "Luke Dashjr" wrote:
On Friday, January 27, 2017 3:04:50 AM Andrew Johnson wrote:
> Comment on #1. You're dropping the blocksize limit to 300KB and only
> reaching the limit that we have in place today 7 years later?
The limit only drops all the way to 300k if it activ
Comment on #1. You're dropping the blocksize limit to 300KB and only
reaching the limit that we have in place today 7 years later? We're
already at capacity today, surely you're not serious with this proposal?
When you promised code for a hard forking block size increase in the HK
agreement I don
I can’t recommend your first 2 proposals. But I only have the time to talk
about the first one for now.
There are 2 different views on this topic:
1. “The block size is too small and people can’t buy a coffee with an on-chain
transaction. Let’s just remove the limit”
2. “The block size is too
On Friday, January 27, 2017 3:04:50 AM Andrew Johnson wrote:
> Comment on #1. You're dropping the blocksize limit to 300KB and only
> reaching the limit that we have in place today 7 years later?
The limit only drops all the way to 300k if it activates before 2017 April.
Considering that this re
I've put together three hardfork-related BIPs. This is parallel to the ongoing
research into the MMHF/SHF WIP BIP, which might still be best long-term.
1) The first is a block size limit protocol change. It also addresses three
criticisms of segwit: 1) segwit increases the block size limit which
23 matches
Mail list logo
