If you're saying the hashrate will be small on core's fork, this is precisely the issue - what chain will economic entities and SPV clients follow. It is possible to voluntarily and involuntarily follow a lower hashrate fork. Note I'm not arguing in favour of anything, just pointing out the facts.
Even with small hashrate, this chain wont work - expect orphaning with empty blocks to kill the small chain economically. Even doublespends could be a problem. This reminds me of Luke-jr attack with his pool to merged minined altcoins - Im pretty sure similar incentive is here as well. The same reason why BIP148 would not work. Assuming they want to spare the hashrate indeed. If it's large enough, however, then it would be too expensive a venture for them to do. At this stage there's enough pool support for segwit2x to believe there isn't enough hashrate (15%) to sustain a fork separate from it in any meaningful way, especially since some of that 15% is not showing support for regular segwit and likely to jump to the bigger fork. |
|
|
|
The point is there wont be two working chains, so from this perspective arguing with "hijacked" or "replay attacks" is moot.
You're assuming there won't be two chains. Why? At this stage there's every reason to believe core will not support the 2MB hard fork component of segwit2x leading to two chains. If you're saying the hashrate will be small on core's fork, this is precisely the issue - what chain will economic entities and SPV clients follow. It is possible to voluntarily and involuntarily follow a lower hashrate fork. Note I'm not arguing in favour of anything, just pointing out the facts. |
|
|
|
Read as: The "backwards compatible softfork" that is designed to be followed by a "backwards compatible hardfork" isn't backwards compatible with the old clients that will no longer work after the fork anyway.  Right, pretty much... There's not really any such thing as a backwards compatible hardfork, only some SPV clients might not validate enough information that they get hijacked. |
|
|
|
Here Jeff Garzik is explaining how the requirement for a >1MB block worked exactly as predicted saying it's not a problem at all... https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-July/000094.htmlPeter Todd asks the valid question of why the hard fork bit wasn't used. https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-July/000098.htmlImportant quote One of your arguments against soft-forks has been that they "fool nodes"(1) by changing the rules in undetectable ways. One of the counter arguments to your argument is we explicitly ensure that soft fork mechanisms use nVersion signalling to ensure all nodes are given an opportunity to learn that the fork is happening; malicious soft-forks of course don't do this, but the fact they're possible is an unavoidable by-product of Bitcoin's design. From the point of view of a headers only lite client, segwit2x is a soft fork with no nVersion signalling mechanism. Now, to be secure all wallets, lite clients or not, will need updating in the event of a hard fork to - for instance - ensure they're getting seed nodes from appropriate places and the like, and to ensure funds aren't lost in replay attacks. I'm unclear as to why something that can be fixed in a line or two of code - code that needs to be changed anyway to safely support the hard fork - trumps these important issues of user consent that you have brought up before yourself. 1) https://twitter.com/jgarzik/status/861656643918069760And basically the question is shrugged off and he is referred back to the git pull request citing tl/dr: https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-July/000096.html |
|
|
|
|
If you want to run a pruned node but have the storage capacity to download the whole blockchain it is indeed much faster to download the whole blockchain and then restart bitcoind in pruned mode to do the pruning afterwards since it is constantly being pruned during the download process otherwise.
|
|
|
|
Although I do agree with many people that this feature is "not Bitcoin" as some say, why the hate for it?
So there are 3 main complaints people make about lightning network and these are a combination of partly true, part misconception, and complete FUD 1. Purists believed the blockchain was good enough for all transactions and the proverbial "cup of coffee" purchases could be done on-chain simply through micro bitcoin transactions. It's clear now that if we had all of VISA's transactions worldwide, in its current form the blockchain would need to have 2GB sized blocks to sustain that volume of transactions. Current technology and even anything we can perceive in the immediate future makes that impossible with transmission of new blocks generated, propagated and stored in a distributed manner. The counterargument is we'll only slowly get up to that size; it won't happen overnight and we'll find a way between now and then to do it. 2. Transactions being done on LN will remove fees from the blockchain by doing all transactions off-chain. LN transactions are actually limited to micro bitcoin values only and the fees all go to the network based on transaction value rather than size (unlike the blockchain) though opening and closing a LN channel requires an actual blockchain transaction and suitable fee. This one particularly had the miners riled up though segwit2x means they no longer believe in it. 3. LN is centralised instead of distributed and blockstream will will run it. Lightning nodes can be run by "someone" but that doesn't mean it will all be held by one entity. It is possible to run a node of your own though it is highly likely that several competing services will come out using the same protocol and people will use that in preference to running a complete full blockchain node and lightning node on top. Where segwit comes in and where the objection to segwit comes from is that segwit makes LN easier and better featured so most LN development has been done with segwit existing in mind. The people who object to the above were against segwit based on the perception that segwit makes LN possible. I expect the large exchanges will probably end up providing LN nodes of their own and compete on fees. |
|
|
|
|
This thread has outlived its usefulness since it had none to begin with. Locking it.
|
|
|
|
|
Attracting nothing but sigspammers now so I'm locking this thread.
|
|
|
|
newb question so I apologise in advance:
What coins does CGminer actually support, where can I find this information? I cannot seem to find it anywhere?
"Anywhere"? First line of the readme, last word. |
|
|
|
Actually, the WinUSB drivers are a lot easier and less annoying than in windows... so perhaps I'll just stick with cgminer on *nix.
Heh, that's a funny thing to say. WinUSB drivers on linux... think about what you just said (hint WINusb.) There is no such thing on linux, cgminer just talks directly to the linux kernel usb interface and doesn't need any driver at all. |
|
|
|
It's tricky, because there has to be a method of preventing replay attacks. Obviously people would be critical of their efforts if they didn't ensure a clean fork. It's almost as though they're damned if they do and damned if they don't. And because the blocksize cap itself was rather a crude cludge to begin with, undoing it probably won't be any more graceful.
Not really. They chose to not use a hard fork bit in the header because they wanted to hijack all the SPV clients onto their fork. A HF bit would have avoided the need for their flaky activation mechanism but then they wouldn't have had their hijack mechanism. NYC agreement is best and final. In 30 days this will be over without any chain split or problems. 100% smooth transition is planned. UASF will not happen.  For the segwit part of segwit2x this might be true, but definitely not for the 2MB part which comes 3 months later. Even for the segwit component, if the miners lose faith in the code because of the showstopper issue just introduced, they may revolt and not deploy it on July 21st as planned (though no mining pool has hinted at that so far.) |
|
|
|
Work meaning to have no backlog thereby reduce fees and lower confirmation times, that's all I want.
I don't doubt the technical aspect of it working, but nobody knows how much it will help with the above until it's implemented.
Segwit is coming and the question will be answered however.
Well I no longer see a fee or confirmation time problem now that the mempool bloat (which was obviously from spam) has now magically disappeared. The only high fees I see now are from services/wallets that still are set to high levels generically based on past mempool bloat that no longer exists and are missing good fee estimators. With segwit on top of that fees will be embarrassingly small even if the uptake is low. Bitcoind is actually filtering out ultra low fee transactions now the transactions are so low and unable to fill a block. So while it's easy to fill 1MB currently by just including all sorts of crap transactions, it's only the garbage that is below standard transaction limits and most pools won't include those. I see this on my own pools which are configured to keep block templates as full as possible but there's nothing to fill them with at times. |
|
|
|
One side believes segwit will work, the other side believes it will make very little difference.
You're kidding me... you really think segwit won't "work" the way it was intended? It's been deployed for over a year on testnet (unlike segwit2x) and has been deployed on litecoin. Sure litecoin has precious little use for it but it's still in use and does exactly what it's supposed to. Or are you saying that exchanges and users simply won't use segwit transactions? Exchanges will jump ASAP for the benefits it provides and they do the bulk of the transactions (except during mempool spamming and then it's 'someone'). |
|
|
|
...This needs to be stopped and making 1 MB the minimum size is a good step in ensuring that.
There it is, the dumbest thing I've read in 59 pages.  Q: And what happens when there isn't 1MB worth of segwit transactions? A: 1 hour block times.  Well, I don't see why a miner wouldn't fill up the block to 1 MB with dummy transactions, just to not waste his hash rate, and get the next block while all others are waiting to start to mine until they can fill up a 1 MB block... A lower limit on block size will never be a problem, because miners can make blocks as large as they want with own dummy transactions. This makes that miners cannot play games with small blocks as they are now not part of the protocol any more, and all "relative network advantage" between 1 MB and 2 MB is much smaller than between 10 KB and 1 MB. Moronic, encouraging miners to create pointless transactions to make big enough blocks... Let's help contribute to blockchain bloat. For the record, by the way, it only needs to be one block to big enough to break the deadlock but it's still a stupid mechanism to secure the hardfork. |
|
|
|
that means that this segwit2x fork will activate only if miners built a block with more than 1mb? And if not the network will be stall until this happen? lol What a crap is this  A big crap. One that I'm sure will create lots of confidence in this 40 billion dollar economy. |
|
|
|
A few days ago I generated 50.01000000000000 BTC. How is this possible? It now has more than 1000 confirmations.
That is impossible using simple mining rig. I am doubtful if the amount you mined is 50 btc or maybe it is not 50 btc after all or other cryptocurrency or just another amount. It could be 50 mbtc or it could be 50 coins of any altcoins. I do hope you can provide us with a screenshot so we can really tell if the is really 50 bitcoins. But if that is really true then you are very lucky and that 50 bitcoin may not be coming from your mining but rather it maybe coming from somebody else. Or possibly somebody has made an error and sent you that huge amount. Well goodluck and congrats, you dont need to be puzzled anymore if that is really btc try encashing it and enjoy your profit. Before you sigspam post, look at what you're quoting - it's a post from 2010 and mining 50btc back then with a PC was easy. Now go away and stop posting for sigspam rewards. |
|
|
|
Antpool is not to deposit it's a mining company and you need to just open account there and use your computer software to mine and you get for mining may be 1 btc per month.
And this is completely wrong too. It's a mining pool and you need dedicated mining hardware to mine there, not computer software, and you'd never get 1btc per month without a lot of expensive hardware. |
|
|
|
Free of speech as long as the thing that we are say still in the topic,
Am i wrong???
No, this is a private forum not some country's ideals. There is no guarantee of freedom of speech. Stick to the rules only. |
|
|
|
Okay and back on topic, it looks like a showstopper bug has shown up in their segwit2x code. They've hit the >1MB hard fork on testnet which refuses to accept a block unless it is bigger than 1MB: https://github.com/btc1/bitcoin/issues/65At this point there aren't enough transactions to create a second block with more than 1MB of transactions on testnet, leading to a fork with 6000 blocks that aren't using the 2x code and the two forks not speaking to each other. They argue that mainnet is busy enough that there will always be blocks with more than 1MB of transactions so it won't be a problem. This is utter bullshit as over the past week I've seen my mempool easily get down below 1MB of transactions now that the transaction spam has ended on mainnet. Making a followup block mandatory 2MB when nothing forces mining to do so is a showstopper IMO. Now they're all scrambling and arguing how to tackle it... This is going to be interesting. I might start selling popcorn. |
|
|
|
|
Show Posts
