Bitcoin Forum

Bitcoin => Bitcoin Technical Support => Topic started by: 420 on December 06, 2012, 08:47:19 PM



Title: Why was this transaction not included in a block?
Post by: 420 on December 06, 2012, 08:47:19 PM
could you tell me why this transaction is not confirmed yet

https://blockchain.info/address/1PMM8TC4NowMnMZronmLp4fEns8cYxC1v6

mt. red, ozcoin and btc guild have all solved a block since this and have not included it

Looks like no transaction fees were paid, is that the reason?


Title: Re: Transactions included in blocks
Post by: DannyHamilton on December 06, 2012, 08:55:10 PM
How come miners get to determine what transactions are included in blocks?
Because that is the purpose for having miners.  That is how bitcoin is designed.  Someone needs to perform a proof-of-work, and create blocks.  In bitcoin we call those people "miners".

For instance a pool can say not to include transactions that haven't paid a fee, is that right?
Yes that is correct.  They can use any conditions they want for determining which transactions to include.


Title: Re: Transactions included in blocks
Post by: 420 on December 06, 2012, 09:00:51 PM
How come miners get to determine what transactions are included in blocks?
Because that is the purpose for having miners.  That is how bitcoin is designed.  Someone needs to perform a proof-of-work, and create blocks.  In bitcoin we call those people "miners".

For instance a pool can say not to include transactions that haven't paid a fee, is that right?
Yes that is correct.  They can use any conditions they want for determining which transactions to include.

so if government were to spend $1 Billion to fuck the bitcoin system they could get the best miners and hardware that would only solve blocks if they included a transaction fee of a specific special number that they give and design people that they wanted to use the bitcoin system

I see that as a possible way to censorship

I assume there's always a way to check what fee's included so they could just have a specific program to determine what the fee would be and if we can't guess that program and they have banks using that program, without it being leaked they could block all bitcoin transactions they don't like for every block they're solving


Title: Re: Transactions included in blocks
Post by: jgarzik on December 06, 2012, 09:07:56 PM
so if government were to spend $1 Billion to fuck the bitcoin system they could get the best miners and hardware that would only solve blocks if they included a transaction fee of a specific special number that they give and design people that they wanted to use the bitcoin system

Sure.  But...

1) There are plenty of cheaper, easier attacks that would disrupt the bitcoin system anyway.

2) You could just as easily spend $100 million to destroy the market value of bitcoins, by manipulating the free market.

3) The community would want to continue, and so, everyone would agree on a new algorithm, rendering all that expensive hardware useless.

There are plenty of reasons why mining attacks cost far more than other, more realistic attacks.



Title: Re: Transactions included in blocks
Post by: 420 on December 06, 2012, 09:15:49 PM
Great. Okay could you tell me why this transaction is not confirmed yet

https://blockchain.info/address/1PMM8TC4NowMnMZronmLp4fEns8cYxC1v6

mt. red, ozcoin and btc guild have all solved a block since this and have not included it


Title: Re: Transactions included in blocks
Post by: DannyHamilton on December 06, 2012, 09:23:54 PM
Great. Okay could you tell me why this transaction is not confirmed yet

https://blockchain.info/address/1PMM8TC4NowMnMZronmLp4fEns8cYxC1v6

mt. red, ozcoin and btc guild have all solved a block since this and have not included it

I haven't looked at recent blocks, but it is possible that either:

  • There are enough transactions with fees to fill the blocks so your transaction, being lower priority, will have to wait until there are less transactions to confirm
  • or, the miners/pools that have solved the recent blocks only include transactions with fees

Note that the "Relayed by" column at blockchain.info doesn't necessarily indicate the miner/pool that "solved" the block.  That is just the first place that blockchain.info heard about the new block.  It is entirely possible for someone to solve a block, have that block relayed from themselves to a mining pool, then from there to another mining pool, and finally relayed to blockchain.info.  So while it may be an indication of who is likely to have solved the block, it isn't certain.


Title: Re: Why was this transaction not included in a block?
Post by: 420 on December 06, 2012, 09:26:42 PM
Okay now I'm quite confused. is there a soft maximum number of transactions included into a block?

And is my transaction even valid if it's listed on blockchain.info but has not had a confirmation yet, if it was a 'double spend' for example it wouldn't even be listed on there right?


Title: Re: Transactions included in blocks
Post by: DannyHamilton on December 06, 2012, 09:27:22 PM
so if government were to spend $1 Billion to fuck the bitcoin system they could get the best miners and hardware that would only solve blocks . . .
Yep, that is how it works.  If a government were to decide to spend enough money to get more then 50% of all the hashing power in the entire bitcoin network, then they would be the ONLY miner to solve any blocks any more, and they could pick and choose which transactions to include.  They could even choose to mine ONLY empty blocks, refusing to include ANY transactions from the network and all and in doing so completely shut down all bitcoin transaction processing for so long as they continue to run their equipment and maintain more than 50% of the hashing power of the entire network.


Title: Re: Why was this transaction not included in a block?
Post by: DannyHamilton on December 06, 2012, 09:31:53 PM
Okay now I'm quite confused. is there a soft maximum number of transactions included into a block?

