the same pools that were mining segwit before are still mining it now, so there doesn't appear to be any increase in support and this is just variance related to pool luck.
It could be those pools (BCC and Bitfury) have increased their share of the hashrate. Which of course is also temporary The downturn back to the same level of ~26% suggests not. It was just variance. Now if f2pool is actually considering signalling segwit, that would be a totally different story. Well, yes. With the benefit of hindsight, you have divined the correct assessment (not so difficult to "predict" that which has happened already). Both were possible before anyone had the chance to use hindsight though. The same mining Cartel behind the BU block, is also going to shift their weight against activation of SegWit on other Alt coins. Reason : If SegWit can be proven as a success on other Alt coins, it would make it easier for SegWit to be accepted for Bitcoin.
They will not allow for that to happen, because it will be used against them as proof that it is the better solution. Litecoin is similar to Bitcoin, so it will be a easy comparison.
That's where BIP148 comes in. The way I'm reading the document, BIP148 simply activates Segwit on a day (November 15th 2017), as long as BIP9 activation has not already happened. |
|
|
|
|
@ImHash
Yes, there is a downside to that proposal (you're not the first to think of something along those lines, but at least you're thinking). The downside is sufficiently serious to rule it out.
|
|
|
|
Here's a schematic of my proposed PoWA (proof-of-work additions) soft-fork blockchain.  New PoW chain is shown in pink, legacy blockchain in blue. Brief description:- New PoW miners and legacy miners mine in parallel. Proofs for the new PoW blockchain's mini-blocks are embedded into legacy chain in a special transaction.
- All assembling of TXs into blocks and reorgs happen on the new PoW chain. Legacy miners' role is restricted to finding SHA256 hashes, final block assembly (calculating payouts, creating the coinbase TX) and broadcasting the block.
- Mini-blocks are 100 Kb in size; new PoW blockchain has one-minute block discovery rate (i.e. confirmation time).
- Mini-block headers are like ordinary block headers but with an added payout address.
- New PoW miners mine with no downtime. Legacy miners experience an avg. of 10% downtime while waiting for new PoW miners to mine one block. (It may be possible to eliminate this downtime by having new PoW miners solve only mini-blocks and not entire block.)
- Initially, 95% of block reward will go to legacy miners and 5% to new PoW miners. Legacy miners' share will be gradually reduced (over a period of years?) until it reaches zero.
- After legacy miner broadcasts a valid block, new PoW miners assemble all TXs from mini-blocks mined so far into a single Bitcoin block with no Coinbase TX, solve the block and broadcast it along with mini-block headers to legacy miners.
- Legacy miner adds mini-block proofs, TX counts and payout addresses to the special transaction, calculates payouts (initially distributing 95% of reward to himself and 5% equally among new PoW miners), adds payout outputs to Coinbase TX and then solves and broadcasts the block as usual.
- If new PoW miners solve nine mini-blocks faster than legacy miners solve one block, then they continue mining empty mini-blocks until legacy miners finally solve the block. Thus a block may contain more than 10 mini-blocks.
- In the reverse case, fewer than 10 mini-blocks will be assembled into a block, and the new PoW miner who assembles the block will add as many TXs to the final mini-block as required in order to reach the blocksize limit (currently 1MB).
All of the above is preliminary and subject to change. What's the rationale for making the mini-blocks 10 per legacy block? I'm thinking of the orphan rate. I'm also unconvinced about a "years" timeframe. I would propose 1 year, where the interval between the 5% steps starts at close to infinity increase for the 5-10% part, and gradually increases the interval between steps (like an exponential curve inverted about x=y, is that the cosine curve?) Going faster to begin with should help to attract hashing power to newPoW, and in turn dissuade the BU miners from even attempting the various attacks they have no doubt developed. The "long tail" will gradually contribute to calming what would inevitably be a very febrile atmosphere surrounding the initial 5% change (the accompanying FUD would no doubt be typically disproportionate) |
|
|
|
Builds, but dies before ArmoryDB launches with this: def PyCreateAndSignTx_old(srcTxOuts, dstAddrsVals):
(ERROR) Traceback (most recent call last):
File "ArmoryQt.py", line 5848, in <module>
checkForAlreadyOpen()
File "ArmoryQt.py", line 5829, in checkForAlreadyOpen
from armoryengine.ProcessMutex import PySide_ProcessMutex
ImportError: No module named ProcessMutex
Traceback (most recent call last):
File "ArmoryQt.py", line 5848, in <module>
checkForAlreadyOpen()
File "ArmoryQt.py", line 5829, in checkForAlreadyOpen
from armoryengine.ProcessMutex import PySide_ProcessMutex
ImportError: No module named ProcessMutex
|
|
|
|
There are several developers working on PoW changes already , but what we need is proper peer review testing and a big bounty for this work. I am willing to donate btc and help fund raise for this , but we need 3 trustworthy an public people to handle the funds. Who is interested or who should we ask to get this started?
The "public" stipulation may be difficult to satisfy. Irrespective of how much support we can build, whoever accepts an escrow role is sticking their head above the parapets rather significantly (Bitfury have already threatened legal action against PoW changes, although against who is undetermined I believe) Can the several developers not present their designs, rates and also addresses to donate to? |
|
|
|
|
I really mean it, you're a terrible communicator, like verbosity incarnate. Please work on using fewer words, and on presenting your thoughts clearly.
|
|
|
|
Unlike "chair manufacturing" (where you are closer to completing it after 5 minutes of work), you are never any closer to solving a block. If the hash rate is balanced with the difficulty, then it is an average of 10 minutes until the next block will be solved. If the whole world under that condition has been trying for 9 minutes without a bock yet, it is still an average of 10 MORE minutes until the a block is solved. If the whole world has been trying for 40 minutes without a bock yet, it is still an average of 10 MORE minutes until the a block is solved. Nobody every makes any progress or gets any closer, but sometimes someone gets lucky and wins the NEXT block hash they try. Meanwhile everyone else just keeps trying, knowing that the odds are that evetually they will get lucky on the NEXT bock hash they try.
yes, this is the statistical concept of "independent trials" in action |
|
|
|
I highly doubt now that there will be a fork.
But people are correct that you need to have ownership of your private keys on devices you control to be safe. The worst place to "store" bitcoin would be exchanges.
This latest push will go the same way "Classic" and "XT" did, which was nowhere....
Fork is still a possibility, good executed and seamless fork is nothing to be afraid of, it is split we want to avoid. I think that 51% hashpower of BU miners and the BU emergent consensus mechanism could be used like a weapon to kill Bitcoin with kindness, like the gentle giant character in "Of Mice and Men". Or at least that's what the Unlimitards will say publicly. If BU pushers can sybil attack the network with >51% BU nodes, and force a hard fork split with >51% hashrate, we may be a little screwed, as follows - The sybil nodes vote for 1.01 MB
- BU miners mine 1.01MB block
- BTC chain elicits chain fork because >1MB
- BU miners mine <=1MB block
- BTC chain re-merges with BU chain, because >PoW
- BTC chain orphans every block since the 1st split
- BU miner mine 1.01 MB block
- Rinse and repeat
It's important to note, as long as BU wreckers control >51% of nodes, they can force the miners into a 1.01 MB > 1MB > 1.01 MB > 1MB dance in perpetuity. Bitcoin itself would be forced into an emergency hard fork if that happened, and it would almost certainly need to be a PoW change, unless there is a less disruptive solution. And it need not be like that, if we can agree to a progressive PoW change and roll that out, before BU do something like this. "But Carlton, why would Jihad and Vermin want to decimate confidence in Bitcoin and the whole cryptocoin field, throwing away their valuable BTC and ASICs?" I can think of several $million reasons, some of which could include young pop stars sitting on Roger and Wu's faces, i.e. the sort of favours money alone can't buy. |
|
|
|
|
Well, it was a terrible explanation. Using a cryptographic concept to metaphorically explain another is bound to confuse anyone reading
Please stop taking up so much space to say nothing, you're not a very good communicator, and it's a waste of everyone's time
|
|
|
|
If you are selling chairs, then your PoW is a chair, it doesn't matter if it took you a week to make your chair, and somebody else only took an hour, you both have a chair to sell. You don't have to burn your chair if you complete it five seconds after somebody else. Are you trying to imply that manufacturing chairs, or anything for that matter, is 100% energy efficient? Or 100% material efficient? I'm not sure where I'm going with this concept. I just got fed up with everybody talking about orphaned blocks, and ignoring aborted blocks. Both are killed by Bitcoin, it's just a question of when they are killed - before or after birth. Either way, they are both a non-productive use of energy.
Ok, you actually don't understand proof of work, then. You may as well say that every hash that doesn't satisfy the difficulty threshold is a waste with that sort of logic. This is a blockchain, and you can't cook a blockchain without orphaing some blocks. Orphan rate has improved over time, and that's as close to "perfect" as one can get, it's in the inherent nature of the tech. |
|
|
|
Without this attack, Bitcoin may not be able to make a giant leap ahead which is long due and overdue. That should be considered as sort of katharsis that Bitcoin should necessarily go through. Indeed, going the hard way is likely not the best way, but there may not be any other option left
As I'm about to explain to BillyBob, it need not be the hard way, if we build support early enough. PoW can be a staged soft-fork, making 5% changes to the SHA-2/newPoW balance over time Changing the PoW would leave a ton of good miners out of the game, with bad financial result as their ASICs would become useless. It's still a clusterfuck of a solution.
Ah, but look at the actual PoW change plan that's gaining traction: https://bitcointalk.org/index.php?topic=1833391.msg18309140#msg18309140If we popularise that plan, no clusterfuck is necessary. It will be smooth and painless. There's no easy solution, all of them would lead to a massive price crash, which is precisely why there will be no HF and no attack. This is all a big bluff, unless all those people pushing for BU are getting paid to kill bitcoin.
I think there isn't going to be a HF. You should read my post above. The danger is that the BU team give zero fucks about what is good for mining, Bitcoin or cryptocurrency. If that's true, and it looks alot that way, BU hashpower attacks like that can cause a huge amount of damage to the credibility of Bitcoin, some developers at Core might have to leave, and the network effect that makes Bitcoin valuable could be seriously damaged. It took time to build this momentum up, and it would take more to regain it. An orderly, pre-emptive change to an ASIC resistant PoW is literally the only thing we can do to stop that, and I'm very concerned that the "destroy it at all costs" MO is what's driving this. Jihad and Vermin can just accept multi-million payoffs in fiat, why would they care what happens to Bitcoin if that's the situation behind closed doors? BU is already losing hashing power and segwit is gaining it. This may have been a troll job to get people buying alts. A lot of people did a lot of money the last few days with this.
I doubt this much effort would be put into trolling the Bitcoin price. Segwit activation can't happen without major fireworks whichever way you want to look at it, I'd be amazed if Jihad and Vermin give it up and activate Segwit. |
|
|
|
You cannot lie down with dogs without rising with fleas actual lol they don't have many ways in which they could actually hurt it. I'm saying that with the attacks they can use with >51% BU hashing power, they can hurt Bitcoin. Bitcoin would recover, but it might take time. It can't be killed, but it can be badly injured. We should not let even that happen, and the only way we can disarm this weapon (hashpower combined with BU design) is to nullify the hashpower. PoW must be changed, before these assholes get a chance to use their weapon |
|
|
|
the same pools that were mining segwit before are still mining it now, so there doesn't appear to be any increase in support and this is just variance related to pool luck.
It could be those pools (BCC and Bitfury) have increased their share of the hashrate. Which of course is also temporary If we are counting on Voger Rer and Jihad Ackbar's supports for a recovery then bitcoin was already dead for a looong time. You just described what a centralized currency is, bitcoin. It's pretty annoying to know that those two actually have the power to destroy bitcoin. Wow. ASIC's boys. ASIC's killed bitcoin.
We've really got to do this PoW change, we're being given no choice BU can just attack without any user support, it's pretty clear that they just don't care about keeping up the charade, really. And they can do this at any time, and will likely choose their timing carefully. If the PoW change isn't at least already in progress by the time BU inevitably do attack, we're far more screwed than we would be otherwise. The alternative is to do a sudden emergency change, as suggested by the Core devs and others, and that's just an invitation for BU to attack. I hope literally everyone can rid themselves of the naivety I'm seeing in some people: BU is intended as an attack, and it will be used that way. Waiting around until they attack is not an option |
|
|
|
So what's the bottom line of all this really?
Should we completely stay away from Bitcoin for the time being so that if things go massively awry (blockchains splitting, then reemerging and total chaos setting in eventually) we won't be affected? Will we effectively double our balances if the split is there to stay, and thus it might make some controversial sense to actually buy even more bitcoins since they will get doubled after the split? Really, if one coin fails, the other takes off for real and thereby we may profit from the split?
Until something is introduced to stop the re-merging attack I'm describing, it's difficult to recommend any course of action (i.e. do nothing) Bitcoin could change to different magic bytes. BU could come up with an excuse to change their magic bytes to Bitcoin's newly changed ones, so that won't work. Bitcoin could stop following the chain with the most cumulative proof of work. That's a terrible, terrible idea for a whole host of reasons. Maybe there's a way of creating some kind of marker other than the magic bytes that cannot be imitated by the BU chain, but I don't know if it's possible. And I hope we're all seeing what a problem this is: BU is designed like an anti-blockchain weapon. There are probably more ways to disrupt than I can think of, but this attack is more than effective enough, I hope that's sufficiently clear. |
|
|
|
Of course I understand the "value of cumulative hashes in a PoW scheme". It is a cryptographic securing ("signing") of a specific chain over another one ; the only way to make a "false copy" is to spend more hashes on the false copy.
Note that most cryptographic systems introduce an asymmetry in the difficulty for the "good guy" and the "bad buy". If I provide a signature of an original document, the making of that signature doesn't cost me a lot of effort, but for the one trying to make a false document with my signature, he has to essentially brute force my public key, which is an infeasible amount of work. This is why a digital signature is an efficient way of securing a given document.
If I were to "sign my document" with PoW, then I would have to spend JUST AS MUCH effort on making the signature, than the attacker. In fact, the one with more hash power would win: perfect symmetry between the "good guy" and the "bad guy". This is the problem with PoW. The "security" comes from the fact that we assume that the good guys wasted most. As I said, you don't get it 1. The hashing stops the whole blockchain being recomputed and the ledger being entirely altered. Signatures have nothing to do with that. Zero. 2. The cryptographic signatures (and the corresponding public and private keypairs) are a completely separate form of security. With an immutable blockchain of transactions (which point 1 provides), the keys and the signatures secure the rights to moving BTC funds between one public key and another. If a transaction between to public keys doesn't have a valid form of signature, it gets rejected. If you're not capable of conflating very, very basic concepts into a total mess of an incomprehensible non-sensical "description", then please be quiet |
|
|
|
“While CIA assets are sometimes used to physically infect systems in the custody of a target it is likely that many CIA physical access attacks have infected the targeted organization's supply chain including by interdicting mail orders and other shipments (opening, infecting, and resending) leaving the United States or otherwise,”
this would never be possible without insiders in the company or direct cooperation by Apple with the agencies
basically Exactly. Look at the quote from Wikileaks above. How can mailed packages containing iPhones look brand new and un-tampered with, if the packaging for the phone itself has been opened to infect the device? There is only one foolproof way to get the phone looking like new again: send it back to the Apple factory assembly line to replace all the transparent plastic packaging needed to infect the phone. Wouldn't that take a while? Wouldn't the time spent waiting seem a bit strange to the customer  And isn't all this a little too elaborate? If you need corrupt factory workers working for the CIA at Apple assembly lines (which are gonna be mostly in China, of course), why bother with all the messing around? Why not just infect each and every phone as it comes off the production line, it's far cheaper and easier (and then, only the more senior staff need to be corrupt CIA workers, not regular factory floor workers) How come Wikileaks can't figure this out for themselves, surely they're not so badly informed that they really believe any of this "intercepting mail" nonsense |
|
|
|
the way I understand Jet Cash is that they call an "aborted block" a potential(!) block which the miner stopped working on when somone else already found a solution for it.
[snip]
Whether this block is later orphaned or not is a different topic.
So really you're arguing about the terminology. But you're not arguing about the fact that it's not a waste. What about the suggestion that reducing the block interval would "fix" this "problem"? It would in fact make it worse, wouldn't it? What about the suggestion that so-called aborted blocks (really unpropagated orphans) slow the network down? I'm not seeing it |
|
|
|
There are essentially two fundamental problems. The first is with Proof of Work. Proof of Work needs to destroy value in order to be valuable. Proof of work is perfect to kill seigniorage, but is a totally horrible way to have "cryptographic security", because there's no advantage for the "good guys". The "good guys" are those that can waste most, not those that "posses a secret key" (which is the usual form of cryptographic protection).
The race to waste most leads to economies of scale (ASICS...) and hence to a concentration of producers of proof of work.
This leads to two problems: centralization, and the fact that those producing proof of work are not necessarily stake holders in the system.
But there's another problem, which is the fact that blocks are rewarded in the first place in "big lumps". This makes that there is a fight to make blocks, and to deny others to make blocks. As such, "making blocks" becomes a huge lottery with big rewards, where pooling together always pays against playing solo. This is a second vector of centralization: pooling.
Finally, the fact that there ARE rewards to "secure" the chain means that strategies to obtain those rewards are more important than correctly securing the chain, and to correctly process transactions. If fees are due, then there will be strategies to extract as many fees from the users as the market can bear, and not the optimal point of resource utilisation.
The whole system of blocks, that are rewarded, and that this reward is an incentive for people to "secure" the chain as by-product, leads to a dynamics that is centralizing, and far from optimal for the users and stake holders. 1. You don't understand PoW's purpose in the Bitcoin system, at all 2. You don't understand the value conferred by cumulative hashes in the PoW scheme 3. As a result of points 1 & 2, you don't even understand the blockchain concept So why should anyone be expected to read your overlong posts when you don't even understand some of the fundamental ideas behind Bitcoin? |
|
|
|
I understand the point of PoW. I'm just pointing out that an aborted block is just as much a waste as an orphaned block.
Yes, but you still don't understand orphans No-one is making the distinction you make between orphans and abortions, and the reason is that they're the same. Your description of an aborted block is simply one way that a block can be orphaned |
|
|
|
|
It's a bit complicated to explain.
Ideally, BU would be using a different blockchain, as it is programmed in a way that breaks Bitcoin Core's consensus rules, and that should hard fork the blockchain.
But because the BU dev team have refused to alter the magic bytes that Bitcoin uses to identify the legitimate blockchain, it could actually end up re-merging with the Bitcoin chain after the fork, orphaning all the Bitcoin Core blocks that happened before the re-merge (so trying to get transactions confirmed on Bitcoin itself could be made impossible)
All BU would have to do would be to push blocksize up to create the hard fork (using sybil nodes to vote and getting the miners to produce blocks over 1MB), then do the same in reverse, get the sybil nodes to vote blocksize back below 1MB, and the miners would have no choice but to accept that. The BTC blockchain would then detect that 1MB BU blockchain with more cumulative PoW as the "real" valid blockchain, and re-merge wiith the BU chain. Total chaos on the regular Bitcoin chain, and everyone has no choice but to stop accepting BTC.
This all assumes BU has 51% hashrate, and that they have enough resources to run 51% BU sybil nodes on the network to stack the blocksize voting.
And, this is exactly the gaping security flaw that everyone has been talking about with BU (although it's only one way to abuse the mechanism, there are almost certainly other ways)
|
|
|
|
|
Show Posts
