cypherdoc



Offline



Activity: 1764

Merit: 1002









LegendaryActivity: 1764Merit: 1002 Re: Gold collapsing. Bitcoin UP. May 15, 2015, 11:33:42 PM #24101 Quote from: rocks on May 15, 2015, 10:46:12 PM Quote from: Erdogan on May 15, 2015, 10:44:02 PM Quote from: rocks on May 15, 2015, 10:40:26 PM Quote from: cypherdoc on May 15, 2015, 10:21:03 PM Quote from: smooth on May 15, 2015, 10:13:02 PM Quote from: cypherdoc on May 15, 2015, 08:18:54 PM as Bitcoin has alot of enemies, why do you think we aren't seeing a regular stream of these types of blocks?



I'm not trying to be conspiratorial here, just factual, but there is no real gain in doing it at 1 MB. 1 MB was chosen to be a size that is fairly immune to spamming attacks. Opinions differ I guess about whether 20 MB is similarly immune.

I'm not trying to be conspiratorial here, just factual, but there is no real gain in doing it at 1 MB. 1 MB was chosen to be a size that is fairly immune to spamming attacks. Opinions differ I guess about whether 20 MB is similarly immune.

Doesn't make sense that the protocol allows non standard TX's to be accepted in block form by nodes yet at the same time they won't relay or accept them if simply propagated.

Doesn't make sense that the protocol allows non standard TX's to be accepted in block form by nodes yet at the same time they won't relay or accept them if simply propagated.

The transactions were always valid.



To make them invalid would require a hard fork. We try to avoid hard forks for obvious solutions.



So the compromise was to change bitcoind nodes to only consider certain types of transactions as "standard" and not re-transmit transactions that did not qualify as "standard", these have since been called "non-standard". Along with this change many miners decided to not include these "non-standard" transactions either (but some still do).



This did not require a fork because the base protocol, which is defined by what constitutes a valid block, did not change.



As a consequence, non-standard transactions can still be included in a block because they are valid transactions from a block verification standpoint. However to discourage them, most P2P nodes and most miners ignore them.

The transactions were always valid.To make them invalid would require a hard fork. We try to avoid hard forks for obvious solutions.So the compromise was to change bitcoind nodes to only consider certain types of transactions as "standard" and not re-transmit transactions that did not qualify as "standard", these have since been called "non-standard". Along with this change many miners decided to not include these "non-standard" transactions either (but some still do).This did not require a fork because the base protocol, which is defined by what constitutes a valid block, did not change.As a consequence, non-standard transactions can still be included in a block because they are valid transactions from a block verification standpoint. However to discourage them, most P2P nodes and most miners ignore them.

So how come they appear in the unconfirmed transaction list on blockchain.info?



So how come they appear in the unconfirmed transaction list on blockchain.info?

Because someone sent them to blockchain.info directly, or they were relayed by a node that ignores the "non-standard" agreement (not rule). blockchain.info's website is also setup to be a view of the network, they include visibility into strange and other transactions. So it would make sense they would also display information on non-standard transactions that most node's won't re-transmit.



Again they are valid transactions, it's just an informal agreement to ignore/limit them. A formal agreement requires a hard fork.

Because someone sent them to blockchain.info directly, or they were relayed by a node that ignores the "non-standard" agreement (not rule). blockchain.info's website is also setup to be a view of the network, they include visibility into strange and other transactions. So it would make sense they would also display information on non-standard transactions that most node's won't re-transmit.Again they are valid transactions, it's just an informal agreement to ignore/limit them. A formal agreement requires a hard fork.

So any code changes made to the Bitcoin Core client do not require forks which is to be distinguished from changes to the protocol which defines what is acceptable as a block and requires a fork? So any code changes made to the Bitcoin Core client do not require forks which is to be distinguished from changes to the protocol which defines what is acceptable as a block and requires a fork?

"The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime." -- Satoshi rtised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.

rocks



Offline



Activity: 1153

Merit: 1000







