Bitcoin Forum
December 16, 2018, 11:41:31 PM *
News: Latest Bitcoin Core release: 0.17.0 [Torrent].
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 [5]
81  Other / Off-topic / 1GH/s, 20w, $700 (was $500) — Butterflylabs, is it for real? (Part 2) on: December 02, 2011, 04:08:11 AM
This is about  a company claiming to offer some very high performance dedicated mining hardware.

Initially pre-orders were offered for $500 but the price has since been raised to $699.  No units have shipped. They also clam to be taking preorders for a 50GH/s unit for $24,980.

There is a lot of justified skepticism about the realness of the advertised products.  I created the original thread because I thought, on the basis of the available data, that it was obviously a scam and I was worried that other bitcoiners were getting ripped off. At that point in time there was only a flashy website and a lot of tall promises. The subsequent disclosures have made me reconsider my initial quick judgement— today there is good evidence that some kind of actual hardware exists.

The other thread was becoming a bit large:

Of course, speculation is going to be contentious, we're not going to all agree on the relative merits of the various bits of data available — but it would be best if people stuck to the facts and evidence.  If you have an irreconcilable difference in conclusions with someone, don't flame— take comfort in the fact that your superior knowledge will allow you to place profitable bets on the outcome.

(Fair warning: Unproductive back and forth flame-wars will get deleted here)

Useful links
82  Alternate cryptocurrencies / Altcoin Discussion / Increasing mining income on litecoin! on: November 15, 2011, 11:21:58 AM


Forwarding and processing transactions in litecoin competes with CPU power that could be better used for mining.

Rather than disallowing free transactions entirely, this patch simply corrects the metric to better match the currently relatively stationary behavior of litecoin: To be free 100 LTC of input must sit around 576 blocks (4x the 144 value from bitcoin).   Otherwise, a fee of 1 LTC applies, pretty reasonable considering the exchange rates.

If people want binaries, let me know for what platforms you want them. Cheers!

diff --git a/src/main.h b/src/main.h
index 5783d67..468f11e 100644
--- a/src/main.h
+++ b/src/main.h
@@ -33,8 +33,8 @@ static const unsigned int MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2;
 static const int MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;
 static const int64 COIN = 100000000;
 static const int64 CENT = 1000000;
-static const int64 MIN_TX_FEE = 50000;
-static const int64 MIN_RELAY_TX_FEE = 10000;
+static const int64 MIN_TX_FEE = 100000000;
+static const int64 MIN_RELAY_TX_FEE = 100000000;
 static const int64 MAX_MONEY = 84000000 * COIN; // Litecoin: maximum of 840k coins
 inline bool MoneyRange(int64 nValue) { return (nValue >= 0 && nValue <= MAX_MONEY); }
 static const int COINBASE_MATURITY = 100;
@@ -527,7 +527,7 @@ public:
         // Large (in bytes) low-priority (new, small-coin) transactions
         // need a fee.
-        return dPriority > COIN * 144 / 250;
+        return dPriority > 100 * COIN * 576 / 250;
     int64 GetMinFee(unsigned int nBlockSize=1, bool fAllowFree=true, bool fForRelay=false) const
83  Other / Off-topic / 1GH/s, 20w, $500 — Butterflylabs, is it a scam? on: October 18, 2011, 02:16:31 PM

Their claims are not outside the realm of physical possibility like some past hardware miner scams have been— but they also don't appear to be possible, at least with current commercially available parts.

The webpage is very thin on evidence that they aren't a scam. The most compelling thing I've seen is that they're looking to hire someone who speaks mandarin, though while that bodes well for their honesty it doesn't bode well for their product actually existing. Smiley

I understand that a fair number of bitcoiners have sent them money (or, well, that they claim so— but I only know of one).

Anyone have any information?   It would be a pretty good deal if it were true.

84  Economy / Lending / Want to be short bitcoin? Borrow from me. on: October 17, 2011, 07:35:11 PM

Greetings.  So— you're convinced that bitcoin is going down for good.  Great for you— personally I haven't a clue.

What I do have is some bitcoin, so I'm entertaining requests for bitcoin loans.

Here is how it will work:

You'll figure out how much you want to borrow (up to what I'm willing to lend you),  and you'll put up a significant multiple of that bitcoin's current market value in gold, USD, or some other agreeable non-cryptocurrency asset into a third party escrow (I suppose you could up up an equal value of BTC, but if you've got the coin why borrow from me? I won't accept alternative block chains as collateral).

You'll pay me a modest amount for interest who's value depends on the amount you've put in escrow and the maximum length of the loan— and I'm willing to negotiate over the exact terms this.

