HI JAMAL , Please help me ^_^ I entered the wrong address i use ETH adress i join TWITTER BOUNTY USERNAME : 99percent BTT Profil :https://bitcointalk.org/index.php?action=profile;u=27300 TWITTER : https://twitter.com/tiara_larasat1waves Adress 3P94SkvXXubMqAzNp8S8cLMu9qVvjRN52AG MY STATUS IN BOUNTY ACCEPTED week = 3 weekly stake = 5 total stake = 15 please change my adress to my waves adress |
|
|
|
|
99percent
#1 Airdrop Closing Date Proposal: 16.08.17
#2 Airdrop Participant Hard Cap Proposal: 1500
|
|
|
|
it's a shame that lot of people belive to something like this, i'm curious who started to share all this spam link. C'mon get up guys, this life isn't that easy, even my country btc fb group sharing this sh*t link almost every minutes ! There is nothing on their website, no project vision, no team developer, no whitepaper, absolutely nothing on their site ! Beware for you who use same password for all your accounts, change it before something bad happens.
True we must be vigilant |
|
|
|
|
Yeah, that was it. I edited the file commenting out the line.
I wonder what changed the bitcoin.conf that way though since I certainly didn't.
|
|
|
|
Is it promoting you to reindex or does it just happen? If the latter, check whatever your are using to start bitcoin core that it doesn't have the -reindex option set.
It just happens. I launch bitcoin-qt from the start menu in Xfce4. The .desktop is as follows: [Desktop Entry]
Encoding=UTF-8
Name=Bitcoin
Comment=Bitcoin P2P Cryptocurrency
Comment[fr]=Bitcoin, monnaie virtuelle cryptographique pair à pair
Comment[tr]=Bitcoin, eşten eşe kriptografik sanal para birimi
Exec=bitcoin-qt %u
Terminal=false
Type=Application
Icon=bitcoin128
MimeType=x-scheme-handler/bitcoin;
Categories=Office;Finance;
|
|
|
|
|
I have upgraded to Bitcoin Core version v0.13.0.0-ga402396 (64-bit) on Ubuntu 15.10
Everytime I start it, it will do a Reindexing of blocks on disk from the start. It takes about a day to do so and consumes a lot of CPU.
I patiently wait for it to finish before closing it down. But the next time I start it, it will again do the reindexing from start.
What could be the issue here?
TIA.
|
|
|
|
i dont think blockchain usage always add up at the same speed with the difficulty rise.
i think the more correct approach would be start at 2 then double when blockchain usage excess 75% of capacity, or halved when its less than 25% of capacity. minimum 1 to a max of 32.
EDIT : why max at 32, i heard there is a network limitation on blocksize that even XT or any implementation will need another hardfork to remove this limitation
Your approach is like BIP Upal. Unfortunately miners can manipulate the metrics involved: tx per block and sum(tx fees). So I think these types of proposals are of no use. We might as well go directly to BIP100 to see what miners really want. Again, if miners can be coerced into only accepting tx that have appeared it the mempool somehow this might work, but I cannot think of a way to enforce this. |
|
|
|
Hi greeting everyone. I just curious with others idea on increasing the size of the blockchain. bitcoin is really unique due to its decentralization. I mean if somehow try to increase block wouldn't be others can run it own wallet due to the size of db. Just wanted to ask everyone opinion Thanks  My prediction: Fees will rise. Small transactions will be done off-chain (think Coinbase) which increases need to trust in 3rd party centralization. Transactions in the block chain will be bigger. There will be more pressure to develop channel protocols like Lightning. It might become so serious that bitcoin will only become the ultimate clearing house mechanism. But is that so bad? |
|
|
|
Most of the proposal are all subjective to much further discussion and test and all must agree with the one that is most reliable. This is somehow relevant on the discussion. http://coin-vote.com/poll/55e8a33299baadff0a34acb7 you can share your thoughts in there. cheers I hope you realize that polls of this type are of no use. For a hard fork to work it must be based on consensus. Consensus is a very dynamic process, it can change by the minute. First ideally core devs must arrive to it somehow (and even then miners have to accept the changes). If that doesn't happen, several implementations of the bitcoin core will appear (Bitcoin XT is the first). Then miners will start using them if they think they are superior without immediately causing a fork (as in Bitcoin XT that takes a super majority of 75% having mined with it). When the forking actually happens, the minority will be forced to join the majority unless they stubbornly refuse because of ideological concerns. In this case their blockchain will be supporting a weaker new altcoin (its price will plummet because the ones having funds on both coins will sell the weak one in favor of the strong one). Thanks anyway. |
|
|
|
BIP101 = serious bullshit
Don't fall for it
I agree. First of all realize that the max blocksize increases linearly. Its not that suddenly after 2 years the max blocksize has doubled from 8MB to 16MB. It is a gradual exponential increase. This is very dangerous as we can be slowly eroding decentralization with no clear sign when it is too late to stop it completely. Secondly, once this hard fork is in place, it will be very difficult to change because there are no constraints to it, except the possible 32MB protocol limit, but by then it might be too late. Much better just do a single increase to 2MB, 4MB or 8MB and kick the can for a more permanent solution later, when we can have more experience with the bitcoin protocol. Besides IMO there is NO urgency. 1MB is still enough for at least another year and it allows us to see what happens to fees when there is demand. |
|
|
|
Remember that currently the market for transactions is distorted severely because of the block reward subsidy. As it goes down, transactions fees become much more significant and will further force the miner to consider which transaction to add to his block. More hashing power makes the bitcoin network stronger, so everyone benefits. More users can lead to increase of bitcoin price, etc
Higher price commands higher difficulty. The other way around is not true. You cannot deduce price has increased because difficulty went up. The only thing it means is that profitability per hash has increased. A wealth of factors can affect that, not just price. An increase in price itself does not equate to an increase in block space demand. The tps can go up when price goes down and vice versa. There is no economic evidence of the contrary. Your proposal has to account for situations when reality contradicts the meaning you give your indicators. I agree that in general, in the absence of a coinbase reward, a growth in difficulty will mean an increase in fee subsidy, and thus block space demand. However, that does not always stand true, and you need a contingency plan for when that is the case. This is actually a pretty uncommon situation right now, as fee subsidy are about 1% of miner revenue. How much of a solution is your proposal if it only works when the stars align? Some people choose to discuss proposals for the now, others prefer to work on solutions that can also withstand the absence of inflation. However at this rate, you are designing a solution that will only start to make sense in some 20 odd years. That is why after thinking a bit more, the max blocksize increases according to difficulty must factor in the current subsidy coming from the block reward by coinbase. I thought of 100% when we reach 0 BTC per block (in 2140) and 75% now at 25 BTC per block. But I realize this is very arbitrary. Then again all other proposals out there are even more arbitrary. Unfortunately we cannot use transaction data (volume, fees etc) or block sizes as a metric because these can be manipulated by the miners themselves leading to tragedy of commons scenarios.
Not really. The emergence of relay networks and IBLT largely increases the cost of these attacks. To fake transaction volume under these conditions means a miner needs to emit txs to himself to recover its own fees. The implies they can't publish these transactions publicly until they are mined, or other miners will pick them up and end making the ill intentioned miner actually pay for the attack. However, relay networks and IBLT produce a coding gain in block propagation by forwarding block content before a solution is found, i.e. each miner is telling others what tx set they are working on. A miner deliberately slowing down his propagation is exposing himself to a lot of natural orphaning, and past a certain point, he is so easy to identify and such a nuisance that other miners have motivation to just out right orphan him on purpose. Add a decay function on top of it and not only miners will have to pay for spam attacks like any other spammer, but their effort will also be lost in the mid term, as the decay function will correct the effect of the attack. Very true and it is very likely that as difficulty increases, the risk for orphaned blocks becomes more significant, specially when the block reward subsidy goes down. So in the end maybe this whole problem about increasing the max block size is overblown. I am tending to think now, lets just go to hard fork to 8MB and kick the can for a long term solution, to several years from now. But if we could some how force the miners to always include transactions that had appeared it the mempool, or at least make it a risk not too then this problem would be solved.
That's inane. the first and best spam filter is letting miners pick transactions based on economic factors. As long as the incentives are not completely warped, this system works. What you are proposing is making any tx spam attack completely trivial. It would also make DoS attacks by high OPs count and low size tx very effective. A lot more than currently, as they can easily be thwarted by their own nature: low miner profit. Sorry I misstated what I meant to say. What I meant is if we could force the miners to only include transactions seen in the mempool (not ALL transactions), so that miners cannot include bogus tx that only pay fees to themselves with the purpose of manipulating the discussed metrics. But I cannot think of any way to do this, basically because different nodes can have different sets of transactions in their mempool because it is designed that new transactions that will cause a double spend be discarded. |
|
|
|
http://www.coindesk.com/bitcoin-network-stress-test-could-occur-next-week/For whatever reason this stress test is launched, I think this is good to see just how resilient the bitcoin network is right now. Miners seem to be already taking steps to counter the transaction backlog, by (ignoring for a while at least) what look like stress test transactions even though they supposedly pay higher fees (0.0005 instead of 0.0001). For the stress test to be more efffective I think the testers need to create real looking transactions to begin with. It is a highly strategic battle. The stress test might come after or before (most likely). Regardless, I think it is very important and good in the end for bitcoin. It will shed some light for example on how to determine the max block size.
|
|
|
|
When the hash rate increases because of new ASIC, the difficulty rises, this will allow for the max block size to increase. This increases supply so transaction fees go down, which will cause an increase in block space demand. All of which if you think it over, it makes sense. The bitcoin network has gotten stronger because of a massive increase of hash rate due to new ASIC, therefore it stands to reason it should support more transaction throughput.
Again there is no link between increased hash rate and block space demand. If a new ASIC tech is unleashed on the market tomorrow, why would transaction volume go up? Your local bank gets a new paint job, a larger parking lot, a McD right next to it and a larger safe, and your reaction is "ima purchase more goods and services"? Where is your extra purchasing power coming from? Isn't the fact that your bank is upgrading the result of the fees it's been charging its customers? What leads you to believe said customer are somehow wealthier as a result of this? If anything, shouldn't it be the opposite? Thanks again for replying. Remember that currently the market for transactions is distorted severely because of the block reward subsidy. As it goes down, transactions fees become much more significant and will further force the miner to consider which transaction to add to his block. More hashing power makes the bitcoin network stronger, so everyone benefits. More users can lead to increase of bitcoin price, etc It doesn't matter really at which rate block space demand grows. If it grows slowly, then transaction fees stay low and investment in mining will be low.
The fee market is not an end in and of itself. It is a mean to support certain network mechanics, one of which is to pay miners enough to have acceptable blockchain security. Not just security, but high enough that it is more profitable for a brute force attacker to just mine blocks than to try and rewrite block history. You should design your proposal with the purpose of the fee market as your goal, not to simply sustain any fee market. Unfortunately we don't have any other metric to determine the max blocksize.
There are plenty of other metrics in the blockchain to represent block space demand. Over a difficulty period consider total fees paid, average fee density, UTXO set, total value transfered, average value per UTXO, straight up average block size. Plenty of stuff to get creative with. Unfortunately we cannot use transaction data (volume, fees etc) or block sizes as a metric because these can be manipulated by the miners themselves leading to tragedy of commons scenarios. UTXO sizes can also be manipulated with fake transactions. But if we could some how force the miners to always include transactions that had appeared it the mempool, or at least make it a risk not too then this problem would be solved. |
|
|
|
1. I think that first we need to force the miners don't "run away" with finder's fee and a few transactions confirmed when there are old transactions waiting and max (current) size not filled yet.
This is a much bigger problem than block size, because the block size doesn't matter at all if miners don't use it well.
2. Then, maybe the block size could be adjusted - with some smart formula - to be bigger only when bigger is needed (edit: meaning when there are old transactions waiting for more than a certain time). So a "smart" BIP1xx.
I have thought about this. We can publish a bitcoin node that does not relay *new* blocks which have a certain percentage of transactions that were never seen in the mempool, and also blocks that are not near max blocksize if there are still many transactions with fees pending in the mempool. This will make miners very very afraid to mine mini blocks or with fake transactions (transactions that were never released to the mempool) since the risk of having their block orphaned increases exponentially against other miners who do mine the transactions that were in the mempool. This bitcoin node doesn't even have to be running, just the idea that it might be out there would be very frightening to miners. |
|
|
|
Generally this kind of proposals cannot function without a second factor, which is meant to define a resizing threshold.
How is your code supposed to distinguish between the release of a new ASIC and actual growth in block space demand?
When the hash rate increases because of new ASIC, the difficulty rises, this will allow for the max block size to increase. This increases supply so transaction fees go down, which will cause an increase in block space demand. All of which if you think it over, it makes sense. The bitcoin network has gotten stronger because of a massive increase of hash rate due to new ASIC, therefore it stands to reason it should support more transaction throughput. However I believe this to be nearing its maximum efficiency and closing in with Moore's Law. Not necessarily. Consider that Intel is a $55B business whereas the Bitcoin as a whole has a $3~4B market capitalization. We're not yet at a stage where professional chip manufacturers have an incentive to build ASICs. Intel has been around for decades, bitcoin only 6 years, of which 3 has shown dramatic growth. And generally, what makes you believe block space demand will grow at least at the same pace as Moore's Law?
It doesn't matter really at which rate block space demand grows. If it grows slowly, then transaction fees stay low and investment in mining will be low. Your proposal has no thresholds. It simply links block size evolution to difficulty. I believe difficulty changes are a good metric to define by how much the block size should be changed, but difficulty is not a good enough metric to reflect block size demand.
You need another factor to track block size demand, and use that as a trigger for resizing. On top of that, a decay function would be preferable for when the resizing condition doesn't trigger. That's a safety harness that will correct the effect of spam attacks, large miners trying to game the system, and too large a jump in block ceiling.
Unfortunately we don't have any other metric to determine the max blocksize. All the other proposals so far only arbitrarily set this limit, or in the case of BIP 100 it gives the miners a way to set it via voting which the more I think about it, the more I tend to believe its a terrible idea. I really appreciate your input. I have been obsessing over my solution for this max blocksize conundrum and I really think it is the best one by far. |
|
|
|
FWIW isn't Lightning Network a band-aid solution?
No, far from it. I suggest you seriously look into it. |
|
|
|
I like great ideas, but great ideas do not fair well on the forums. thanks
Dynamic Block size with min. change to 2MB no doubt.
Whether or not the change is proportionate to difficulty of mining is not really what I would call relevant. The main concern is latency when blocks begin to get into the double digits but people overlook the added incentive of increased transaction volumes = increased incentive.
As I said the problem with latency is resolved when blocks get orphaned by the miners. This affects difficulty directly because the hash rate is affected by the wasted block - the hashes that went into generating the discarded block are lost. We could keep 1MB until it starts slowing down the network and then go to a Fibonacci Sequence that increases dynamically based upon whether the block size is deemed too small by Core. Say if Mempools start crashing Nodes etc...
1MB,2MB,3MB, 5MB,8MB, 13MB, 21MB etc
That seems to be a part of another suggestion to hard fork. You would need to elaborate. I really appreciate your time and contribution but I believe all the Core developers have already been bought out by Blockstream so they can be the First Lightning Network hub and take fees from miners and keep 1MB forever because they want to capitalize on the inability of the community to reach consensus without arguing. I really detest any suggestion of politics or buying out of core developers in this discussion. FWIW I fully support the Lightning Network. I think its a fantastic idea. The Lightning network also needs an increase in max blocksize btw. People like you are who keep bitcoin going. Thank you. Remember, We Are Satoshi.
was
thanks |
|
|
|
|
Show Posts