And is my transaction even valid if it's listed on blockchain.info but has not had a confirmation yet, if it was a 'double spend' for example it wouldn't even be listed on there right?
Unless it is a transaction for a significantly large amount of bitcoin, a double spend is unlikely (though not impossible).  If I'm wrong, hopefully someone will correct me, but from what I've heard, I believe it is possible (though VERY unlikely) for an unconfirmed transaction to show up on blockchain.info and still be a double spend attempt.  I think it's even possible (though extremely unlikely) for a transaction to be in a block with 1 confirmation and still turn out to be rolled back as a double spend.


Title: Re: Why was this transaction not included in a block?
Post by: 420 on December 06, 2012, 09:43:59 PM
Okay now I'm quite confused. is there a soft maximum number of transactions included into a block?

And is my transaction even valid if it's listed on blockchain.info but has not had a confirmation yet, if it was a 'double spend' for example it wouldn't even be listed on there right?
Unless it is a transaction for a significantly large amount of bitcoin, a double spend is unlikely (though not impossible).  If I'm wrong, hopefully someone will correct me, but from what I've heard, I believe it is possible (though VERY unlikely) for an unconfirmed transaction to show up on blockchain.info and still be a double spend attempt.  I think it's even possible (though extremely unlikely) for a transaction to be in a block with 1 confirmation and still turn out to be rolled back as a double spend.

wow, never heard of one getting a confirmation and being a double spend. then no wonder exchanges wait for 6 confirmations

that doesn't make sense unless a powerful miner was solving the block and trying to doublespend at the same time


Title: Re: Why was this transaction not included in a block?
Post by: DannyHamilton on December 06, 2012, 09:46:24 PM
Okay now I'm quite confused. is there a soft maximum number of transactions included into a block? . . .

The last I heard the blocksize limit was 1 megabyte.  From what I heard, this should be large enough for approximately 2,400 average sized transactions.


Title: Re: Why was this transaction not included in a block?
Post by: DannyHamilton on December 06, 2012, 09:54:24 PM
. . . And is my transaction even valid if it's listed on blockchain.info but has not had a confirmation yet, if it was a 'double spend' for example it wouldn't even be listed on there right?
. . . I think it's even possible (though extremely unlikely) for a transaction to be in a block with 1 confirmation and still turn out to be rolled back as a double spend.

wow, never heard of one getting a confirmation and being a double spend. then no wonder exchanges wait for 6 confirmations

that doesn't make sense unless a powerful miner was solving the block and trying to doublespend at the same time

That is one way for it to occur. Like I said, it is extremely unlikely, but if 2 miners each relay a block at approximately the same time, and one miner includes the transaction while another doesn't, then the miner who solves the next block will determine which of the 2 relayed blocks is the legitimate one.  If that miner solving the next block chooses the block that doesn't have the original transaction and instead includes a double spent output in a different transaction, then the first block that had the original transaction vanishes from the current blockchain and the double spent transaction becomes the legitimate one.


Title: Re: Why was this transaction not included in a block?
Post by: DannyHamilton on December 06, 2012, 09:58:21 PM
I'm always surprised when I come across someone who has been active enough on bitcointalk.org to have over 1,000 posts, and yet has somehow managed to avoid learning the basics of how bitcoin works.


Title: Re: Why was this transaction not included in a block?
Post by: MoonShadow on December 06, 2012, 10:10:58 PM
Okay now I'm quite confused. is there a soft maximum number of transactions included into a block?


There is currently a hard data size limit for a block at one MB, and a soft data size limit for all transactions that do not pay the minimum fee of roughly 10% of that, or about 100KB.  Since the average transaction is about 1.5 KB, it'd only take about 70 free and low fee transactions to hit that soft limit.  Eventually, though, such transactions do make it in.

Quote

And is my transaction even valid if it's listed on blockchain.info but has not had a confirmation yet, if it was a 'double spend' for example it wouldn't even be listed on there right?

Blockchain.info can't really know if your transaction is part of a double spend attempt or not, because such conflicts are sovled by a race of sorts.  When a transaction is broadcast to the network, it is received, checked for validity, and forwarded to all that node's peers.  If any node has already seen a transaction that spends particular inputs, any other transaction that it sees afterwards that attempt to spend those same inputs will be invalid, and will not be forwarded.  So what happens is the two competing transactions will move across the p2p network trying to capture as much of the network as possible before they meet at a front.  Once a block is solved, whichever of the two transactions that particular node saw first will be included, and the other becomes forever invalid.  Once that block is accepted by the part of the network that saw the losing transaction first, the losing transaction is droped from their transaction queues altogether.  So under such conditions, the transaction that hits the p2p network first has the advantage.  Right now, the edge to edge propogatin time for the entire network is only about 10 seconds, so it's a very small window of opprotunity.


Title: Re: Why was this transaction not included in a block?
Post by: MoonShadow on December 06, 2012, 10:13:42 PM
Looks like it was included in a block.


Title: Re: Why was this transaction not included in a block?
Post by: DannyHamilton on December 06, 2012, 10:27:48 PM
Looks like it was included in a block.
Yep, looks like it only took about 45 minutes or so.


