Gold collapsing. Bitcoin UP.

[TPTB_need_war]

[–]gavinandresenGavin Andresen - Bitcoin Expert

I think 1-minute blocks is a good idea. The best time to roll that out would be the next subsidy halving (makes the code much simpler).

We still need a bigger max block size, though.

   reddit

Just to throw the cat amongst the pigeons, how about changing the block interval?

I'm in favor of changing it.  About 16 block per day would be about right as far as I'm concerned.  Bitcoin never was a real-time system and real-time behavior when needed is best done for real in a proxy (e.g., a bitcoin-backed sidechain designed for such use-cases.)

That addresses only a small symptom of the overall problem, i.e. the orphan rate.

It does nothing for the fact that UXTO won't scale with RAM.

Take them out of RAM.  Slow the whole system, and more importantly, use it as the slow system that it is.  Make quality (robustness) the over-arching goal over quantity and speed.  It will never be competitive in this role and will burn itself up trying...even with minimal assistance from those whom it threatens.

The tx rate doesn't slow down. You will need massively parallel disk arrays. Again centralization.

It does nothing for the Transactions Withholding attack, pool Sybil attack, and inefficacy of getblocktemplate-at-scale issues I've raised.

More time to cross-check and verify when the system is operating slowly.  More critically this slow rate expands and diversify the pool of potential operators which fosters decentralization into realms (virtual and otherwise) where it can really make a difference.

That doesn't make any sense. It doesn't change any factor that addresses those attacks.

It can't help you scale to micropayments volume.

Even the most stary-eyed gave up on the micro-payment-on-native-bitcoin pipe dream a long time ago.  They are, however, one of the driving forces behind using Bitcoin in it's current proven form as a backing upon which target solutions such as micropayments can ride and thus become nearly a pure proxy.  (Sidechains of course.)

Sidechains will have the same technical challenge.

What you are in effect doing is handing micropayments to Paypal, Coinbase, Circle, etc.. The cartel will control micropayments.

I have the solution. But nobody likes me because I am frank. Insanity prevails!

[1714049195]

1714049195

[1714049195]

1714049195

[1714049195]

1714049195

[1714049195]

1714049195

[tvbcof]

An attack I thought of years ago would be to formulate UTXO's systematically to chain blocks together in such a way that 1) their count would stress the working database (currently implemented in RAM most often) and 2) verifying them would touch as many blocks as possible making rendering of much of the actual blockchain itself require for many transactions.  I'm sure there is a name for such an attack.  If not, call it the 'tvbcof attack' I suppose.

Mining a block with such a tx is disincentivized by its long block propagation time (and hence higher orphan risk). Miners could evaluate tx verification time before inclusion and compare to fee.

How does a miner distinguish between a natural transaction which has this (presumed by me) detrimental characteristic by chance and one which was designed for the purpose of being disruptive?  If they treat all disruptive transactions as attackers (assuming miners really give enough of a shit to try due to orphan problems or otherwise) they are likely to piss off a fair number of people it seems to me.

[lunarboy]

[–]gavinandresenGavin Andresen - Bitcoin Expert

I think 1-minute blocks is a good idea. The best time to roll that out would be the next subsidy halving (makes the code much simpler).

We still need a bigger max block size, though.

   reddit

Just to throw the cat amongst the pigeons, how about changing the block interval?

I'm in favor of changing it.  About 16 block per day would be about right as far as I'm concerned.  Bitcoin never was a real-time system and real-time behavior when needed is best done for real in a proxy (e.g., a bitcoin-backed sidechain designed for such use-cases.)

Wouldn't this dramatically weaken/dilute 1/10th  the hashing power? Surely this is playing with fire especially if there was not full consensus at the time of the hard fork? Conflicts more likely won by the 10minute block side

Also it seems to fundamentally change the incentive structure.... what's left after that? just increase the amount of coins to 42 million?  /rhetoric

[smooth]

[–]gavinandresenGavin Andresen - Bitcoin Expert

I think 1-minute blocks is a good idea. The best time to roll that out would be the next subsidy halving (makes the code much simpler).