LegendaryActivity: 1153Merit: 1000 Re: Gold collapsing. Bitcoin UP. May 16, 2015, 12:37:05 AM #24106 Quote from: cypherdoc on May 15, 2015, 11:33:42 PM Quote from: rocks on May 15, 2015, 10:46:12 PM Quote from: Erdogan on May 15, 2015, 10:44:02 PM Quote from: rocks on May 15, 2015, 10:40:26 PM Quote from: cypherdoc on May 15, 2015, 10:21:03 PM Quote from: smooth on May 15, 2015, 10:13:02 PM Quote from: cypherdoc on May 15, 2015, 08:18:54 PM as Bitcoin has alot of enemies, why do you think we aren't seeing a regular stream of these types of blocks?



I'm not trying to be conspiratorial here, just factual, but there is no real gain in doing it at 1 MB. 1 MB was chosen to be a size that is fairly immune to spamming attacks. Opinions differ I guess about whether 20 MB is similarly immune.

I'm not trying to be conspiratorial here, just factual, but there is no real gain in doing it at 1 MB. 1 MB was chosen to be a size that is fairly immune to spamming attacks. Opinions differ I guess about whether 20 MB is similarly immune.

Doesn't make sense that the protocol allows non standard TX's to be accepted in block form by nodes yet at the same time they won't relay or accept them if simply propagated.

Doesn't make sense that the protocol allows non standard TX's to be accepted in block form by nodes yet at the same time they won't relay or accept them if simply propagated.

The transactions were always valid.



To make them invalid would require a hard fork. We try to avoid hard forks for obvious solutions.



So the compromise was to change bitcoind nodes to only consider certain types of transactions as "standard" and not re-transmit transactions that did not qualify as "standard", these have since been called "non-standard". Along with this change many miners decided to not include these "non-standard" transactions either (but some still do).



This did not require a fork because the base protocol, which is defined by what constitutes a valid block, did not change.



As a consequence, non-standard transactions can still be included in a block because they are valid transactions from a block verification standpoint. However to discourage them, most P2P nodes and most miners ignore them.

The transactions were always valid.To make them invalid would require a hard fork. We try to avoid hard forks for obvious solutions.So the compromise was to change bitcoind nodes to only consider certain types of transactions as "standard" and not re-transmit transactions that did not qualify as "standard", these have since been called "non-standard". Along with this change many miners decided to not include these "non-standard" transactions either (but some still do).This did not require a fork because the base protocol, which is defined by what constitutes a valid block, did not change.As a consequence, non-standard transactions can still be included in a block because they are valid transactions from a block verification standpoint. However to discourage them, most P2P nodes and most miners ignore them.

So how come they appear in the unconfirmed transaction list on blockchain.info?



So how come they appear in the unconfirmed transaction list on blockchain.info?

Because someone sent them to blockchain.info directly, or they were relayed by a node that ignores the "non-standard" agreement (not rule). blockchain.info's website is also setup to be a view of the network, they include visibility into strange and other transactions. So it would make sense they would also display information on non-standard transactions that most node's won't re-transmit.



Again they are valid transactions, it's just an informal agreement to ignore/limit them. A formal agreement requires a hard fork.

Because someone sent them to blockchain.info directly, or they were relayed by a node that ignores the "non-standard" agreement (not rule). blockchain.info's website is also setup to be a view of the network, they include visibility into strange and other transactions. So it would make sense they would also display information on non-standard transactions that most node's won't re-transmit.Again they are valid transactions, it's just an informal agreement to ignore/limit them. A formal agreement requires a hard fork.

So any code changes made to the Bitcoin Core client do not require forks which is to be distinguished from changes to the protocol which defines what is acceptable as a block and requires a fork?

So any code changes made to the Bitcoin Core client do not require forks which is to be distinguished from changes to the protocol which defines what is acceptable as a block and requires a fork?

I'd define it as Bitcoin is the blockchain data structure and the set of rules that govern what constitutes a valid block. If you want to change the rules that govern what is a valid block (transactions and block structure) then that is a fork. Anything else is not a fork. The reasoning is simple, these are the rules that govern if a specific chain is valid and thus govern consensus.



Nodes however can operate however they want, as long as they agree on the rules that define a valid block. If some nodes decide on a different set of rules, then they will be forced onto their own chain and lose consensus with the main chain.



Take Gavin's IBLT proposal as an example. This is a major change to bitcoind that changes how nodes communicate blocks to each other. This is not a fork simply because it does not change anything at all about what defines a valid or invalid block. Just the communication of blocks.



