On Tuesday 11. August 2015 00.52.23 Pieter Wuille wrote:
The whole point is that whether confirmation at a particular price point is
reliable depends on how much demand there is at that price point. And
increasing the block size out of fear of what might happen is failing to
recognize that it
On Mon, Aug 10, 2015 at 4:12 PM, Gavin Andresen gavinandre...@gmail.com
wrote:
Executive summary: when networks get over-saturated, they become
unreliable. Unreliable is bad.
Unreliable and expensive is extra bad, and that's where we're headed
without an increase to the max block size.
I
On Aug 10, 2015 7:03 PM, odinn via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Note that I've
been in favor of going ahead with Cameron Garnham's dynamic softfork
proposal right now, which can be seen at http://is.gd/DiFuRr
No offence, but I think that anyone who claims a block
On Mon, Aug 10, 2015 at 9:19 PM, Ross Nicoll via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
That could definitely be done, for example by making the genesis field
repeated, so it specifies all potential networks. The response would need
to indicate which hash it used, but that
On Sat, Aug 8, 2015 at 2:37 PM, Thomas Zander via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
On Saturday 8. August 2015 12.54.36 Adam Back wrote:
On 8 August 2015 at 09:54, Thomas Zander tho...@thomaszander.se wrote:
I didn't say off-chain, and gave an example of on-chain usecase
I think the point you don't need to trust anyone to use Bitcoin remains.
I don't think that is a true statement. Users need to trust the mining
system is working as intended. Users also need to trust the developers
to a certain extent. It is about levels of trust and how much you need
to
On 08/10/2015 05:39 AM, Thomas Zander via bitcoin-dev wrote:
On Monday 10. August 2015 07.57.30 Rune K. Svendsen via bitcoin-dev wrote:
What Lightning does is raise the value of a transaction on the block chain.
Imagine you're a Lightning node, and in order to collect your fees, that
you've
On Mon, Aug 10, 2015 at 08:14:08PM +0100, Hector Chu wrote:
On 10 August 2015 at 19:50, Anthony Towns via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
...but I think at present the time value of bitcoin is effectively zero
Since bitcoin is liquid you forget that one can just sell
On Tue, Aug 11, 2015 at 05:02:40AM +0800, Anthony Towns wrote:
On Sun, Aug 09, 2015 at 06:44:08PM -0400, Gavin Andresen via bitcoin-dev
wrote:
I'd love to see somebody write up a higher-level description of what the
user experience is like, what communication happens underneath, and what
On Monday 10. August 2015 12.53.33 Leo Wandersleb via bitcoin-dev wrote:
The reason of it being faster makes no sense, as your example the channel
has been open for a month then he really doesn't care it takes 1, 10 or
50 blocks before his transaction is included. What is 5 hours wait on a
On Mon, Aug 10, 2015 at 6:01 PM, Pieter Wuille pieter.wui...@gmail.com
wrote:
On Aug 7, 2015 11:19 PM, Sergio Demian Lerner via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
b. Reduce the block rate to a half (average 5 minute blocks)
Suppose this is a one time hard fork.
On Monday 10. August 2015 10.24.18 Alex Morcos via bitcoin-dev wrote:
think they are more just an example of how
immature all of this technology is, and we should be concentrating on
improving it before we're trying to scale it to world acceptance levels.
Would it be an idea to create a
On Aug 7, 2015 11:19 PM, Sergio Demian Lerner via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
b. Reduce the block rate to a half (average 5 minute blocks)
Suppose this is a one time hard fork. There no drastic technical problems
with any of them: SPV mining and the relay network
On Monday 10. August 2015 22.17.52 Jorge Timón wrote:
But I don't see how that is relevant, allowing trust to be involved in
different ways is a feature, but it's optional.
Agreed.
I think the point you don't need to trust anyone to use Bitcoin remains.
yes, and thats fine.
The argument
In terms of usage I think you'd more imagine a wallet that basically
parks Bitcoins onto channels at all times, so long as they are
routable there is no loss, and the scalability achieved thereby is
strongly advantageous, and there is even the potential for users to
earn fees by having their
On Sat, Aug 8, 2015 at 6:10 AM, Thomas Zander via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
The idea that Bitcoins very reason for existence is to avoid trusting anyone
but yourself is something I've heard before, and I have to comment because it
is a destructive thought. It is
On Monday 10. August 2015 13.55.03 Jorge Timón via bitcoin-dev wrote:
Gavin, I interpret the absence of response to these questions as a
sign that everybody agrees that there's no other reason to increase
the consensus block size other than to avoid minimum market fees from
rising (above
On Aug 11, 2015 12:11 AM, Sergio Demian Lerner sergio.d.ler...@gmail.com
wrote:
What I'm saying is that this ratio may have improved 20x since miners
began using the TheBlueMatt relay network, so deteriorating the ratio 2x
does not put miners in a unknown future, but in an future which is far
On Mon, Aug 10, 2015 at 8:40 PM, Luke Dashjr via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Genesis blocks are not necessarily unique. For example, Litecoin and
Feathercoin share the same one.
That's a fatal design in Feathercoin, not a mistake all altchains have
done and
Nonsense. Hoping that the bitcoin price will rise is called speculation.
Hub operators won't want to do that, since prices can go down as well as
up. The money markets and government bond yield curve prices risk-free
rates of return, a guaranteed rise in value. These rates are always
positive.
On
Here's some related commits from #6382 :
https://github.com/jtimon/bitcoin/commit/1a4e8d8637ced45e8785ddb95b0fc20a5b8365d1
https://github.com/jtimon/bitcoin/commit/a6941e318a7028ce3d8919d50825762ca9c0c74c
https://github.com/jtimon/bitcoin/commit/1754928d3ceeb26b2491ad1384095058e456fa9b
On Mon, Aug 10, 2015 at 2:33 PM, Btc Drak btcd...@gmail.com wrote:
Additionally, correct me if I am wrong, but the net effect from preventing
fees rising from zero would be to guarantee miners have no alternative
income from fees as block subsidy dries up and thus harm the incentives to
secure
On Mon, Aug 10, 2015 at 2:53 PM, Mike Hearn he...@vinumeris.com wrote:
We're not modifying BIP 70, it's now immutable and can only be extended.
Well, yes, I guess it's modifying that in the extension BIP.
There's really not much point in having a dedicated chain ID for regtest
mode. You
Following this, Bitcoin and proposed payment networks like LN will be
competing for fees based on duration and cost to process transactions.
If fees on Bitcoin network stay low and zero-conf txns are possible,
competing payment networks will need some very special features to survive
and make
On Sunday 9. August 2015 23.51.50 Btc Drak via bitcoin-dev wrote:
I thought it's worth mentioning there is a specific Lightning Network
development mailing list at
http://lists.linuxfoundation.org/mailman/listinfo/lightning-dev and already
some pretty interesting explanations in the archives.
On Monday 10. August 2015 07.57.30 Rune K. Svendsen via bitcoin-dev wrote:
What Lightning does is raise the value of a transaction on the block chain.
Imagine you're a Lightning node, and in order to collect your fees, that
you've earned over the past month, you have to settle on the
Gavin, I interpret the absence of response to these questions as a
sign that everybody agrees that there's no other reason to increase
the consensus block size other than to avoid minimum market fees from
rising (above zero).
Feel free to correct that notion at any time by answering the
questions
On Fri, Aug 7, 2015 at 1:33 PM, Jorge Timón jti...@jtimon.cc wrote:
On Aug 7, 2015 5:55 PM, Gavin Andresen gavinandre...@gmail.com wrote:
I think there are multiple reasons to raise the maximum block size, and
yes, fear of Bad Things Happening as we run up against the 1MB limit is one
of
Gavin,
They are not analogous.
Increasing performance and making other changes that will help allow
scaling can be done while at small scale or large scale.
Dealing with full blocks and the resultant feedback effects is something
that can only be done when blocks are full. It's just too
29 matches
Mail list logo
