Bitcoin Forum
March 05, 2015, 02:33:56 PM *
News: Latest stable version of Bitcoin Core: 0.10.0 [Torrent] (New!)
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 ... 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 [58] 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 ... 798 »
1141  Bitcoin / Pools / Re: Fascinating what Michael Deletes [BTCguild 90% luck and dropping] on: May 09, 2014, 06:46:08 PM
Can someone explain to me how is "block withholding attack" different from the "false negative" type of hardware fault? I mean in the observable symptoms, not in the intent.

The last time I looked into the miners source codes (late FPGA era,early bitfuries) I've only seen the "false positives" counted as "hardware errors": nonce comes up as gold, but software re-check shows that it isn't.

I haven't seen any published source code that does the opposite check for "false negatives": chip should find a golden nonce but hadn't.

From the skimming of the available hardware documentation I see that only Spondoolies has a BIST operation that allows to cheaply test for false negative. By "cheaply" I mean "cheaper than doing a regular, full scan".

Obviously this test has to be hardware specific, because e.g. bitfuries only test 768/1024 of the available nonce space. This would have to be even more complex to account for failed sub-engines in the multi-engine chips.

I think that Stratum Mining protocol can be extended to allow the client to send to the pool server the maps of the "blind spots" in the nonce space. Then the pool can sensibly proctor the tests meant to discover withholding attacks.


You are correct that there isn't any observable difference between the 2 types of problems.  And in practice, I think it's extremely unlikely that someone with hardware that has catastrophic levels of false negative errors is unaware of the issue, so the intent is likely equivalent as well.

When you have people of very questionable competence designing silicon on crash schedules it's inevitable that serious hardware defects are going to be in play.  And with the money involved, if there is a way to externalize the cost of failure to pool participants people are going to choose that over eating the loss themselves.

I think it's an absolute must that stratum allow pools to send test jobs to validate hardware integrity in a blind way that allows detection of malicious withholding as well.  Without that, I expect the days of public pools are numbered, and with them all hope of even modest decentralization will go as well.

It has nothing to do with hardware errors (although they are another minor source of false positives). 

Simple version:
If nonce 728937289 solves the block for a given unit of work and a particular hardware for a variety of reasons doesn't check nonce 728937289 it is not going to find a solution.

If a user doesn't return a solution is it because he is cheating or is it because his hardware didn't check that nonce with that work?  The answer is there is absolutely no way to know.
1142  Bitcoin / Pools / Re: Fascinating what Michael Deletes [BTCguild 90% luck and dropping] on: May 09, 2014, 06:44:07 PM
It isn't a hardware fault or error.

If nonce 728937289 solves the block for a given unit of work and a particular hardware for a variety of reasons doesn't check nonce 728937289 it is not going to find a solution.  It is that simple.  I assume you are confused because you believe that hardware normally checks all nonces all the time.  Nothing could be further from the truth.  There are dozens of reasons why a nonce wouldn't be checked and no software is going to report that as an error.  HW errors as reported by cgminer and the like are the result of the hardware reporting that work A + nonce B produces a hash of particular difficulty and it doesn't.

Quote
I think that Stratum Mining protocol can be extended to allow the client to send to the pool server the maps of the "blind spots" in the nonce space.
It isn't a static range.  Say you have an ASIC with 64 cores the designer may decide to take the nonce range (2^32) and break it into 64 chunks.  It does this by assinging an offset to each core.  So all the cores get the same work, each one starts at a difference nonce value and they all increment 2^26.  However due to yields not all chips will have all 64 cores operating.  The seller may have designed it around 60 cores being "good enough" to achieve the hashrate.   So if 4 cores are "off" then that means millions of nonces will never even be attempted.  Most ASICs also work on dynamic load so as the hardware error rate and/or temp rise it shuts off the cores.   So the same nonces won't be covered all the time.

Still it goes way beyond just which nonces are checked.  Both the ASICs and the mining software queue work.  So what happens when a miner has 30 seconds worth of work queued up and you send him the "test work".  Are you going to hold the block for 30 seconds which would mean a >7% orphan rate?  What happens if due to latency the miner returns the proper solution but only after you have broadcast the block?  If he cheating or just slow or just had a lot queued up, or poor connectivity?   How are you going to avoid the attacker just sharing info between workers to detect the "test work" and always return those with 100% success?  

Also don't take this is as exhaustive I just don't feel like covering every possible scenario.  The only way to prevent these types of attacks is for the pool to know something the miner doesn't.  The current block hashing protocol doesn't make that possible.
1143  Other / Off-topic / Re: Are the console wars killing AAA gaming? on: May 09, 2014, 06:18:58 PM
Quote
I guess you need to go newegg ect for windows pc games now, steam, ea for the digital crap, no hard copies like back in the day.

I haven't bought physical media for software in years, so people like me are probably what accelerated that trend.  Then again I don't really see the appeal.  My computer is online, the software is online, often online is a large component of the software, updates are online.  So why do I need a box & DVD to lose or take up space again?
1144  Bitcoin / Development & Technical Discussion / Re: MultiSig Broadcast Network on: May 09, 2014, 04:26:15 PM
I don't think it ever got beyond a concept.  The preferable solution is to use the existing decentralize message relaying network called Bitcoin. Smiley  There is a risk that an attacker would use partially signed transactions to flood the network at no or minimal cost.  Some DOS prevention mechanism is needed to ensure the network is hardened against that type of an attack.  The reason bitcoin nodes enforce a minimum fee to relay some transactions, is to protect the network from this type of attack.  The min fee to relay has nothing to do with compensating miners (a common misconception), miners can already include whatever transactions they like in the next block regardless of what rules nodes follow for relaying transactions.

At its core Bitcoin IS a message relay system.  Nodes share information by propagating messages to peers .  Blocks, transactions, alerts, peer data are all passed as messages.  All the low level plumbing (peer discovery, bootstrapping, versioning, node banning, message encoding, etc) has already been written.  The network is robust in terms of reach and uptime.  Creating a new "partially signed tx" message is trivial, figuring out how keep an attacker from abusing that new feature isn't as trivial but is solvable.  A couple of ideas come to mind.  The first would be to for nodes to require and verify a "proof of work" attached to partially signed message before relaying.  It couldn't be SHA-256 based because ASICs are just too efficient but other proofs of work may be effective.  A second option would be a proof of burn where the message creator references a transaction where they previously destroyed a minimum number of coins as a provable cost.   Lastly it is possible that it could be accomplished with some good old fashion relay volume limits and node banning but that would need to be carefully tested.  

If someone wanted to build a third party relaying network, they are still going to need to ensure the network is hardened against DOS attacks.  Once built, deployed, and tested, it would make sense for it to be incorporated into Bitcoin clients.  So a good place to start for any proof of concept would be to fork the existing codebase. That would make it easy to integrate that functionality back into Bitcoin and it would save the developer a lot of time reinventing the wheel (peer discovery, bootstrapping, message parsing, etc).
1145  Bitcoin / Press / Re: [2014-05-06] Western Union Obtains Alternative Currency Exchange System Patent on: May 09, 2014, 04:05:05 PM
There seems to be some confusion (maybe some because people don't read).  The patent is not about digital currency systems in general or a blockchain based digital currency.

The patent is regarding AN EXCHANGE which deals in the conversion of digital currencies for "real" currencies.   The patent is still nonsense and if there is any justice will be thrown out the first time WU tries to enforce it.  In no case would Bitcoins, Bitcoin transactions, the blockchain, mining, miners, mining pools or proof of work fall within the scope of the patent.

If successfully enforced traditional bitcoin exchanges like BitStamp, BTC-e, etc would be the target.  It isn't immediately clear if the scope would cover bitcoin "dealers" and non-traditional systems like coinbase, BitSimple, etc.

So those saying the genesis block is prior art are missing the point.  That would be like saying amazon can't patent "1-click" checkout because the dollar existed two hundred years prior to that, or a commodity exchange can't patent a novel order matching system because Gold has been around for thousands of years.
1146  Other / Off-topic / Re: Are the console wars killing AAA gaming? on: May 09, 2014, 04:00:04 PM
Wait Bioshock Infinite lost money?

While topping plenty of charts at release, and being a wildly fun game, it's assumed by many (you may not agree, that's fine) that it's budget was 150mil+ and couldn't make that back.

Most people link this to the closing of Irrational.

