On Sat, Aug 1, 2015 at 12:05 AM, Hector Chu via bitcoin-dev
wrote:
> There is nothing tying
> transactions to the blocks they appear in.
Transactions can be recieved or accepted in different orders by
different nodes. The purpose of the blockchain is to resolve any
potential conflicting transacti
I haven't seen much discussion on this list of what will happen when the
blockchain forks due to larger blocks. I think the debate surrounding this
issue is a storm in a teacup, because transactions on the smaller chain can
and will appear on the bigger chain also. There is nothing tying
transactio
Forgot to include the list.
> From: Jean-Paul Kogelman
> Date: July 31, 2015 at 4:02:20 PM PDT
> To: Jorge Timón
> Cc: mi...@bitcoins.info
> Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't
> temporary
>
>
> I wrote about this a earlier this month:
> http://www
I generally agree with this as well. I think it is crucial we avoid
controversial hardforks. The risks greatly outweigh the benefits.
This is a good start to making it less controversial.
- Eric
On Jul 31, 2015 2:31 PM, "Jorge Timón" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Fri, Jul
On Fri, Jul 31, 2015 at 2:15 AM, Milly Bitcoin via bitcoin-dev
wrote:
> These are the types of things I have been discussing in relation to a
> process:
>
> -A list of metrics
> -A Risk analysis of the baseline system. Bitcoin as it is now.
> -Mitigation strategies for each risk.
> -A set of goal
Having said that, I must admit that the complex filtering mechanisms are
pretty clever...they almost make it practical to use SPV...now if only we
were committint to structures that can prove the validity of returned
datasets and miners actually validated stuff, it might also offer some
level of se
I would love to be able to increase block size. But I have serious doubts
about being able to do this safely at this time given what we presently
know about the Bitcoin network. And I'm pretty sure I'm not alone in this
sentiment.
Had we been working on fixing the known issues that most complicate
On Fri, Jul 31, 2015 at 7:40 PM, Thomas Kerin via bitcoin-dev
wrote:
> I really think there should be a document before a BIP number is assigned.
There was a document from the start, but after I got the BIP number, I
was renaming the file, moving from org-mode to mediawiki and getting
the code re
Le 27/07/2015 23:51, Justin Newton via bitcoin-dev a écrit :
> Thomas,
> I think this is interesting and has some good thoughts behind it. For
> clarity, are you recommending that the "_oa2" portion of the domain name be
> "hidden" as a way to make it easier to delegate just wallet names from
On Fri, Jul 31, 2015 at 7:58 AM, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> But it is easier to find common ground with others by compromising. Is 8mb
> better than no limit? I don't know and I don't care much:
>
People seeing statements like this might imagine
There's a large array of solutions that are bigger than the cheapest home
broadband, but smaller then renting hardware in a data center. Every
company with internet service to their location purchases one of these
options. If Bitcoin full node bandwidth requirements ever exceed a
hobbyist's reach
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I really think there should be a document before a BIP number is assigned.
On 23/07/15 12:10, Jorge Timón via bitcoin-dev wrote:
> Discussions about whether to get miner's confirmation on
> uncontroversial hardforks or not, and about whether to us
Here are some books that will help more people understand why Adam's
concern is important:
Kicking the Dragon (by Larken Rose)
The State (by Franz Oppenheimer)
Like he said, it isn't much about bitcoin. Our crypto is just one of the
defenses we've created, and understanding what it defends will h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/31/2015 09:58 PM, Mike Hearn via bitcoin-dev wrote:
> How more users or more nodes can bring more miners, or more
> importantly, improve mining decentralization?
>
>
> Because the bigger the ecosystem is the more interest there is in
> taking
On Thu, Jul 30, 2015 at 10:55 AM, Gavin Andresen
wrote:
> On Thu, Jul 30, 2015 at 11:24 AM, Bryan Bishop via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Because any decentralized system is going to have high transaction costs
>> and scarcity anyway.
>
>
> This is a meme tha
On Fri, Jul 31, 2015 at 11:56 AM, Thomas Zander via bitcoin-dev
wrote:
> On Friday 31. July 2015 03.21.07 Jorge Timón via bitcoin-dev wrote:
>> If I was a miner and you want me to include your transaction for free,
>> you're asking me to give you money
>
> What?
>
> Ask yourself; why do miners inc
>
> How more users or more nodes can bring more miners, or more importantly,
> improve mining decentralization?
>
Because the bigger the ecosystem is the more interest there is in taking
part?
I mean, I guess I don't know how to answer your question. When Bitcoin was
new it had almost no users an
On Fri, Jul 31, 2015 at 7:15 AM, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> He is not saying that. Whatever the reasons for centralization are, it
>> is obvious that increasing the size won't help.
>>
>
> It's not obvious. Quite possibly bigger blocks == more use
On Fri, Jul 31, 2015 at 2:15 PM, Mike Hearn wrote:
> Hey Jorge,
>
>> He is not saying that. Whatever the reasons for centralization are, it
>> is obvious that increasing the size won't help.
>
>
> It's not obvious. Quite possibly bigger blocks == more users == more nodes
> and more miners.
How mo
> On 31 Jul 2015, at 06:59, Un Ix via bitcoin-dev
> wrote:
>
> +1 on the comments below by Thomas.
>
> "Fee market" is not a binary option, either on or off. Like all markets it
> exists in varying degrees over time and with more or less influence on the
> process of which it is part of.
+1 on the comments below by Thomas.
"Fee market" is not a
binary option, either on or off. Like all markets it exists in varying
degrees over time and with more or less influence on the process of which it is
part of. As it stands now, and likely for another decade at least, t
That's all well and fine. But the pattern of your argument I would
say is "arguing security down" ie saying something is not secure
anyway, nothing is secure, everything could be hacked, so lets forget
that and give up, so that what is left is basically no
decentralisation security.
It is not par
1. Data centers are not some uniform group of businesses with identical
policies nor firms with identical laws applied. The ability to get a search
warrant at a Swedish hosting provider will be dramatically different than a
Singaporean business. Similar to the decentralized nature of bi
Yes, data-center operators are bound to follow laws, including NSLs
and gag orders. How about your ISP? Is it bound to follow laws,
including NSLs and gag orders?
https://edri.org/irish_isp_introduces_blocking/
Do you think everyone should run a full node behind TOR? No way, your
repressive
> Quite possibly bigger blocks == more users == more nodes and more miners.
I agree and would say that this is the only prediction of bitcoin's future
we can be absolutely sure of: more users equals more decentralization as
long as the cost of running a node is not prohibitively high.
It's incred
> On 31 Jul 2015, at 11:56, Thomas Zander via bitcoin-dev
> wrote:
>
> On Friday 31. July 2015 03.21.07 Jorge Timón via bitcoin-dev wrote:
>> If I was a miner and you want me to include your transaction for free,
>> you're asking me to give you money
>
> What?
>
> Ask yourself; why do miners
Hey Jorge,
He is not saying that. Whatever the reasons for centralization are, it
> is obvious that increasing the size won't help.
>
It's not obvious. Quite possibly bigger blocks == more users == more nodes
and more miners.
To repeat: it's not obvious to me at all that everything wrong with Bi
On Fri, Jul 31, 2015 at 12:16 PM, Mike Hearn via bitcoin-dev
wrote:
>> Well, centralization of mining is already terrible. I see no reason why we
>> should encourage making it worse.
>
> I see constant assertions that node count, mining centralisation, developers
> not using Bitcoin Core in their
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Hearn, I might be a nobody to you, but you know i talk with
skill, so let me tell this Friday...
On 07/31/2015 05:16 PM, Mike Hearn via bitcoin-dev wrote:
> I agree with Gavin
You would, of course.
> Bitcoin can support a large scale and it mu
I agree with Gavin - whilst it's great that a Blockstream employee has
finally made a realistic proposal (i.e. not "let's all use Lightning") -
this BIP is virtually the same as keeping the 1mb cap.
> Well, centralization of mining is already terrible. I see no reason why we
> should encourage mak
I think trust the data-center logic obviously fails, and I was talking
about this scenario in the post you are replying to. You are trusting the
data-center operator period. If one could trust data-centers to run
verified code, to not get hacked, filter traffic, respond to court orders
without no
On Friday 31. July 2015 03.21.07 Jorge Timón via bitcoin-dev wrote:
> If I was a miner and you want me to include your transaction for free,
> you're asking me to give you money
What?
Ask yourself; why do miners include transactions at all? What it the incentive
if there really is only less than
There is a summary of the proposals in my previous mail at
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html
I think there could be a compromise between Gavin's BIP101 and
Pieter's proposal (called "BIP103" here). Below I'm trying to play
with the parameters, whi
On Thursday 30. July 2015 11.02.43 Mark Friedenbach wrote:
> It is possible for a decentralized system like bitcoin to scale via
> distribution in a way that introduces minimal trust, for example by
> probabilistic validation and distribution of fraud proofs. However changes
> to bitcoin consensus
34 matches
Mail list logo