We still need a bigger max block size, though.

   reddit

Just to throw the cat amongst the pigeons, how about changing the block interval?

I'm in favor of changing it.  About 16 block per day would be about right as far as I'm concerned.  Bitcoin never was a real-time system and real-time behavior when needed is best done for real in a proxy (e.g., a bitcoin-backed sidechain designed for such use-cases.)

Wouldn't this dramatically weaken/dilute 1/10th  the hashing power? Surely this is playing with fire especially if there was not full consensus at the time of the hard fork? Conflicts more likely won by the 10minute block side

Also it seems to fundamentally change the incentive structure.... what's left after that? just increase the amount of coins to 42 million?  /rhetoric

It doesn't change the incentive structure at all as long as the block rewards are scaled accordingly. It would still be 25 BTC every 10 minutes (currently), just broken up into 2.5 BTC pieces.

I'm not in favor and frankly it makes me start to question Gavin's motives, which I didn't with respect to just the larger block size. This adds another bit of evidence supporting the case that he is actively supporting centralization, or is being heavily influenced by those in favor of centralization and doesn't care or isn't able to resist that influence.

[molecular]

An attack I thought of years ago would be to formulate UTXO's systematically to chain blocks together in such a way that 1) their count would stress the working database (currently implemented in RAM most often) and 2) verifying them would touch as many blocks as possible making rendering of much of the actual blockchain itself require for many transactions.  I'm sure there is a name for such an attack.  If not, call it the 'tvbcof attack' I suppose.

Mining a block with such a tx is disincentivized by its long block propagation time (and hence higher orphan risk). Miners could evaluate tx verification time before inclusion and compare to fee.

How does a miner distinguish between a natural transaction which has this (presumed by me) detrimental characteristic by chance and one which was designed for the purpose of being disruptive?  If they treat all disruptive transactions as attackers (assuming miners really give enough of a shit to try due to orphan problems or otherwise) they are likely to piss off a fair number of people it seems to me.

He doesn't. He just requires a higher fee for inclusion to make up for the risk of a slower propagation.

In the end it's up to the wallet to assign a higher fee.

This is not up to us to decide anyways. Miners can and probably will or are already doing this or something similar.

[tvbcof]

[–]gavinandresenGavin Andresen - Bitcoin Expert

I think 1-minute blocks is a good idea. The best time to roll that out would be the next subsidy halving (makes the code much simpler).

We still need a bigger max block size, though.

   reddit

Just to throw the cat amongst the pigeons, how about changing the block interval?

I'm in favor of changing it.  About 16 block per day would be about right as far as I'm concerned.  Bitcoin never was a real-time system and real-time behavior when needed is best done for real in a proxy (e.g., a bitcoin-backed sidechain designed for such use-cases.)

Wouldn't this dramatically weaken/dilute 1/10th  the hashing power? Surely this is playing with fire especially if there was not full consensus at the time of the hard fork? Conflicts more likely won by the 10minute block side

Also it seems to fundamentally change the incentive structure.... what's left after that? just increase the amount of coins to 42 million?  /rhetoric

I was half joking...and half not...I wish the system had been designed such that one could anticipate a solid result in about a day although it is true that it would have killed some early marketing potential (for the bogus idea that Bitcoin is a suitable exchange currency) and Bitcoin probably would have withered on the vine near the beginning of it's life.

At this point in time I favor just sticking to the 10 min frequency.  I would note, however, that the difference between a real real-time system and the 10 minute batch cycle approaches infinity.  The difference between a 10 second human patience time and the 10 min block frequency time is a factor of 60, and that does not include the multiple block confirmations cycles which can and at some point probably will be needed for a solid result.  The factor between my 90 minute proposal and the current 10 minute cycle is 9.  That is my point about Bitcoin being far from a real-time system.  The two options are to try to shoe-horn it into being one which is fraught with danger and risk, or using it as something closer to what it is naively.

As for the circulation and inflation rate rhetoric, I think most people took it as implicit that these factors would not change under either a slower or faster cycle time for an offsetting adjustment.

[tvbcof]