Presumably you'll sell the coin after borrowing it from me then buy it back later when the market price is lower... but thats your business I don't care.

When the loan expires (or any time before then) you either return the same amount of bitcoin,  or you break the contract and I get the escrowed funds.

I benefit because I'll make some income on coins I was just going to sit on, the risk to me that you're compensating me for is the risk that bitcoin increases a bunch in value and you break the contract and all I get is the escrowed funds back.

The benefit to you is that you get to make use of your superior predictive powers. Without my help all you can do is tell everyone how smart you are, with my help you can prove it and profit from it.
85  Bitcoin / Development & Technical Discussion / Signature schemes on: October 06, 2011, 07:11:32 AM
Another improvement would be the introduction of the Bernstein signature scheme with a similar security parameter to the existing ECDSA but a much faster verification. Transactions using the cheaper signatures could get a discount on the fees or be allowed more sigOps. To be clear, the scheme I'm thinking of is "A secure public-key signature system with extremely fast verification" from about 2000.

If you wanted to introduce a signature scheme which was much faster but which required more storage, then offset that storage with improved pruning, why not hash based signatures (lamport or similar tree analogs)?

They are quite fast, have fewer security assumptions than other signature schemes (other signatures also become insecure if H() has the same weaknesses which would break lamport), an intuitive security proof, and are strong against proposed QC models (regardless of the real merits of QC attacks, marketing garbage is making the public think that QC's are already a real thing and the true but misleading assertion that bitcoin would fall to some highly hypothetical very large QC is harmful to public confidence, though I don't have a real feel for how harmful it is generally but "OMG QC's break bitcoin" shows up in IRC ever other week or so).

Lamport signatures also allow distributed storage of signature data. You can forget parts of signatures over time at random but still use them for lower confidence validation of the signature, you can also partially validate them for a big speedup.

86  Bitcoin / Bitcoin Discussion / Planning you withdraw your BTC in mtgox? Make a new wallet first. on: June 24, 2011, 07:20:02 PM

I'm quite concerned that during the last week while mtgox has been down people have been very actively stealing wallets. We've seen many trojans and other wallet collection scams.  Perhaps people took less care to make sure wallets that had little/nothing in them were not stolen.

If someone made a copy of your wallet this week they may be sitting on it hoping that when mtgox comes up you'll withdraw all your BTC and as soon as they see that transaction they'll launch a matching transaction to give all that coin to them. Even if your wallet had nothing in it before, if someone copies your wallet they will also gain access to future payments to the addresses in it as well as 100 future addresses (which are pregenerated and hidden).

If there is _any_ chance that your wallet has been compromised, do not deposit a bunch of coin in it. Instead make a new wallet or cycle out your old keys by hitting getaddress 101 times before using the next address. Make sure to update your backups too.

Stay safe!

87  Bitcoin / Development & Technical Discussion / Merkle tree of open transactions for lite mode? on: June 24, 2011, 04:20:16 PM

As I understand it,  in lite mode you can validate that a transaction is in a particular block, but you can't validate that it hasn't been redeemed by a subsequent block.

This has a couple nontrivial consequences.  For example, a lite mode client can't tell if a transaction its been told about is even _possibly_ valid or if it is completely jibberish until someone mines it.   

This also means that you can't make a zero trust lite mode namecoin resolver because the only way to be sure that a later transaction didn't transfer the ownership of a name to someone else is to have reviewed the entire blockchain and made your own summary of the open transactions. You can't ask a peer to do this for you unless you trust them not to lie.    I think this is not just a namecoin issue, I think it also impacts various distributed contract proposals that require you to be able to see that a transaction is mined but not yet redeemed.

What if the coinbase TXN included the merkle root for a tree over all open transactions, and this was required by the network to be accurate if it is provided.

Then if you wanted to validate that a transaction was really open, you would obtain the block headers, then obtain the N most recent blocks, then ask an untrusted peer for the pruned open-transaction merkle trees leading to that the transaction in question.  You are now sufficiently confident that the open transaction is still open as of the height of the blockchain you have access to.

Since full nodes must already keep track of all open transactions for validation, maintaining such a tree would be relatively cheap (log2(n) for single updates, fewer per update if more than one txn changes at a time).

