Doesn't that conflict with the recent protocol change to reduce spam where you cannot spend single satoshis anymore?
Also, if a public protocol has to rely on "please don't do it because it would cause problems" then the protocol is desgined to fail.
The blockchain has to be able to deal with such a transaction, either by successfully processing it, or by rejecting it.
Otherwise Bitcoin would be instantly ddos'ed if this transaction would be a problem.
They wouldn't be spendable without adding to the balance in a given address, you are correct. How do bounties work? What will you gain by sending BTC to all these addresses? Someone please explain in detail, thanks!
It just means I will send you 1 BTC when the action is complete. It's not something that happens automatically. that is a lot of work for 40$
Is it? I was hoping some people would already have an easy way to use sendmany. Yeah we all have scripts lying around that do just that... Sending a Satoshi to 35k addresses is like my hobby. Great! Please PM me for the list of addresses so you can get right on that! |
|
|
|
|
Looks pretty good Jan. My only comment is that the line "The order of appearance..." is largely irrelevant. We have agreed that order in a block doesn't matter - all addresses with matching firstbits in the same block will have characters added until they each have unique firstbits.
|
|
|
|
that is a lot of work for 40$
Is it? I was hoping some people would already have an easy way to use sendmany. Well, maybe OP should place a bounty for an app for this purpose.
I don't necessarily want an app, I just want it done. I know many people use sendmany for a variety of reasons - it's not a new thing. |
|
|
|
|
I have a list of around 35,000 addresses that I would like recorded in the blockchain. PM me for the list of addresses if you are serious about completing this bounty, and include the timeline in which you expect to complete the offer. Send 1 satoshi to each address on the list via sendmany, send me proof of doing so by sending me the transaction ID(s) you generated, and I will send you 1 BTC once all transactions have confirmed. You must cover the fees, which I expect to total around 0.6 BTC, but could be less. I did a test with 2,000 addresses, and the fee was 0.0345 BTC.
Quicker is better, but if you do not complete the job within the timeline you specify, then I may send the job to another willing participant, and I will not reimburse you for whatever efforts you have made up to that point. I will, however, PM you back to let you know if the job has been sent to someone else.
|
|
|
|
Please show the laws or case studies that indicate it is a breach of contract for a company to cancel your order and refund your money.
IANAL. Can't answer that question for you. However, I have to trust that my extremely knowledgeable (and justifiably expensive) council knows what they are talking about and how they are advising me. IANAL either. Interesting. I would love to see the precedent they are relying on, because I can't seem to find any (with my limited research tools). If you had a February order for a Single with BFL and didn't have to pay for your electricity, would you keep your order? Or do everything possible to get a refund?
Will these guys ever end up shipping 2013 orders?
I would keep it, definitely. The BTC you eventually mine will be worth more than the USD you will get from a refund. I bet the people who canceled their 6/23 orders for singles in April, May, or June are banging their heads on a wall right now. The only reason I would want to cancel is if the BTC price dropped significantly (down to single digits). |
|
|
|
|
My 6/23 order was received on 7/16/13!
|
|
|
|
You could really benefit from some positive customer service skills.
They evidently don't care - seemingly live in their own arrogant reality distortion bubble where they can do no wrong, we should not complain about their "mistakes", and their customers are yapping animals who have the honor and privilege of being allowed to purchase their fine, American-made Bitcoin products. If they fire and refund you, whereby breaching your contract with them to receive product you have paid for, they will threaten to countersue you for slander and defamation should you start legal proceedings. Even if you have a defensible case and can rebut your "slander and defamation" systematically with facts and evidence to support your statements. In my opinion, such enterprises should not be rewarded with customer patronage on basic principle. Life is just too short. Absolute power corrupts absolutely, and it would appear we are watching such a scenario play out with America's favorite Bitcoin company on both these forums and their own, with certain personalities running amok and unchecked. Please show the laws or case studies that indicate it is a breach of contract for a company to cancel your order and refund your money. |
|
|
|
Yes, and I fear that "what the protocol accepts" and what future users will consider an "appearance of an address" may be computationally infeasible for an unvarying standard such as firstbits should be. For example, each normal address (starting with 1) has a unique corresponding, standard 1-of-1 P2SH output script and address starting with 3. If you know the 1-address, you can find the 3-address, but not vice versa, at least until the output is spent. Does the spending of such an output constitute appearance of the 1-address? Some might say yes, others no. The firstbits standard must give an answer for every possible case like that that may appear in the future. Firstbits must be derived only from the blockchain, obviously. "Bitcoin addresses" never occur directly in the blockchain; rather, they are extracted by matching scripts against templates and associating script types with well-known "version bytes". If your address were spelled out in the block whenever it sent or received coins, we could trivially define first appearance. Since that is not the case, it is up to us to cope with the complexity. It is still an open question to me, whether to ignore non-functional trailing script fragments such as Eligius's OP_NOP. The whole class of them would have to be easily identified, or if a special case for the single OP_NOP would yield better backward compatibility, I would consider just that. I do not have time right now to find out the answers, but if someone more interested than I comes up with the data, I will comment on it.  Essentially what you are saying is, there are a potentially infinite number of ways that operations can be arranged and used, and each one could require special handling to resolve firstbits. In order to eliminate inconsistencies between different firstbits implementations, we need to stick to commonly-used scripts and operation combinations, as one would find in widely-distributed Bitcoin clients. Otherwise, all firstbits implementations must continually update to account for odd transactions, or risk providing different firstbits information than other implementations. Implementations in this case would also have to agree to some set of handling rules for new odd transactions that appear, in cases where there might be ambiguity (such as the P2SH case you presented above). This makes sense, and I now agree that we should stick to providing firstbits only for those transactions deemed "regular". Said transaction types should be well-defined and listed, so that all implementations can easily follow the same rule set. |
|
|
|
I received my 30 GH/s miner 2 weeks ago, and it has been mining perfectly fine since. Sure, I had to wait for over a year and it was not fun seeing the difficulty go exponential in 2013, but at least it is here now. I guess I got lucky since I will likely be able to make most (but not all) of the bitcoins I invested back.
But let's face it, most users in the BFL queue at the moment will never make a profit by the time they receive their unit. And that is likely the reason that all sales are final. So while BFL is not a scam, most customers are screwed anyway. Bitcoin mining is a race against time and most people bet on the wrong horse.
It depends on how you define profit. A profit in BTC? Probably not if they ordered when BTC was worth less than $50. A profit in USD? Quite certainly, yes. |
|
|
|
Touche on the about page.  I know we specifically didn't mention it there because we didn't want to go into too much detail, but it sounds like we should have anyway. Yes, you are correct about making that change for addresses in the same block - the distinction would only invalidate some firstbits, it wouldn't actually change any of them from pointing at one address to pointing at another. I wouldn't have a problem with making this change then. Regarding the OP_NOP transactions, I read that some people used them to donate transaction fees to a certain pool. It's a bit beyond my level of comprehension as to how exactly that works, but essentially, only Eligus could take the fee for these transaction: https://bitcointalk.org/index.php?topic=11481.0I suppose I would still lean towards what the Bitcoin protocol accepts, not what various clients do and do not accept and can and cannot generate. If the protocol allows it to be placed in the blockchain, then it should be given a firstbits. OP_NOP transactions are not normal, and cannot be generated with the default client, but they are still valid Bitcoin transactions. I don't see any reason to disclude any valid scripts that anyone wants to run from being included in firstbits calculations. You certainly know a great deal more about the inner workings of Bitcoin than I do. I'd just like to see why you don't want these non-normal transactions to be included. You mentioned having to modify your code slightly to be able to handle these special transactions - are you concerned about having to continue to modify your code in order to deal with new combinations of operations? |
|
|
|
========================================================
BFL
========================================================
there was a thread talking about BFL mining with customers miner...
showing a heat map around the globe - texas... showing it was the most/heavily (dnt really remember the exact words).. but showing that in BFL's office/hq has the highest ghz/TH in terms of mining...
disclaimer:
sorry if that is very confusing... lol... I am just trying to put up whats inside my head... but I can assure you.. there was a few threads about that... I just don't have the time to search for it... but i know "I READ IT"... and from what i understood they mined with customers miners...
Did you know that Josh hosts customer rigs, and had a pool hosted as well (eligus)? It's not BFL mining on customer rigs - it's customer rigs being hosted at a given pool. https://forums.butterflylabs.com/showwiki.php?title=FAQ:MiniRig+SC+and+Single+SC+HostingWhen ordering equipment from Butterfly Labs, you have the option of hosting your equipment locally with one of our affiliate data centers. While BFL does not host equipment directly, we do work with local providers to place your equipment.
Currently, we work with a company called J. Morgan and Associates, which will host your equipment at their facilities. The current cost structure for hosting is:
MiniRig SC: $625 per month, per rig
50 GH/s, 60 GH/s $100 per month, per unit
|
|
|
|
I wasn't even aware that Abe even performed firstbits resolution.
Let me refresh your memory. https://bitcointalk.org/index.php?topic=16217.msg957933#msg957933Thank you, but this is not a precise specification. Whatever address appears first in the blockchain claims the Firstbits for every previously unused combination up to the full address. For example, 1SgTspiKe5HHkjdSeD72q9WsiJhRiaxf9 doesn't have the firstbits 1s, 1sg, 1sgt, or 1sgts because other addresses used prior to this one already started with those combinations, but it DOES have the firstbits 1sgtsp, 1sgtspi, 1sgtspik, 1sgtspike, 1sgtspike5, etc, all the way up to 1SgTspiKe5HHkjdSeD72q9WsiJhRiaxf.
If two addresses with the same firstbits appear in the same block, then the addresses are given firstbits in the order they are seen in the raw block data (i.e., the first one would be given 1sgtspike, and the second would be given 1sgtspikeX, where X is the next character in the address).
IIRC, this contradicts information given earlier, that neither address would get 1sgtspike: both new firstbits would contain enough characters to distinguish them from each other, regardless of their ordering within the block. This is always how firstbits have been resolved. If Abe resolves firstbits in a different manner than the above, then it should not be calling them firstbits.
True, but if so, it is not for lack of trying. Rather than rename the function in Abe, why don't we finish the standard and bring ourselves into agreement. Here is where we left off: https://bitcointalk.org/index.php?topic=16217.msg960077#msg960077Hello again John! Firstbits.com had always differentiated by order of appearance in the raw block data, and given the first appearance the shorter firstbits. I'm not sure who stated otherwise, but for firstbits.com, that's always been the case. I am not sure what standard blockchain.info follows on that front, but I assumed it followed the same. We should find out. Regardless, giving enough firstbits to distinguish both addresses in the same block is certainly cleaner. I didn't want to change it for fear it could screw up someone relying on the original implementation. The likelihood of someone using one of those addresses is slim, but the possibility still exists. Now would be a good time to change it, if we are also nailing down other portions of the specification. Yes, let's indeed finish the standard. I suppose I dropped out of that original discussion because I am not familiar enough with the different OP functions of Bitcoin and what they mean/do. Is there some reading I can do somewhere that explains more about these? I suppose I would say that as long as a transaction is valid and included in the blockchain, there is no reason it shouldn't also be included in firstbits. Will the average person know what a transaction with OP_NOP means, or how to know if a transaction has it or not? For example, transaction 5492a05f1edfbd29c525a3dbf45f654d0fc45a805ccd620d0a4dff47de63f90b has an OP_NOP appended to one of the addresses. Blockexplorer decodes the address correctly, but blockchain.info doesn't seem to have a handle on it: http://blockexplorer.com/tx/5492a05f1edfbd29c525a3dbf45f654d0fc45a805ccd620d0a4dff47de63f90bhttps://blockchain.info/tx/5492a05f1edfbd29c525a3dbf45f654d0fc45a805ccd620d0a4dff47de63f90bSo you are arguing that these OP_NOP transactions should be discluded, despite the fact that they are included in the blockchain? I am not disagreeing with you, I just want to understand more about what the disclusions are and how easy it will be for the average person to understand why a particular address doesn't have firstbits. |
|
|
|
(yep... there were proof/images/screenshots that both BFL/AVALON DID MINE using customers miners)
Care to share said proof? I remember seeing rather blatant proof of Avalon doing it (dusty fans, etc), but not BFL, at least beyond testing prototypes and doing the 24 hr burn-in. |
|
|
|
Alright, I quickly put firstbits.net up, but right now it just reads from blockchain.info's API. I need to rewrite the engine for calculating them, because the original one was simply too slow.
I may be interested in adding firstbits functionality to the Mycelium backend system. To do this I need to know exactly what the rules for name resolution are. It seems that blockchain.info does not do it the same way that Abe does. Without a firm rule-set the purpose of firstbits is defeated. SgtSpike, can you share the precise definition of a firstbits address? I wasn't even aware that Abe even performed firstbits resolution. Is there a running example you can point me to? The definition is mostly displayed in layman's terms here: http://firstbits.net/about.phpAlso there's the basic SQL statement used here: http://firstbits.net/logic.htmlWhatever address appears first in the blockchain claims the Firstbits for every previously unused combination up to the full address. For example, 1SgTspiKe5HHkjdSeD72q9WsiJhRiaxf9 doesn't have the firstbits 1s, 1sg, 1sgt, or 1sgts because other addresses used prior to this one already started with those combinations, but it DOES have the firstbits 1sgtsp, 1sgtspi, 1sgtspik, 1sgtspike, 1sgtspike5, etc, all the way up to 1SgTspiKe5HHkjdSeD72q9WsiJhRiaxf. If two addresses with the same firstbits appear in the same block, then the addresses are given firstbits in the order they are seen in the raw block data (i.e., the first one would be given 1sgtspike, and the second would be given 1sgtspikeX, where X is the next character in the address). Blockexplorer.com shows the raw block data, and lists the transactions in the same order as they are seen in the raw block data, so it is a reliable source for determining which address should come first in the event that the same new firstbits combination is shared by two addresses in the same block. This is always how firstbits have been resolved. If Abe resolves firstbits in a different manner than the above, then it should not be calling them firstbits. |
|
|
|
|
What're we watching for, again?
|
|
|
|
seriously?
I was a customer of bfl as well... I have 6 fpga... so my conscience of bashing them is clean...
I did not do "2012" pre-order any asics for some trust reason... but these pre-orders really need to stop...
They are trying to manipulate here... it is very obvious that they are the ones getting rich here...
they get to do whatever they wants...
1) GET MONEY from preorders...
2) build miners...
3) Mine with them first until people gets mad and really want their orders...
4 ) deliver a few orders (so consumers gets some hype and buys MORE PRE-ORDERS)
5 ) Repeat step 1-4
I mean avalon did the right thing in their "FIRST BATCH"... now they're trying to do the same as what is BFL is doing...
One thing i really want to happen is.. have at least 5 companies manufacturing miners...
that way they'll have to compete to get the consumers business.... and not abuse their capability to build these miners...
I still don't quite understand what your complaint is. If you don't like BFL, don't order from them. If you don't like Avalon, don't order from them. If you don't like pre-orders, don't pre-order anything. Your steps 1-4 are not at all obvious, and simply conjecture based upon the little evidence you can see from looking at the company as an outsider. There is no proof of your accusations. |
|
|
|
DrHaribo, my BFL Singles arrived today, but they are not working with the BitMinter client. It logs errors like this many times per second: BitFORCE (COM4) ERROR: Unexpected response to work results poll command: 8636095F59A26EE93EC42907D221D59B3FF3659FAC2CF16002C6F67E8A14207A,2BA85F2E51E5F4F81A00A429,1,0 Any ideas what could be wrong? They work fine on Easy Miner, but I prefer the BitMinter client. Has he updated to support 1.2.5 firmware yet? Could be that. The reply in 1.2.5 adds the chip that found the result - in your case that says: 8636095F59A... = midstate 2BA85F... = blockdata 1=chip 0=nonce count 1.0.0 Jalapeno or PARALLELIZATION disabled, would not have the "1," in there. Maybe so? Thanks for the input. |
|
|
|
I think it is about time that someone takes up on this...
i am getting sick on these pre-orders...
if u have stuff stocked... sell it... if not.. don't sell it...
If you don't like pre-orders, don't buy them. Some people like/want pre-orders though. What you mean ? We can take back our money from bfl
How? As far as I know they dont refund anymore nor do they deliver I got my BFL 60ghs miner today Likewise, I received my two a couple days ago. They do deliver. |
|
|
|
i ordered my product from butterflylabs like 2months ago sitll nothing i agree this company is nothing but a scam
Ha! Think two months is long? I ordered an SC on June 26th, 2012 and just received it last Friday. 381 days. It will likely NEVER make me back the 120 BTC it cost me. If that's what you think, you should sell it to someone for 150 BTC! That's the going rate I hear... EDIT: BTW, received my singles today, they are happily hashing away! |
|
|
|
DrHaribo, my BFL Singles arrived today, but they are not working with the BitMinter client. It logs errors like this many times per second: BitFORCE (COM4) ERROR: Unexpected response to work results poll command: 8636095F59A26EE93EC42907D221D59B3FF3659FAC2CF16002C6F67E8A14207A,2BA85F2E51E5F4F81A00A429,1,0 Any ideas what could be wrong? They work fine on Easy Miner, but I prefer the BitMinter client. |
|
|
|
|
Show Posts