Take LukeJr's insertion of Ubuntu nodes that block SatoshiDice type services into the Ubuntu default client. This was not a fork because he simply made the nodes decide not to relay transactions to/from specific addresses, but these nodes still followed the same rules on what is a valid block, and so they would accept these transactions after they were confirmed in a block. (To do otherwise would be a fork and they would be kicked onto their own tiny chain). I'd define it as Bitcoin is the blockchain data structure and the set of rules that govern what constitutes a valid block. If you want to change the rules that govern what is a valid block (transactions and block structure) then that is a fork. Anything else is not a fork. The reasoning is simple, these are the rules that govern if a specific chain is valid and thus govern consensus.Nodes however can operate however they want, as long as they agree on the rules that define a valid block. If some nodes decide on a different set of rules, then they will be forced onto their own chain and lose consensus with the main chain.Take Gavin's IBLT proposal as an example. This is a major change to bitcoind that changes how nodesblocks to each other. This is not a fork simply because it does not change anything at all about what defines a valid or invalid block. Just the communication of blocks.Take LukeJr's insertion of Ubuntu nodes that block SatoshiDice type services into the Ubuntu default client. This was not a fork because he simply made the nodes decide not to relay transactions to/from specific addresses, but these nodes still followed the same rules on what is a valid block, and so they would accept these transactions after they were confirmed in a block. (To do otherwise would be a fork and they would be kicked onto their own tiny chain).

cypherdoc



Offline



Activity: 1764

Merit: 1002









LegendaryActivity: 1764Merit: 1002 Re: Gold collapsing. Bitcoin UP. May 16, 2015, 01:03:11 AM #24107 Quote from: rocks on May 16, 2015, 12:37:05 AM Quote from: cypherdoc on May 15, 2015, 11:33:42 PM Quote from: rocks on May 15, 2015, 10:46:12 PM Quote from: Erdogan on May 15, 2015, 10:44:02 PM Quote from: rocks on May 15, 2015, 10:40:26 PM Quote from: cypherdoc on May 15, 2015, 10:21:03 PM Quote from: smooth on May 15, 2015, 10:13:02 PM Quote from: cypherdoc on May 15, 2015, 08:18:54 PM as Bitcoin has alot of enemies, why do you think we aren't seeing a regular stream of these types of blocks?



I'm not trying to be conspiratorial here, just factual, but there is no real gain in doing it at 1 MB. 1 MB was chosen to be a size that is fairly immune to spamming attacks. Opinions differ I guess about whether 20 MB is similarly immune.

I'm not trying to be conspiratorial here, just factual, but there is no real gain in doing it at 1 MB. 1 MB was chosen to be a size that is fairly immune to spamming attacks. Opinions differ I guess about whether 20 MB is similarly immune.

Doesn't make sense that the protocol allows non standard TX's to be accepted in block form by nodes yet at the same time they won't relay or accept them if simply propagated.

Doesn't make sense that the protocol allows non standard TX's to be accepted in block form by nodes yet at the same time they won't relay or accept them if simply propagated.

The transactions were always valid.



To make them invalid would require a hard fork. We try to avoid hard forks for obvious solutions.



So the compromise was to change bitcoind nodes to only consider certain types of transactions as "standard" and not re-transmit transactions that did not qualify as "standard", these have since been called "non-standard". Along with this change many miners decided to not include these "non-standard" transactions either (but some still do).



This did not require a fork because the base protocol, which is defined by what constitutes a valid block, did not change.



As a consequence, non-standard transactions can still be included in a block because they are valid transactions from a block verification standpoint. However to discourage them, most P2P nodes and most miners ignore them.

The transactions were always valid.To make them invalid would require a hard fork. We try to avoid hard forks for obvious solutions.So the compromise was to change bitcoind nodes to only consider certain types of transactions as "standard" and not re-transmit transactions that did not qualify as "standard", these have since been called "non-standard". Along with this change many miners decided to not include these "non-standard" transactions either (but some still do).This did not require a fork because the base protocol, which is defined by what constitutes a valid block, did not change.As a consequence, non-standard transactions can still be included in a block because they are valid transactions from a block verification standpoint. However to discourage them, most P2P nodes and most miners ignore them.

So how come they appear in the unconfirmed transaction list on blockchain.info?