Ouch that makes me feel a little sadder.  I hate to see such talent not compensated.
1147  Bitcoin / Development & Technical Discussion / Re: Mistake when Creating and using multisig address on: May 09, 2014, 03:44:51 PM
i think you still have some mistakes.  I don't have the time to take a detailed look however it is important to understand there are two different multisigs in Bitcoin.  There is the original multsig where the script is encoded in the output itself.  I generally call this "native multisig" to be explicit.  Then there is P2SH (pay to script hash) where the payment is sent to a hash of the script (redeem script).

It appears in your tx above that out[0] is a payment using p2sh and out[1] is a payment using "native multisig".  Also it looks like you are using the same keys both outputs.  So you have 7.09 BTC going to the same set of keys, 0.01 BTC being sent using P2SH address (out[0]) and another 7.08 BTC being sent using native multisig (P2SH).

There is no requirement for change.  The protocol just sees inputs and outputs.  We only use a "change" address to balance the equation sum(input) = sum(outputs) + fee when the intended transaction amount is smaller than the input being "spent".

So I am going to assume the input (txid: 3349d7e3d8b25bbe7556d04c2ab37f7d071b7b2679c7ab364f4e12c15761538b index: 1) is worth 7.09 BTC (I don't see it on testnet blockchain but that may be my issue) and you are trying to make a tx with no fee?

If you just want to send the full amount to the P2SH address then you only need a single output worth 7.09 (or the value of the input - intended miner fee)

If you wanted to send 0.01 BTC to the P2SH address then the second output should just be another address in the senders wallet (if you are using a single wallet and sending to yourself I would just grab a "normal" address to use as the second output and the value of that should be value of input - 0.01 - intended fee.

If you haven't already I would do this demo from start to finish (just substitute your keys and your funding transaction) using bitcoind on testnet:
https://gist.github.com/gavinandresen/3966071

Gavin's demo is good because it walks through all of the following:
1) Create a P2SH address (2 of 3)
2) Send funds to the P2SH address
3) Create a tx "spending" funds from the P2SH address
4) Sign the P2SH address in multiple steps (simulating keys on different machines)
5) Broadcast the fully signed transaction.

Make sure you can do all this using nothing but bitcoind before moving on to custom java.  Otherwise it makes it difficult to see if the problem is in your java or your understanding of P2SH or your understanding on bitcoin tx in general.  Once you are able to go through it once, you can do it again, save the output of each step but don't broadcast.  You now have a step by step template and your java should produce the same outputs at each step.
1148  Economy / Service Discussion / Re: Bitstamp TX Fee Exploit - Fee 1.16% instead of 0.2% [Bitstamp Fixes on May 15th] on: May 09, 2014, 03:02:18 PM
So is BitStamp going to refund the excess fees they mischarged customers?
1149  Other / Off-topic / Re: Are the console wars killing AAA gaming? on: May 09, 2014, 02:56:12 PM
Wait Bioshock Infinite lost money?

To the OP it is a problem and PC games are not immune either.  I remember reading an article which talked about how the cost of developing the "art" for games has increased exponentially with the pixel count.  Now with consoles all being able to push 1080p (due to TV standard) the pixel count isn't going higher but the graphical capabilities are still expanding so that "art" development cost is still exploding.

To be honest, for games early in a console life cycle, the big developers are more interested in the graphics engine for the licensing revenue it can generate.  The best ones will end up being adopted by smaller studios and will end up in dozens if not hundreds of games.  That can mean revenue on a scale that makes the direct sales of the game look like chump change.  Is it any wonder the graphics element is pushed so hard.  You didn't buy a game, you bought a demo for their graphics engine. Smiley
1150  Economy / Service Discussion / Re: Greendot Moneypak is such a shitty company on: May 09, 2014, 02:51:44 AM
PayPal doesn't own MoneyPak.  You don't honestly think Greendot wants to turn customers away do you?  Hell they would love for you to buy 100 reloads @ $5 in profit per day, everyday for the rest of your life.  They do it because the government requires them to limit transaction volume to be compliant w/ AML limits.  Shutting you down doesn't make them any money, what would possibly make you think they like not making money?  They comply or they lose their money transmitter license potentially forever.  That would essentially bankrupt the company.  Thank FinCEN and your Congressman for fighting the war on nouns.
Sorry, I thought paypal bought out green dot cause the first time I used one someone told me that. Looks like that is indeed untrue.

I didn't exceed their limits, which was 4 per day or 7 per week, so I still think it's absurd they shut me down with no notice.

Hopefully this doesn't happen to me with vanilla reload, or i'd be up a river. I've loaded many more vanillas than moneypaks with no problem though.

