Bitcoin Forum
April 10, 2024, 06:33:41 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Bitcoin Technical Support / My node is having problems with validating Slush blocks on: October 08, 2015, 11:13:18 AM
It seems my node is having problems with validating Slush blocks. Example : block#377983 and he now falls behind the network. Each time I checks he was 4-10 blocks behind the network and the next block he was trying to validate was from Slush.

Any idea where this may come from ?

Thanks in advance.
2  Other / Meta / Are Forum signatures really useful ? on: May 28, 2015, 06:32:11 AM
Quite a bunch of people put adds into their signature (dice companies -.-, mining, etc) and answer/write posts with irrelevant content in order to earn money. This process is known as "signature campaigns" and is of course sponsored by companies.

On this forum I sometimes run into "signature people" having a 300+ post history and having no clue of how bitcoin works.

The result is that "honest" forum users waste a lot of time reading these irrelevant answers/posts.

Some people came up with solutions like "ignore list sharing". But I believe most honest users, especially new users aren't aware of them. And blacklisting is not really in the spirit of Bitcoin after all. However I use one because I feel I don't have the choice, and sometime I click on a post and all of the answers are ignored.

Instead, why not just disable signatures in order to improve over all user experience ?
3  Bitcoin / Development & Technical Discussion / Proposal: a fee driven dynamic maxblocksize on: May 10, 2015, 10:13:19 AM
Dear reader, please accept my apologies if you're fed up with this very popular topic.

The maximum blocksize (MBS) limit is the most controversial and challenging problem the Bitcoin community is facing today. Yet one of the most fascinating.

When a transaction is broadcasted to the network, the fee attached to it can be seen as an expression of the transaction's value and as a contribution to the network security.

I believe the scarce resources of the highly redundant and decentralized Bitcoin ledger should not be used by low value transactions that do not contribute to the network security: this cannot not be sustainable in the long term, neither for decentralization, neither for miner retribution.

This message suggests a way to push low value transactions towards off chain solutions while at the same time adjusting the MBS to accept new high value transactions: a fee driven dynamic MBS.

The main proposal is the following:

MBS[n+1] = f(fee*[n])

Where:
[n]: is the chain ranging from block number 2016n+1 to 2016(n+1) And

fee*[n]= Median[n](Min (fees inside a block))

Dishonest pools/miners could be tempted to add fake transactions (to themselves) with huge fees in order to artificially increase the MBS :
1) technically they would need to collude and obtain 50% of the hashrate in order the reach the median.
2) They would have to fill their blocks only with those fake transactions (else the formula will pick up the transaction with the minimum fee in their blocks to estimate fee*[n]) : depriving themselves from any transaction fees. Furthermore they would need to do this as long as they want to keep this artificial MBS (else the MBS would adjust back at [n+1]), which would not be sustainable for them, especially after the next block halving.
3) This strategy would be noticeable: miners would leave the pools behaving this way hence these pools would end up losing money and hashing power and gaining nothing.

And what about this f function ? I first though it would make sense making it somewhat linear, then playing around with WolframAlpha, a square root made me feel more comfortable. It could look like something:
1) Fees ranging from 0 to 0.001 btc. Here the MBS is expressed in MB
http://imgur.com/GBfNCAv
2) Fees ranging from 0 to 0.01 btc. Again MBS in MB.
http://imgur.com/SgCY7p2

We now have a system with a MBS that adjusts to fees, pushes low value transactions towards off-chain solutions, limites the usage of the scarce resources to what is really valuable and provides a long term solution to the miner subsidy halving issue (known has the tragedy of the commons).

However in the long term, we also need to take into consideration:
1) Software optimizations, hardware & bandwidth enhancements
2) Significant increase of bitcoin value that could act as a too strong force decreasing the fees expressed in btc and hence decreasing MBS drastically and crippling activity.
3) Arrival of layer 2 protocols that will likely bring more high value transactions on the blockchain.

The idea here could be to double the MBS every 4 years, similarly as bitcoin production is decreased every 4 years.

This doubling every 4 years would give a roadmap to bitcoin companies and to the public, while saving us time to test, tune and hopefully avoid any other hardforks in the future. At some point in the long run, a hard limit can always be enforced via a softfork.

So the MBS formula could end up like this.

MBS[n+1]=2^{p-1} x f(fee*[n])

Where {p} is similar to the reward periods defined as the chains ranging from blocks number 210000p+1 to 210000(p+1)
And where f is a somewhat slow growing function to be defined, square root or whatever
And [n] and fee*[n] defined earlier.


4  Bitcoin / Development & Technical Discussion / Difficulty readjusting every 2 weeks? on: May 02, 2015, 05:18:00 PM
Anyone knows why this period was chosen?

Why was the readjustment period not made shorter ?

If mining power drops down (for example because of a fork, but that's just an example) that would paralyze transaction confirmations. And just waiting for 15 days would not help since I assume the adjustment algorithm is based on number of blocks found.

5  Bitcoin / Development & Technical Discussion / Mining consecutive blocks on: May 19, 2014, 10:07:04 AM
In order to mitigate the risk of a 51% attack (and selfish mining, etc ...) why can't we implement a rule saying that a "miner" cannot mine 2 (or 3?) consecutive blocks ?

I am aware that "miner", "cannot", "mine" are general terms. Perhaps something like "when a node relays a block, the other nodes check that ip address of that node was not used to relay the previous block, if it did, the block is rejected by the other nodes", would be more specific.

What are your thoughts ? Does that make any sense ?
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!