Proposing new feature in Bitcoin protocol to reduce the number of thefts

[blackarrow]

Dear Bitcoin Developers,

We would like to propose a feature in Bitcoin protocol in order to reduce the number of Bitcoin thefts.

Real world scenario: attacker installs a trojan into your computer, downloads the Bitcoin wallet and keylogs your computer to get the password. The attacker can and will spend all your money and there's nothing you can do about it.

So, we would like to propose this feature to be added to Bitcoin protocol:

A "Time Lock" command for Bitcoin addresses.

    This will function in the same way as a safe does: The owner of the address will announce the network that he/she wishes to lock this address and will require X amount of minutes/days to be unlocked.
     This would mean that the Bitcoin network will require the user to issue the unlock command and wait for the timer to expire before allowing him/her to spend the money from that address. The GUI client must announce the owner that his address has been unlocked and display a countdown timer so he has a chance to take action.

     There's a problem with the above scenario: as the hacker has access to the keys, the owner still cannot stop spending because he/she can lock the money again but the attacker can unlock them, triggering a race that leads only to a draw (permanent lock of the funds) or the attacker to win (as the hackers are dedicated to make software that will trigger their transaction faster or will spend higher commissions to get the transaction processed quicker etc).

Here is the solution to this problem:

    Lock command will also require an emergency backup address. A 2nd lock command issued will not allow to change the emergency backup address. If the attacker triggers the unlock command and the real owner wants the money back, he/she can issue an emergency recover command and the network will send the money to the emergency address (that was set-up when the first lock command was issued).  It is important that transfer will be completed only after the lock timeout expires and the new address will be locked again for the original timeout. This is required in order to give a chance to the real owner to issue the last and final command (if the hacker had managed to get access to the 2nd address as well).
    The last and final command that can be issued by the real owner of the new address will be to destroy the funds. The funds will be destroyed, not sent to the miners. This is important in order to deter the hackers to develop any other techniques to steal the money (for example few days ago I read that they hacked 6 ISPs and redirected the whole hashing power towards themselves). If we do not destroy the funds, we are inviting them to hack our hashing power.


To summarize:

   lock(address, delay, emergency address)
      note: a new lock command, issued while the lock is active, will not accept to change the emergency address or the delay.
   unlock(address, where_to_spend);
      note: a new unlock command will refresh the timer to the original lock command. If a previous unlock command was issued with no address to spend, there will not be accepted any new addresses
   issue_emergency(address);
       will cancel any unlock commands and send the money to the emergency address set with original lock(). emergency address will be locked for the same amount of time as issued by original lock(). No further unlock commands are accepted.
   destroy(emergency_address);
       can be issued only on emergency addresses that are locked. it is important that this transaction to be signed by emergency_address only as we do not want the hacker that has access to our original address to be able to destroy our saved funds.

   

Regards!

[vancsj]

A 2-of-2 multisignature address would cover your needs, I think.

[vancsj]

I've considered that, it is not the same.

Can you explain the difference?

[confirmation120]

You lock the funds. The thief cannot access them and you will become aware if your funds are in danger. You can postpone the transfer as much as you want until the police can locate the thief. If you cannot locate the thief, you can destroy the funds.

Why destroy the funds? It is the same as death penalty in real life: will deter other people to repeat the crime.

IMO, most bitcoin related thefts are done behind TOR and VPNs that do not keep logs, therefore most thefts are not traceable.

Another issue is that this would lead to additional "transactions" needing to be done by the miners without compensation. In order for this to work properly, both "lock" and "unlock" transactions would need to be confirmed by the miners otherwise the network would not know for sure which one is "correct".

This would also make it much easier to launch what would essentially be double spend attacks against merchants that accept 0/unconfirmed TXs. The attack would work like this: You send a TX to a node that a merchant is connected to, and send a "lock" command to a well connected node a few seconds later. If the "lock" command would have a higher priority then a TX (it would have to in order to be effective) then the "lock" command would take precedent over the TX and the merchant would never receive their funds (having the same effect as a double spend). You would then issue an "unlock" command after the 0/unconfirmed TX is "forgotten" by the nodes

Another issue is that this would make it very easy to attack the network. Someone could easily create thousands of BTC addresses, send a very small amount BTC to each of these addresses and then send "lock" and "unlock" commands for each of these addresses. This would likely overwhelm both the miners and the nodes, making it difficult to even get a TX propagated, or if it is propagated to get it confirmed. 

[Cubic Earth]

I proposed almost the exact same thing in this thread: https://bitcointalk.org/index.php?topic=511881.0;all
At first I titled the thread Transaction reversability would be a good thing, but I some point I realized people were not even reading the original post, and they were just attacking the idea on the title.  That's when I changed it to Transaction reversability would be a BAD thing.

[justusranvier]

So, we would like to propose this feature to be added to Bitcoin protocol:

A "Time Lock" command for Bitcoin addresses.

Are you aware that Bitcoin addresses do not exist on the blockchain or in the protocol?

[DannyHamilton]

So, we would like to propose this feature to be added to Bitcoin protocol:

A "Time Lock" command for Bitcoin addresses.

Are you aware that Bitcoin addresses do not exist on the blockchain or in the protocol?

And that "addresses" are not spent, "outputs" are.

And that transactions don't have timestamps?

And that the timestamp on a block is unreliable as an indication of current real-world calendar time?

And that the change you are proposing would require so much modification to the way the protocol works that it would likely destroy the consensus system and the fungible nature of bitcoins?

[cr1776]

If flood is a problem, lock and unlock can be charged as any other transaction.

Just go ahead and implement it and do a pull request. That will give everyone time to evaluate the proposal in reality and determine whether this hard fork is justified. 

[inBitweTrust]

One problem with depending upon "lock_time" for security is that it will tie up the funds from the owner when for his own security he may need to access his funds sooner than anticipated.

This service could also be handled off the block with mutisig with a service like copay where the other party or oracle locks the transaction for a certain time period.

[Cubic Earth]

One problem with depending upon "lock_time" for security is that it will tie up the funds from the owner when for his own security he may need to access his funds sooner than anticipated.

Tying up, or encumbering one's own funds is and would always be a personal choice.  With freedom comes the freedom to make bad decisions.  It would be up the owner to weigh the pros and cons of trying up the funds.  It sounds to me like you are saying the 'problem' would be people making a choice, and then later regretting it.  Or am I missing something?

[inBitweTrust]

It sounds to me like you are saying the 'problem' would be people making a choice, and then later regretting it.  Or am I missing something?

No, I want people to have the freedom to make bad decisions. They can already use nTimeLock right now to make this decision so that isn't the issue.
blackarrow is definitely correct there are very specific use case benefits for doing this for either security (akin to how banks have timers on their vaults),
 preventing an interference from immediately being used,  or for green addresses.

The original recommendation wouldn't be feasible without a serious overhaul of the way the bitcoin protocol functions but lets assume that we are just talking about
adding a button on Bitcoin core that performed the timelock for the user. Additionally, lets ignore the ability to do this with Oracles- https://github.com/orisi/wiki/wiki/Performing-a-Timelock-transaction
What we are discussing is a UI implementation to ease the use of this feature that already exists in the protocol.

A few concerns:
1) Should we go out of our way implementing a feature that has a very specific use case that can be so easily accidentally misused?
2) Under "blackarrow's" scenario :

For example, imagine that you are at home and a theif bust in. They will get your 2 keys or 100 keys if they are located at home.
However, if you have a timelock they cannot override it. This feature give enough time to the police to take action.

When a physical attacker has a person hostage, ntimelock is a good way of getting this hostage killed either out of the thief's frustration or the thief needs more time until the timelock is released and killing the hostage would grant him that time.

3) There are other concerns with timelock with heavy use either being purposely or accidentally DDoS'ing the network.

[vancsj]

I think that the advantages of timelock are:
 - ease of use
 - more secure

For example, imagine that you are at home and a theif bust in. They will get your 2 keys or 100 keys if they are located at home.
However, if you have a timelock they cannot override it. This feature give enough time to the police to take action.

I agree it may be easier to use when your private key is not stolen, but I don't think it's more secure.

For the 2-of-2 strategy, the hacker can do nothing with just 1 key; but with your proposal, the hacker still have chance to succeed, if the hostage doesn't response quickly.

[dabura667]

How would you plan to implement this securely without exposing the pubkey?

The entire reason for not reusing addresses and using two types of hash on the pubkey is so you wouldn't have to expose it, protecting you from a theoretical breaking of ECDSA.

Obviously this would require a digital signature to prove ownership to the lock function, and thus expose the pubkey.

How would you mitigate this problem?

[DannyHamilton]

- snip -

- snip -

- snip -

Are you aware that 10% of the bitcoins in circulation are currently stolen? Are we going to do anything about it?

Are you including bitcoins that were willingly given to the thief or situations where large quantities of bitcoins weren't stored in cold storage at all (such as inputs.io, MtGox, pirateat40, SilkRoad, etc) in your calculation of "10%"?

If so, please explain how your proposal would have helped in any of those situations?

If not, then please explain where you come up with a number like 10%?

[inBitweTrust]

If you gave them the BTC willingly, I assure you that we did not.

183k already. If they reach 1M, I can only guess what will happen to BTC value ...

Grifters will always be able to game the credulous if you allow people to make dumb decisions. With freedom comes responsibility.

The lesson to be learned with all these "hacked" exchanges and hot wallets is that by exchanging your private keys for IOU tokens
you are defeating one of the main purposes of Bitcoin being p2p and not needing a middleman.  Bitcoin's purpose is not just to become a
cheaper paypal.

Exchanges should be decentralized and these are many ways to accomplish this task.

[CIYAM]

The lesson to be learned with all these "hacked" exchanges and hot wallets is that by exchanging your private keys for IOU tokens
you are defeating one of the main purposes of Bitcoin being p2p and not needing a middleman.  

Agreed - services will always be created "above Bitcoin" and numerous of those will "turn out to be scams".

Not everyone is *ready* to take *responsibility for their own money* (so if banks ever decide to allow "Bitcoin accounts" I am sure they'll be very popular).

[inBitweTrust]

Not everyone is *ready* to take *responsibility for their own money* (so if banks ever decide to allow "Bitcoin accounts" I am sure they'll be very popular).

Correct, and with Bitcoin it doesn't have to be an either or proposition. People can benefit by storing some of their BTC in insured and regulated hot wallets like circle and coinbase
and than keep most of their savings offline in multisig paper wallets or hardware wallets.

Our task and goal is to make the above task easy and user friendly. The OP intentions are in the right place but the details are what we have concerns about.

[CIYAM]

Correct, and with Bitcoin it doesn't have to be an either or proposition.

Agreed 100% - if one of the banks I use decided to offer a BTC account I think I'd probably put some BTC there.

[OgNasty]

What makes you say that these coins are stolen?

We've chased our stolen coins here.

Maybe you should ask KunaBTC why they ended up with your supposedly stolen coins?

https://twitter.com/kunabtc

EDIT:  Anyone know who runs KunaBTC?  Are they a forum member here?  I would love to have their explanation of how they ended up with "stolen coins" from Black Arrow. 

[silversurfer1958]

Whatever scenario you envisage that requires a solution, I'm sure someone else can come up with a scenario that will require anotrher solution.
at the end of the day, the tools are available for us to protect our assets.
If someone chooses to holds a gun to our heads, or to our children's they can possibly defeat any means of protection employed by most people.

[notbatman]

What makes you say that these coins are stolen?

We've chased our stolen coins here.

Serves you right you piece of shit thief.

[ElGrandJefe]

[SimonBeCoinin]

want to reduce the number of thefts?   get rid of unethical manufacturers like Black Arrow and jail the lying bastards that run them, including BlackArrow, who made a number of promises to consumers right here on this forum to sell their miners that have since been broken.

who knows if this claim of stolen BTC is even true in the first place?  that's a big assumption given the history of the OP. 

[Pentax]

Dear Bitcoin Developers,

We would like to propose a feature in Bitcoin protocol in order to reduce the number of Bitcoin thefts.

Real world scenario: attacker installs a trojan into your computer, downloads the Bitcoin wallet and keylogs your computer to get the password. The attacker can and will spend all your money and there's nothing you can do about it.

So, we would like to propose this feature to be added to Bitcoin protocol:

A "Time Lock" command for Bitcoin addresses.

    This will function in the same way as a safe does: The owner of the address will announce the network that he/she wishes to lock this address and will require X amount of minutes/days to be unlocked.
     This would mean that the Bitcoin network will require the user to issue the unlock command and wait for the timer to expire before allowing him/her to spend the money from that address. The GUI client must announce the owner that his address has been unlocked and display a countdown timer so he has a chance to take action.

     There's a problem with the above scenario: as the hacker has access to the keys, the owner still cannot stop spending because he/she can lock the money again but the attacker can unlock them, triggering a race that leads only to a draw (permanent lock of the funds) or the attacker to win (as the hackers are dedicated to make software that will trigger their transaction faster or will spend higher commissions to get the transaction processed quicker etc).

Here is the solution to this problem:

    Lock command will also require an emergency backup address. A 2nd lock command issued will not allow to change the emergency backup address. If the attacker triggers the unlock command and the real owner wants the money back, he/she can issue an emergency recover command and the network will send the money to the emergency address (that was set-up when the first lock command was issued).  It is important that transfer will be completed only after the lock timeout expires and the new address will be locked again for the original timeout. This is required in order to give a chance to the real owner to issue the last and final command (if the hacker had managed to get access to the 2nd address as well).
    The last and final command that can be issued by the real owner of the new address will be to destroy the funds. The funds will be destroyed, not sent to the miners. This is important in order to deter the hackers to develop any other techniques to steal the money (for example few days ago I read that they hacked 6 ISPs and redirected the whole hashing power towards themselves). If we do not destroy the funds, we are inviting them to hack our hashing power.


To summarize:

   lock(address, delay, emergency address)
      note: a new lock command, issued while the lock is active, will not accept to change the emergency address or the delay.
   unlock(address, where_to_spend);
      note: a new unlock command will refresh the timer to the original lock command. If a previous unlock command was issued with no address to spend, there will not be accepted any new addresses
   issue_emergency(address);
       will cancel any unlock commands and send the money to the emergency address set with original lock(). emergency address will be locked for the same amount of time as issued by original lock(). No further unlock commands are accepted.
   destroy(emergency_address);
       can be issued only on emergency addresses that are locked. it is important that this transaction to be signed by emergency_address only as we do not want the hacker that has access to our original address to be able to destroy our saved funds.

   

Regards!

Dear BlackArrow,

Nobody cares if someone stole from you.  That it was possible only serves to further display your utter incompetence, as anyone but a total noob understands the concept of cold storage.  Furthermore, I doubt that this amount is anywhere near what you have cost your customers with your false promises, production delays, and refunds that were never made.

Please go back to building your miners that start on fire and concocting reasons not to keep promises you made to customers to sell them mining units while whining about everyone one else for the numerous miserable failures of your company.  While you clearly suck at all of that too, or your miners wouldn't be this late nor starting on fire, I'm sure that you're better at that than at contributing anything meaningful to the bitcoin protocol.

You've wasted more than enough of people's time already and done quite enough damage to the bitcoin community as well, so please go crawl back under whatever rock you slithered out from under in the first place.

Regards!

[inBitweTrust]

I didn't even realize that the original poster was a asic company. Wow, perhaps this is a disingenuous thread where he is merely manufacturing evidence as to a supposed theft that he is "concerned" about as a excuse to not fulfill his obligations.

What is up with this?

https://bitcointalk.org/index.php?action=trust;u=105804

[Waramp22]

Dear Bitcoin Developers,

We would like to propose a feature in Bitcoin protocol in order to reduce the number of Bitcoin thefts.

Real world scenario: attacker installs a trojan into your computer, downloads the Bitcoin wallet and keylogs your computer to get the password. The attacker can and will spend all your money and there's nothing you can do about it.

So, we would like to propose this feature to be added to Bitcoin protocol:

A "Time Lock" command for Bitcoin addresses.

    This will function in the same way as a safe does: The owner of the address will announce the network that he/she wishes to lock this address and will require X amount of minutes/days to be unlocked.
     This would mean that the Bitcoin network will require the user to issue the unlock command and wait for the timer to expire before allowing him/her to spend the money from that address. The GUI client must announce the owner that his address has been unlocked and display a countdown timer so he has a chance to take action.

     There's a problem with the above scenario: as the hacker has access to the keys, the owner still cannot stop spending because he/she can lock the money again but the attacker can unlock them, triggering a race that leads only to a draw (permanent lock of the funds) or the attacker to win (as the hackers are dedicated to make software that will trigger their transaction faster or will spend higher commissions to get the transaction processed quicker etc).

Here is the solution to this problem:

    Lock command will also require an emergency backup address. A 2nd lock command issued will not allow to change the emergency backup address. If the attacker triggers the unlock command and the real owner wants the money back, he/she can issue an emergency recover command and the network will send the money to the emergency address (that was set-up when the first lock command was issued).  It is important that transfer will be completed only after the lock timeout expires and the new address will be locked again for the original timeout. This is required in order to give a chance to the real owner to issue the last and final command (if the hacker had managed to get access to the 2nd address as well).
    The last and final command that can be issued by the real owner of the new address will be to destroy the funds. The funds will be destroyed, not sent to the miners. This is important in order to deter the hackers to develop any other techniques to steal the money (for example few days ago I read that they hacked 6 ISPs and redirected the whole hashing power towards themselves). If we do not destroy the funds, we are inviting them to hack our hashing power.


To summarize:

   lock(address, delay, emergency address)
      note: a new lock command, issued while the lock is active, will not accept to change the emergency address or the delay.
   unlock(address, where_to_spend);
      note: a new unlock command will refresh the timer to the original lock command. If a previous unlock command was issued with no address to spend, there will not be accepted any new addresses
   issue_emergency(address);
       will cancel any unlock commands and send the money to the emergency address set with original lock(). emergency address will be locked for the same amount of time as issued by original lock(). No further unlock commands are accepted.
   destroy(emergency_address);
       can be issued only on emergency addresses that are locked. it is important that this transaction to be signed by emergency_address only as we do not want the hacker that has access to our original address to be able to destroy our saved funds.

   

Regards!

Instead, why don't you propose a system where after you manufacture bitcoin mining hardware with customer preorder money, you deliver it to your customers in the advertised time period, with the advertised compensation plans, with the advertised quality.

Even better, when customers ask why their orders have yet to be manufactured even 6 months after your revised ship date, you tell them the truth and explain the current compensation plans instead of worrying about your untouched bitcoin hoard and funding the next 14nm preorder scam.    

[juju]

What about the project Hal was working on: bcflick - https://bitcointalk.org/index.php?topic=154290.0

I have not found enough time to try to setup a machine as he describes(Maybe during holidays), however the setup he has is essentially what your talking about.

Also if anyone has any more info outside of that thread on this project, I would be happy to read the information or at-least save it for when I have free time. Did anyone continue working on the project?

[SimonBeCoinin]

I didn't even realize that the original poster was a asic company. Wow, perhaps this is a disingenuous thread where he is merely manufacturing evidence as to a supposed theft that he is "concerned" about as a excuse to not fulfill his obligations.

What is up with this?

https://bitcointalk.org/index.php?action=trust;u=105804

that's the very first thing that went through my head.

"gee, isn't that convenient"

people have been saying all along that they can see their btc sitting in the wallets they sent them to to pay these people.  Meanwhile they're crying poor and saying they can't refund, after promising they would and people say their btc are sitting in plain view.   

and now they've suffered a theft. 

could be totally legit, but it could also just be yet another suspicious move out of a company that seems to ooze them like some people sweat.

and the trust ratings?   they earned each and every one I'm sure.  they've also left negative trust for people claiming they're not customers that are being paid to post in their thread, while in an online article they admit they have no proof of those claims.  they've set up a bot in that thread to delete some people's posts automatically, which is why that BlackArrow user is signed on 24/7, and have done whatever they can to control information going back months, including deleting 100 pages or so from that original thread and deleting comments and entire threads from their forum. 

is it that much of a stretch to think they would actively spread misinformation by doing something like this as a gambit?  not for me it's not.  I've been watching this for months and don't believe a word they say at this point, nor trust that their motives on any action are not on some level self-serving. 

[btmtb]

It had become quite clear that blackarrow were sitting on the value of the orders paid in BTC, seeming to a casual observer to possibly be playing currency investment game, hoping to cash out on a rise. People asked repeatedly whether these had even been declared as income/assets on your balance sheets only to have the question evaded. It seems very convenient that they've now been 'stolen'. I do hope we can get to the bottom of this, have you any information you can share as to why why you think they were stolen? I know it was mentioned in your main thread (before you deleted several 100 pages) that several people had contacted the HK Inland Revenue Department to ask them to investigate whether you had declared these, perhaps you have more details you could share about this 'theft' that will clear these things up?
 
Without wanting to lend credibility to this incredulous story, have you perhaps asked your team member who you claim stolen all your customer/victim contact information to XBtech (remembering xbtech say they bought it from you, and this has never been satisfactorily resolved)?

Regarding your proposal, I believe that better adoption and support of mutlisig would achieve a suitably equivalent improvement if used properly, and this has the benefit of already being partially supported/implemented and is far more adaptable moving forward, less limited to a specific use-case.

[MichelG]

Another trick from Black Arrow for not refunding their customers ! These psychotic monkeys are thieves, scammers, and incompetent ! Stay away from anything coming from them... Last but not least, their PSU are burning and exploding ...

This kind of firm must be ERASED from the BTC / crypto-currencies world ! They have done too much damages...

Regards!

[goozman96]

Anyone who has bitcoins tied up with black arrow, check to see if those coins are still sitting in the original wallet you sent them to, or if they've been 'stolen' like BA is trying to make it seem.

Also, just for fun, since this isn't a self-moderated thread:

Alexandru Ion Sovu is a Romanian scammer running a fraud of a business by the name of Black Arrow.
Find their personal info here:
http://www.kiwi.nz/blackarrow/
https://www.facebook.com/alex27a
Dukesbridge House, 23 Duke Street, Reading, Berkshire, RG1 4SA
cardreaderfactory.com
http://companycheck.co.uk/director/914928330
http://black-arrow-information-technology-shenzhen-co.imexbb.com
http://alexsovu.blogspot.com

[Waramp22]

If you have purchased any equipment from Black Arrow Software, here is how to file a complaint with the Hong Kong Consumer Council

The company is registered in Hong Kong, so the proper agency from what I have been able to find out so far is the Hong Kong Consumer Council.

They request some documents and need to establish that this is a Hong Kong registered company before they will agree to pick it up, therefore:

Send the annual report http://www.filedropper.com/ps30001577654901 along with the documents they have requested. Those documents are:

1. The invoice showing you paid
2 your bank or payment records showing the payment
3. any e-mail or support discussions you've had
4. The annual report referenced above.

Here's the link to file a complaint if you decide you want to do that.

https://www.consumer.org.hk/cc-complaint/index.php?lang=en

Also indicate that their TOS indicates Hong Kong law.

15.2 Applicable law and dispute resolution
16.2 1 This Agreement shall be interpreted and applied in accordance with the law of Hong Kong S.A.R. of PRC.


Black Arrow LTD
Room 1701, 17/F, Henan Building, No. 90-92
Jaffe Road
Wanchai, N/A
Hong Kong
PHONE: +852 8199 0849

Other forum users who are in on the scam.
Lexx2k
David105396
Bobsag3

[greenlion]

So, we would like to propose this feature to be added to Bitcoin protocol:

A "Time Lock" command for Bitcoin addresses.

Are you aware that Bitcoin addresses do not exist on the blockchain or in the protocol?

And that "addresses" are not spent, "outputs" are.

And that transactions don't have timestamps?

And that the timestamp on a block is unreliable as an indication of current real-world calendar time?

And that the change you are proposing would require so much modification to the way the protocol works that it would likely destroy the consensus system and the fungible nature of bitcoins?

Are you aware that 10% of the bitcoins in circulation are currently stolen?

Are we going to do anything about it?

One obvious first step is suing the hell out of you for stealing millions of dollars from your mining customers.

[Gleb Gamow]

So, we would like to propose this feature to be added to Bitcoin protocol:

A "Time Lock" command for Bitcoin addresses.

Are you aware that Bitcoin addresses do not exist on the blockchain or in the protocol?

And that "addresses" are not spent, "outputs" are.

And that transactions don't have timestamps?

And that the timestamp on a block is unreliable as an indication of current real-world calendar time?

And that the change you are proposing would require so much modification to the way the protocol works that it would likely destroy the consensus system and the fungible nature of bitcoins?

Are you aware that 10% of the bitcoins in circulation are currently stolen?

Are we going to do anything about it?

Yes we are Alex Sovu, by exposing your ass for stealing millions of dollars due to non-deliveries of your Black Arrow pieces of shit.

[bigasic]

So, we would like to propose this feature to be added to Bitcoin protocol:

A "Time Lock" command for Bitcoin addresses.

Are you aware that Bitcoin addresses do not exist on the blockchain or in the protocol?

And that "addresses" are not spent, "outputs" are.

And that transactions don't have timestamps?

And that the timestamp on a block is unreliable as an indication of current real-world calendar time?

And that the change you are proposing would require so much modification to the way the protocol works that it would likely destroy the consensus system and the fungible nature of bitcoins?

Are you aware that 10% of the bitcoins in circulation are currently stolen?

Are we going to do anything about it?

Yes we are Alex Sovu, by exposing your ass for stealing millions of dollars due to non-deliveries of your Black Arrow pieces of shit.

I was wondering when Gleb was going to show up!.. good job, keep at it..

[roshii]

Instead, why don't you propose a system where after you manufacture bitcoin mining hardware with customer preorder money, you deliver it to your customers in the advertised time period, with the advertised compensation plans, with the advertised quality.

+1

Cannot say that better!

I was wondering for some time if I was reading correctly?! BA talking about bitcoin protocol?!?
Nothing else better to do at the moment?!?!?!?  Un-fu****-believable...

[ElGrandJefe]

Instead, why don't you propose a system where after you manufacture bitcoin mining hardware with customer preorder money, you deliver it to your customers in the advertised time period, with the advertised compensation plans, with the advertised quality.

+1

Cannot say that better!

Was I was wondering for some time if I was reading correctly?! BA talking about bitcoin protocol?!?
Nothing else better to do at the moment?!?!?!?  Un-fu****-believable...

They're still looking for suckers investors to finance their 14nm SHA256 ASIC and scrypt ASIC chip development.

Oh yeah, and frantically searching for new excuses as to why they're still not shipping.

[Rawted]

One of my favorite threads in recent memory. Nothing like some good old fashioned community vigilantism!

[Waramp22]

[ElGrandJefe]

Quoted to boost page rankings:

Black Arrow Software - Bitcoin Miner Scam
SCAM: Black Arrow Software

[btmtb]

One of my favorite threads in recent memory. Nothing like some good old fashioned community vigilantism!

It would only be vigilantism if someone stolen them to avenge the victims of black arrows incompetence and negligence, I've not seen any convincing evidence that theft is actually the case yet. Although that would be better than the alternative.

[roshii]

It would only be vigilantism if someone stolen them to avenge the victims of black arrows incompetence and negligence, I've not seen any convincing evidence that theft is actually the case yet. Although that would be better than the alternative.

Even though time passes and does not comfort my feelings it do not feel stolen (yet) and still want to believe BA will offer proper compensation at some point in time.

I personally think BA does have a real crap supply chain, vendor management and customer service...
They have proven (more than once) not being able to maintain a proper/realistic production schedule.
They have proven not being able to get what they require from their vendors
They have proven not being able to offer what they stated to their customers

It looks like I (amateur miner/developer) would start tomorrow an bitcoin mining ASCI company a promise delivery within 6 month, with off course no experienced team nor established vendor relationship.

This would have been a (meant) scam, I assume we'd not hear about BA anymore with their founder enjoying a pile of dollars somewhere on a sunny island.... But we still hear and read about them (mainly not in a positive manner though).

To make it short, I think/assume:
1. BA realized about supply chain management early 2014 - too late
2. BA realized about vendor management mid 2014 - much too late
3. Consequently, BA faced reliability issue on their X3 unit putting even more pressure on their (nonexistent) supply chain management
4. Consequently again, BA faces customer anger for defect product and delayed delivery putting even more pressure on their (nonexistent) customer service

Since I still trust BA has good will, I think it is a wise decision to continue with new product development since only next gen units could now fairly compensate customers. Refunding/financial compensation would just kill the company in my opinion and vigilantism by stilling from them would only benefit to the theft (BA customer would probably never see a single satoshi of such a theft)

For the history, I have ordered two X1 units back in November '13 and received them functional (without LCD and WiFi) late July '14. Units are working perfectly since then.
Now required from BA a free "X1 14 nm" as compensation, which they said they'd investigate...

[notbatman]

It would only be vigilantism if someone stolen them to avenge the victims of black arrows incompetence and negligence, I've not seen any convincing evidence that theft is actually the case yet. Although that would be better than the alternative.

Even though time passes and does not comfort my feelings it do not feel stolen (yet) and still want to believe BA will offer proper compensation at some point in time.

I personally think BA does have a real crap supply chain, vendor management and customer service...
They have proven (more than once) not being able to maintain a proper/realistic production schedule.
They have proven not being able to get what they require from their vendors
They have proven not being able to offer what they stated to their customers

It looks like I (amateur miner/developer) would start tomorrow an bitcoin mining ASCI company a promise delivery within 6 month, with off course no experienced team nor established vendor relationship.

This would have been a (meant) scam, I assume we'd not hear about BA anymore with their founder enjoying a pile of dollars somewhere on a sunny island.... But we still hear and read about them (mainly not in a positive manner though).

To make it short, I think/assume:
1. BA realized about supply chain management early 2014 - too late
2. BA realized about vendor management mid 2014 - much too late
3. Consequently, BA faced reliability issue on their X3 unit putting even more pressure on their (nonexistent) supply chain management
4. Consequently again, BA faces customer anger for defect product and delayed delivery putting even more pressure on their (nonexistent) customer service

Since I still trust BA has good will, I think it is a wise decision to continue with new product development since only next gen units could now fairly compensate customers. Refunding/financial compensation would just kill the company in my opinion and vigilantism by stilling from them would only benefit to the theft (BA customer would probably never see a single satoshi of such a theft)

For the history, I have ordered two X1 units back in November '13 and received them functional (without LCD and WiFi) late July '14. Units are working perfectly since then.
Now required from BA a free "X1 14 nm" as compensation, which they said they'd investigate...

This BA pre-order has been scam from the beginning same as BFL and all the others. The guys who run these operations are career criminals.

The fact is that BA lied to get my money, never delivered any product and is not refunding me.

[HELP.org]

So, we would like to propose this feature to be added to Bitcoin protocol:

A "Time Lock" command for Bitcoin addresses.

Are you aware that Bitcoin addresses do not exist on the blockchain or in the protocol?

And that "addresses" are not spent, "outputs" are.

And that transactions don't have timestamps?

And that the timestamp on a block is unreliable as an indication of current real-world calendar time?

And that the change you are proposing would require so much modification to the way the protocol works that it would likely destroy the consensus system and the fungible nature of bitcoins?

The Bitcoin addresses are not in the blockchain directly but it is easy to calculate the addresses from Blockchain data so that seems to be a non-issue.  Also, I thought the timestamps on the blocks that contain confirmed transactions was a good estimate of the time.  I thought blocks won't propagate unless they are within a couple of hours of the average time of other blocks that were recently published.  I also thought this capability already exists as part of P2SH.  This sounds like a variation of the "dead man's switch."  I thought these types of transactions are possible today as long as you can a miner to mine that type of transaction.

[greenlion]

This thread is not a serious thread about any sort of protocol recommendation, frankly what they're describing is so misguided and ridiculous, it's not even "wrong".

The OP is a wire fraud criminal who fled Romania for the UK in the mid/early-2000's to avoid prosecution, and is currently running a scam with the Black Arrow Prospero line of pre-ordered miners to the tune of several million dollars of customer funds.

Black Arrow did not actually cash out any customer payments made upwards of a year ago until mysteriously finally moving them from the original payment addresses exactly when this thread was created, which indicates that this entire thread is merely a cover for embezzling the entirety of their customer's payments that were performed in bitcoin.

[roshii]

This thread is not a serious thread about any sort of protocol recommendation, frankly what they're describing is so misguided and ridiculous, it's not even "wrong".

The OP is a wire fraud criminal who fled Romania for the UK in the mid/early-2000's to avoid prosecution, and is currently running a scam with the Black Arrow Prospero line of pre-ordered miners to the tune of several million dollars of customer funds.

Black Arrow did not actually cash out any customer payments made upwards of a year ago until mysteriously finally moving them from the original payment addresses exactly when this thread was created, which indicates that this entire thread is merely a cover for embezzling the entirety of their customer's payments that were performed in bitcoin.

Well well... I was wondering for some times what action should I take... I now know and have no trust in BA left: I'll file a complaint with the Hong Kong Consumer Council.

Does anyone knows if "group complaint" can be made under HK law? Or does it have to be individual claims only?

[silversurfer1958]

Can't switch on the timelock feature as it would open up bitcoin to having to handle transactions that might not mature for a very long time.   

[Waramp22]

14nm Bitcoin ASIC

We are still heavily involved in the 14nm ASIC project.
We are happy to report that after bringing on board more talent we have exceeded our initial 0.3W/Ghash target by 4.3 times by employing all techniques possible in ASIC and algorithm design. Our current design efficiency is now 70mW/Ghash (0.07W/Ghash) which allows us to build a 1 Terrahash chip in a single die while using 70 Watts at chip level. This will allow development of a 20Thash machine while using 1.5kw.
We intend to make this chip available for sale only from stock (No pre-orders)

Here, let me correct some mistakes you made in your post.

28nm Bitcoin ASIC

We are still heavily involved in the 28nm ASIC preorder scam.
We are unhappy to report that after bringing on board more fictitious third part manufacturers we have exceeded our initial delivery date by 6 months or 4.3 times by employing all excuses possible in ASIC and bitcoin miner development. Our current design efficiency is now 0.49/GH/s (according to our computer model) which allows us to build a 1 Terrahash unit that may or may not burn your sleeping children to death. This will allow you to mine your own bitcoins for a monthly loss of just $174.
We intend to make this chip available for sale only from stock (No pre-orders) the same way you can still purchase a non-existent X-3 from our website that is displaying IN STOCK with a shipping date of May 15 2014

[work2heat]

doesnt the bitcoin script already support timelocked outputs?

[DannyHamilton]

doesnt the bitcoin script already support timelocked outputs?

Not that I know of.