Title: Re: Why was this transaction not included in a block?
Post by: 420 on December 06, 2012, 11:33:00 PM
now all a sudden it shows 8 confirmations, does it speed it up after 1st confirmation? people are more likely to include it then or what? or that is all it takes to get the ball rolling

or did blockchain have an error it didn't show me it was confirmed when it was


Title: Re: Why was this transaction not included in a block?
Post by: DeathAndTaxes on December 06, 2012, 11:35:00 PM
It is only included in 1 block.  The 2nd and 3rd ... and 8th confirmation simply mean more blocks have been found AFTER the block containing your tx.  Your tx, its fee (or lack of fee) has absolutely no effect on the 2nd confirmation onward. 

The fact that it got 8 confirmations "quickly" simply means 7 more blocks were found "quickly" after the block containing your tx.


Title: Re: Why was this transaction not included in a block?
Post by: 420 on December 07, 2012, 02:02:05 AM
It is only included in 1 block.  The 2nd and 3rd ... and 8th confirmation simply mean more blocks have been found AFTER the block containing your tx.  Your tx, its fee (or lack of fee) has absolutely no effect on the 2nd confirmation onward. 

The fact that it got 8 confirmations "quickly" simply means 7 more blocks were found "quickly" after the block containing your tx.

So then is it wrong someone said it's possible a double spend could get 1 confirmation?


Title: Re: Why was this transaction not included in a block?
Post by: Anon136 on December 07, 2012, 02:14:23 AM
Okay now I'm quite confused. is there a soft maximum number of transactions included into a block? . . .

The last I heard the blocksize limit was 1 megabyte.  From what I heard, this should be large enough for approximately 2,400 average sized transactions.

so what happens if bitcoin becomes so popular that 100 or 1000 or 100,000 times as many transactions as we see now begin to take place in a given amount of time? would the devs just have to change that cap from 1 mb to something larger? or is the system capable of self adjusting?


Title: Re: Why was this transaction not included in a block?
Post by: jgarzik on December 07, 2012, 02:33:14 AM
so what happens if bitcoin becomes so popular that 100 or 1000 or 100,000 times as many transactions as we see now begin to take place in a given amount of time? would the devs just have to change that cap from 1 mb to something larger? or is the system capable of self adjusting?

It is economically self-adjusting.



Title: Re: Why was this transaction not included in a block?
Post by: DannyHamilton on December 07, 2012, 04:37:29 AM
Okay now I'm quite confused. is there a soft maximum number of transactions included into a block? . . .
. . . the blocksize limit is 1 megabyte . . .
so what happens if bitcoin becomes so popular that 100 or 1000 or 100,000 times as many transactions as we see now begin to take place in a given amount of time? would the devs just have to change that cap from 1 mb to something larger? or is the system capable of self adjusting?

Yes, the block size could be increased, but if I understand it correctly it would require everyone using bitcoin to agree and upgrade their miners/clients otherwise the blockchain would fork and we'd have 2 competing incompatible versions of bitcoin.  The blocksize is not self adjusting, but as the number of transactions increases we'll find that larger fees are required to get a transaction into a block.  As larger fees are needed, people will become less willing to use bitcoin, reducing the number of transactions until an equilibrium is reached.


Title: Re: Transactions included in blocks
Post by: cunicula on December 07, 2012, 04:42:26 AM
so if government were to spend $1 Billion to fuck the bitcoin system they could get the best miners and hardware that would only solve blocks if they included a transaction fee of a specific special number that they give and design people that they wanted to use the bitcoin system

Sure.  But...

1) There are plenty of cheaper, easier attacks that would disrupt the bitcoin system anyway.

2) You could just as easily spend $100 million to destroy the market value of bitcoins, by manipulating the free market.

3) The community would want to continue, and so, everyone would agree on a new algorithm, rendering all that expensive hardware useless.

There are plenty of reasons why mining attacks cost far more than other, more realistic attacks.


$1 million is a more realistic estimate of gov't costs than $1 billion.

As usual, jgarzik claims that disruptive attacks which cause the attacker to lose money are more realistic than regulatory attacks that cause the attacker to gain money.
Of course, this makes no sense, but apparently the dev community wants to reinforce this misunderstanding.


Title: Re: Why was this transaction not included in a block?
Post by: 420 on December 07, 2012, 06:51:29 AM
Okay now we're messed.

Would a more logical answer be that if major crisis like that happens (transactions not included in blocks without large exorbitant fees) there would be developed a new digital currency based off original Bitcoin but with this problem inherently solved already?

That could be the case if everyone using Bitcoin could not cooperate in changing the code at once...oh boy

EDIT:
or maybe just as easily that software could be built ON TOP of bitcoin...


Title: Re: Why was this transaction not included in a block?
Post by: cunicula on December 07, 2012, 09:53:10 AM
Okay now we're messed.

Would a more logical answer be that if major crisis like that happens (transactions not included in blocks without large exorbitant fees) there would be developed a new digital currency based off original Bitcoin but with this problem inherently solved already?

That could be the case if everyone using Bitcoin could not cooperate in changing the code at once...oh boy

EDIT:
or maybe just as easily that software could be built ON TOP of bitcoin...

I have a design for a proof-of-stake algorithm that generates consensus without proof-of-work and without time stamping. I need to find developers who are interested in implementing such a project.
I don't think you can build anything on top of bitcoin.