An attack I thought of years ago would be to formulate UTXO's systematically to chain blocks together in such a way that 1) their count would stress the working database (currently implemented in RAM most often) and 2) verifying them would touch as many blocks as possible making rendering of much of the actual blockchain itself require for many transactions.  I'm sure there is a name for such an attack.  If not, call it the 'tvbcof attack' I suppose.

Mining a block with such a tx is disincentivized by its long block propagation time (and hence higher orphan risk). Miners could evaluate tx verification time before inclusion and compare to fee.

How does a miner distinguish between a natural transaction which has this (presumed by me) detrimental characteristic by chance and one which was designed for the purpose of being disruptive?  If they treat all disruptive transactions as attackers (assuming miners really give enough of a shit to try due to orphan problems or otherwise) they are likely to piss off a fair number of people it seems to me.

He doesn't. He just requires a higher fee for inclusion to make up for the risk of a slower propagation.

In the end it's up to the wallet to assign a higher fee.

This is not up to us to decide anyways. Miners can and probably will or are already doing this or something similar.

Sounds good to me.  I would like to see the fee be around the equivalent of $10 per transaction.  That is about what I set my client to pay and it's worth every penny to me.  In a busy year I may do 10 native transactions or so.  In a dry one (like 2015 so far) the number of transactions I perform drops to zero.

[molecular]

An attack I thought of years ago would be to formulate UTXO's systematically to chain blocks together in such a way that 1) their count would stress the working database (currently implemented in RAM most often) and 2) verifying them would touch as many blocks as possible making rendering of much of the actual blockchain itself require for many transactions.  I'm sure there is a name for such an attack.  If not, call it the 'tvbcof attack' I suppose.

Mining a block with such a tx is disincentivized by its long block propagation time (and hence higher orphan risk). Miners could evaluate tx verification time before inclusion and compare to fee.

How does a miner distinguish between a natural transaction which has this (presumed by me) detrimental characteristic by chance and one which was designed for the purpose of being disruptive?  If they treat all disruptive transactions as attackers (assuming miners really give enough of a shit to try due to orphan problems or otherwise) they are likely to piss off a fair number of people it seems to me.

He doesn't. He just requires a higher fee for inclusion to make up for the risk of a slower propagation.

In the end it's up to the wallet to assign a higher fee.

This is not up to us to decide anyways. Miners can and probably will or are already doing this or something similar.

Sounds good to me.  I would like to see the fee be around the equivalent of $10 per transaction.  That is about what I set my client to pay and it's worth every penny to me.  In a busy year I may do 10 native transactions or so.  In a dry one (like 2015 so far) the number of transactions I perform drops to zero.

We obviously have differing usage patterns. I made 62 transactions so far this year (in the main trezor wallet alone, not counting paying for pizza with mycelium)

[lunarboy]

Sounds good to me.  I would like to see the fee be around the equivalent of $10 per transaction.  That is about what I set my client to pay and it's worth every penny to me.  In a busy year I may do 10 native transactions or so.  In a dry one (like 2015 so far) the number of transactions I perform drops to zero.

Mike Hearns blogs post finally convinced me this was not such good idea.  Crash landing

What not to do

[solex]

[–]gavinandresenGavin Andresen - Bitcoin Expert

I think 1-minute blocks is a good idea. The best time to roll that out would be the next subsidy halving (makes the code much simpler).

We still need a bigger max block size, though.

   reddit

Just to throw the cat amongst the pigeons, how about changing the block interval?

This is an interesting idea. I can see the benefits but not sure about the block orphaning implications.

I have kicked off a poll!
https://bitcointalk.org/index.php?topic=1057423.msg11343627#msg11343627

[tvbcof]

He doesn't. He just requires a higher fee for inclusion to make up for the risk of a slower propagation.

In the end it's up to the wallet to assign a higher fee.

This is not up to us to decide anyways. Miners can and probably will or are already doing this or something similar.

Sounds good to me.  I would like to see the fee be around the equivalent of $10 per transaction.  That is about what I set my client to pay and it's worth every penny to me.  In a busy year I may do 10 native transactions or so.  In a dry one (like 2015 so far) the number of transactions I perform drops to zero.