FinCEN obligates companies selling prepaid cards to limit sales to no more than $500 per day per customer and create an AML program designed to detect and prevent transfer of value between third parties.  Let me guess the four you loaded in one day were all purchased on the same day by multiple people in multiple states?  They might be willing to bend FinCEN rules a little but at some point it becomes so obvious they are going to pull the plug.  Vanilla and all the others will shut you down eventually if you are doing the same thing.

They probably have filed a SAR to FinCEN as they are required to file reports on patterns of activity would be considered suspicious.  The law prohibits them from even confirming or denying if they have filed a SAR.

1151  Economy / Service Discussion / Re: Greendot Moneypak is such a shitty company on: May 09, 2014, 02:26:05 AM
PayPal doesn't own MoneyPak.  You don't honestly think Greendot wants to turn customers away do you?  Hell they would love for you to buy 100 reloads @ $5 in profit per day, everyday for the rest of your life.  They do it because the government requires them to limit transaction volume to be compliant w/ AML limits.  Shutting you down doesn't make them any money, what would possibly make you think they like not making money?  They comply or they lose their money transmitter license potentially forever.  That would essentially bankrupt the company.  Thank FinCEN and your Congressman for fighting the war on nouns.
1152  Bitcoin / Pools / Re: Fascinating what Michael Deletes [BTCguild 90% luck and dropping] on: May 09, 2014, 02:15:50 AM
Well yes a hard fork would imply that all nodes would need to update not just for mining but for validating the new block version as well.   Solo miners wouldn't be affected.  There would still be two values in the new block header but they would know both.  No need to hide info from yourself.
1153  Bitcoin / Pools / Re: Fascinating what Michael Deletes [BTCguild 90% luck and dropping] on: May 09, 2014, 01:45:08 AM
well then the game is over for public pool mining with no innovation here..  if there was already a solution there wouldn't be a problem

There is a very good solution but it will require a hard fork.

It seems to me that the solution you recommended earlier in this thread would allow a pool to withhold vital information about the hash's that a miner submits.  The miner wouldn't know if he really found a block or not or even know what difficulty of the share was.  So a miner would have no way to verify if a pool was above board or not or even know how much he was getting paid for his hash's.

That is not correct.  The miner would know the exact difficulty of the share just not if the share solves a block or not.

Checking a share difficulty IS checking if it meets or exceeds current difficulty.  I don't see how you could separate one from the other.  It would have to be same operation.

How about reading the linked proposal that meni spent a lot of time developing and writing up?  Without a hard fork you are right there is no way to separate it, that is why a hard fork would be needed to support a method that prevents a miner from knowing if the hash solves a block.  It would change the blockheader such that a valid block is based on two different hash values and the miner only knows one.   The miner can compute the share difficulty, the pool can compute if it meets the difficulty for solving a block.  The pool withholds the second value from the miner which prevents the miner from knowing what the pool knows.
1154  Bitcoin / Pools / Re: Fascinating what Michael Deletes [BTCguild 90% luck and dropping] on: May 09, 2014, 01:43:20 AM
The other question of course:  Would that proposed solution even work with existing ASICs, since you're changing the block header fields that are going to be hashed?

Probably or it could be revised to fit.  The actual ASICs really have no concept of what they are hashing just that they are hashing a blob of data and checking the output of the hashed blob.  So the size of the blob (and the fact that the trailing 32 bits are the incrementing nonce) can't change but the header can be extended in 256 bit increments by making the midstate the result of two blocks (hashing definition not bitcoin definition) of inputs instead of one.

As far as will people support a hard fork?  I don't know but if convinced it is a legit threat non-miners may see little downside in supporting it and potential devaluation of their bitcoins if they don't.   If nothing else I find it interesting because "if" this ends up being the Bitcoin killer, well there is already a solution for the altcoin that replaces bitcoin.
1155  Bitcoin / Pools / Re: Fascinating what Michael Deletes [BTCguild 90% luck and dropping] on: May 09, 2014, 01:36:47 AM
well then the game is over for public pool mining with no innovation here..  if there was already a solution there wouldn't be a problem

There is a very good solution but it will require a hard fork.

It seems to me that the solution you recommended earlier in this thread would allow a pool to withhold vital information about the hash's that a miner submits.  The miner wouldn't know if he really found a block or not or even know what difficulty of the share was.  So a miner would have no way to verify if a pool was above board or not or even know how much he was getting paid for his hash's.