So how come they appear in the unconfirmed transaction list on blockchain.info?

Because someone sent them to blockchain.info directly, or they were relayed by a node that ignores the "non-standard" agreement (not rule). blockchain.info's website is also setup to be a view of the network, they include visibility into strange and other transactions. So it would make sense they would also display information on non-standard transactions that most node's won't re-transmit.



Again they are valid transactions, it's just an informal agreement to ignore/limit them. A formal agreement requires a hard fork.

Because someone sent them to blockchain.info directly, or they were relayed by a node that ignores the "non-standard" agreement (not rule). blockchain.info's website is also setup to be a view of the network, they include visibility into strange and other transactions. So it would make sense they would also display information on non-standard transactions that most node's won't re-transmit.Again they are valid transactions, it's just an informal agreement to ignore/limit them. A formal agreement requires a hard fork.

So any code changes made to the Bitcoin Core client do not require forks which is to be distinguished from changes to the protocol which defines what is acceptable as a block and requires a fork?

So any code changes made to the Bitcoin Core client do not require forks which is to be distinguished from changes to the protocol which defines what is acceptable as a block and requires a fork?

I'd define it as Bitcoin is the blockchain data structure and the set of rules that govern what constitutes a valid block. If you want to change the rules that govern what is a valid block (transactions and block structure) then that is a fork. Anything else is not a fork. The reasoning is simple, these are the rules that govern if a specific chain is valid and thus govern consensus.



Nodes however can operate however they want, as long as they agree on the rules that define a valid block. If some nodes decide on a different set of rules, then they will be forced onto their own chain and lose consensus with the main chain.



Take Gavin's IBLT proposal as an example. This is a major change to bitcoind that changes how nodes communicate blocks to each other. This is not a fork simply because it does not change anything at all about what defines a valid or invalid block. Just the communication of blocks.



Take LukeJr's insertion of Ubuntu nodes that block SatoshiDice type services into the Ubuntu default client. This was not a fork because he simply made the nodes decide not to relay transactions to/from specific addresses, but these nodes still followed the same rules on what is a valid block, and so they would accept these transactions after they were confirmed in a block. (To do otherwise would be a fork and they would be kicked onto their own tiny chain).

I'd define it as Bitcoin is the blockchain data structure and the set of rules that govern what constitutes a valid block. If you want to change the rules that govern what is a valid block (transactions and block structure) then that is a fork. Anything else is not a fork. The reasoning is simple, these are the rules that govern if a specific chain is valid and thus govern consensus.Nodes however can operate however they want, as long as they agree on the rules that define a valid block. If some nodes decide on a different set of rules, then they will be forced onto their own chain and lose consensus with the main chain.Take Gavin's IBLT proposal as an example. This is a major change to bitcoind that changes how nodesblocks to each other. This is not a fork simply because it does not change anything at all about what defines a valid or invalid block. Just the communication of blocks.Take LukeJr's insertion of Ubuntu nodes that block SatoshiDice type services into the Ubuntu default client. This was not a fork because he simply made the nodes decide not to relay transactions to/from specific addresses, but these nodes still followed the same rules on what is a valid block, and so they would accept these transactions after they were confirmed in a block. (To do otherwise would be a fork and they would be kicked onto their own tiny chain).

and your definition of a hard vs soft fork? and your definition of a hard vs soft fork?

Rizla2345



Offline



Activity: 238

Merit: 100







Full MemberActivity: 238Merit: 100 Re: Gold collapsing. Bitcoin UP. May 16, 2015, 01:05:38 AM #24108 The stock market seems ripe for a major collapse. Is gold likely to rocket? And bitcoin? Also the dollar has been sagging quite a bit lately. That should help gold but what about BTC?

solex



Offline



Activity: 1078

Merit: 1000





100 satoshis -> ISO code







LegendaryActivity: 1078Merit: 1000100 satoshis -> ISO code Re: Gold collapsing. Bitcoin UP. May 16, 2015, 04:00:12 AM

Last edit: May 17, 2015, 06:26:38 AM by solex #24110 Compromise solution: up to 500 tps on-chain while keeping the 1MB limit, however, a hard-fork is still needed.



