 Show Posts
|
|
Pages: [1] 2 3 »
|
Is this only on XT's testnet or will we be seeing a forked XT chain soon? If so seems like an unorganized and sloppy way to release it.
XT will not fork the blockchain until a supermajority (75%) of the miners is running XT. So running XT now is no difference to running Core. |
|
|
|
just pay another couple pennies to get your transactions confirmed in the next block.
Ahh, yes. If only those 10k unconfirmed transactions had paid higher fees they would be confirmed by now. |
|
|
|
 Raise the limit! Lol. Isn't that Peter Todd on the right?  |
|
|
|
I was just reading something in regards to this. Peter Todd: Anyway, given the huge growth potential of Bitcoin and blockchain tech, if 20MB is the max limit there is a high chance we'll be seeing 20MB blocks soon; if the limit was 100MB there is a high chance we'd be seeing 100MB blocks.
However I don't see any evidence behind such a statement nor do I believe that it is true. Looking at the blockchain, we can see that it isn't actually about the number of transactions but rather their size.  We can clearly see that some blocks are quite big but with a lower number of transactions. However someone else will have to explain this as I'm not that familiar with the blockchain. Although it could also be that someone is doing this on purpose or stress testing. These addresses seems to be involved: https://blockchain.info/address/1HRh1ec6zMBFFHZR3gnhDo9CSAXGxfXDCkhttps://blockchain.info/address/19vJZjvvgMmef24h7VETTxyXzpoWoEHqvSPublic note on the transactions mention CoinWallet.eu |
|
|
|
this is good, i was worried that they will eventually end up refusing everything and stay with their own fork of 1MB, apparently they do care about bitcoin a bit, besides their revenue from mining activity
from what i can grasp of one of the comments, it seeems that the total chinese miners contorl 60% of the network, is this correct?
Just AntPool, F2Pool and BW.COM control almost 50% just those three. https://blockchain.info/pools?timespan=4days |
|
|
|
Microsoft supports Bitcoin XT!   |
|
|
|
I'm also switching my node to XT.
I've already switched mine. Doubled my bitcoin in five minutes. If anyone wants to buy BitcoinCore bitcoin, I'll sell them for a discount of $175. I am also selling the new bitcoin BitcoinXt for $250. Send me a PM with your address. I can make the trade today. lol people are really selling xt coins? they treating it like a shitty altcoin on another note, i don't have all the stuff for compiling it, there is an exe somewhere? or could someon provide the exe please Here: https://github.com/bitcoinxt/bitcoinxt/releases |
|
|
|
What would this solve? When will we do once we reach 8MB limit? what wil we do once we reach 20MB limit? are we just buying time with this?
It is just buying time. Increasing the blocksize now is a solution that will buy enough time for people to come up with a better solution for this issue when it actually becomes a problem. You are missing one of Gavins most important points. I will automatically increase by almost 50% each year, to follow bandwidth. "Scaling up a little less than Nielsen's Law of Internet Bandwidth predicts for the next 20 years? (I think predictability is REALLY important)." I see that it will scale up every year by 50%. However, I don't think this is the final solution to the problem. I think that doing this is a solution that works, but it is not the best or final solution. So, while this solution is implemented, other people will work on new ways to solve the problem. Yes, you are right. It is not the final solution. There needs to be, and will be, many solutions to this. This one is about increasing the max block size in a way that no one can reasonably complain about. There will also be many off blockchain solutions to this. But we should not discuss one solution against the other, they are all needed. |
|
|
|
What would this solve? When will we do once we reach 8MB limit? what wil we do once we reach 20MB limit? are we just buying time with this?
It is just buying time. Increasing the blocksize now is a solution that will buy enough time for people to come up with a better solution for this issue when it actually becomes a problem. You are missing one of Gavins most important points. I will automatically increase by almost 50% each year, to follow bandwidth. "Scaling up a little less than Nielsen's Law of Internet Bandwidth predicts for the next 20 years? (I think predictability is REALLY important)." |
|
|
|
What would this solve? When will we do once we reach 8MB limit? what wil we do once we reach 20MB limit? are we just buying time with this?
No it will scale automatically with Nielsen's Law (a little less to be sure). So a little less than 50% per year. http://www.nngroup.com/articles/law-of-bandwidth/So one year from implementation it would be 12MB, a year after 18MB and so on. |
|
|
|
|
I vote XT for bigger blocks. As I see it there is a handful devs that try to kidnap Bitcoin for their own ideological reasons.
Gavin and Mike are the ones that keeps the promise given from the beginning. If others want something else, i.e. a small altcoin that you can run on your laptop, then work on that. Bitcoin is supposed to be the big global ledger. That needs much bigger block size.
I run my own full node and I will switch to XT when it has the bigger block size implementation.
|
|
|
|
To say 10 min per block is only statistically right.
You might see several blocks mined in a row in a few minutes but in another time none for an hour.
Height Age Transactions Total Sent Relayed By Size (kB)
346427 29 minutes 46 1,773.59 BTC BTC Guild 21.74
346426 29 minutes 217 607.58 BTC F2Pool 119.97
346425 32 minutes 772 6,959.44 BTC BTC Guild 416.73
346424 46 minutes 320 1,659.23 BTC F2Pool 155.84
346423 51 minutes 1010 8,987.83 BTC F2Pool 507.12
346422 1 hour 10 minutes 614 6,597.82 BTC KnCMiner 417.55
Yes, I understand that. My question is about average waiting time for a block. Is the average time until a new block is found always 10 min no matter how long I have waited, or does the average waiting time decrease the more time has passed since the last block? Edit: I'm waiting for a confirmation right now, that's why I'm asking |
|
|
|
|
I was wondering about waiting time for blocks. Is the probability of finding a new block always the same, like the probability of rolling a six on a dice does not change no matter how many sixes you have rolled in a row, or does it decrease because the search space of the problem exhausts?
Ex: I go to blockchain.info and see that the last block was created 60min ago. I think "oh, how unlucky the miners have been, but that's good, then they should find a new block any second now."
Is that correct, or should I expect the average time until a new block is 10min no matter how long ago the last block was created?
|
|
|
|
is it possible to point your own Miners towards a specific adress ? to make the confirmations go faster ?
The answer to your question really depends on what exactly you are asking. If you are asking if you can solo mine with the goal of getting a transaction confirmed quicker then yes you can do that however this would really be a moot point unless you are trying to broadcast a transaction with either a 'lot' of inputs or a 'lot' of outputs and are not paying a sufficient fee. If you are asking if you can mine so that the block reward goes to 'your' address, then this is what every pool (except eligius) does as the block reward goes to the pool's address and then the pool will in turn pay the pool's users. (or someone who is solo mining will simply have the block reward go to their own address) I have a address that revives and sends out hundreds and hundreds of tx everyday, some of them are so small that the fee needs to be so low that it really don't matter. That's why I thought it would be a good idea to point some of my miners towards some specific transactions to make them confirm faster. If you have miners running they are most likely mining for a pool of miners. Then it's up to the pool operator to decide what transactions to confirm. Your miners are only doing what the pool operator tells them. |
|
|
|
I will not argue with you gmaxwell since you know the code much better than me. My fear is about implicit consensus in the code that is prone to bugs. If this code is implemented differently on different clients there can be a fork where we would think there should be consensus. I hope the libconsensus can help with this. Peter Wuille explains it well, I think. http://youtu.be/asC_kVJ6sig?t=12m45s |
|
|
|
|