We obviously have differing usage patterns. I made 62 transactions so far this year (in the main trezor wallet alone, not counting paying for pizza with mycelium)

I'll look forward to joining you and hopefully eclipsing your profligate spending as soon as I can do so on a variety of sidechains and thus not stress what I consider to be a monumental achievement.

[molecular]

Sounds good to me.  I would like to see the fee be around the equivalent of $10 per transaction.  That is about what I set my client to pay and it's worth every penny to me.  In a busy year I may do 10 native transactions or so.  In a dry one (like 2015 so far) the number of transactions I perform drops to zero.

Mike Hearns blogs post finally convinced me this was not such good idea.  Crash landing

What not to do

One the one hand, yes: his blog post has instilled a sense of urgency and importance in me and I'm still for the 20 MB block size increase. On the other hand a part in me (a destructive part of my personality, I guess) wants to see what would actually happen and how bad things would crash and burn... the user/media reaction and all. It'd be exciting to watch, I'm sure and we could probably scoop up many more cheap coins.

[tvbcof]

Sounds good to me.  I would like to see the fee be around the equivalent of $10 per transaction.  That is about what I set my client to pay and it's worth every penny to me.  In a busy year I may do 10 native transactions or so.  In a dry one (like 2015 so far) the number of transactions I perform drops to zero.

Mike Hearns blogs post finally convinced me this was not such good idea.  Crash landing

What not to do

I anticipated and commented on it years ago in a thread including Mike IIRC.  My solution at the time was as it is now.  Heavily advertise the fact that in almost any sort of a failure mode no actual value is at risk with the possible exception of a few corner-case transactions for a few people who have bad luck.  One's Bitcoin is as safe as one's ability to maintain control of their signing key (which is dubious in way to many cases.)  But that is only if people are using Bitcoin in a certain way...namely as a high-powered solution to be used with caution for critical things.

The route which was taken was exactly the opposite.  That is, steer the herd to a mentality that Bitcoin is a drop-in replacement for every exchange currency and super secure and convenient and generally a panacea which will elevate all human problems.  Now all of a sudden the earth is going to collapse if people people are inconvenienced for a little while and Bitcoin does not perform to it's absurd marketed specs.  If we have a real problem of any sort when the transaction rate approaches any particular maximum then there is no excuse and

 - Dev was completely remiss in addressing real problems...and I've been chagrined at Gavin for a long time for focusing on new GUI's and other 'talking-paperclip' bullshit at the expense of core improvements.  Enough to kill any incentive I may or may not have had to do anything productive toward the solution at all.

 - Almost everyone else involved can be held to fault for false advertising.

---

Since I took the day off and spent most of it on bitcointalk I did run across Maxwell's critique of Mikes article on the tech board.  It's worth a skim and should be active on that board and not terribly difficult to find for anyone who is interested.

[lunarboy]

 That is, steer the herd to a mentality that Bitcoin is a drop-in replacement for every exchange currency and super secure and convenient and generally a panacea which will elevate all human problems.  
---

you make it sound like convincing the whole world of something is easy   if that were the case we'd all be doing it already.

 Why limit the possibilities and use cases of the protocol?

Since I took the day off and spent most of it on bitcointalk I did run across Maxwell's critique of Mikes article on the tech board.  It's worth a skim and should be active on that board and not terribly difficult to find for anyone who is interested.

i'll have a read

[sickpig]

can one of you tech guys comment on Peter Todds claim that there was an entire book embedded in the BC a month ago?  how is it done?

https://www.reddit.com/r/Bitcoin/comments/34uu02/why_increasing_the_max_block_size_is_urgent_gavin/cqystoo?context=3

As Odalv already said tx size can be really big. If you go over the 100KB a transaction
is considered non-standard though, see: https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L603-L611
and  https://github.com/bitcoin/bitcoin/blob/master/src/main.h#L55-L56

Code:

    // Extremely large transactions with lots of inputs can cost the network
    // almost as much to process as they cost the sender in fees, because
    // computing signature hashes is O(ninputs*txsize). Limiting transactions
    // to MAX_STANDARD_TX_SIZE mitigates CPU exhaustion attacks.
    unsigned int sz = tx.GetSerializeSize(SER_NETWORK, CTransaction::CURRENT_VERSION);
    if (sz >= MAX_STANDARD_TX_SIZE) {
        reason = "tx-size";
        return false;
    }

Code:

/** The maximum size for transactions we're willing to relay/mine */
static const unsigned int MAX_STANDARD_TX_SIZE = 100000;

That said as long as you find a miner/poll that accept to include your tx
in the next block you're golden.

As soon as I have time I'll look for the actual txs that Peter Todd was referring to.

[worth]

Sounds good to me.  I would like to see the fee be around the equivalent of $10 per transaction.  That is about what I set my client to pay and it's worth every penny to me.  In a busy year I may do 10 native transactions or so.  In a dry one (like 2015 so far) the number of transactions I perform drops to zero.

Trying to figure out why you would do this, even if you apparently almost never use Bitcoin. 

[jeezy]

Sounds good to me.  I would like to see the fee be around the equivalent of $10 per transaction.  That is about what I set my client to pay and it's worth every penny to me.  In a busy year I may do 10 native transactions or so.  In a dry one (like 2015 so far) the number of transactions I perform drops to zero.

Mike Hearns blogs post finally convinced me this was not such good idea.  Crash landing

What not to do

One the one hand, yes: his blog post has instilled a sense of urgency and importance in me and I'm still for the 20 MB block size increase. On the other hand a part in me (a destructive part of my personality, I guess) wants to see what would actually happen and how bad things would crash and burn... the user/media reaction and all. It'd be exciting to watch, I'm sure and we could probably scoop up many more cheap coins.

[TPTB_need_war]

Sounds good to me.  I would like to see the fee be around the equivalent of $10 per transaction.  That is about what I set my client to pay and it's worth every penny to me.  In a busy year I may do 10 native transactions or so.  In a dry one (like 2015 so far) the number of transactions I perform drops to zero.

And destroy the use value and network effects of having millions of people transacting in Bitcoin, thus destroying your investment and store-of-value too.

Kudos.  

P.S. I come back here to see if there are any serious (not useless noise) posts and the only one is from smooth. What else is new. Why he and I aren't working together is still a mystery to me.

[tvbcof]

Sounds good to me.  I would like to see the fee be around the equivalent of $10 per transaction.  That is about what I set my client to pay and it's worth every penny to me.  In a busy year I may do 10 native transactions or so.  In a dry one (like 2015 so far) the number of transactions I perform drops to zero.

Trying to figure out why you would do this, even if you apparently almost never use Bitcoin. 

I like to practice what I preach I suppose.

[tvbcof]

Sounds good to me.  I would like to see the fee be around the equivalent of $10 per transaction.  That is about what I set my client to pay and it's worth every penny to me.  In a busy year I may do 10 native transactions or so.  In a dry one (like 2015 so far) the number of transactions I perform drops to zero.

And destroy the use value and network effects of having millions of people transacting in Bitcoin, thus destroying your investment and store-of-value too.

Kudos.  

P.S. I come back here to see if there are any serious (not useless noise) posts and the only one is from smooth. What else is new. Why he and I aren't working together is still a mystery to me.

The value of the 'network effect' peaked some time time ago an it is now a distinct negative and a distinct threat to the system in my opinion.  By now everyone who can make legitimate use of the system has heard about it.  Most of the new-users are of the class who have no real chance of protecting themselves (even less than the historic dismal record that the userbase has demonstrated) and will thus induce even more nanny-systems to lend them a hand.  These are inevitably bad for Bitcoin in a variety of ways (the most common one being that they are scams and/or even worse that the mainstream banking system in multiple important ways.)

Bitcoin will not really fill it's potential until sidechains are up-and-running.  I just hope it lasts that long before it is destroyed from within.  If so something else and probably something much better will take it's place though it would probably set certain things back by a few years.  I hope(d) it would be Bitcoin since I still sit on a fair number of them and it would make my life easier.