Title: Re: Why was this transaction not included in a block?
Post by: DannyHamilton on December 07, 2012, 12:33:46 PM
Okay now we're messed.

Would a more logical answer be that if major crisis like that happens (transactions not included in blocks without large exorbitant fees) there would be developed a new digital currency based off original Bitcoin but with this problem inherently solved already?

That could be the case if everyone using Bitcoin could not cooperate in changing the code at once...oh boy

EDIT:
or maybe just as easily that software could be built ON TOP of bitcoin...
Well, the new code could be written such that it requires 1 MB blocks until a particular block is found in the future (the 262,500the block for example) and from then on requires some larger fixed size.  This would give people time to upgrade without having to worry about trying to get everyone to upgrade at the same moment.  As long as you got a significant majority of the users upgraded before the target block was found, you wouldn't have much of a fork in the blockchain.  The few stragglers would have a large incentive to upgrade quickly once the switchover occurred since they would be unable to receive bitcoins from the majority of users.

Note that in this scenario even without upgrading the stragglers should still theoretically be able to send their bitcoins to people running the upgraded system, they just couldn't receive any bitcoins that were newer than the target switchover block, and would stop seeing confirmations.

I'm curious though who will get to decide that the fees are getting too large, and how will they convince the miners who are making a lot of money off those fees to upgrade to a new system that may reduce their income?


Title: Re: Why was this transaction not included in a block?
Post by: Anon136 on December 07, 2012, 01:53:46 PM
Okay now I'm quite confused. is there a soft maximum number of transactions included into a block? . . .
. . . the blocksize limit is 1 megabyte . . .
so what happens if bitcoin becomes so popular that 100 or 1000 or 100,000 times as many transactions as we see now begin to take place in a given amount of time? would the devs just have to change that cap from 1 mb to something larger? or is the system capable of self adjusting?
As larger fees are needed, people will become less willing to use bitcoin, reducing the number of transactions until an equilibrium is reached.

yea i already figured that one out myself from what i understand about economics but this is not a very good solution once it moves beyond cleaning up the dust problem.


Title: Re: Why was this transaction not included in a block?
Post by: cunicula on December 07, 2012, 01:58:23 PM
yea i already figured that one out myself from what i understand about economics but this is not a very good solution once it moves beyond cleaning up the dust problem.

You are correct. This is a ridiculously bad solution. It could lead to ass-raping fees that dwarf paypal. However, that's the plan. Proof of stake solves the problem completely, but that's off the table for BitPal.


Title: Re: Why was this transaction not included in a block?
Post by: Anon136 on December 07, 2012, 02:22:37 PM
Okay now we're messed.

Would a more logical answer be that if major crisis like that happens (transactions not included in blocks without large exorbitant fees) there would be developed a new digital currency based off original Bitcoin but with this problem inherently solved already?

That could be the case if everyone using Bitcoin could not cooperate in changing the code at once...oh boy

EDIT:
or maybe just as easily that software could be built ON TOP of bitcoin...

i dont think its correct to say "everyone would need to change at once". As soon as someone created an alternate client where this problem (assuming it is a problem) had been solved or mitigated the blockchain would split. Anyone who did nothing and maintained their coins in both blockchains would be unaffected no matter which of the two won the battle that was about to ensue. Some people would sit idally by and do nothing, however some people would exchange the coins from one blockchain into the other in the hopes of profiting. These people would be the ones who decided which of the two forks would "be bitcoin". Which ever side attracted more capital in the end would "become bitcoin". Those who bet correctly would win at the expense of those who bet incorrectly. It is also possible that people would really be divided on whether the change was a good idea, if this was the case than the two blockchains would co-exist the way bitcoin and litecoin do now.

(this all assumes that the guy who said this problem wasnt self adjusting was correct i did get two different contradicting responses)


Title: Re: Why was this transaction not included in a block?
Post by: DannyHamilton on December 07, 2012, 03:06:55 PM
(this all assumes that the guy who said this problem wasnt self adjusting was correct i did get two different contradicting responses)

I believe that when jgarzik said:

It is economically self-adjusting.

He was saying the same thing that I was.  "Economically" self adjusting in that there would eventually be an equilibrium between the fees that people would be willing to pay and the number of transactions in a block.


Title: Re: Why was this transaction not included in a block?
Post by: cunicula on December 07, 2012, 03:32:12 PM
(this all assumes that the guy who said this problem wasnt self adjusting was correct i did get two different contradicting responses)

I believe that when jgarzik said:

It is economically self-adjusting.

He was saying the same thing that I was.  "Economically" self adjusting in that there would eventually be an equilibrium between the fees that people would be willing to pay and the number of transactions in a block.

Listen, this is not rocket science. Sure, there could be a positive equilibrium fee. But the equilibrium is chosen based on throwing darts and it is quite likely to produce a shit turd equilibrium. Worse yet, because of the rigidity involved in making any change to the rules, we could end up mired in shit turds for the indefinite future. The moniker Buttcoin could prove quite apt.

Q_D(p)=a-bp               Txn demanded per block (Q_D) is a function of p, the price per txn. I'm assuming it is linear here just for simplicity.
Q_S=min{a,4000)}

