From: Hector Chu <hectorchu@gmail.com>
To: Alex Morcos <morcos@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fees and the block-finding process
Date: Sun, 9 Aug 2015 06:52:37 +0100 [thread overview]
Message-ID: <CAAO2FKH_DKrFYfDR1-q0GrM5cHFtQQcYtECXKzzrUybfTSeh-A@mail.gmail.com> (raw)
In-Reply-To: <CFD5F030-D518-4998-93BD-A19054C54058@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6103 bytes --]
You people are the most selfish kind of people in the world. Blackmail
developers with overload of the system, to try to force them to urgently
come up with solutions to the problem. The solution is always going to
be... wait for it... "increase the block size". There is not enough time or
manpower to do anything else. We are witnessing a tragedy of the commons
before our very eyes.
On 9 August 2015 at 00:05, Alex Morcos via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I agree
> There are a lot of difficult technical problems introduced by insufficient
> block space that are best addressed now. As well as problems that scale
> will exacerbate like bootstrapping that we should develop solutions for
> first.
>
>
> Sent from my iPad
>
> On Aug 8, 2015, at 6:45 PM, Dave Scotese via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I see value in lowering the block size or leaving it where it is. We
> expect to run out of space, and I think it's a good idea to prepare for
> that, rather than avoid it. When we run out of space and the block size is
> low, we will see problems. If we raise the block size, we will NOT see
> these problems until bitcoin is bigger and more important and the pressure
> is higher.
>
> Someone mentioned that when the backlog grows faster than it shrinks, that
> is a real problem. I don't think it is. It is a problem for those who
> don't wait for even one confirmation, but backlogs in the past have already
> started training users to wait for at least one confirmation, or go
> off-chain. I am comfortable leaving those zero-conf people in a little bit
> of trouble. Everyone else can double-spend (perhaps that's not as easy as
> it should be in bitcoin core) and use a higher fee, thus competing for
> block space. Yes, $5 transactions suck, but $0.15 is not so bad and about
> twice the average right now.
>
> Meanwhile, the higher fees everyone starts feeling like paying, along with
> the visibility of the problems caused by full-blocks, will provide
> excellent justification and motivation for increasing the limit. My
> favorite thing to do is to have a solution ready for a problem I expect to
> see, see the problem (so I can measure things about it) and then implement
> the solution.
>
> In my experience, the single biggest reason not to run a full node has to
> do with starting from scratch: "I used to run a full node, but last time I
> had to download the full blockchain, it took ___ days, so I just use (some
> wallet) now." I think that has been improved with headers-first, but many
> people don't know it.
>
> I have some ideas how a "full node" could postpone being "full" but still
> be nearly completely operational so that the delay between startup and
> having a full blockchain is nearly painless. It involves bonded
> representation of important not-so-large pieces of data (blocks that have
> my transactions, the complete UTXO as of some height, etc.). If I know
> that I have some btc, I could offer it (say, 100 or 1000 transaction fees'
> worth) to anyone who will guarantee good data to me, and then when I have
> the whole blockchain, I will know if they were honest. If done right, the
> whole network could know whether or not they were honest and enforce the
> bond if they weren't. Credit the Lightening paper for parts of this idea.
>
> Dave
>
> On Fri, Aug 7, 2015 at 4:06 PM, Adam Back via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Please try to focus on constructive technical comments.
>>
>> On 7 August 2015 at 23:12, Thomas Zander via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > What will the backlash be when people here that are pushing for
>> "off-chain-
>> > transactions" fail to produce a properly working alternative, which
>> > essentially means we have to say NO to more users.
>>
>> But > 99% of Bitcoin transactions are already off-chain. There are
>> multiple competing companies offering consumer & retail service with
>> off-chain settlement.
>>
>> I wasnt clear but it seemed in your previous mail that you seemed to
>> say you dont mind trusting other people with your money, and so
>> presumably you are OK using these services, and so have no problem?
>>
>> > At this time and this size of bitcoin community, my personal experience
>> (and
>> > I've been part of many communities) saying NO to new customers
>>
>> Who said no to anything? The systems of off-chain transfer already
>> exist and are by comparison to Bitcoins protocol simple and rapid to
>> adapt and scale.
>>
>> Indications are that we can even do off-chain at scale with Bitcoin
>> similar trust-minimisation with lightning, and duplex payment
>> channels; and people are working on that right now.
>>
>> I think it would be interesting and useful for someone, with an
>> interest in low trust, high scale transactions, to work on and propose
>> an interoperability standard and API for such off-chain services to be
>> accessed by wallets, and perhaps periodic on-chain inter-service
>> netting.
>>
>> Adam
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> --
> I like to provide some work at no charge to prove my value. Do you need a
> techie?
> I own Litmocracy <http://www.litmocracy.com> and Meme Racing
> <http://www.memeracing.net> (in alpha).
> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
> which now accepts Bitcoin.
> I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
> "He ought to find it more profitable to play by the rules" - Satoshi
> Nakamoto
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 8106 bytes --]
next prev parent reply other threads:[~2015-08-09 5:53 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-07 14:57 [bitcoin-dev] Fees and the block-finding process Gavin Andresen
2015-08-07 15:16 ` Pieter Wuille
2015-08-07 15:55 ` Gavin Andresen
2015-08-07 16:28 ` Pieter Wuille
2015-08-07 17:47 ` Ryan Butler
2015-08-07 18:25 ` Mark Friedenbach
2015-08-07 18:57 ` Ryan Butler
2015-08-07 19:07 ` Ryan Butler
2015-08-07 19:15 ` Mark Friedenbach
2015-08-07 20:17 ` Ryan Butler
2015-08-07 20:33 ` Dave Hudson
2015-08-07 18:17 ` jl2012
2015-08-07 18:35 ` Bryan Bishop
2015-08-07 18:36 ` Simon Liu
2015-08-11 23:20 ` Elliot Olds
2015-08-07 17:33 ` Jorge Timón
2015-08-07 22:12 ` Thomas Zander
2015-08-07 23:06 ` Adam Back
2015-08-08 22:45 ` Dave Scotese
2015-08-08 23:05 ` Alex Morcos
2015-08-09 5:52 ` Hector Chu [this message]
2015-08-09 10:32 ` Thomas Zander
2015-08-09 10:42 ` Thomas Zander
2015-08-09 20:43 ` Dave Scotese
2015-08-11 17:03 ` Jorge Timón
2015-08-10 11:55 ` Jorge Timón
2015-08-10 12:33 ` Btc Drak
2015-08-10 13:03 ` Jorge Timón
2015-08-10 22:13 ` Thomas Zander
2015-08-11 17:47 ` Jorge Timón
2015-08-11 18:46 ` Michael Naber
2015-08-11 18:48 ` Mark Friedenbach
2015-08-11 18:55 ` Michael Naber
2015-08-11 19:45 ` Jorge Timón
2015-08-11 21:31 ` Michael Naber
2015-08-11 18:51 ` Bryan Bishop
2015-08-11 18:59 ` Michael Naber
2015-08-11 19:27 ` Jorge Timón
2015-08-11 19:37 ` Michael Naber
2015-08-11 19:51 ` Pieter Wuille
2015-08-11 21:18 ` Michael Naber
2015-08-11 21:23 ` Adam Back
2015-08-11 21:30 ` Angel Leon
2015-08-11 21:32 ` Pieter Wuille
2015-08-11 21:34 ` Adam Back
2015-08-11 21:39 ` Michael Naber
2015-08-12 6:10 ` Venzen Khaosan
2015-08-11 22:06 ` Angel Leon
2015-08-11 21:35 ` Michael Naber
2015-08-11 21:51 ` Pieter Wuille
2015-08-12 3:35 ` Elliot Olds
2015-08-12 4:47 ` Venzen Khaosan
2015-08-14 21:47 ` Elliot Olds
2015-08-12 0:56 ` Tom Harding
2015-08-12 1:18 ` Eric Voskuil
2015-08-12 8:10 ` Thomas Zander
2015-08-12 9:00 ` Jorge Timón
2015-08-12 9:25 ` Thomas Zander
2015-08-11 19:53 ` Jorge Timón
2015-08-11 20:56 ` Michael Naber
2015-08-12 7:54 ` Thomas Zander
2015-08-12 8:01 ` Thomas Zander
[not found] ` <1679272.aDpruqxXDP@coldstorage>
2015-08-12 8:51 ` Jorge Timón
2015-08-12 9:23 ` Thomas Zander
2015-08-12 9:45 ` Jorge Timón
2015-08-12 16:24 ` Thomas Zander
2015-08-17 14:49 ` BitMinter operator
2015-08-17 15:01 ` Peter Todd
2015-08-10 14:12 ` Gavin Andresen
2015-08-10 14:24 ` Alex Morcos
2015-08-10 22:12 ` Thomas Zander
2015-08-10 14:34 ` Pieter Wuille
2015-08-10 22:04 ` Thomas Zander
2015-08-20 14:40 ` Will Madden
2015-08-10 14:55 ` Jorge Timón
2015-08-10 22:09 ` Thomas Zander
2015-08-10 22:52 ` Pieter Wuille
2015-08-10 23:11 ` Pieter Wuille
2015-08-11 5:34 ` Thomas Zander
2015-08-11 6:03 ` Mark Friedenbach
2015-08-11 6:31 ` Thomas Zander
2015-08-11 7:08 ` Mark Friedenbach
2015-08-11 8:38 ` Thomas Zander
2015-08-11 9:14 ` Angel Leon
2015-08-11 19:00 ` Mark Friedenbach
2015-08-11 19:26 ` Michael Naber
2015-08-11 20:12 ` Adam Back
2015-08-12 0:32 ` odinn
2015-08-11 11:10 ` Thomas Zander
2015-08-12 0:18 ` odinn
2015-08-07 21:30 ` Jim Phillips
2015-08-07 18:22 ` Anthony Towns
2015-08-07 18:36 ` Peter R
2015-08-12 1:56 Corey Haddad
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAO2FKH_DKrFYfDR1-q0GrM5cHFtQQcYtECXKzzrUybfTSeh-A@mail.gmail.com \
--to=hectorchu@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=morcos@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox