|
That's ok that you're fearful - less wait time and more BFL ASICs for me then!
|
|
|
|
Oh boy, I'm just beginning to truly realize what a mess an algorithm change will be...
Even assuming a best case scenario - people don't have TENS OF THOUSANDS OF DOLLARS in ASICs to pay off yet - bitstreams and miners need to be changed and it will take MONTHS, it's going to be slow, the new fork (with the better algorithm) will generate mostly worthless coins for the moment (since very few are involved in it) so people will insist on staying on the old fork, with the vulnerability, arguments will arise not to mention the severe confidence hit Bitcoin will take. A lot of people will dump their coins when they hear Bitcoin is vulnerable to the very core and their money's security depends on using a fork that very few miners support. Not to mention that every merchant and service provider using Bitcoin will have to change their entire infrastructure... Holy shit, it's a nightmare. And that's the BEST case scenario...
The WORST case scenario is that ASICs have a good chunk of the hashing power. In that case that entire chunk is there to stay. Since ASICs can't be updated and the miners have lots of money invested in them, they would lose all of their investments if they would support the new fork. So they won't support it. Therefore the new fork will be reserved to a few percent of the hashing power and the old fork will carry on with the vulnerability. So the change would come at a dead slow pace and it could be enough to make Bitcoin dead in the water.
Either way, a hashing algorithm change is extremely likely to be disastrous for Bitcoin. The entire infrastructure would need updating, specialized hardware would need to be thrown out rendering tens, maybe hundreds of thousands of dollars lost. The dead slow updating and people insisting on keeping a vulnerable fork could be the final nail in the coffin.
Now that I managed to scare myself shitless regarding the future, can somebody tell me I'm wrong and how can all this be easily mitigated?
Maybe starting the updating procedure a year or so in advance, before any vulnerability is discovered, giving time to everyone to update slowly and be prepared. The new fork could start as a test net of sorts and be reset when it's decided to start the fork proper.
Perhaps start with the obvious: We don't need an algorithm change. We don't need one YET. But such an eventuality is being planned for. Well, ok, I can agree with that. We'll eventually have to move from SHA256 to something else, maybe in 25, 50, 100 years. And in that case, it should be a change that will be known well in advance (the bruteforcibility of SHA256 should always be easy to calculate). If it is well known in advance, then manufacturers will have time to create new ASICs that pertain to the new algorithm, and, in all likelihood, difficulty wouldn't actually drop too catastrophically. The only thing that would be truly catastrophic is if a flaw in SHA256 is suddenly revealed. |
|
|
|
Oh boy, I'm just beginning to truly realize what a mess an algorithm change will be...
Even assuming a best case scenario - people don't have TENS OF THOUSANDS OF DOLLARS in ASICs to pay off yet - bitstreams and miners need to be changed and it will take MONTHS, it's going to be slow, the new fork (with the better algorithm) will generate mostly worthless coins for the moment (since very few are involved in it) so people will insist on staying on the old fork, with the vulnerability, arguments will arise not to mention the severe confidence hit Bitcoin will take. A lot of people will dump their coins when they hear Bitcoin is vulnerable to the very core and their money's security depends on using a fork that very few miners support. Not to mention that every merchant and service provider using Bitcoin will have to change their entire infrastructure... Holy shit, it's a nightmare. And that's the BEST case scenario...
The WORST case scenario is that ASICs have a good chunk of the hashing power. In that case that entire chunk is there to stay. Since ASICs can't be updated and the miners have lots of money invested in them, they would lose all of their investments if they would support the new fork. So they won't support it. Therefore the new fork will be reserved to a few percent of the hashing power and the old fork will carry on with the vulnerability. So the change would come at a dead slow pace and it could be enough to make Bitcoin dead in the water.
Either way, a hashing algorithm change is extremely likely to be disastrous for Bitcoin. The entire infrastructure would need updating, specialized hardware would need to be thrown out rendering tens, maybe hundreds of thousands of dollars lost. The dead slow updating and people insisting on keeping a vulnerable fork could be the final nail in the coffin.
Now that I managed to scare myself shitless regarding the future, can somebody tell me I'm wrong and how can all this be easily mitigated?
Maybe starting the updating procedure a year or so in advance, before any vulnerability is discovered, giving time to everyone to update slowly and be prepared. The new fork could start as a test net of sorts and be reset when it's decided to start the fork proper.
Perhaps start with the obvious: We don't need an algorithm change. |
|
|
|
Thanks a bunch Obsi! It was a pleasure.  |
|
|
|
I would probably look something like this.
loan A 126/2000 @ 1.2 btc each
loan B 334/1000 @ .5 usd each
Would that work for you?
That'd be perfect. |
|
|
|
shtylman, How long does it take to get ACH setup? Do I have to email you for each withdraw I want to make? Or can I get ACH setup one time, then keep using it without having to email you each time?
On my account he set it up the same day. You only need to send account info once. There is no automated way to request a withdrawal you need to email support. You don't need to send account info on each request though. Low tech but it works and response time has been fantastic. I was concerned about security and asked for a public key to encrypt the account details. He sent me his openSSL public key which I have no idea how to use. I asked him if he could provide a PGP key instead and he did within minutes. TL/DR shtylman is a pro! Did he email you to confirm your account info? I sent an email 2-3 days back and haven't heard a peep... Sometimes I don't respond to the ACH setup request right away. This does not mean there was a problem. Since most requests just send the info but don't wish to withdraw any funds at the time I just setup the ACH and wait until a withdraw request is sent. Soon it will be clear from your online profile that ACH is setup and no follow-up email will be required  It wasn't just a setup request though - I requested setup and withdrawal in the same email at the same time, still haven't heard anything back. |
|
|
|
shtylman, How long does it take to get ACH setup? Do I have to email you for each withdraw I want to make? Or can I get ACH setup one time, then keep using it without having to email you each time?
On my account he set it up the same day. You only need to send account info once. There is no automated way to request a withdrawal you need to email support. You don't need to send account info on each request though. Low tech but it works and response time has been fantastic. I was concerned about security and asked for a public key to encrypt the account details. He sent me his openSSL public key which I have no idea how to use. I asked him if he could provide a PGP key instead and he did within minutes. TL/DR shtylman is a pro! Did he email you to confirm your account info? I sent an email 2-3 days back and haven't heard a peep... |
|
|
|
|
This thread is hilarious.
|
|
|
|
I just can not believe this. GPUs are useless, FPGAs are useless before they give me positive ROI.
All the money invested in mining HW will go to BFL. This is a dangerous situation.
Why is it dangerous? |
|
|
|
|
I currently have an order in for four BFL Singles... can I switch those to these ASIC miners?
|
|
|
|
|
Well, they promised a June 15th announcement, yet it's past closing time in their part of the world... June 16th then?
|
|
|
|
Order Date: May, 10 2012
Shipped Date: July 10th
Quantity: 1
ALSO Ordered
Order Date: May 22, 2012
Shipped Date: July 22
Quantity: 2
Still waiting but it sucks when a company sit on your cash for more than 30 days. I would have saved in BTC and saw 20% return.
I would buy 5 more but that much cash in the wind for 60 days is just crazy.
I'm not sure where you got the 60 days, the Mini-Rig is quoted 12 to 15 weeks, that's at least 84 days! If you look at the wait times located here https://bitcointalk.org/index.php?topic=77796.0 you will see the singles are were down to less than 60 days. Fixed that for you. |
|
|
|
I suppose I could implement something that could divide between different lenders... The borrower could just as easily request multiple small loans and divide it up that way. That would be much easier to program and less prone to failure. Would having to make multiple loan requests be a huge problem for you? What could some of the complications be?
I'll just say this much: The popularity of P2P USD lending is, in part, due to lenders being able to diversify their loans so as to mitigate the risk of default. A person with $10,000 would much rather invest $100 each into 100 loans than the full $10,000 into 1 loan. That way, if one of the loans is defaulted on, it's not such a big hit, whereas the $10,000 loan defaulting would be devastating. The loans could be split up by the person requesting them, but then, the person requesting them wouldn't know how much each lender wants to lend, so how would they know what to split the loan into? It's more programming to implement this, I agree, but in my opinion, you're going to lose out on a lot of potential lenders if you don't allow this type of fractional lending. This is great input thank you. I could implement package loans. Where a loan could consist of hundreds of smaller loans. When the lender would like to lend a particular amount he could type in the number of small loans he would like to take on much like shares... This would not be that difficult because it would not deviate far from my currently implemented coding. What do you think? I think people would raise an eyebrow at something like that. I'd much rather see this: Loan A: $300/$10,000
Loan B: $100/$1,000 Than this: Loan A.1: $10
Loan A.2: $10
Loan A.3: $10
Loan A.4: $10
Loan A.5: $10
...
etc, etc, you get the idea Now, if you can do the multiple loans thing in the background, and make it seamless to the end user, then I suppose it doesn't matter how you do it. Just don't make a lender or borrower look at pages of tiny loans that are all, ultimately, part of the same loan. |
|
|
|
I suppose I could implement something that could divide between different lenders... The borrower could just as easily request multiple small loans and divide it up that way. That would be much easier to program and less prone to failure. Would having to make multiple loan requests be a huge problem for you? What could some of the complications be?
I'll just say this much: The popularity of P2P USD lending is, in part, due to lenders being able to diversify their loans so as to mitigate the risk of default. A person with $10,000 would much rather invest $100 each into 100 loans than the full $10,000 into 1 loan. That way, if one of the loans is defaulted on, it's not such a big hit, whereas the $10,000 loan defaulting would be devastating. The loans could be split up by the person requesting them, but then, the person requesting them wouldn't know how much each lender wants to lend, so how would they know what to split the loan into? It's more programming to implement this, I agree, but in my opinion, you're going to lose out on a lot of potential lenders if you don't allow this type of fractional lending. |
|
|
|
Well, I applaud them for providing some nice liquidity on that exchange...
Do you have any more BTC to sell him? A bit, but I'm holding back the rest for a few days. |
|
|
|
|
Well, I applaud them for providing some nice liquidity on that exchange...
|
|
|
|
It was a lot higher until I sold into it.  |
|
|
|
Contemplating cancelling my orders (they are well beyond 6 weeks now)....the possibility of ASIC being released soon is scaring me.
You shouldn't cancel. You should sell your place in line. No, he should just cancel. |
|
|
|
|
So there won't be the possibility of multiple lenders for a single loan?
|
|
|
|
|
Markm - having everyone store the same data is a bit different than having a handful of people store the same data, and a different handful storing different data, etc.
|
|
|
|
|
Show Posts