That is not correct.  The miner would know the exact difficulty of the share just not if the share solves a block or not.
1156  Bitcoin / Development & Technical Discussion / Re: On The Longest Chain Rule and Programmed Self-Destruction of Crypto Currencies on: May 08, 2014, 11:45:17 PM
So they stamp all the blocks which could sort of be exploited for double spends but not really and then the stamp is used for the diff change.

Correct.  All blocks contain a timestamp, all blocks timestamps are validated by all nodes to ensure they are within an acceptable window.  This is done to "keep miners honest".  Without it miners could use false timestamps to manipulate the 2016 block timespan, lower difficulty, and boost their profits. 

That validation in theory could be exploited to isolate and double spend a node.  The article describes how that attack could be executed.




1157  Bitcoin / Development & Technical Discussion / Re: On The Longest Chain Rule and Programmed Self-Destruction of Crypto Currencies on: May 08, 2014, 11:29:47 PM
Sorry but I am missing something here.

Why is there a possible attack vector if the protocol
is using the time stamps for anything other than
difficulty adjustments? (Using them to validate blocks)

 Huh


I assume you mean isn't?

The article explains the attack in pretty simple language.  The attacker isolates the node and feeds it incorrect timestamps.  This causes the computed network time on the victim's node to be SLOWER than the rest of the network.  The attacker then creates a block with an incorrect timestamp that is faster than the correct time.  For most of the network although the timestamp is wrong it is still within the validation window and the block is accepted.  The victim's clock however has been slowed down enough that the block is outside the validation window and the block is rejected.

The victim has now been forked off the main network and can be fed false information and double spent at will.

The timestamps validation of blocks is only used to prevent manipulation of difficulty but the fact that nodes validate timestamps is exploited to isolate and attack the node.  In reality this attack would be rather difficult to pull off, is expensive as it requires mining full strength blocks which will be orphaned by the main network, and there are some pretty cheap and easy countermeasures. 


Essentially the target's proper checking of timestamps (to prevent manipulation of difficulty) is used against the target by careful manipulation of timestamps.  I don't believe this is a very effective attack in the real world for a couple of reasons.
1158  Bitcoin / Development & Technical Discussion / Re: On The Longest Chain Rule and Programmed Self-Destruction of Crypto Currencies on: May 08, 2014, 11:14:51 PM
Quote
The network time is used to validate new blocks.
.
Basically it is talking about double spends, etc.  

The article is saying block timestamps are used to prevent double spends, it is showing how block timestamps can be manipulated to exploit the fact that nodes will validate the timestamp and use that to isolate nodes .   The timestamps are only validated to ensure difficulty can't be gamed.   No other function of the bitcoin protocol relies upon them.  To prevent difficulty from being gamed requires invalidating blocks outside of an acceptable range.  The article is pointing out that the validation of timestamps can be an attack vector for double spends.  The attack vector wouldn't exist if the network didn't validate block timestamps.  Of course if there were no validation of timestamps then there would be no secure provable way of setting difficulty.  It is a catch-22.  The article recommends reducing the window for validating blocks to make this attack more difficult (an attack which has been successfully executed).

Satoshi understood that timestamps are very difficult to authenticate as such limited them to areas where there is no solution which doesn't involve timestamps.
1159  Economy / Trading Discussion / Re: Zero Fee 0% Bitcoin Exchange on: May 08, 2014, 10:54:57 PM
I thought Huobi and OKcoin did not have trading fees

I believe they charge fees of deposits and withdraws.  More than one way to skin a cat.  I believe the OP's idea is to build the worlds best exchange with state of the art features, security, and speed without any revenue.
1160  Bitcoin / Development & Technical Discussion / Re: On The Longest Chain Rule and Programmed Self-Destruction of Crypto Currencies on: May 08, 2014, 10:52:53 PM
Wasn't aware that time stamping was used at all, except for difficulty changes.

It isn't.

Quote
Seems it used as a sort of double checking for blocks, although seems unnecessary or at least not critical because of the longest chain rule.

How is change in difficulty computed?  What would happen to difficulty computation if there was no timestamp checking on blocks (attacker could use any timestamp he wanted)?
Pages: « 1 ... 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 [58] 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 ... 798 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!