Beyond the namecoin/funky distributed contract case/ this would also permit semi-lite clients which track only the headers and open transactions and are allowed to forget about very old open transactions because they can be reminded of them by untrusted peers but can still do full validation.   This might be helpful for network health in the future (e.g. keep track of only recent, likely to be quickly redeemed transactions, and give them forwarding priority. If you can't validate a txn give it low priority, if its children show up again and keep bothering you, then ask a full peer to prove to you that they are are valid and then add them to your cache)

So, can someone please correct my understanding of the system if I'm wrong?
88  Bitcoin / Development & Technical Discussion / Tor Support via Onion cat (onion in IPv6) on: June 21, 2011, 04:24:00 AM

Today the bitcoin client can work over Tor, but it can't connect to nodes which exist exclusively in the Tor cloud except manually. When using tor your node will just connect to regular internet nodes via tor.

This means, e.g. that while running bitcoin over tor can protect your privacy it doesn't help secure bitcoin against ddos and internet filtering attacks, because tor hidden nodes can't play much of a role.

To fix this bitcoin would need to know how to connect to onion addresses and how to share them with other nodes.

Fortunately this can be done without changing the bitcoin p2p protocol.  Bitcoin already shares addresses in IPv6 form. Fortunately the onion address space is already 80 bits and there is already a widely used mapping of onion to IPv6 called onioncat:

To support this bitcoin would need to know to pack and unpack onion hostnames to onioncat IPv6 addresses, and would need to know to only attempt to connect to them via the tor-socks-proxy.  It would also be useful for it to know how to have a tor-proxy used only for onion while the rest of the connections use the public internet.

Is there any reason that this wouldn't be a good way of handling this?
89  Bitcoin / Bitcoin Discussion / Bitcoin: Now with fractional reserve? on: June 20, 2011, 11:05:04 PM

Since we know that more was removed from Mtgox than they were previously claiming ( see Kevin's post) and it's clear that mtgox's daily float requirements were far smaller than their balance (e.g. the >400k wallet) is there now a risk that mtgox will go back into operation with effectively fractional reserve, thus artificially inflating the supply of bitcoin?

They can only do so within their exchange, but thats by far the most economically significant place to create inflation.

How can the bitcoin community be confident that exchanges aren't doing this?

90  Bitcoin / Development & Technical Discussion / Deterministic wallets on: June 18, 2011, 09:27:29 PM
I've discussed this enough on IRC that I thought I ought to put it someplace more lasting.

Bitcoin really ought to offer and default to using deterministic wallets.   The additional security of the current pre-generated ones is fairly small considering how most people use bitcoin and the liability of harm due to insufficient backups and increased pressure to keep a single wallet online is enormous.

What is a deterministic wallet?  It's a wallet which you can backup once and it stays backed up forever because all future addresses are determined in advance. It can also be stripped down to a very small size which could be easily backed up on paper (e.g. with a QR code). This is in contrast to the current non-determinstic wallets where the keys are random but are precomputed ahead so that you're safe only if you backup at least every 100 get addresses or sends, and which grow large and harder to backup on paper over time.

I've found the backup behavior of the current wallets fairly difficulty to get even moderately technical people to understand. The current system provides enough safety to encourage complacency but not enough to make complacency acceptable.  The positive side of a non-determistic wallet is that it becomes "unstolen" over time but people are frequently reusing addresses and attackers will not act slowly regardless.

There are two types of deterministic wallet I'd like to discuss. I'll call them type-1 and type-2.

Type-1 is the most obvious kind:

The wallet stores a large random seed  S (which can be encrypted if the user uses wallet encryption)

Privatekey(type,n) is then simply set to H(n|S|type)  where H is an acceptable secure hash function and type can be set to different values for change addresses vs displayed addresses (so this distinction is preserved even if new wallet metadata is lost).

The system would generate some (maybe 1000 of each type) addresses ahead of the furthest it has observed on the network but only bother to store the addresses. The keys can be regenerated as needed.

Type-2 is a bit less obvious and understanding it requires you to know about a property of ECC keys, roughly:

A_public_key = A_private_key*point

Which means you can do:

B_public_key = A_public_key+B_secret*point
and have a new key which has a private key:
B_private_key = A_private_key+B_secret

So a type2 wallet stores:
A large Random_seed S.

and keys are given by

Privatekey(type,n) = Master_private_key + H(n|S|type)

which works just like a type-1, the advantage of the type-2 is that you can separately secure the Master_private_key, but still generate new addresses with
Publickey(type,n) = Master_public_key + H(n|S|type)*point

This means that a e-commerce site could have the front end webserver with access to the public key and S, and someone who hacked the server could violate the confidentiality of the addresses in use (because he could enumerate all past and future addresses based on an infrequently changed public key) but couldn't actually steal any of they money sent to the addresses because he would have no access to the private keys.

This could also be used to allow getaddress to work in the client without having to provide a key (access to the TXN data in the wallet means that access to the wallet, even with private key encryption, screws your confidentiality)  which would avoid the problem of backups being endangered due to address depletion from hitting getaddress a lot between entering in the key.

91  Bitcoin / Bitcoin Discussion / Mtgox using single precision float for bitcoin? on: June 03, 2011, 06:25:56 AM
I put in a sell order for 1 BTC on MTGOX at 1e120, just to see what the limit was. The system now reports I have an open order at 3.40282e+38.

This doesn't fill me with confidence. Might make some of the weird rounding on orders I've heard people complain about in IRC make more sense...

92  Bitcoin / Development & Technical Discussion / Bitcoin (software) doesn't work for new users on: June 01, 2011, 07:35:17 PM

The behavior a typical firewalled new users sees is that they start the software and they see 0 connected.

The system may spend hours in this state. Restarting the client repeatedly may make it get connected, but it may not receive any blocks.  Eventually if the operator is patient enough and/or restart enough they will probably get synced up to the network but it may take then 24 hours.

I think this gives users an initial impression that the bitcoin technology is unreliable and dampens interest and confidence in bitcoin.

After IRC discussion it seems that the problem seems to be the result of several interacting issues:

(1) The connect() timeout behavior is unreasonable. Once the 8 slots are filled up with connections to unreachable hosts the node will just sit there idly. I think the OS will eventually give up— but only after 5 minutes or so.  this is worsened by the fact that:

(2) Most nodes on IRC are unreachable. We've had a large amount of newbie growth lately and lots of nodes are up behind firewalls without port forwarding. If you grab 8 nodes from IRC it is appears fairly likely that you get all 8 non-reachable.

(3) addr.dat remembers nodes which you've never connected to (or only connected to long ago) and these non-working addresses are passed on to other nodes when you connect to them. So even when you do get a working network connection you'll likely get fed more addresses that make connect time out. (there also appears to be a DOS vulnerability here, since I could run a node that simply claims every IP is a bitcoin node)

If they addnode a working node, or forward the port then it will work too (though addnoding after an addr.dat is full of junk seems less effective). But that is a lot of non-obvious work to just get the software going.

This situation is severe enough that when I spun up eight totally new test nodes (behind a firewall), all eight were still sitting at zero connections five minutes later. I had another test node run for 20 hours and not get any blocks— though it did get connected, most likely because it ended up in an island of new nodes, so thats probably another issue.

Fortunately this isn't terrible to fix:

Issue (1) has a patch available
Issue (2) can be addressed by the use of DNSSeed (which checks that hosts are reachable before including them, and could also check to make sure they weren't islanded nodes)
Issue (3) seems like a mostly straight forward fix though the security implications need to be thought through.

Additionally,  enabling UPNP by default would help by getting more nodes listening, but thats not sufficient without solutions to (1) and probably (2).

But these fixes need to actually get into the software to be of any use. I don't think many long term bitcoin users are realizing the severity of this problem because they either have established nodes, public IPs, or port-forwards, and because the issue has become much worse in the last two weeks. (I didn't experience it personally due to forwarding the port, but a regular stream of people into #bitcoin asking inspired me to investigate some)

93  Bitcoin / Bitcoin Discussion / Satoshi's spare change? on: May 25, 2011, 01:38:03 AM

(This looks like change from a send from an active address being sent to the address which was paid by the genesis block)

Did older client software not generate random addresses to receive change and instead pick a random address in the wallet?

94  Bitcoin / Development & Technical Discussion / Bitcoin vending — Making it easie to convert cash to coins on: May 16, 2011, 07:36:25 AM

Has anyone considered assembling a hardened vending machine (perhaps a retrofitted change machine) into a device that converts USD to bitcoin?

You'd put them in publicly accessible places. Person walks up and scans a QR code of a wallet ID off a phone or from a printout (speech recognition is out due to mixed case, most likely),  then stuff money into it.  It prints a receipt (including a QR code of the TX itself, to guard against network problems) and sends money to you on the network.

Bill validators don't appear to be very expensive.  While I don't think this would be a profitable business on its own any time soon (and would only be interesting in a few major cities right now) it might be something worth operating for the sake of increasing the viability of bitcoin.

Going the other direction (BTC->$) has some extra complications— requiring a retrofit of an more costly atm and having instant gratification problems since waiting around the machine for a block confirmation would suck (and not waiting would almost certainly be exploited).

BTC->$ doesn't solve the more urgent issue of "I want to use this BTC thing but can't get any money in it before I lose interest, because mining now has high upfront costs", but $-> BTC sure does.

95  Bitcoin / Bitcoin Discussion / Stuck transactions on: May 12, 2011, 06:49:25 AM
User makes a 0.01 payment using a 0.02 coin in a no fee transaction. They get 0.01 change.  The TX is low priority.
(TX: c9bdcc0ba07812c76e6c6635049f0b55b628a4c3321b02ab4317d79273861232)

Two days later they make a 36BTC transaction, they include a nice fee.  The change gets used.  The TX is hung waiting on the unconfirmed 0.01 contributor. It's something like an hour old now and it's still unconfirmed as I write this. Based on the ages of the other unconfirmed TX like the blocking one, it might take seven days to clear.

Maybe the client could try harder to help the users avoid spending unconfirmed coin, but it seems to me that the miners should group all the TX involved in a dependency, add up the sizes and the fees, and apply their criteria to the group as if it were a single TX.

Otherwise we can expect more holdups as the QOS for no-fee transactions continues to decrease.

96  Bitcoin / Bitcoin Discussion / Immunity to sit-in-strike extortion by mining unions? on: May 05, 2011, 08:56:34 PM
Imagine that there exists a mining union with 1/2th of the global mining capacity.

Assume the union members have substantial investments in specialized mining hardware and they are unhappy about the decreased payoffs due to increasing difficulty, decreasing block yield, and exchange rates. Also assume that the miners are in it for the money, and don't care about the health of the currency except in so far as they want to maximize their income. 

This mining union decides to impose a 1btc minimum on transactions they include in their blocks. The miners keep working, thus keep solving blocks and getting paid for doing so, but they're not doing any useful work as far as the bitcoin network is concerned, they're just dead weight slowing down the transaction processing for everyone.

Because transaction fees are currently insignificant compared to the block reward miners will not lose a significant amount of money as a result of their strike and so the union members will not break the strike.

If few pay the extortion transaction fees then the strike constitutes a DOS attack on the bitcoin currency—transactions would be confirmed 50% slower on average—, but still doesn't hurt the striking miners, they still get paid about the same.  There would be no reason (except to protect the network) that other mining unions wouldn't join the strike too— and unions will not compete on transaction price because there currently can be no reasonable transaction cost (e.g. wouldn't be disproportionate with mining costs, and wouldn't kill bitcoin) which would be significant compared to the block reward for the next few years.

I don't see any elegant solutions to this risk. I don't think the obvious tweaks work.. e.g. Changing the longest chain rule to make blocks with the most transactions win would just be gamed by the strikers adding in their own dummy transactions.

Cooperating bitcoin users could join together add more mining capacity in order to make the striking group(s) small with respect to the overall mining capacity. For example, I estimate that it would currently cost $2.5 million dollars to reduce 50% of the current capacity to 10%, (or twice that to convert 100% of the current capacity to 10%)— changing a large DOS to a more tolerable one.  Assuming they paid for the hardware with bitcoins at todays exchange rate (744300 BTC) on loan with 6% APY, they'd need to make about 6.6BTC per block to pay off the hardware in three years. But since this is less than the current (and near term) built-in block payoff the strikers would rationally add capacity too.

The equilibrium point of this system is the point where 100% of the block reward was being spent on mining and at only at that point miner unions would actually compete on transaction fees, making striking no longer profitable. At current exchange and block reward amounts the equilibrium point would be a worldwide mining spend of $8.9 million dollars per year.   Thats one _hell_ of an overhead for a currency with a total value of only $20million dollars.

I'm concerned that this outcome may be an inevitable consequence of the large amount of for-profit mining combined with the upcoming point change in mining returns which will leave a large number of math impaired commercial miners regretting their financial decisions. No one would have started out intending to create this situation, but if you're sitting on a lot of expensive hardware then trying to shake people down on fees might look pretty attractive.

Pools provide a trivial hook for this. We could enter this state slowly through pools agreeing to initially impose increasingly higher transaction minimums. They don't even have to collude, but it would be more profitable for them to do so.  We're already seeing new pools imposing higher transaction minimums as a result of the current policy of pools to keep the transaction fees for themselves (and then competing on the how much of the block reward they leave to members).

Is there some point that I'm missing before I go and invest in fab capacity to arm the impending mining war? Wink

TL;DR:  I'm pointing out that miners can't compete on transaction prices until the mining costs rises to consume 100% of the block bonus, because of this miners can hold the bitcoin market hostage by refusing to process transactions. This isn't a risk further in the future as the block bonus goes away, but at the moment I think there is a risk of a break-away mining arms race which will disrupt the network and only be profitable for GPU makers.
Pages: « 1 2 3 4 [5]
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!