4000 is just the number of txns that can fit with the current  block size limit. If a<4000, then the fee is approximately 0. This is the current equilibrium with 0 or minimal fees.

If a>4000, then there will be equilibrium fees. You can just set Q_D=Q_S and solve the equation to get equilibrium fees.

4000=a-bp
p*=(a-4000)/b

That is the fee with a block size limit. It goes up as demand increases (a). It will go down if substitutes for bitcoin are developed (this would increase b).

Consider the monopoly situation, where the monopoly picks block size. In this case, the monopoly maximizes total feel revenue (ignoring costs because those are hard to predict right now). That is p*q, or ap-bp^2. The solution is just given by a=2bp, or p=a/2b

If a/2b<(a-4000)/b, then the monopoly (like Paypal), leads to lower fees than the current plan. Rearranging. This is
a>8000

Essentially this says that if people demand more than 2 MB blocks at a txn fee of 0, then monopoly leads to lower fees than a block size cap of 1 MB.

The whole example is ad hoc because I assumed a linear demand curve. Nevertheless, the example illustrates what utter and complete garbage a block size cap is. Usually we try to do better than monopoly. Here it seems quite plausible, even likely, that we will do worse on all counts.

There are many other solutions which make more sense. Many of these alternatives are also bad and arbitrary. However, the solution at hand is really fucking extraordinarily bad and really fucking extraordinarily arbitrary. It can simultaneously fail on both security grounds and txns cost grounds. If the cap results in a functional outcome, you can thank dumb luck because I'm sure as hell that no thought process went into this.

In short, the current plan is utter and complete fail. Anyone who says otherwise is completely full of shit and cannot be competent to make this type of decision (i.e. if they were competent, they never would have suggested anything remotely as stupid as this.). The developers know this is utter and complete shit. They suggest otherwise when speaking in public to avoid damage to confidence.

Of course, if they wanted to solve the problem, they would say: "Hey we have a problem, does anyone have any ideas?"



Title: Re: Why was this transaction not included in a block?
Post by: Anon136 on December 07, 2012, 04:03:36 PM
(this all assumes that the guy who said this problem wasnt self adjusting was correct i did get two different contradicting responses)

I believe that when jgarzik said:

It is economically self-adjusting.

He was saying the same thing that I was.  "Economically" self adjusting in that there would eventually be an equilibrium between the fees that people would be willing to pay and the number of transactions in a block.

Listen, this is not rocket science. Sure, there could be a positive equilibrium fee. But the equilibrium is chosen based on throwing darts and it is quite likely to produce a shit turd equilibrium. Worse yet, because of the rigidity involved in making any change to the rules, we could end up mired in shit turds for the indefinite future. The moniker Buttcoin could prove quite apt.


So if there was no limit and the blocks were no longer rewarding miners, the market should arrive at a natural equilibrium that is a tranaction fee which is just enough to incentivize miners to include your transaction in the block. this same minimum transaction fee should prevent the government or large corporations from using micro transactions to bloat the blockchain. It seems like satoshi should have coded maximum block size to double at the same time as block reward halving.


Title: Re: Why was this transaction not included in a block?
Post by: cunicula on December 07, 2012, 04:07:47 PM
(this all assumes that the guy who said this problem wasnt self adjusting was correct i did get two different contradicting responses)

I believe that when jgarzik said:

It is economically self-adjusting.

He was saying the same thing that I was.  "Economically" self adjusting in that there would eventually be an equilibrium between the fees that people would be willing to pay and the number of transactions in a block.

Listen, this is not rocket science. Sure, there could be a positive equilibrium fee. But the equilibrium is chosen based on throwing darts and it is quite likely to produce a shit turd equilibrium. Worse yet, because of the rigidity involved in making any change to the rules, we could end up mired in shit turds for the indefinite future. The moniker Buttcoin could prove quite apt.


So if there was no limit and the blocks were no longer rewarding miners, the market should arrive at a natural equilibrium that is a tranaction fee which is just enough to incentivize miners to include your transaction in the block. this same minimum transaction fee should prevent the government or large corporations from using micro transactions to bloat the blockchain. It seems like satoshi should have coded maximum block size to double at the same time as block reward halving.

No, if there was no limit, the market would arrive at a txn fee of approximately zero (just enough to verify the ECSDA signature and transmit the block to peers). (To see this, set the limit to an arbitrarily large number in the previous example. The txn fee will be negative, but that is not feasible so it will stop decreasing when it hits 0.)

This could actually manages to do worse then the current plan and much worse than monopoly. The outcome assures that the blockchain open for rape by any common vandal. At least the other plan has a chance of succeeding due to dumb luck.

Surprisingly, this is actually another one of the developers' plans. Support the blockchain using 'donations'. LOL! You can start by donating to miners today! I'm sure this will top everyone's list of charitable causes.

The only realistic way to get an acceptable solution to a problem like this is through voting. Probably coin-owners should suggest a fee. And the fee proposed by the median coin should be selected. They could also vote on a block size limit. As far as economics is concerned the two are equivalent. In the blockchain, you could probably instrument this by including votes in each txn and weighting them by output. Probably a vote to move the current fee up by 0.1% or down by 0.1% is sufficient. i.e. this is just one byte of extra info per txn. You could even encode it in a pre-existing piece of information, like include 5 satoshis in the fee to vote up, 6 satoshis in the fee to vote down, and anything else to abstain.  

Algorithmic solutions are hopelessly complicated and error prone. I'm an economist and do this kind of stuff for a living. I wouldn't trust an economist to design an algorithm to do this and not fuck up; let alone a computer scientist. The only reasonable thing an algorithm could target without a reasonable chance of seriously fucking up is the monopoly solution (total fee revenue maximization). I would say this is a second best option to actual voting.

Finally, recall that proof-of-stake solves this problem entirely without meaningful fees. There would still be a fee to vote on, but you could vote for an extremely small fee just sufficient to deter spam.


Title: Re: Why was this transaction not included in a block?
Post by: Anon136 on December 07, 2012, 04:33:33 PM
(this all assumes that the guy who said this problem wasnt self adjusting was correct i did get two different contradicting responses)

I believe that when jgarzik said:

It is economically self-adjusting.

He was saying the same thing that I was.  "Economically" self adjusting in that there would eventually be an equilibrium between the fees that people would be willing to pay and the number of transactions in a block.

Listen, this is not rocket science. Sure, there could be a positive equilibrium fee. But the equilibrium is chosen based on throwing darts and it is quite likely to produce a shit turd equilibrium. Worse yet, because of the rigidity involved in making any change to the rules, we could end up mired in shit turds for the indefinite future. The moniker Buttcoin could prove quite apt.


So if there was no limit and the blocks were no longer rewarding miners, the market should arrive at a natural equilibrium that is a tranaction fee which is just enough to incentivize miners to include your transaction in the block. this same minimum transaction fee should prevent the government or large corporations from using micro transactions to bloat the blockchain. It seems like satoshi should have coded maximum block size to double at the same time as block reward halving.

No, if there was no limit, the market would arrive at a txn fee of approximately zero (just enough to verify the ECSDA signature and transmit the block to peers). (To see this, set the limit to an arbitrarily large number in the previous example. The txn fee will be negative, but that is not feasible so it will stop decreasing when it hits 0.)

This could actually manages to do worse then the current plan and much worse than monopoly. The outcome assures that the blockchain open for rape by any common vandal. At least the other plan has a chance of succeeding due to dumb luck.

Surprisingly, this is actually another one of the developers' plans. Support the blockchain using 'donations'. LOL! You can start by donating to miners today! I'm sure this will top everyone's list of charitable causes.

The only realistic way to get an acceptable solution to a problem like this is through voting. Probably coin-owners should suggest a fee. And the fee proposed by the median coin should be selected. They could also vote on a block size limit. As far as economics is concerned the two are equivalent. In the blockchain, you could probably instrument this by including votes in each txn and weighting them by output. Probably a vote to move the current fee up by 0.1% or down by 0.1% is sufficient. i.e. this is just one byte of extra info per txn. You could even encode it in a pre-existing piece of information, like include 5 satoshis in the fee to vote up, 6 satoshis in the fee to vote down, and anything else to abstain.  

Algorithmic solutions are hopelessly complicated and error prone. I'm an economist and do this kind of stuff for a living. I wouldn't trust an economist to design an algorithm to do this and not fuck up; let alone a computer scientist. The only reasonable thing an algorithm could target without a reasonable chance of seriously fucking up is the monopoly solution (total fee revenue maximization). I would say this is a second best option to actual voting.

Finally, recall that proof-of-stake solves this problem entirely without meaningful fees. There would still be a fee to vote on, but you could vote for an extremely small fee just sufficient to deter spam.

yea i failed to take into account the fact that the same person who was writing bogus transactions could also attempt to mine the blocks to write them into. The least bad option definitely seems to be leaving it up to the devs and community to work to gather to adjust it manually from time to time.


Title: Re: Why was this transaction not included in a block?
Post by: cunicula on December 07, 2012, 04:53:04 PM
(this all assumes that the guy who said this problem wasnt self adjusting was correct i did get two different contradicting responses)

I believe that when jgarzik said:

It is economically self-adjusting.

He was saying the same thing that I was.  "Economically" self adjusting in that there would eventually be an equilibrium between the fees that people would be willing to pay and the number of transactions in a block.

Listen, this is not rocket science. Sure, there could be a positive equilibrium fee. But the equilibrium is chosen based on throwing darts and it is quite likely to produce a shit turd equilibrium. Worse yet, because of the rigidity involved in making any change to the rules, we could end up mired in shit turds for the indefinite future. The moniker Buttcoin could prove quite apt.


So if there was no limit and the blocks were no longer rewarding miners, the market should arrive at a natural equilibrium that is a tranaction fee which is just enough to incentivize miners to include your transaction in the block. this same minimum transaction fee should prevent the government or large corporations from using micro transactions to bloat the blockchain. It seems like satoshi should have coded maximum block size to double at the same time as block reward halving.

No, if there was no limit, the market would arrive at a txn fee of approximately zero (just enough to verify the ECSDA signature and transmit the block to peers). (To see this, set the limit to an arbitrarily large number in the previous example. The txn fee will be negative, but that is not feasible so it will stop decreasing when it hits 0.)