This is an idea which I have been mulling over since Gavin came up with IBLT, but have not expounded because, until recently I did not realise the depth of support within Core dev for maintaining the 1MB. If dev are not able to compromise on a can-kick, e.g. 20MB, or an adaptive limit which leverages the demand for larger blocks with pressure to keep a cleaner UTXO set / better fees market, then there is an alternative. Also, Pieter's "headers-first" change which went live in version 0.10 makes this alternative safer on resync.



A "third way": Decoupling the size limit check on blocks from new block messages.



Today, the 1MB size limit is bluntly used to check any block which a node sees. It does not matter whether the block being checked is 2 years old and just read from disk, or whether it is a new block announcement to a fully-synced node. The principle here is that the 1MB check would be retained for new block announcement messages, but not when processing old blocks, or applied after a new block is constructed from an announcement message.



A hard-fork is still required, as the window is then opened for blocks to be accepted which are >1MB on disk, and to support compression/decompression of new blocks. All nodes will need to be able to decode blocks which might be compressed by different methods.



Notes:



Bandwidth usage for new blocks is kept to 1MB per 10 minutes. People can continue to mine via TOR.



More than one type of compression would then be supported, e.g. IBLT and transaction hash lists, so miners have a choice of which to use. IBLT could be used on top of hash lists which gives even greater compression. CPU overhead is a consideration.



The network can already handle a much higher tps of real-time unconfirmed tx so block propagation methods which rely on the initial publication of tx are encouraged.

e.g. IBLT usage is incentivized for miners wanting to construct blocks larger than 1MB. This also reduces blockchain spam as miners cannot stuff new blocks >1MB with secret transactions. This reduces the rate of increase in UTXO relative to average block size increase.



Fees on a 20MB disk block would approximate the 6.25 reward in 5 years time. This happy state could be reached while retaining the 1MB limit on new block messages.



Resync would still require sending blocks >1MB, however this is not on the critical path for the whole network, just one node.



Current status:



Wladimir has indicated that he wants to close off version 0.11 soon.

If nothing is done about the 1MB in version 0.11 then one of the last chances is wasted for achieving a smooth transition to larger tx volumes without a period of serious confirmation delays, (user unhappiness, bad publicity, price hit, harm to the network effect).



I suggest that if no compromise is possible in dev on the 1MB then at the very least version 0.11 should prepare the way for block compression, and provide an incentive for it to be used, incorporating software to decode an IBLT, and be able to use transaction hashes like the block relay service. This might take a number of weeks/months, but far less time than waiting for Lightning Networks, tree-chains, or other off-chain scaling solutions.



IMHO, the safest hard fork uses both a block version transition PLUS a 30 or 60 day grace period. i.e. after the 75% target is reached, a delay occurs before the change becomes effective. This achieves mining consensus and also allows non-mining nodes and laggard miners more time to upgrade.



Have at it!

P2Pool decentralized mining at 1KxvX5Hx8nh36ig2gT5bpeEcqLQcwJsZGB

rocks: Changing the supply limit fundamentally destroys bitcoin, but increasing the blocksize limit is absolutely needed to make it successful. Please help fund projects to advance Bitcoin:at 1KxvX5Hx8nh36ig2gT5bpeEcqLQcwJsZGB

Rizla2345



Offline



Activity: 238

Merit: 100







Full MemberActivity: 238Merit: 100 Re: Gold collapsing. Bitcoin UP. May 16, 2015, 04:13:48 AM #24111 Quote from: sidhujag on May 16, 2015, 03:08:23 AM Quote from: Rizla2345 on May 16, 2015, 01:05:38 AM The stock market seems ripe for a major collapse. Is gold likely to rocket? And bitcoin? Also the dollar has been sagging quite a bit lately. That should help gold but what about BTC?

I like the stock market here.. Lots of high risk gamblers will make a fortune in coming time.. Usd also a good buy right now.

I like the stock market here.. Lots of high risk gamblers will make a fortune in coming time.. Usd also a good buy right now.

Well, you know what they say, sell when they yell etc. It looks rather stretched to me, that is DOW, NAS, S&P. But I suspect that there might be something attractive in smaller caps which have been overlooked while the big boys were being pumped up. Well, you know what they say, sell when they yell etc. It looks rather stretched to me, that is DOW, NAS, S&P. But I suspect that there might be something attractive in smaller caps which have been overlooked while the big boys were being pumped up.

