 Show Posts
|
|
Pages: [1] 2 »
|
Suppose for a moment that Bitcoin software would be " 'completely' open source". Would it survive?  Currently Bitcoin is "theoretically open source", which means that - in principle - everybody is able to modify the client, to setup an alternative chain with a different block chain speed, with a larger or smaller bounty, with different behavior regarding fees, with different script mechanisms and so on and so on. However, setting up an alternative chain in practice is a completely different thing. It requires quite some programming skills to be able to read the Satoshi client or the few other implementations such as libbitcoin; it requires GUI programming skills; it requires a working tool chain environment for compilation; it requires version control skills, regression testing skills, time to deal with your growing user base - and, as a result, it is not so easy. And, even if you succeed, you would still have to convince the big mining pools to adopt the changes, because otherwise your changes will never be reflected in the block chain.  Now, assume the situation would be different. For example, imagine software, in which a large number of parameters could be changed very easily, at the click of a mouse button. For example, all the essential parameters of the algorithm could be set by a script kiddie or by grandma in an "Options..." dialogue. Let us look at a concrete example: You would, as part of your wallet software as well as part of your mining software, have an option tab, where it says "mining bounty per block". You may decide on your own (1) which blocks you would be willing to accept as correct blocks (when your wallet software checks the block chain for correctness) and (2) which blocks you would hand out to fellow mining pool members, in case you operate a pool, and (3) which shares you would be mining on, in case you participate in a pool. Alternatively, we could assume a perfectly computer-literate world, we teach C++ and assembler in kindergarden and if you wanted to have you own version of the wallet / mining software you would just write that up between breakfast and lunch.  I am completely aware that this would probably not work in the current protocol structure and would, no doubt, generate quite some chaos, because block compatibility would be broken. Nodes which changed the parameters in a stupid way would lose all their coins and much more nasty stuff. Still, please stay with me for a moment for the following thought experiment. One day my electricity bill goes up - and I feel tempted to change the bounty parameter from 50 to 60 BTC: I would accept every block as valid, if the coin base was 50 BTC (to maintain compatibility) but I would also accept blocks with a bounty up to 60 BTC. I would have a small number of my GPUs do mining on 60 BTC bounty blocks and I would publish this change on the web page of the pool I operate. (Remember, we assume that all this does not take a lot of programming, web page redesign, pool software redesign...it is just an experiment I can start with two clicks in my options dialogue). Interesting enough, since I am a medium sized pool and my mining community lives in the same region with increased electricity bill, my fellow users adopt this move. We are even lucky and win two or three blocks in a row with this new strategy. Now, other mining pools watch this with some attention: Since my fellow miners just split a 60 BTC block in my pool, some miners leave their pools and join my 60 BTC pool. After a while some pools move on and adopt my 60 BTC policy. More and more users, miners and pool participants adopt the change: It is easy to set up (just a click with the mouse) and it can be undone quickly, if it proves a bad idea. After 4, 5, 6, days a majority has moved to a 60 BTC chain (of course, back compatible to the original 50 BTC chain). NOW someone comes up with this idea of setting this parameter to 200 BTC. At first, many are sceptical. But as soon as a pool wins the first two or three 200 BTC blocks in a row...again some miners change their mind. After some 4, 5, 6 days... OK. By now you have got the idea. (And, again, the disclaimer: It is not a request for changing the algorithm but a request for comment !) NOW my issue: I would like to understand if there is a mechanism which would prevent such a "drift" in the parameters of the algorithm. Right now the though experiment is absurd, because it takes many days of hard work to get a different algorithm running, and even much more work to convince even a small number of miners or fellow poolers to spend their electricity bill on the different algorithm. BUT WHAT IF? Is there any additional mechanism which would prevent such a drift from happening - beyond human laziness of programming and testing the different algorithm and beyond that human inertia and resistance against innovation("I have mined using the original Satoshi parameters for 2 years and I will mine using these parameters until I die"). With regard to the amount of the bounty, there might be an obvious mechanism: Inflation. As soon as we change the bounty from 50 BTC to 500 BTC, the real-world value measured in dollars or working-hours should drop to 1/10. So, maybe a different move might be more interesting. A few miners might decide to drop the bounty from 50 BTC to 1 BTC. Why should they? Well, that's easy. IF they do so and succeed to convince a sufficient number of fellow BTC millionaires, Bitcoin would enter a fast deflationary development, which is beneficial to all those, who already own many BTCs. All of a sudden the value of their BTCs rises and rises - all they have to do is organize a sufficient number of fellow miners who follow their modification, a bit of luck to win some blocks and catch the attention of more miners. But what about the other parameters? For example, block chain speed (we would double the chain speed and half the bounty, so that there would be no bounty effect). Or, somebody might suggest using SHA512 instead of SHA256 as hash. My incentive for this thread is not a modification of the algorithm but an understanding of it's social mechanism. The Bitcoin nodes form a swarm of networked individuals. Currently, they all use the Satoshi client, simply because it is there and working and everybody does so. If a small number of nodes in the swarm follows a different course and benefits from this change - others might join in. If the number of others, which join in, is too small, this development will die down again. If the number of others is large enough for a short period of time, the development might grow and prevail in the long run. The swarm will soon fly into a different direction. |
|
|
|
|
I am writing up a formal specification for the block chain algorithm and came across a question I was not able to settle on my own. (Disclaimer: I am not trying to make yet-another-suggestion for modifying Bitcoin nor am I proposing yet-another alternate chain. Just trying to understand).
When a block becomes orphaned - the bounty for the miners is lost, since the transaction does not make it into the "true" block chain. Life is risky and that is one of the risks of a miner. That said, it would be quite easy to change this: If someone presented this orphaned block (with correct difficulty, target matched properly etc.) to a mining node, this node could accept the coinbase transaction of the orphaned block and include it into the block it currently is working on. If this block wins, there would be 100 BTC created. Of course, there would be some checks (for example, correct difficulty, time stamp not too old, depth not too old - we want to prevent very old orphans from being use for that purpose).
I do not want to suggest that as a modification, but I would like to understand if there is any strong (technical, security, economic etc.) reason against this. (I might have missed the obvious).
One issue I see is: It would reduce incentive for miners to immediately switch to a new block, if one is found, since they could make money with old blocks. To prevent that could be easy: Pay only half the bounty for orphaned blocks; accept only blocks with with a very small depth difference.
So far as I see, it would not break correctness/security of the algorithm, just mess with miner incentives.
Thanx for listening.
|
|
|
|
|
Dear Bitcoiners,
on September 20 the German city of Braunschweig will host the annual meeting of the German Computer Society (GI). At this event we will present a half day tutorial on Bitcoin and a half day workshop with published academic contributions.
Both events will be mainly english spoken, but german contributions will be accepted as well.
More information will be found here or on a web page currently under development.
Contributors will be:
Clemens Cap, author of a German academic article on Bitcoin in HMD Wirtschaftsinformatik
Kay Hamacher and Stefan Katzenbeisser, who spoke at the 28th CCC event in Berlin on Bitcoin.
Jörn Loviscach, who wrote an article on Bitcoin in c't.
Best regards
Forp.
|
|
|
|
|
Liebe Bitcoin Gemeinde,
am 20. September findet in Braunschweig an der Jahrestagung der deutschen Gesellschaft für Informatik ein halbtägiges Tutorial und ein halbtägiger Workshop zum Thema Bitcoin statt.
Mit von der Partie als Vortragende sind:
Clemens Cap (Autor des Bitcoin Artikels in der HMD Wirtschaftsinformatik Nr. 283)
Kay Hamacher und Stefan Katzenbeisser (Vortragende zu Bitcoin am CCC Jahreskongress in Berlin)
Jörn Loviscach (Autor des c't Artikels zu Bitcoin)
Für den Workshop suchen wir noch Beiträge.
Mehr Informationen dazu folgen hier bzw. stehen demnächst im Netz.
Gruß
Forp
|
|
|
|
|
Currently, Bitcoin is sealing transaction histories. If a new installation wants to know if there are coins stored at address X which can be used, it has to download the entire block chain upto the current block and check the history of Bitcoin address X. So, there is a first transaction where this address is used. Then, depending on the user, there are some transactions, and finally we are up to date, knowing the current block. Only then can we decide about the value available at X.
This approach is completely safe, but it has a significant disadvantage. Throughout the game the storage efficiency is getting worse and worse.
There is a different approach, which is sealing state. In this approach every block seals the state of all addresses. If this approach is used, knowledge of the latest block (and proof of its "correctness") would be sufficient to know the amount of money encoded at address X.
Of course, this approach is not really feasible for a number of reasons.
First, a single block would have to contain the information of ALL 500.000 and more addresses, which makes the block quite large and would delay handling and hashing the block.
Second, the proof of "correctness" cannot be properly given, since Bitcoin uses the concept that after a certain block-length after a transaction chances are small that a different, competing transaction might "make it into the longest chain". This concept does not sits well with the concept of having a single latest correct block.
However, we could combine these two aspects.
Do we, in the current moment, still have to keep the information on block, say, 1000? Yes, we have to, since Satoshi mined some coins in block 259 and has not yet used them. So we need this information. But: we could look at all the blocks 1 to 1000. Some coins will have changed owners several times and we do not really need to know the entire history of these coins in their past history. We could replace blocks 1 to 1000 by a new data structure, we might call them a state snapshot, and encode a list of all coins at their current addresses (not keeping their past). As a result, the block chain would become shorter.
Now, we could improve this. Assume the current blocknumber is B. It would suffice, if we kept the last, say, 10.000 blocks (to get the difficulty adaption working smoothly), but all the information from block 1 to block B - 10.000 could be "collected" into a snapsho-like state record.
We would thus combine advantages from two concepts: We have compact storage of that information which we must store and we would keep only so much of the development to ensure that we have the right concept of "longest" chain and to keep difficulty adaption running smoothly.
Any comments on this?
|
|
|
|
|
I am trying to understand why Bitcoin has a parallelizable proof of work.
The task of the proof of work in Bitcoin is to make it increasingly difficult for an attacker to "change" the "past" and to ensure some kind of convergence in the concept of the "longest chain" in the block structure. Also, the block bonus provides some incentive to the miner, which keeps the system running.
The currently employed proof of work schemes are parallelizable.
As a result of this, pooled mining is faster than GPU mining (250 cores) is faster than iCore 7 mining (8 cores) is faster than Celeron mining (1 core). In my opinion, this is a disadvantage, for a number of reasons:
* Larger pools have a significant share of the total hash capacity. This increases their chances for a 50% attack.
* The speed with which the block chain "converges" (or in the case of a fork "heals") is faster, when many competitors with small computing power are in competition, as compared to the situation, when there are less competitors or competitors with higher (aggregated) computing power.
* Bitcoin was meant to be peer 2 peer; pooling is in contradiction to this. The pools are the banks of tomorrow.
A non-parallelizable proof of work would still serve the same goals as a parallelizable proof of work but would solve these problems.
Of course, at the current difficulty, chances to "win" a block for a single miner would be small. This issue however can be solved easily:
* By increasing block speed and apropriately reducing the bounty, the economics could be kept the same in the long run, but the granularity of the block bounty would be adapted.
* If we want to keep block speed and bounty, we could still have miners operate several computers or GPU work on blocks, but every core would work on its own block variant. This would still increase the return on investment for the miner linearly, but it would not show the problems outlined above.
Therefore my question: Why are we having a parallelizable proof of work ??
Is there a good reason which I do not see or is it merely a historical accident (possibly waiting to be cured?) ?
|
|
|
|
Hi there. Proudly upgraded my 2x 6990 / Windows to a 3x 6990 / Debian. :-) Now I get a weird situation: I am getting the same performance as with ONE 6990. :-( This is catalyst 11.7, SDK 2.4 on a fresh Debian. clinfo, atconfig and flrxinfo see all 6 GPUs. Phoenix / poclbm see all 6 devices. I started 6 miners for 6 different pool workers and I get...a hash rate of 590 MH/s. All 3 cards get warm, atitweak reports that all 6 GPUs are working, albeit at a utilization of 30%. If I start additional miners, situation stays the same. When I start the miners, the first two miners run at 300 MH/s and on 2 GPUs. Adding miners (to the remaining 4 free GPUs) has them run slower and slower, evenly distributing the load on all 6 GPUs but never reaching more performance than I usually get on one 6990 card. It's probably not the motherboard or the CPU, since on Windows the TWO 6990 nicely produced 1,2 GH/s. After 1 day tweaking and twisting ... I am a bit desperate ... and could use some help ... please ...  |
|
|
|
Liebe Bitcoiner, da die erste Planung eines Meetings in Hamburg nicht so ganz geklappt hat ( http://forum.bitcoin.org/index.php?topic=23391.0), sich aber einige Kollegen bereits auf ein Event eingestellt haben, soll nunmehr das folgende Treffen definitiv stattfinden. Ort: Zentral in Hamburg, direkt gegenüber dem Hauptbahnhof im Hotel Europäischer Hof. Update: Als wir die Reservation in eine fixe Buchung umwandeln wollten, war der europäische Hof plötzlich doch nicht mehr frei. Wir haben aber im Reichshof, Kirchenallee 34-36, der ist gerade um die Ecke, nun eine alternative Location und die ist fix gebucht.Links zur Location:Dort sollte dann ein Raum unter "Bitcoin Workshop" angeschrieben sein. Im europäischen Hof haben wir ein Redirect aufgesetzt.  Zeitpunkt: Samstag 30. Juli, 16:00 - 20:00 Uhr. Ich werde ab ca. 15:15 vor Ort sein. Inhalte: In Form eines Barcamps. Zum Einstieg und als Appetitanregung kann ich anbieten: - Wenn erwünscht, kann ich eine kurze Präsentation zu Bitcoin machen (auf einführendem oder fortgeschrittenem Niveau)
- Wir diskutieren Herausforderungen und Entwicklungsbedarf zu Bitcoin
- Wir besprechen den Aufbau eines Bitcoin Netzwerks (Information, Gedankenaustausch, Interessen)
Infrastruktur: Wir haben vor Ort Flipchart und vermutlich Internet über WLAN im Hotel. Zusätzlich kann ich vor Ort über Laptop / iPhone eine lokale WLAN Infrastruktur anbieten und dazu eine Wiki-Server / Etherpad-artige Austausch-Infrastruktur, sollten wir so etwas brauchen. Es macht also Sinn, Geräte mitzubringen, die sich da dranklinken können. Wenn jemand einen portablen Beamer mitbringen kann und ein VGA Kabel, so wäre das hilfreich. Kommunikation: Weitere Kommunikation über das Event findet hier und in diesem Thread statt. Da ich aktuell reise (Zug, Urlaub, usw) bin ich nur fallweise Online. Das nächste Mal Freitag vormittags. Dann wieder Freitag sehr spät abends. Samstag je nach UMTS Versorgung im Zug nach Hamburg. Dort sehen wir uns dann am nachmittag. Wenn es updates gibt: Hier im Forum. Randbedingungen: Der Raum hat eine Kapazität von ca 12 Personen. Buchung des Raums macht mein Sekretariat morgen vormittags, Update: Buchung hat mein Sekretariat gerade gemacht (daher auch das Update in der Location, siehe oben) auf meinen Namen, mein Risiko und meine Rechnung. Damit daraus keine facebook Party wird: Das ist eine Veranstaltung, zu der primär jene Zutritt haben, die hier auf dem Bitcoin Forum in einem der Threads Interesse gezeigt haben; weitere Interessenten sind willkommen - bis zur Erreichung der Raumkapazität. Andererseits: Ich hoffe auch, dass ich dort nicht allein rumsitze! Zu mir: Ich bin seit 20 Jahren als Informatiker, hauptberuflich in der Ausbildung tätig und schreibe gerade an einem Fachartikel über Bitcoin. Gruß, Forp |
|
|
|
Trying to work my way through the code according to Richard Feynman's principle of learning "What I can't produce - I do not understand". So, I reached another place I do not understand.  Every node always considers the longest chain the correct one. Yes? Ok. What happens if there are two longest chains. Well, this is not a problem for the future of the entire system since, eventually, there will be a longest chain again. Odds are exponentially decreasing for a "two equally long longest chains" to survive in the long run. That said: A single node (and, similarly, blockexplorer) has at any given moment in time a concept of what is the longest chain (even if there are two equally long chains). I checked the code. In the -printblock functionality there is no clear answer to this and I did not yet manage to digest the chain reorganization algorithms to understand this aspect. So, assume there is this situation: B-C / GENESIS-A \ X-Y What does the individual node or the block explorer consider the longest chain ? GENESIS-A-B-C or GENESIS-A-X-Y ? This question might be considered academic, since in the long run one of the chains will stabilize and become the longest. But there might be one interesting aspect here. I think, for quick chain stabilization, it is important that the nodes pick the same chain as the correct chain. Assume, 1/2 of the nodes pick GENESIS-A-B-C and the other 1/2 of the nodes pick GENESIS-A-X-Y. In this case the "battle" for the right correct chain might take much longer. Now assume that all nodes pick GENESIS-A-B-C. In this case the "battle" will be over quite quickly (not necessarily in favour of GENESIS-A-B-C though, but the chances of oscillating back and forth should be smaller). Any ideas on this? |
|
|
|
I am trying to make my daily advancement in Bitcoin knowledge and got stuck again. Trying to understand the blockchain a bit better, I stumbled upon this transaction here: http://blockexplorer.com/tx/719eb1028a473ac8e804be26542ba3a90effd81e852f83774042ece9ff5bdd04Looks like this is 1AZUP.... spending some of his/her hard earned bitcoins. But there are three things I do not understand. Where is the economic sense of paying to 113 recipients in one transaction? And how would one generate such a transaction? I could come up with an idea to these two aspects: Probably the tx has not been generated by the GUI client but by a command line or RPC client. And, maybe, it is a mining pool paying out all the fellow miners in a single efficient transaction. Smart. But how likely would it be that the recipients would ALL have their addresses start with the same prefix of "1Kr" This probability is ...um... zero. So this is not the correct interpretation. So what is the correct interpretation here ? What is the deeper mystery of things going on here |
|
|
|
Never change a running system.  I felt tempted to upgrade AMD Catalyst from 11.5 to 11.6 (link at AMD). Afterwards GUI miner did not work so I removed and reinstalled the new version. This is one windows 7 / 64 bit. Since then my system is unstable. This means: I get a frozen system in 10 - 20 % of the restarts and the system stops mining and freezes after some 8 - 15 hours of mining. No error logs or events pointing out the reason. I am not overclocking or otherwise provoking things and before that on 11.5 and the May (?) version of GUI miner everything was rock solid and stable. Any similar experiences ? Any ideas ? |
|
|
|
|
I am following this Mt Gox thing on and off, once in a while.
I was asking myself how many of those who complain about their service ever had the idea (courage, ability, balls) to offer a similar service and face the possibly conneted riscs.
Disclaimer: I have no account at Mt Gox (until now) and did not lose money with them (until now).
|
|
|
|
|
Maybe this has a stupid drawback or has already been discussed - but let me just put a thought on the board for discussion.
Currently we send money by sealing transactions in a block chain. This approach is higzhly susceptible to network analysis attacks. Although the bitcoin addresses are pseudonyms, all transactions are public and you can follow payment streams. I am currently doing some analyses here, but that's a different story.
Now, suppose we did different:
Alice wants to send 5 BTC to Bob. So she prepares a fresh bitcoin address, posts 5 BTC to this address and sends the private key [sic] for the address to Bob. Now, Bob can use this private key for spending this money.
Wait a minute, how can Bob be sure that Alice isn't using his money before he is. Well, this is a non-problem. Even in the traditional bitcoin protocol Bob has to wait some time until the transaction is cleared. So, in this case, Bob just uses the money to move it to yet another bitcoin address and waits until this transaction clears out. So there is no difference in this regard, but there is an important advantage: An attacker can no longer make the assumption that one bitcoin address corresponds to one person. Now, let's make it even worse for the analyst: Every 2 hours alice generates a new bitcoin address and shuffles here money from her old addresses to her new addresses. One in a while she buys merchandise from Bob and in this case she just forwards Bob the current private keys and Bob continues this address shuffling.
So...just think of bit coins to be private keys to addresses and no longer money attached to addresses, Conceptually, this becomes a different world.
And, voila, bitcoin now is really anonymous.
Feedback?
|
|
|
|
Once in a while timestamps are moving backwards. Block 32649 is from 09:49:06 and the next block 32650 is from the same day 2 hours earlier, 7:50:31. This is not the only example, there are quite many - and it is also not just 3 or 6 minutes but hours. I am trying to understand that phenomenon - but I don't. even if there is a chain reorganization, the chains mut be built in sequence - and the code shoulod check linearity in time. Where is my mistake? |
|
|
|
Bitcoin 2.0 ? WTF ?? We haven't got Bitcoin 1.0 running and accepted - so what is this rubbish.  Well, have an open mind and read on. While I am writing up some pages on Bitcoin economy, I came across the following observation: If a major bug in the Bitcoin program shows up, eg. some fancy buffer overflow which allows remote coin theft, the course of Bitcoin is likely to crash. Of course, with Bitcoin this is not possible. It has been coded very well. But still...it has been heared of many times, that even programs like Windows (watch out: irony) have bugs. Read on ! So, assume we had multiple implementations fo Bitcoin. Bitcoin 2.0 and Bitcoin 3.0. Of course, these would be built on different clients, maybe slightly different parameters regarding bounties, fees, hash algorithms and stuff. They would be convertible into each other on the click of a mouse (or even by automated action). In such an ecosystem there is the chance to switch currencies. If Bitcoin 1.0 runds into trouble, no problem, you just switch to Bitcoin 2.0. And, of course, you would not have all your assets in just one of the Bitcoin variants, but you would distribute your money accordingly. Now my idea ist the following: A multi-variant Bitcoin world is probably not a good idea right now, as Bitcoin 1.0 is struggling for acceptance, but in the medium and long run, having several Bitcoin variants would be of mutual benefit for all involved Bitcoin variants. I am not saying that Bitcoin 1.0 has problems...I am arguing that the mere possibility of switching from one variant to another variant increases trust in all variants. Any ideas on this ? |
|
|
|
In the german part of the forum we currently are discussing a very delicate, dangerous bug in the GUI. If you enter 0,005 as amount to be sent, the client sends 5.00 For the US-only localized guys I must add: 0,005 is, for example, in Germany the natural way to type what in the US would be typed as 0.005 - and this is consistent with all kinds of localizations in the operating system. So a German user is likely to send a much higher amount than she intended to. We have the bug confirmed on the 0.3.23-beta client on Windows 7 by Dennis1234 and on the 0.3.23-beta client on Linux self compilation by mself. Since my client is running in testnet currently I did some testing: 0,0005 is parsed as "error in amount" 0,005 is reparsed as 5.00 0,05 produces an "error in amount" 0,5 produces an "error in amount" Reparsed as 5.00 means the following: I enter 0,005 and upon "Send" the displayed amount changes into 5.00 and I get an error on insufficient funds (I do not have 5 BTC in my current testnet account). From the normal behaviour of the client I assume that, if I had more than 5.00 i would just lose these 5.00. I am not into wxWidgets programming otherwise I would do it myself. I think it is VERY important that we get that fixed ASAP ! |
|
|
|
main.h: CTransaction::IsFinal() decides, when a transaction is considered final. Now, it looks like nLockTime is not really used currently, so if is the line if (nLockTime == 0) return true;which usually is doing its job here. A bit lower in the code there is this little thingie: if ((int64)nLockTime < (nLockTime < 500000000 ? (int64)nBlockHeight : nBlockTime)) return true;which I personally would have expected to be  if ((int64)nLockTime < nBlockTime) return true;What is the purpose of comparing to BlockHeight in case nLockTime is smaller than 500 000 000. 500 000 000 is definitely in the past? As nLockTime is compared to GetAdjustedTime() earlier in the code, it is absolute Unix epoch time. 500 000 000 is November 05, 1985, 01:53:20 in my timezone. What's the idea of comparing with this date in the past ?!? Moreover: if nLockTime < 500000000 then almost certainly also nLockTime < nBlockHeight so this earlier test does not make sense ?!? I would appreciate any ideas shedding some light on this line of code. And, while being in this part of the code, a bit lower in IsFinal() we find: BOOST_FOREACH(const CTxIn& txin, vin) if (!txin.IsFinal()) return false;The logic is obvious: If an input to a transaction is not final, then the transaction under consideration is not final. But...hm...shouldn't this be the very first thing to check? There are various cases earlier in the function which lets the system decide that a transaction is final - without having made this check. |
|
|
|
|
Hi there,
in the fallout of the recent theft of 0.5 M there was an interesting discussion on a german board and a suggestion for an attack. I am not sure if we can withstand this attack and thus post it for comments here.
Mallory has a good mining rig / pool. He has by no means the majority of the hashing performance but he knows he has the largest or second largest hasing performance.
He now sends to every participant a different tx and starts building a block on yet another tx. Everyone will solve HIS version of the tx and Mallory will win, assuming nobody has more hashes / sec than him.
Note: We do not assume absolute majority of hashes, but (only) being the largest participant.
According to my understanding the attack would work, although it might not be practical.
Opinions?
|
|
|
|
|