This could actually manages to do worse then the current plan and much worse than monopoly. The outcome assures that the blockchain open for rape by any common vandal. At least the other plan has a chance of succeeding due to dumb luck.

Surprisingly, this is actually another one of the developers' plans. Support the blockchain using 'donations'. LOL! You can start by donating to miners today! I'm sure this will top everyone's list of charitable causes.

The only realistic way to get an acceptable solution to a problem like this is through voting. Probably coin-owners should suggest a fee. And the fee proposed by the median coin should be selected. They could also vote on a block size limit. As far as economics is concerned the two are equivalent. In the blockchain, you could probably instrument this by including votes in each txn and weighting them by output. Probably a vote to move the current fee up by 0.1% or down by 0.1% is sufficient. i.e. this is just one byte of extra info per txn. You could even encode it in a pre-existing piece of information, like include 5 satoshis in the fee to vote up, 6 satoshis in the fee to vote down, and anything else to abstain.  

Algorithmic solutions are hopelessly complicated and error prone. I'm an economist and do this kind of stuff for a living. I wouldn't trust an economist to design an algorithm to do this and not fuck up; let alone a computer scientist. The only reasonable thing an algorithm could target without a reasonable chance of seriously fucking up is the monopoly solution (total fee revenue maximization). I would say this is a second best option to actual voting.

Finally, recall that proof-of-stake solves this problem entirely without meaningful fees. There would still be a fee to vote on, but you could vote for an extremely small fee just sufficient to deter spam.

yea i failed to take into account the fact that the same person who was writing bogus transactions could also attempt to mine the blocks to write them into. The least bad option definitely seems to be leaving it up to the devs and community to work to gather to adjust it manually from time to time.

Sigh. We have reviewed why the devs ideas are lacking. Your conclusion is that the problem is best left up to the devs to solve. Sigh.



Title: Re: Why was this transaction not included in a block?
Post by: Anon136 on December 07, 2012, 05:02:59 PM
(this all assumes that the guy who said this problem wasnt self adjusting was correct i did get two different contradicting responses)

I believe that when jgarzik said:

It is economically self-adjusting.

He was saying the same thing that I was.  "Economically" self adjusting in that there would eventually be an equilibrium between the fees that people would be willing to pay and the number of transactions in a block.

Listen, this is not rocket science. Sure, there could be a positive equilibrium fee. But the equilibrium is chosen based on throwing darts and it is quite likely to produce a shit turd equilibrium. Worse yet, because of the rigidity involved in making any change to the rules, we could end up mired in shit turds for the indefinite future. The moniker Buttcoin could prove quite apt.


So if there was no limit and the blocks were no longer rewarding miners, the market should arrive at a natural equilibrium that is a tranaction fee which is just enough to incentivize miners to include your transaction in the block. this same minimum transaction fee should prevent the government or large corporations from using micro transactions to bloat the blockchain. It seems like satoshi should have coded maximum block size to double at the same time as block reward halving.

No, if there was no limit, the market would arrive at a txn fee of approximately zero (just enough to verify the ECSDA signature and transmit the block to peers). (To see this, set the limit to an arbitrarily large number in the previous example. The txn fee will be negative, but that is not feasible so it will stop decreasing when it hits 0.)

This could actually manages to do worse then the current plan and much worse than monopoly. The outcome assures that the blockchain open for rape by any common vandal. At least the other plan has a chance of succeeding due to dumb luck.

Surprisingly, this is actually another one of the developers' plans. Support the blockchain using 'donations'. LOL! You can start by donating to miners today! I'm sure this will top everyone's list of charitable causes.

The only realistic way to get an acceptable solution to a problem like this is through voting. Probably coin-owners should suggest a fee. And the fee proposed by the median coin should be selected. They could also vote on a block size limit. As far as economics is concerned the two are equivalent. In the blockchain, you could probably instrument this by including votes in each txn and weighting them by output. Probably a vote to move the current fee up by 0.1% or down by 0.1% is sufficient. i.e. this is just one byte of extra info per txn. You could even encode it in a pre-existing piece of information, like include 5 satoshis in the fee to vote up, 6 satoshis in the fee to vote down, and anything else to abstain.  

Algorithmic solutions are hopelessly complicated and error prone. I'm an economist and do this kind of stuff for a living. I wouldn't trust an economist to design an algorithm to do this and not fuck up; let alone a computer scientist. The only reasonable thing an algorithm could target without a reasonable chance of seriously fucking up is the monopoly solution (total fee revenue maximization). I would say this is a second best option to actual voting.

Finally, recall that proof-of-stake solves this problem entirely without meaningful fees. There would still be a fee to vote on, but you could vote for an extremely small fee just sufficient to deter spam.

yea i failed to take into account the fact that the same person who was writing bogus transactions could also attempt to mine the blocks to write them into. The least bad option definitely seems to be leaving it up to the devs and community to work to gather to adjust it manually from time to time.

Sigh. We have reviewed why the devs ideas are lacking. Your conclusion is that the problem is best left up to the devs to solve. Sigh.