rocks



Offline



Activity: 1153

Merit: 1000







LegendaryActivity: 1153Merit: 1000 Re: Gold collapsing. Bitcoin UP. May 16, 2015, 04:58:03 AM #24113 Quote from: cypherdoc on May 16, 2015, 01:03:11 AM Quote from: rocks on May 16, 2015, 12:37:05 AM Quote from: cypherdoc on May 15, 2015, 11:33:42 PM Quote from: rocks on May 15, 2015, 10:46:12 PM Quote from: Erdogan on May 15, 2015, 10:44:02 PM Quote from: rocks on May 15, 2015, 10:40:26 PM Quote from: cypherdoc on May 15, 2015, 10:21:03 PM Quote from: smooth on May 15, 2015, 10:13:02 PM Quote from: cypherdoc on May 15, 2015, 08:18:54 PM as Bitcoin has alot of enemies, why do you think we aren't seeing a regular stream of these types of blocks?



I'm not trying to be conspiratorial here, just factual, but there is no real gain in doing it at 1 MB. 1 MB was chosen to be a size that is fairly immune to spamming attacks. Opinions differ I guess about whether 20 MB is similarly immune.

I'm not trying to be conspiratorial here, just factual, but there is no real gain in doing it at 1 MB. 1 MB was chosen to be a size that is fairly immune to spamming attacks. Opinions differ I guess about whether 20 MB is similarly immune.

Doesn't make sense that the protocol allows non standard TX's to be accepted in block form by nodes yet at the same time they won't relay or accept them if simply propagated.

Doesn't make sense that the protocol allows non standard TX's to be accepted in block form by nodes yet at the same time they won't relay or accept them if simply propagated.

The transactions were always valid.



To make them invalid would require a hard fork. We try to avoid hard forks for obvious solutions.



So the compromise was to change bitcoind nodes to only consider certain types of transactions as "standard" and not re-transmit transactions that did not qualify as "standard", these have since been called "non-standard". Along with this change many miners decided to not include these "non-standard" transactions either (but some still do).



This did not require a fork because the base protocol, which is defined by what constitutes a valid block, did not change.



As a consequence, non-standard transactions can still be included in a block because they are valid transactions from a block verification standpoint. However to discourage them, most P2P nodes and most miners ignore them.

The transactions were always valid.To make them invalid would require a hard fork. We try to avoid hard forks for obvious solutions.So the compromise was to change bitcoind nodes to only consider certain types of transactions as "standard" and not re-transmit transactions that did not qualify as "standard", these have since been called "non-standard". Along with this change many miners decided to not include these "non-standard" transactions either (but some still do).This did not require a fork because the base protocol, which is defined by what constitutes a valid block, did not change.As a consequence, non-standard transactions can still be included in a block because they are valid transactions from a block verification standpoint. However to discourage them, most P2P nodes and most miners ignore them.

So how come they appear in the unconfirmed transaction list on blockchain.info?



So how come they appear in the unconfirmed transaction list on blockchain.info?

Because someone sent them to blockchain.info directly, or they were relayed by a node that ignores the "non-standard" agreement (not rule). blockchain.info's website is also setup to be a view of the network, they include visibility into strange and other transactions. So it would make sense they would also display information on non-standard transactions that most node's won't re-transmit.



Again they are valid transactions, it's just an informal agreement to ignore/limit them. A formal agreement requires a hard fork.

Because someone sent them to blockchain.info directly, or they were relayed by a node that ignores the "non-standard" agreement (not rule). blockchain.info's website is also setup to be a view of the network, they include visibility into strange and other transactions. So it would make sense they would also display information on non-standard transactions that most node's won't re-transmit.Again they are valid transactions, it's just an informal agreement to ignore/limit them. A formal agreement requires a hard fork.

So any code changes made to the Bitcoin Core client do not require forks which is to be distinguished from changes to the protocol which defines what is acceptable as a block and requires a fork?

So any code changes made to the Bitcoin Core client do not require forks which is to be distinguished from changes to the protocol which defines what is acceptable as a block and requires a fork?

