More serious issues might be possible when there is a reorg. For example, when one coinbase is disconnected, all of its duplicates will also be disconnected.
Yeah, which in theory means that all the nodes that had the block containing that duplicate coinbase in their main chain would wrongly treat an attempt to spend it as invalid and all those that hadn't would correctly consider it valid. This may be usable to create a persistent fork in Bitcoin - that is to say, one that can never actually resolve itself without a huge amount of manual intervention by everyone involved. |
|
|
|
So by "digging" do you mean you read the first thread, posted several months ago or do you mean you duplicated the effort others already went through?
He might be here from Something Awful. From what I've seen they seem to be very proud to have rediscovered all this recently.  |
|
|
|
Some of the security of bitcoin comes from the fact that it's economically more sensible to cooperate than to defect— that doing nasty things to the system will _lose_ money for the people who have the ability to do it (e.g. blockchain bloating attacks, and transaction prohibition attacks). But a key element in that is educating people about whatever is in their best interests. As a miner, it's not in your interest to cause increased centralization or enable attacks. Ah. The problem here is that your argument is wrong. As a miner, it's not in your interest for other miners to cause increased centralization or enable attacks. Unless you're a really huge miner your own choice as to where to mine doesn't make very much of a difference to Bitcoin as a whole - if enough other miners choose to help do nasty thing to Bitcoin they will happen, if they don't they won't, and your own share of the total mining done is too small to make a difference either way. However, choosing not to mine at places like GPUMAX - even if they don't have the restrictions on what work can be sent - does have a huge effect on your own income. So basically it's in your interest to mine for the highest bidder. |
|
|
|
Bitcoind itself however seems to be just one single software with no real competitors (yes, I know about bitcoinj) where many people complain a bit about this or that but noone dares/wants to implement their own version. Transactions are already now complex enough to implement, that it seems noone so far even dares to do another implementation. I was considering re-implementing parts of it, re-using some code from the original client, but there's some scarily nasty quirks Bitcoin has involving duplicate coinbase transactions that make that a frankly terrifying idea right now. |
|
|
|
It seems like some of them are indeed pipelined, but the level of pipelining is equal to the level of unrolling. It seems like ztex uses 125-way unrolling and 125-way pipelining. So the design computes in a single clock rounds of hashes for nonces (N-124 to N). When nonce N is on the input the output shows the final hash for nonce N-124.
In general a 125-way unrolled design can be pipelined anywhere from 1 to 125 stages. ztex's latest code actually has two pipeline stages for every SHA-256 round, which is partly why it's so much faster; ISE has trouble routing the design efficiently. It varies as to how much sense this makes though. Also, the FPGA synthesis tools support something called register rebalancing where they move the registers that divide up the calculations into pipeline stages backwards and forwards in order to get the best speed, so it's not necessarily a simple question of one (or two) pipeline stages per round. Somebody else posted a code that explicitly uses ternary adders Y = A + B + C. As far as I know Xilinx ISE will always synthesize adder trees Y = (A + B) + C or Y = A + (B + C) or Y = (A + C) + B.
Actually, I seem to recall that it's quite happy to automatically use ternary adders on Spartan-6. |
|
|
|
Do you have a magic solution to recipients losing the freedom to have complicated rules because the sender doesn't want to handle the TXN fees or risk of slow processing? The concentration of more data in unprunable unspent outputs? etc.  Thats it— it's just not simply "big addresses", there are other issues even if they aren't super major. Nope, no magic solutions to either of those sadly - there's a reason that I supported the idea of P2SH back in the OP_EVAL era before the whole thing turned into a circus, and in fact Coiledcoin started off as my personal testbed for playing with it with all the mainnet checks still in operation. Something that works is better than something that might work eventually though. |
|
|
|
Huh? Lose money? What?
I don't think you understand how this works.
If the roll-out of full validation is postponed and eleuthria - or any of the other pool owners - doesn't postpone it on their pool too, there's a rather large chance that they'll get stuck mining their own fork of the network that no-one else will accept. Since BTC Guild is PPS, that means that it'll keep paying out bitcoins for shares but won't earn any block rewards to pay for those shares, leaving eleuthria rather badly out of pocket. Once we do have full validation of BIP 16 there will of course be a similar problem in the other direction for pools that don't upgrade to a version that does the new validation, but for various technical reasons that's much lower risk. |
|
|
|
Due to the impending server switch, I have not been making an official decision on BIP16/17. I will likely side with whatever most of the developers have sided with, which at this time is BIP16 (the only major dissent has been from Luke). But we will see what happens between now and the second week of February when I compile a fresh bitcoind for the new server.
Hmmm. Well, it looks like the original switch-on date of the 15th is going to get postponed, quite possibly even repeatedly, so I presume you'll be able to restart bitcoind with the appropriate options as and when necessary? Bearing in mind of course that you will lose money if you fail to postpone BIP 16 validation and your node does full validation of BIP 16 transactions in blocks before it should. |
|
|
|
Yes. Some of us are perfectly fine with complex transactions having addresses a hundred characters long and that is just as legitimate an option as BIP-16, 17, or anything else that could possibly replace them.
I challenge you to demonstrate how well informed you are on this sub-subject by linking to posts giving at least three total distinct arguments against that position. Some of them may be less important than you think. For example, I seem to recall you were worried that someone malicious could easily create their own pay-to-script address that only differed from the genuine address by a few characters but could be redeemed by them instead. There's an obvious solution to that if you don't care about address length: append the 160-bit hash of the script to the start of the address. That way, the more characters at the start someone compares, the harder it is to trick them. |
|
|
|
No, he cannot make anyone upgrade. Every single miner chooses for himself which version to run. No matter what Gavin does, miners always have the choice whether to download and run the new changes. If 51% of the miners don't do that, then nothing will change.
If 51% of the miners don't upgrade, then their blocks will be treated as invalid to those that do upgrade. All the developers need to do is to convince enough of the users that if they don't upgrade they'll be screwed, and they have the advantage of being able to broadcast alerts to them through the client itself. |
|
|
|
Okay then, so is it any different from the inevitable release of BIP16 without testing just because one developer thinks that way? And the fact that miners refusing to accept the change themselves get rejected from the network? I had faith in Bitcoin's decentralization before. But unfortunately for me not to accept P2SH is for me to fight a losing battle.
Misinformation. Please get a new source. In the case of P2SH, the development team could easily deploy this functionality against the will of the miners: they'd simply issue a new client that enforces the BIP16 rule and send an alert which would pop up a message for every bitcoin user telling them to update. Miners that failed to update would eventually extend a chain containing a contradictory transaction and from that moment they would no longer be miners from the perspective of the majority of Bitcoin users, no matter how many yottahashes they had. Done.
(If users reject the change too—well, they can get themselves some new developers, but the miners never come into that picture except as users) Now, a fun puzzle for you - how can users find out enough information to know whether to reject the changes, given that the Bitcoin developers in general and particularly gmaxwell are opposed to anyone saying anything on here beyond the fact that the developers think this is a good idea? BIP16 isn't inevitable. Gavin implemented BIP16, checked it in, and nothing happened, because Gavin cannot force any change on anybody. Bitcoin is decentralized. He probably could, and in fact one of the proposed solutions to BIP 16 missing the deadline involves him doing exactly that, it's just that he's chosen not to approach the problem in that way. So far anyway. |
|
|
|
What LukeDashJr did to coiledcoin, without his users consent, or permission, is proof positive of why he needs to be severed.
Perhaps ironically, the entire reason I launched Coiledcoin in the first place was because I saw that P2SH was turning into a fiasco and didn't expect it to launch any time soon in any form - and it would probably have failed to do so even without Luke's meddling. Gavin was doing the equivalent of a hairpin turn in a supertanker and his code kept turning out to have bugs that would cost miners money, and none of the reasons for the last-minute change or the rushed schedule were terribly convincing. It's actually gotten worse since then. gmaxwell keeps accusing anyone who dares to tell end-users about any of the technical details of spreading FUD by drawing the users' attention to something that's none of their business and is trying to shut them up, whilst spreading his own fricking FUD about Luke Jr's proposal (no it doesn't reverse the bugfix that evaluates scriptSig and scriptPubKey seperately rather than appending them, nor can it cause the kind of security vunerabilities that split protects against). Gavin claimed that Deepbit was somehow attacking Bitcoin by not immediately adopting his buggy code, despite the fact that hardly any of the other pools had either, in an attempt to force Deepbit to do so and use their hash power to force all the other pools to follow suit. And so on and so forth. Luke's actually been polite by comparison and frankly that's scary. |
|
|
|
It is executed 64 times. So a fully looped version of SHA-256 code (in C# or on a FPGA it doesn't matter) would be something like this in psuedo code:
Initialize all variables, and inputs, round = 1
while round <=64
(
perform SHA-256 round
round++
)
record output Which is actually a reasonably sensible way of implementing SHA-256 in an FPGA if you just want to have an efficient way to hash arbitrary pieces of data rather than do something like Bitcoin mining or password cracking. If you're only hashing a single message there's no parallelism that can be exploited - you can't start work on any chunk of the message until you've completely hashed the previous chunks - and no reason to unroll the hashing. That's partly why off the shelf SHA-256 cores aren't much use for Bitcoin mining. |
|
|
|
The Bitcoin system is _NOT_ up for a majority election. Not a majority of hashpower, not a majority of people, not a majority of money.
For example, what happens if a super-majority—even 100%—of the current miners decide that the subsidy should be 50 BTC forever? NOTHING. Miners who change that rule in their software simply stop existing from the perspective of the bitcoin network. What happens if a super-majority—even 100%—of the current miners decide that they're going to mine a transaction that takes all of your Bitcoin and gives it to them? NOTHING. Miners who violate the protocol rules stop existing from the perspective of the bitcoin network. What happens if a super-majority—even 100%—of the current miners decide that they're going to lie about the current time in order to mine 20 million BTC this year instead of over the next decades? NOTHING(* ignoring the timewarp bug). Miners who produce objectively incorrect blocks are ignored by the Bitcoin software run by everyone else.
Your bitcoin is secured in a way that is physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter a majority of miners, no matter what. This is only true so long as you assume that people would go on and continue to use a version of Bitcoin when they know that there's more than enough miners hostile to its existence that a small proportion of them could execute a 51% double-spend attack and that they have an incentive to do so. In fact, if 100% of current miners leave even a small proportion of them could just block all transactions from getting confirmed. As you've pointed out elsewhere, in order for Bitcoin to work miners need an incentive to co-operate rather than defect. Once they've all announced they're planning to defect from the developer-approved version it's likely to get screwed badly. In the case of P2SH, the development team could easily deploy this functionality against the will of the miners: they'd simply issue a new client that enforces the BIP16 rule and send an alert which would pop up a message for every bitcoin user telling them to update. Miners that failed to update would eventually extend a chain containing a contradictory transaction and from that moment they would no longer be miners from the perspective of the majority of Bitcoin users, no matter how many yottahashes they had. Done. Of course, getting users to upgrade seems to be even harder than getting miners to upgrade, which is presumably why you're not doing it this way. Plus, the uncertainty as to which version to use would probably be hugely disruptive in itself - the only safe thing to do would be to just stop using Bitcoin until the dust settled and everyone had agreed on which side of the resulting fork to use, because if the miners are hostile and have a financial incentive to destroy the developer's side of the chain fork... |
|
|
|
[Look the Statix III is a 65nm chip. Alterra isn't even making it anymore. They want to sell Stratix IV and soon they will need to sell Stratix V. They want that inventory gone. Gone from their website, gone from wholesalers, gone from retail outlets. when Stratix V is in full production it becomes the high end part and the Statix IV becomes the value segment. The Stratix III is just a third wheel. I'm not sure it works that way, though - there's always customers out there who've built designs around older chips and for whatever reason either can't or don't want to move over to the latest and greatest. From what I've seen the FPGA vendors are really slow at taking older chips out of production for this exact reason. Case in point: The CEO (and probably sole proprietor) of ZTEX did. Before the 1.15x module, with its 8 Amp core voltage supply, came the 1.15d module, and the originally recommended supply for it http://www.ztex.de/usb-fpga-1/pwr-1.0.e.html only sported a 3 Amp core voltage supply! He found out the hard way that all these unrolled loops of SHA-2 cause something like 50% of all flip-flops on the FPGA to switch simultaneously, and thus blowing even the most conservative power estimations out of the water. That board wasn't really designed for Bitcoin mining in the first place - he's been selling them on eBay for ages as generic FPGA development boards. |
|
|
|
For additional context, as a result of developing it I found and reported a couple of fairly nasty security vulnerabilities in the OP_EVAL implementation that BIP 16 could've inherited - though I believe Gavin may have already found and fixed the second one and just not notified the pools about it. Also, CoiledCoin has been dead for a long time now courtesy of luke-jr having more than 51% of the hash power and using it to block transactions. It's complicated and mostly irrelevant which is why I didn't mention CoiledCoin in the first place. |
|
|
|
So apparently, despite the fact that the miners are currently getting to make the decision and are the ones most directly affected by the bugs resulting from the code being deployed in the way it has been, letting them decide is an attack on Bitcoin: 23:32 < gmaxwell> luke-jr: perhaps because you're in charge of 400GH of other people's hash power you're happy to say that a coinbase tally is the right way to determine support, but I don't think thats good for bitcoin.
23:34 < gmaxwell> If miners were to force this by simple majority of hashing power, but the community opposed it — we'd call that a 50% attack. However, trying to give users enough information to make a decision is also apparently unnecessary and everyone should just trust the developers to make the right decision on their behalf. Sigh. Wonder if people have underestimated just how fundamentally Bitcoin relies on its developers remaining honest. This isn't true. Yes, Gavin created a bot that exploits a differential weakness of BIP17 vs BIP16. This was pretty helpful as luke was insisting there was no difference, and this let us feel out how the difference actually mattered. On the other hand Gavin didn't even try and create a bot to exploit the weakness that exists in BIP16. It also took him quite a while to admit that he'd done it leaving everyone puzzled as to what was going on and who was doing it. (Either would have been quite easy to exploit on testnet and a bit harder to exploit elsewhere from what I recall; testnet isn't an entirely realistic place to test this kind of thing.) |
|
|
|
Wow. 75 Mhash/sec is fairly impressive for a DE0-nano if you can pull it off. I've got one sitting on my desk mining away and have only managed to get it to 25 MHash/sec - and that's using the entire FPGA, some slightly mind-warping optimizations, and a whole bunch of luck. (The Altera toolchain actually reckoned this'd use more resources than the FPGA had available.) Plus I had to upgrade the cooling and power regulation circuitry and power it off a wall-wart rather than USB to get that. The stock DE0-nano uses linear regulators for everything, which means that for every milliwatt the core consumes three times as much power is dissipated by the voltage regulators as heat. I can confirm the 3.6GH as he had it running on my private pool server for a little while ( Although a software bug caused it to have 100% rejects  ). By my math (Guestimation based on submitted shares, ((shares/total_seconds)*4294967296=4.3GH/sec) the hash rate was a little higher though  Speaking from personal experience, I tend not to count anything as working until its shares are being accepted. It tends to be the most thorough test. |
|
|
|
While practical testing is valuable, it should have no bearing on which BIP is accepted. These BIPs are protocol changes, and providing a stable implementation is the duty of the client, not the protocol. That being said, I'm confident that my bitcoind BIP 17 backports are more likely to hold up to testing, provided the signature check is sane (signing the relevant parts of the transaction), which would actually be a bug in the existing protocol if it weren't.
I'll see if makomk is up to this. His "coiledcoin" post implied he might be.
I'm not really up to anything right now. Coiledcoin's dead (probably together with new altchains in general), and it's not really worth starting anything Bitcoin-based at this point in time. |
|
|
|
It is pretty darn close to what I think would be the ideal solution. It even has a byte at the beginning of the redemption script hash that specifies what hash type to use (OP_HASH160) !
Except of course that you can't change the hash type - not even to the other hash type that Bitcoin scripts already support, plain SHA-256 - without getting everyone to upgrade and going through the whole process again. As soon as you change the opcode for the hash type the transaction stops being a P2SH transaction and there's no way to make it one anymore. |
|
|
|
|
Show Posts
