|
Hi Sebastian, I'd like to keep my chips please.
Username: Roy Badami
BTC-Refund Payment-adress: N/A
Amount of chips you want to keep: 40
I know it probably won't make ROI now but I've already paid for assembly, and anyway, hopefully enough batches will cancel overall that this will bump our batches up the list a bit.
ETA: Besides I like mining - also, it's good for the network. I never expected to make money out of mining - at best I hope it will pay a substantial proportion of the costs. Mainly it's a more fun way of acquiring BTC than buying on an exchange. If I didn't have my BFL tracking number in hand I wouldn't even have considered cancelling my Avalon chips as I only have 1.34 Gh/s of hashing power currently mining. As it is the BFL tracking number made it a harder decision. But I decided I will keep the Avalon chips, even assuming I will almost certainly get my Single before my Bitburners. But the Bitburners are a lot prettier than a Single, and I think this way also supports burnin's work better.
roy
|
|
|
|
And i ask myself if its ok when i pay out 95% of the paid bitcoins at the end so that i dont have to sit alone on the accrued costs and the work time.
The way I see it, the chips cost BTC 0.07821 per chip from Avalon and we paid you an extra BTC 0.00779 for the service of organising the group buy. If the refund from YiFu is BTC 0.07821 then naturally that should be refunded to buyers. If you choose to choose to refund a portion of the BTC 0.00779 then I'm sure people would thank you, but it seems to me you've done a lot of work and you're certainly not obliged to return all of it (or even any of it). Just my 2c - I haven't decided if I'm going for a refund yet or will just take the chips. roy |
|
|
|
|
Well, so it *appears* from other threads that YiFu is going to offer to refund undelivered batches of chips.
It *appears* from other threads that most people seem to want the group buys to go down the refund route.
This looks like it is going to get messy for everyone involved. At a minimum, it is going to be a lot of extra administrative work for burnin, zefir, Sebastian (and others).
Primarily, I'd like to see a solution that doesn't result in burnin, zefir or Sebastian being out-of-pocket (obviously) and also that doesn't result in burnin being so fed up that he gives up on Bitcoin hardware work.
I'd also quite like to have the two Bitburners I ordered hashing away - they're pretty :-)
Not sure I'll get any of that, but I can live in hope....
roy
|
|
|
|
Most of the discussion of this seems to be happening in zefir's thread atm, but as I said there: Option B would be the best outcome, though not for burnin and other developers.
Also not for customers who have already paid burnin. Also not for those of us who don't want burnin to get seriously screwed by this, because we are looking forward to the Bitfury boards he's planning to design. (I'm in SebastianJu's group buy, not zefir's) Personally I don't quite see why 0.35BTC/Ghash for something you can't actually get hold of is such a gamechanger, anyway. A BFL Single is 0.35BTC/Ghash for something you can't actually get hold of, too. roy |
|
|
|
Option B would be the best outcome, though not for burnin and other developers.
Also not for customers who have already paid burnin. Also not for those of us who don't want burnin to get seriously screwed by this, because we are looking forward to the Bitfury boards he's planning to design. (I'm in SebastianJu's group buy, not zefir's) Personally I don't quite see why 0.35BTC/Ghash for something you can't actually get hold of is such a gamechanger, anyway. A BFL Single is 0.35BTC/Ghash for something you can't actually get hold of, too. roy |
|
|
|
The network difficulty defines how many of these you need to find before you should, on average, find a block
Where does cgminer's reported 'network difficulty' come from - and is it supposed to be the same as Bitcoin's difficulty? (I find it's not the same - but I guess that may be just down to what the pools report?) roy It's there in the block header you are hashing. Block header being hashed is: Type, Prev, Merkl, Time, Bits, Nonce. Diff = f(Bits) Thanks. And of course the value reported by cgminer is correct :-) I made the mistake of believing the figure at the top of bitcoincharts.com roy |
|
|
|
The network difficulty defines how many of these you need to find before you should, on average, find a block
Where does cgminer's reported 'network difficulty' come from - and is it supposed to be the same as Bitcoin's difficulty? (I find it's not the same - but I guess that may be just down to what the pools report?) roy |
|
|
|
That's an amateurish problem that only happens with custom implementations of ECDSA. You have to use a random number when calculating the signature, and every basic implementation of ECDSA guarantees this (at least to the extent of the randomness it can pull from your system). The problem there was people hand-rolling their own and not realizing that reusing "random" numbers when signing different messages with the same key reveals the private key.
What do you think of this? Is it safe? (Or is it too new to say?) https://tools.ietf.org/html/rfc6979 |
|
|
|
This post http://seclists.org/oss-sec/2013/q3/358 mentions deterministic ECDSA signatures and references RFC 6979. Is there any reason why Bitcoin clients shouldn't use this construction, other than perhaps the possible newness of this exact instantiation? roy |
|
|
|
Thanks for pointing this out. Thats not a good thing. One would need special PSU's that have different 12A-Outputs since a high wattage PSU with only 1 or 2 such channels used with Y-cables would hurt the miners when i understand it correctly.
Its a good thing i didnt buy more psu's yet but others might have bought wrong ones. Or is there a workaround for this?
You don't need special power supplies. As I understand it we need to do one of two things: - EITHER: Power each miner via its PCI-E connector, just like you do with most other miners. How you do this doesn't matter, as long as you don't overload your PSU or cables
- OR: Connect your miners together in pairs, using the screw connectors and the solid-core wires that burnin specifies, and then power each pair of miners through the PCI-E connector of one miner in the pair
What you must not do is connect larger groups together using the screw connectors, in an attempt to power three or more miners all from power fed to one of the PCI-E connectors. Either connect them in pairs, or just ignore the screw connectors and power each miner via its PCI-E connector. If in any doubt at all, just ignore the screw connectors. Corrections welcome if I've misunderstood anything. roy |
|
|
|
Nobody is saying that Mt. Gox claimed they sent a USD wire transfer and the funds were not received by the recipient.
Almost exactly that is claimed here https://bitcointalk.org/index.php?topic=231960.msg2540042#msg2540042 (more specifically - as I said previously - the payment is received, but then reversed when the covering payment is blocked) Indeed, MT 202 COV SWIFT messages exist precisely so that US correspondent banks can block 'illegal' USD transactions. There is a link in that same thread to the famous example of US correspondent banks blocking a payment for cuban cigars that was made between two European companies. roy |
|
|
|
Was that for an international wire transfer through the SWIFT system? Details would be useful. SWIFT rules don't allow banks to revoke transactions for SwiftPay transactions up to USD 20,000 (50,000 EUR between banks in the EU). Settlement has to occur within six days. "Priority" transactions are even less revocable. Banks have to sign a service level agreement with SWIFT to use the system. Once the bank has sent payment instructions via SWIFT, the bank is obligated to cover them with bank funds. It's not at the option of the sending bank. SWIFT is compliant with relatively recent (few years) international AML rules which require all covering payments to include details of the payment that they cover. Indeed, SWIFT introduced the MT 202 COV message a few years ago specifically to comply with AML requirements. I think the AML rules trump the SWIFT rules. No US correspondent bank will process a covering payment for a transaction that (they believe) violates US law, and SWIFT would be mad to try and draft a contract that requires them to violate US law. roy |
|
|
|
And BTW, why would the bank "reject" credits after holding them for a few days?
Imagine you are outside the US. Gox, of course, is also outside the US. You wire USD to Gox. Your bank sends a message to Gox's bank instructing them to credit Gox's account, which they do. In parallel with this, they send instructions to arrange a covering payment between the US banks that your bank and Gox's bank use to settle USD payments (so called 'correspondent banks') One or other of the correspondent banks' compliance departments then decides to refuse the covering payment for some reason. So Gox's bank finds itself out of pocket, because it has not been paid the funds for the transfer. So obviously Gox's bank reverses the transfer. We've had at least one report of a withdrawal wire being reversed a couple of weeks after the fact (apparently as a result of Citibank's compliance department blocking a covering payment) so it's not at all surprising that similar has happened with deposit wires. roy |
|
|
|
Hi All,
So my 5 x ASiCMiNER Block Erupter USB Sticks Arrived and I am incredibly bored with them already. So I thought Hey! Why don't I mine for some other people just gettin into bitcoins that could really use the starting coins.
So...
I'm offering to mine 0.001 Bitcoin on EclipseMC just post your Bitcoin Address I will be paying out random 1 BTM Payouts throughout the year
Cheers,
CrazyRabbi
*UPDATE* Well I officially derped the payouts and I greatly apologize as I forgot about the dust and the minimum payout of 5430 Satoshis so because of this I'm going to be offering 1 BTM each Randomly throughout the year.
1. sudorfrm (48th Post Random.org Result of 48) Bitcoin Address: 13caLEcXKRkYAt9bf2SMSJ5jRiiyCNwH4V TXiD 9d6850ed2a65c50844a2b7dbaa240ed66f81369b219a05ab436f9525b4615539
2. albon (10th Post Random.org Result of 10) Bitcoin Address: 1E7XiGWa3YjFJasoZ1omJZCMv8TdPQLdqv TXiD: bdb909ce4c8728a1cb9aee3897d4526ac514ebda939dc06b96de9955066eaa4a
3. steveds (28th Post Random.org Result of 28) Bitcoin Address: 1MPktEKGB5kzYspdVv2qQJPcYchjXqHRnT TXiD: 2a74eda9c3af96e9308d780d08d18f2e2d15f3e3c66f584a607eda5151dcc914
4. 2048-bit (35th Post Random.org Result of 35) Bitcoin Address: 17i4zPGj3yR94T3XrT1vtgexbLoVvFEwN2 TXiD: 6b70644f4aef0153bf9f339c8489aeba658e38c26d331f1932a53b631c6042b2
5. lovecoins (41st Post Random.org Result of 41) Bitcoin Address: 1LkGkETvi9xUMrQvtBV9H7dMhbeKpVqzvP TXiD: de280d39bb72ef74e969ce01e38f68dbdb66efea5f8d463cbf34fa8c2f276c0d
6. JuenoMT (4th Post Random.org Result of 4) Bitcoin Address: 189UkUcUtan6kMmbk4bn3UaCZNgWS9Lwav TXiD: d34e559730c800e8f6169105c908cde99695cb3f6dedb8263619646373e72336
7. Benson Samuel (44th Post Random.org Result of 44) Bitcoin Address: 1DE9zAE9iEetbojfbuGy6JvTfULG6x9pzP TXiD: ccc2392d97479004c9c00079662374ac3499b2f59e3de9873b6e462cd45352fe
8. karlzt (95th Post Random.org Result of 95) Bitcoin Address: 1LYQf3Ys4YWDWMxrivyQCEGuNoKWgu7yFv TXiD: 1e166422b5813fde768277862fde5be84c00e0c8aa9312c474d9583bfd276dda
9. bitcoinfanboy (25th Post Random.org Result of 25) Bitcoin Address: 12fJywCo5CeK9NtD6Rpr4SAdPM9EVbmyeR TXiD: 91f425f811b3130c5d3a38e2dbe0cdd1a52fb04223149931c00645af901e73f9
10. Chode (3rd Post Random.org Result of 3) Bitcoin Address: 13GebGv284cQN7xRs7S6husHX5cczijAA2 TXiD: 1f7899ed81e59574290af4004d4d693b36e998683703ff34b31b2eb9e8840596
11. Helmholtz (86th Post Random.org Result of 86) Bitcoin Address: 1MWNTEwygKLxvSzreA5NytgqXKdicNyJQs TXiD: 1f516ede86afd1ce49a26b4fa88fc0a6ee20d4f07ed5492df90a539ff38ffd2e
12. Blood Ninja (105th Post Random.org Result of 105) Bitcoin Address: 1PRA2ijbv31mHxGFurWUmduPkztTHCWsLo TXiD: 14d6456c24f8b88db59d47b7588fb94355d1543cf268115e540a59f84e6d7ff7
13. HeroC (29th Post Random.org Result of 29) Bitcoin Address: 1HeroCCotNLtJzpEiWGrRkaFSFDBZkF1jG TXiD: 3d9457395f898716768faf0337fd8d525d2d52a15012fa7d018d4853e9e36222
14. jesse11 (155th Post Random.org Result of 155) Bitcoin Address: 1Ns9v93ngjYJavLc6VMQj7HKPCv5BCPSRE TXiD: 8d2751b848497a96646034b213d31c8bbdccfd0d73523633e691b5f60335e194
Post Payments Completed:
Post 48
Post 10
Post 28
Post 35
Post 41
Post 4
Post 44
Post 95
Post 25
Post 3
Post 86
Post 105
Post 29
Post 155
This looks like you had to post the address to a forum post to (possibly) receive a millibit. What we're talking here is millibit transfers to unpublished addresses. roy |
|
|
|
In the Netherland's everyone may have at least a basic account (with no credit limit). Because you can't exist in modern society without a bank account.
You can't receive income or pay taxes without one.
I guess this is another reason why Bitcoin is needed.
They've been talking about this here for the last three years, but with little action so far. |
|
|
|
And here's another one - resulting in someone's accounts being closed for fraud (all accounts, with all banks) due to an error by their bank! At least this one was finally resolved, but it seems a fair amount of luck was involved in resolving it. http://www.bbc.co.uk/news/business-18540832 |
|
|
|
10 weeks have now passed since batch 2 was ordered. This week Avalon shipped only one 10k batch of chips to zefir, and nobody else has got nothing. If Avalon continues to process only one chip order per week are we getting any chips before winter  I tend to think that avalon had 10k chips lay around and they wanted to show good will by shipping a batch. If they didnt the customers would cry already. So they are silent... Its the only explaination to me that this single batch is the only shipped. Well, Zefyr's batch 1 was ordered 16 April. Assuming the wafer run is only booked with the foundry when the chips are ordered from Avalon, then even our batch 1 wafers would have been ordered quite a few weeks after zefir's. And then of course actual lead time might vary, depending on how busy the foundry is when the order is placed (and how busy the packaging house is, and how quick Avalon is at shipping the chips out - and indeed how quick Avalon was to place the order with the foundry in the first place). It will be interesting to see how long Zefir's next batches take, since they were only ordered a couple of days later. In fact even zefir's batch 7 was ordered before our batch 1 - so does that mean our batch 6 will actually ship before our batch 1? :-) |
|
|
|
Still, if OP has not divulged his address, how could the anonymous sender know his address? Duh, the blockchain is a public ledger, the question is why him specifically, and not somebody else?
It isn't him specifically, it is him and a bunch of somebody elses. If it is ongoing maybe it would be worth it to figure out the mechanism used for deciding and snag some cool milibits. Right. It's lots of people - and it appears we have no idea who or why. In my case, I know with reasonable certainyy that there is only one place where that address had ever been published before, and that was on the blockchain at transaction 931a219896260b003c322d3a03df86cb663b2415398e555ee5f36c0184658b29 Of course, now that I've published the address in this post, I fully expect to be spammed with huge numbers of free coins  (Or maybe not) roy |
|
|
|
|
Show Posts