We wait around untill the maximum size becomes a problem, then the devs let people vote on whether or not to double the maximum size and if they get idk 80% yes than they implement it in the next release. Why would this not work? (sorry i dont claim to be an expert)


Title: Re: Why was this transaction not included in a block?
Post by: cunicula on December 07, 2012, 05:08:33 PM
(this all assumes that the guy who said this problem wasnt self adjusting was correct i did get two different contradicting responses)

I believe that when jgarzik said:

It is economically self-adjusting.

He was saying the same thing that I was.  "Economically" self adjusting in that there would eventually be an equilibrium between the fees that people would be willing to pay and the number of transactions in a block.

Listen, this is not rocket science. Sure, there could be a positive equilibrium fee. But the equilibrium is chosen based on throwing darts and it is quite likely to produce a shit turd equilibrium. Worse yet, because of the rigidity involved in making any change to the rules, we could end up mired in shit turds for the indefinite future. The moniker Buttcoin could prove quite apt.


So if there was no limit and the blocks were no longer rewarding miners, the market should arrive at a natural equilibrium that is a tranaction fee which is just enough to incentivize miners to include your transaction in the block. this same minimum transaction fee should prevent the government or large corporations from using micro transactions to bloat the blockchain. It seems like satoshi should have coded maximum block size to double at the same time as block reward halving.

No, if there was no limit, the market would arrive at a txn fee of approximately zero (just enough to verify the ECSDA signature and transmit the block to peers). (To see this, set the limit to an arbitrarily large number in the previous example. The txn fee will be negative, but that is not feasible so it will stop decreasing when it hits 0.)

This could actually manages to do worse then the current plan and much worse than monopoly. The outcome assures that the blockchain open for rape by any common vandal. At least the other plan has a chance of succeeding due to dumb luck.

Surprisingly, this is actually another one of the developers' plans. Support the blockchain using 'donations'. LOL! You can start by donating to miners today! I'm sure this will top everyone's list of charitable causes.

The only realistic way to get an acceptable solution to a problem like this is through voting. Probably coin-owners should suggest a fee. And the fee proposed by the median coin should be selected. They could also vote on a block size limit. As far as economics is concerned the two are equivalent. In the blockchain, you could probably instrument this by including votes in each txn and weighting them by output. Probably a vote to move the current fee up by 0.1% or down by 0.1% is sufficient. i.e. this is just one byte of extra info per txn. You could even encode it in a pre-existing piece of information, like include 5 satoshis in the fee to vote up, 6 satoshis in the fee to vote down, and anything else to abstain.  

Algorithmic solutions are hopelessly complicated and error prone. I'm an economist and do this kind of stuff for a living. I wouldn't trust an economist to design an algorithm to do this and not fuck up; let alone a computer scientist. The only reasonable thing an algorithm could target without a reasonable chance of seriously fucking up is the monopoly solution (total fee revenue maximization). I would say this is a second best option to actual voting.

Finally, recall that proof-of-stake solves this problem entirely without meaningful fees. There would still be a fee to vote on, but you could vote for an extremely small fee just sufficient to deter spam.

yea i failed to take into account the fact that the same person who was writing bogus transactions could also attempt to mine the blocks to write them into. The least bad option definitely seems to be leaving it up to the devs and community to work to gather to adjust it manually from time to time.

Sigh. We have reviewed why the devs ideas are lacking. Your conclusion is that the problem is best left up to the devs to solve. Sigh.


We wait around untill the maximum size becomes a problem, then the devs let people vote on whether or not to double the maximum size and if they get idk 80% yes than they implement it in the next release. Why would this not work? (sorry i dont claim to be an expert)

Sorry. I'm a little abrasive.

Yeah, something along the lines of what you are saying would work [provided the people who actually own coins get to vote]. I don't know why they aren't pursuing this. I'm just trying to promulgate sensible ideas here. My feeling is that voting will be rejected based on the claim that Satoshi's rules are inviolable. This kind of faith-based stuff makes me sick. Thus the abrasiveness.


Title: Re: Why was this transaction not included in a block?
Post by: jgarzik on December 07, 2012, 05:41:16 PM

Please note that cunicula trolls every thread in this way.  His is a minority opinion and his ignore button is colored for a very good reason.



Title: Re: Why was this transaction not included in a block?
Post by: cunicula on December 07, 2012, 06:15:25 PM

Please note that cunicula trolls every thread in this way.  His is a minority opinion and his ignore button is colored for a very good reason.



No need to come up with my own words when someone else has done it for me.

cunicula is right, the pricing is inefficient because the block size limits are arbitrary, and without a central entity controlling them it's unlikely that prices will settle at an optimal value. Actually, just read his posts again, they provide an accurate explanation of the problem.

The Bitcoin devs just had no better idea than an arbitrary limit, and since it's not an easy problem, it's hard to blame them. We can can probably deal with high future fees by introducing extra systems that use Bitcoin as backing. Thus we have limits that are only somewhat high now but probably low on the long run.



It's amazing how people just use some sort of mob-truth-finding and wander on. It seems that "Haha, I ignored you" remains the best BS-indicator.


Title: Re: Why was this transaction not included in a block?
Post by: 420 on December 07, 2012, 11:06:56 PM
I'm glad my point initiated this important discussion