I'd define it as Bitcoin is the blockchain data structure and the set of rules that govern what constitutes a valid block. If you want to change the rules that govern what is a valid block (transactions and block structure) then that is a fork. Anything else is not a fork. The reasoning is simple, these are the rules that govern if a specific chain is valid and thus govern consensus.



Nodes however can operate however they want, as long as they agree on the rules that define a valid block. If some nodes decide on a different set of rules, then they will be forced onto their own chain and lose consensus with the main chain.



Take Gavin's IBLT proposal as an example. This is a major change to bitcoind that changes how nodes communicate blocks to each other. This is not a fork simply because it does not change anything at all about what defines a valid or invalid block. Just the communication of blocks.



Take LukeJr's insertion of Ubuntu nodes that block SatoshiDice type services into the Ubuntu default client. This was not a fork because he simply made the nodes decide not to relay transactions to/from specific addresses, but these nodes still followed the same rules on what is a valid block, and so they would accept these transactions after they were confirmed in a block. (To do otherwise would be a fork and they would be kicked onto their own tiny chain).

I'd define it as Bitcoin is the blockchain data structure and the set of rules that govern what constitutes a valid block. If you want to change the rules that govern what is a valid block (transactions and block structure) then that is a fork. Anything else is not a fork. The reasoning is simple, these are the rules that govern if a specific chain is valid and thus govern consensus.Nodes however can operate however they want, as long as they agree on the rules that define a valid block. If some nodes decide on a different set of rules, then they will be forced onto their own chain and lose consensus with the main chain.Take Gavin's IBLT proposal as an example. This is a major change to bitcoind that changes how nodesblocks to each other. This is not a fork simply because it does not change anything at all about what defines a valid or invalid block. Just the communication of blocks.Take LukeJr's insertion of Ubuntu nodes that block SatoshiDice type services into the Ubuntu default client. This was not a fork because he simply made the nodes decide not to relay transactions to/from specific addresses, but these nodes still followed the same rules on what is a valid block, and so they would accept these transactions after they were confirmed in a block. (To do otherwise would be a fork and they would be kicked onto their own tiny chain).

and your definition of a hard vs soft fork?

and your definition of a hard vs soft fork?

They are both forks in the sense above.



The difference is in whether or not all nodes need to change to accept blocks under the new rules or if the change is backward compatible and old nodes can still function without changing themselves.



This is a good description

http://bitcoin.stackexchange.com/questions/30817/what-is-a-soft-fork



Obviously a soft fork is easier to roll out. A hard fork required everyone to agree to the change and the exact block to change.

They are both forks in the sense above.The difference is in whether or not all nodes need to change to accept blocks under the new rules or if the change is backward compatible and old nodes can still function without changing themselves.This is a good descriptionObviously a soft fork is easier to roll out. A hard fork required everyone to agree to the change and the exact block to change.

TPTB_need_war



Offline



Activity: 420

Merit: 255







Sr. MemberActivity: 420Merit: 255 Re: Gold collapsing. Bitcoin UP. May 16, 2015, 05:48:47 AM

Last edit: May 16, 2015, 06:40:01 AM by TPTB_need_war #24116 Quote from: Adrian-x on May 14, 2015, 07:06:53 PM IMO this block size debate is not about block size but other interests.



Correct (I agree). The block size must be increased. Within the current design (even with IBLT) this is driving Bitcoin towards centralization as I have outlined. And only a radical redesign that removed transaction data from blocks could change that. So increasing block size and implementing IBLT has to be done and moving towards censorship (via increased centralization) has to be accepted. The only alternative is radical redesign.



Butthurt idols aside, it is better when we deal in reality and not fantasy. I would bother to explain why mentioning Nash equilibrium in this context is not applicable, but I see that my efforts here are not welcome. Correct (I agree). The block size must be increased. Within the current design (even with IBLT) this is driving Bitcoin towards centralization as I have outlined. And only a radical redesign that removed transaction data from blocks could change that. So increasing block size and implementing IBLT has to be done and moving towards censorship (via increased centralization) has to be accepted. The only alternative is radical redesign.Butthurt idols aside, it is better when we deal in reality and not fantasy. I would bother to explain why mentioning Nash equilibrium in this context is not applicable, but I see that my efforts here are not welcome. UnunoctiumTesticles, iamback, contagion, formerly AnonyMint TheFascistMind , etc