* [bitcoin-dev] Block size hard fork
@ 2015-08-01 0:05 Hector Chu
2015-08-01 0:17 ` Gregory Maxwell
0 siblings, 1 reply; 3+ messages in thread
From: Hector Chu @ 2015-08-01 0:05 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 999 bytes --]
I haven't seen much discussion on this list of what will happen when the
blockchain forks due to larger blocks. I think the debate surrounding this
issue is a storm in a teacup, because transactions on the smaller chain can
and will appear on the bigger chain also. There is nothing tying
transactions to the blocks they appear in.
Miners will migrate to the bigger chain in search of higher profits due to
higher volume of fees. They can also collect the higher fees of the smaller
chain by including into the bigger chain as many as possible of the
transactions from the smaller chain.
To stop this from happening the smaller chain would somehow need to change
the serialized format of their transactions so the signatures would no
longer be valid across chains.
Incidentally I read somewhere that the losing chain would have their coins
sold down. Trying to sell the smaller chain's coins in the short term at
least is not advisable, as those transactions will appear on the bigger
chain too.
[-- Attachment #2: Type: text/html, Size: 1101 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] Block size hard fork
2015-08-01 0:05 [bitcoin-dev] Block size hard fork Hector Chu
@ 2015-08-01 0:17 ` Gregory Maxwell
2015-08-01 8:43 ` Hector Chu
0 siblings, 1 reply; 3+ messages in thread
From: Gregory Maxwell @ 2015-08-01 0:17 UTC (permalink / raw)
To: Hector Chu; +Cc: Bitcoin Dev
On Sat, Aug 1, 2015 at 12:05 AM, Hector Chu via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> There is nothing tying
> transactions to the blocks they appear in.
Transactions can be recieved or accepted in different orders by
different nodes. The purpose of the blockchain is to resolve any
potential conflicting transactions by providing a globally agreed
total ordering.
As soon as one of the forks accepts a different transaction in a
conflicting set then there will be transactions which exist on one
chain which cannot exist on the other.
One can quite easily transact in a way to intentionally produce such a
split to seperate the existance of your coins onto the seperate forks;
just as anyone would need to do to perform a reorg-and-respend attack
on a single blockchain.
Additionally, new coins will be issued, along with fees, on both
chains. These new outputs become spendable after 100 blocks, and any
transaction spending them can exist exclusively on one chain.
Also any transaction whos casual history extends from one of the above
cases can exist only on one chain. This also means that someone who
has single-chain coins (via a conflict or from coinbase outputs) can
pay small amount to many users to get their wallets to consume them
and make more of the transactions single chain only-- if they wanted
the process to happen faster.
> Miners will migrate to the bigger chain in search of higher profits due to higher volume of fees
The migration remark is a considerable oversimplification. Imagine if
I released a version of the software programmed to reassign ownership
of a million of the earliest created unmoved coins to me at block
400k, and then after that I made transaction to pay 5 coin/block in
fees. Would miners move to this chain? It pays more in fees!
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] Block size hard fork
2015-08-01 0:17 ` Gregory Maxwell
@ 2015-08-01 8:43 ` Hector Chu
0 siblings, 0 replies; 3+ messages in thread
From: Hector Chu @ 2015-08-01 8:43 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2206 bytes --]
On 1 August 2015 at 01:17, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> One can quite easily transact in a way to intentionally produce such a
> split to seperate the existance of your coins onto the seperate forks;
> just as anyone would need to do to perform a reorg-and-respend attack
> on a single blockchain.
>
Right. Why anyone would want to do this intentionally, however, is not
clear. The coins would be worth less as they wouldn't be fungible across
the chains anymore.
Additionally, new coins will be issued, along with fees, on both
> chains. These new outputs become spendable after 100 blocks, and any
> transaction spending them can exist exclusively on one chain.
>
This is something that hadn't entered my mind when I made my assertions. At
the moment I can't see any way to avoid this fact.
Also any transaction whos casual history extends from one of the above
> cases can exist only on one chain. This also means that someone who
> has single-chain coins (via a conflict or from coinbase outputs) can
> pay small amount to many users to get their wallets to consume them
> and make more of the transactions single chain only-- if they wanted
> the process to happen faster.
>
Wallets could detect this and notify the user. Due to Gresham's Law, I'll
admit the observation that these outputs would likely get spent in
preference (as they are less fungible), but whether the payee would be
happy to accept them is a different matter.
> Miners will migrate to the bigger chain in search of higher profits due
> to higher volume of fees
>
> The migration remark is a considerable oversimplification. Imagine if
> I released a version of the software programmed to reassign ownership
> of a million of the earliest created unmoved coins to me at block
> 400k, and then after that I made transaction to pay 5 coin/block in
> fees. Would miners move to this chain? It pays more in fees!
>
Well in your example they wouldn't, because they know that your version
wouldn't be accepted by the economic majority. But it's not as clear cut
for the larger blocks case. They may move over gradually as they see the
new chain gain acceptance, demonstrated by the higher trading volume on it.
[-- Attachment #2: Type: text/html, Size: 3095 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-08-01 8:44 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-01 0:05 [bitcoin-dev] Block size hard fork Hector Chu
2015-08-01 0:17 ` Gregory Maxwell
2015-08-01 8:43 ` Hector Chu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox