[bitcoin-dev] TestNet block starved?

Any idea what's going on with TestNet? No blocks for nearly 2 hours now, according to multiple block explorers (blockr.io, my own bitcoin node, etc). Prior to the last block (530516), there were a lot of blocks with zero transactions and only an occasional block with a ton of txs. Any info? Thx

Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size

To be clear, these two are just my personal lists of arguments on "each side" to clear my mind and try to be perfectly objective. The resulting lists may not have any practical value but I'm going to maintain them locally nonetheless. If that's is not useful for the participants they can just leave

Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size

On Sat, Aug 15, 2015 at 12:35 AM, Jorge Timón wrote: > On Wed, Aug 12, 2015 at 1:21 PM, Venzen Khaosan > wrote: >> 4) General, undefined fear that something bad is going to happen when >> nodes choke up on a backlog of transactions. >> - - no specific symptoms are pointed at but presumably there

Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size

On Fri, Aug 14, 2015 at 12:01 AM, Geir Harald Hansen via bitcoin-dev wrote: > So in summary: > - Bitcoin dies. The end. I believe this is included in "btc exchange rate may fall". ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https:

Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size

On Thu, Aug 13, 2015 at 11: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 curve.

Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size

On Wed, Aug 12, 2015 at 9:52 PM, Elliot Olds wrote: > On Wed, Aug 12, 2015 at 2:59 AM, Jorge Timón > wrote: >> >> I believe all concerns I've read can be classified in the following >> groups: >> >> > 1) Potential indirect consequence of rising fees. > > > I'd rephrase this as "Consequences of hi

Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size

On Wed, Aug 12, 2015 at 1:21 PM, Venzen Khaosan wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Jorge, you say 3 concerns at the end of your message but I only see 1) > and 2). Assuming you've got a 3) and will add it, I'll contribute: No, sorry it's 2 concerns/risks with 2 sub-conce

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

I extremely dislike the inversion to preserve the "previous nSequence semantics". The "previous nSequence semantics" were consensus-unenforceable but we can cover the same use cases (or the realistic ones at least) with nMaturity. Let's face it and move on without technical debt we don't need and m

Re: [bitcoin-dev] Adjusted difficulty depending on relative blocksize

Nobody mentioned exchange rates. Those matter to miners too. Does it make sense for George Soros and every other rich person / institution to have the power to move difficulty, even pin it to min or max, just by buying or selling piles of BTC to swing the exchange rate? On 8/14/2015 8:03 AM, Ad

Re: [bitcoin-dev] A summary list of all concerns related to rising the block size

On Wed, Aug 12, 2015 at 6:41 PM, Thomas Zander via bitcoin-dev wrote: > On Wednesday 12. August 2015 12.28.39 Jorge Timón wrote: >> But let's just list the concerns first. > > Concerns? Yes, concerns or risks. Feel free to bike-shed the word. > I have never heard of "develop-by-concerns"? Is tha

Re: [bitcoin-dev] Fees and the block-finding process

On Tue, Aug 11, 2015 at 9:47 PM, Venzen Khaosan wrote: > > On 08/12/2015 10:35 AM, Elliot Olds via bitcoin-dev wrote: > > It depends on which use case's reliability that you focus on. For > > any specific use case of Bitcoin, that use case will be more > > reliable with a larger block size (ignori

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

With the assumed malleability-fix CHECKSIG2 version of lightning, watching for and responding to bad behavior is fully outsourceable. You can synchronize channel state (signed refund transactions) with a third party that watches for replay of old transactions on the mainnet, and starts the refund p

Re: [bitcoin-dev] libconsensus assertion fails if used in multiple threads

Ugh, what an unfortunate oversight! The good news is that this issue should be solved in future versions when we switch to the new libsecp256k1 lib for validation. For now, I've thrown together a quick hack to allow a user-specifiable callback for libbitcoinconsensus. I think it's not worth messi

[bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions

Hi everyone, I'd like to propose a new set of requirements as a policy on when to accept new transactions into the mempool and relay them. This policy would affect transactions which have as inputs other transactions which are not yet confirmed in the blockchain. The motivation for this policy

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

On 08/14/15 00:47, Mark Friedenbach via bitcoin-dev wrote: > On Thu, Aug 13, 2015 at 4:42 PM, Joseph Poon via bitcoin-dev > > wrote: > > I haven't tested the details of this, but is there another bit available > for use in the future for the

[bitcoin-dev] libconsensus assertion fails if used in multiple threads

We integrated libconsensus into bits of proof. It works well, in-line for all test cases with our Java engine and is about 50% faster on a single thread. The performance advantage unfortunatelly reverses if libconsensus is executed on several threads simultaneously as we do with the Java engine,

Re: [bitcoin-dev] Adjusted difficulty depending on relative blocksize

Ah, there we go. I should have dug deeper into the mailing list Thanks /jakob > 14 aug 2015 kl. 17:03 skrev Adam Back : > > There is a proposal that relates to this, see the flexcap proposal by > Greg Maxwell & Mark Friedenbach, it was discussed on the list back in > May: > > http://lists.linu

Re: [bitcoin-dev] Adjusted difficulty depending on relative blocksize

There is a proposal that relates to this, see the flexcap proposal by Greg Maxwell & Mark Friedenbach, it was discussed on the list back in May: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008017.html and http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008038.h

Re: [bitcoin-dev] Adjusted difficulty depending on relative blocksize

On 14 August 2015 at 16:48, Jakob Rönnbäck < bitcoin-dev@lists.linuxfoundation.org> wrote: > 14 aug 2015 kl. 16:20 skrev Anthony Towns : > > On 14 August 2015 at 11:59, Jakob Rönnbäck < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> What if one were to adjust the difficulty (for individual b

Re: [bitcoin-dev] Adjusted difficulty depending on relative blocksize

> 14 aug 2015 kl. 16:20 skrev Anthony Towns >: > > On 14 August 2015 at 11:59, Jakob Rönnbäck > > wrote: > What if one were to adjust the difficulty (for individual blocks) depending > on the relative size to the averag

Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size

On Friday 14. August 2015 09.26.33 Venzen Khaosan via bitcoin-dev wrote: > 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

Re: [bitcoin-dev] Adjusted difficulty depending on relative blocksize

On 14 August 2015 at 11:59, Jakob Rönnbäck < bitcoin-dev@lists.linuxfoundation.org> wrote: > What if one were to adjust the difficulty (for individual blocks) > depending on the relative size to the average block size of the previous > difficulty period? (I apologize if i’m not using the correct t

Re: [bitcoin-dev] Adjusted difficulty depending on relative blocksize

Hmm… well, yes and no. Mostly no :) The main idea i was trying to describe was that the actual difficulty for the block could be adjusted according to how much the size of the proposed block differ compared to the average size of blocks in the previous difficulty period. Unless I’m being very d

Re: [bitcoin-dev] Adjusted difficulty depending on relative blocksize

Like this? https://gist.github.com/gubatron/143e431ee01158f27db4 http://twitter.com/gubatron On Fri, Aug 14, 2015 at 5:59 AM, Jakob Rönnbäck < bitcoin-dev@lists.linuxfoundation.org> wrote: > Greetings, > > a thought occurred to me that I would love to hear what some bitcoin > experts think about

Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size

In that case it didn't remedy the problem of constantly full blocks, but got a ton of people on board the bitcoin train in the meanwhile. And with them more interest, investments, research and ideas. In the case we increase the limit and no government or banking group immediately uses up all the s

[bitcoin-dev] Adjusted difficulty depending on relative blocksize

Greetings, a thought occurred to me that I would love to hear what some bitcoin experts think about. What if one were to adjust the difficulty (for individual blocks) depending on the relative size to the average block size of the previous difficulty period? (I apologize if i’m not using the c

Re: [bitcoin-dev] CFP Bitcoin Scalability Workshop (Sept 12-13), Montreal Canada

Dear Mark, Thank you for your email. Registration was opened on Wednesday as planned and we list some initial background papers here: https://scalingbitcoin.org/papers/ To encourage early submissions to help with planning, review and circulation, we