-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Geir,
In the scenario below, you argue that the current 1MB limit would lead
to "constantly full" blocks. If the limit is increased to say 1.6GB
then a government or banking group may choose to utilize 1.5GB of the
capacity of each block (and pay fees
On Thu, Aug 13, 2015 at 4:42 PM, Joseph Poon via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I haven't tested the details of this, but is there another bit available
> for use in the future for the relative blockheight?
>
> I strongly believe that Lightning needs mitigations for
Very cool! This will certainly help make Lightning Network testable on
the main-chain and permit channels to remain open indefinitely. I'm
looking forward to it.
On Thu, Aug 13, 2015 at 12:06:44PM +0100, Btc Drak via bitcoin-dev wrote:
> // Note that unlike CHECKLOCKTIMEVERIFY we do not ne
3) A few more people begin using bitcoin. Bitcoin buckles and dies.
- Something happens a few months from now causing an influx of new users
and more transactions.
- Blocks are constantly full.
- A backlog of transactions keeps growing indefinitely.
- At first people say "bitcoin is slow". After a
On Thu, Aug 13, 2015 at 6:12 PM, Mark Friedenbach wrote:
> As per the rules of BIP 1, I hereby request that the BIP editor please
> assign an official number to this work. The idea has been discussed before
> on the bitcoin-dev mailing list:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-d
As per the rules of BIP 1, I hereby request that the BIP editor please
assign an official number to this work. The idea has been discussed before
on the bitcoin-dev mailing list:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008452.html
And a reference implementation is availab
> On Aug 13, 2015, at 2:52 AM, Ashley Holman via bitcoin-dev
> wrote:
>
> A concern I have is about security (hash rate) as a function of block size.
>
> I am assuming that hash rate is correlated with revenue from mining.
>
> Total revenue from fees as a function of block size should be a cu
On August 13, 2015 7:34:03 PM GMT+03:00, Nicolas Dorier via bitcoin-dev
wrote:
>Would be wonderful to have this pushed together with CLTV and BIP68.
>If BIP68 get pushed in the next fork, this CSV is a no brainer.
>
>Was there a competing RCLTV implementation somewhere that did not
>depend on
>
Would be wonderful to have this pushed together with CLTV and BIP68.
If BIP68 get pushed in the next fork, this CSV is a no brainer.
Was there a competing RCLTV implementation somewhere that did not depend on
BIP68 for information ? I don't manage to find it.
__
I have written the following draft BIP for a new opcode
CHECKSEQUENCEVERIFY by Mark Friedenbach, which introduces a form of
relative-locktime to Bitcoin's scripting language.
https://github.com/btcdrak/bips/blob/bip-checksequenceverify/bip-csv.mediawiki
BIP: XX
Title: CHECKSEQUENCEVERIFY
A
A concern I have is about security (hash rate) as a function of block size.
I am assuming that hash rate is correlated with revenue from mining.
Total revenue from fees as a function of block size should be a curve. On
one extreme of the curve, if blocks are too big, fee revenue tends towards
0
11 matches
Mail list logo
