Search content
Sort by
Showing 20 of 129 results by sebastian
ETFbitcoin:
It means you can more accurately trust messages as coming from bitcointalk.
Meaning, you don't need to be afraid of phishing, if SPF or DKIM comes through, you know the message is genuine.
It means you can more accurately trust messages as coming from bitcointalk.
Meaning, you don't need to be afraid of phishing, if SPF or DKIM comes through, you know the message is genuine.
⭐ Merited by DdmrDdmr (2)
I made this transaction:
662f7e90b1e3d6f55c06388c07b62e15c6ab672c936372b64e8748c22d3923fb (game purchase on indiegala)
And it had a really hard time getting into a block even tough paying like 0.0004 in fee. Sites listed it like miners didn't want this transaction.
Then I did this transaction:
f3cb81d3a01f03b4e3b473fd3d264d0661d31f9081ca8ec6c544fee08b4ef853 (purchase of 100€ Steam gift card on bitrefill)
and this time, even when paying LESS in fee - 0.00032649 - it got pretty quick into a block and some sites listed it as a preferable transaction for miners.
What causes this?
662f7e90b1e3d6f55c06388c07b62e15c6ab672c936372b64e8748c22d3923fb (game purchase on indiegala)
And it had a really hard time getting into a block even tough paying like 0.0004 in fee. Sites listed it like miners didn't want this transaction.
Then I did this transaction:
f3cb81d3a01f03b4e3b473fd3d264d0661d31f9081ca8ec6c544fee08b4ef853 (purchase of 100€ Steam gift card on bitrefill)
and this time, even when paying LESS in fee - 0.00032649 - it got pretty quick into a block and some sites listed it as a preferable transaction for miners.
What causes this?
Re: Please ban this IP: 43.224.109.33 (IP is hacking bitcointalk accounts)
the .msg file is a exact Verbatim copy of the email I received from the BitCoinTalk software alerting me about the changed password.
Many antiviruses block .msg due to it can carry viruses, but this file is as safe to open as any email from BitCoinTalk.org
You need Outlook to open .msg
Many antiviruses block .msg due to it can carry viruses, but this file is as safe to open as any email from BitCoinTalk.org
You need Outlook to open .msg
Please ban this IP: 43.224.109.33 (IP is hacking bitcointalk accounts)
Apparently this IP is going around and hacking BitCoinTalk accounts by bruteforcing/hacking/guessing the password:
43.224.109.33
Have got some weird Ubex advertisment everytime I log in now...
Here is an copy of the email:
https://fuskbugg.se/I0p279f9b8/Password_changed.msg
43.224.109.33
Have got some weird Ubex advertisment everytime I log in now...
Here is an copy of the email:
https://fuskbugg.se/I0p279f9b8/Password_changed.msg
>>Fees will always be based on an open market.
>>Txfee isn't defined by the network.
What I have understand, is that txfee is something that is defined in bitcoin-core client (1000 satoshi per kB), but clients can choose a lower or higher txfee. But it isn't defined by network.
My idea is thus to change this definition in bitcoin-core to be based on difficulty instead. (new clients may then follow)
Then miners will be forced to accept transactions using these new fee's as theres no other transactions to choose from.
>>The target of a block is very heavily dependent on luck
Yes I know.
>>What do you mean by new and old blocks?
I meant with "old block" I mean mining blocks based on tx's that are from Before a specific difficulty change, and "new block" with mining blocks based on tx's that are after a specific difficulty change.
Since the blocks Before a difficulty rise, will have higher fee's, it will be more favorable for miners to then choose to mine blocks that are based on old transactions, while if theres a difficulty drop, then it will be more favorable to mine "new" transactions (thus becoming a "new block")
I know that im using the "wrong terminology" here but its easier to explain that way.
>>Not really, though it is unreasonable. There are more factors affecting the price of Bitcoin than that.
Are you really sure? Since the txfee is basically pinned to the size of transaction, it means it won't follow the market when value of bitcoin rises (compared to fiat). That causes the market to saturate when the txfee becomes so high so its unfavorable to invest in bitcoin due to the "spread" caused by the txfee. When market is fully saturated, it causes the value to drop because nobody is buying and nobody is selling due to the txfee's.
"Value" of something (Money, goods etc) is just the definition of the relation between demand and supply. If demand is low and supply is high, the thing is worthless, if demand is high and supply is low, the value increases.
>>Fees are more than just a tool to prevent spam, blockchain space is a very scarce resource
I know that block space are a very scarce resource, but still, if the requested txfee (that the client request per default) did follow the market price, I don't Think miners would have anything against it, because they would still get as much Money (in fiat) in transaction fee's.
>>Txfee isn't defined by the network.
What I have understand, is that txfee is something that is defined in bitcoin-core client (1000 satoshi per kB), but clients can choose a lower or higher txfee. But it isn't defined by network.
My idea is thus to change this definition in bitcoin-core to be based on difficulty instead. (new clients may then follow)
Then miners will be forced to accept transactions using these new fee's as theres no other transactions to choose from.
>>The target of a block is very heavily dependent on luck
Yes I know.
>>What do you mean by new and old blocks?
I meant with "old block" I mean mining blocks based on tx's that are from Before a specific difficulty change, and "new block" with mining blocks based on tx's that are after a specific difficulty change.
Since the blocks Before a difficulty rise, will have higher fee's, it will be more favorable for miners to then choose to mine blocks that are based on old transactions, while if theres a difficulty drop, then it will be more favorable to mine "new" transactions (thus becoming a "new block")
I know that im using the "wrong terminology" here but its easier to explain that way.
>>Not really, though it is unreasonable. There are more factors affecting the price of Bitcoin than that.
Are you really sure? Since the txfee is basically pinned to the size of transaction, it means it won't follow the market when value of bitcoin rises (compared to fiat). That causes the market to saturate when the txfee becomes so high so its unfavorable to invest in bitcoin due to the "spread" caused by the txfee. When market is fully saturated, it causes the value to drop because nobody is buying and nobody is selling due to the txfee's.
"Value" of something (Money, goods etc) is just the definition of the relation between demand and supply. If demand is low and supply is high, the thing is worthless, if demand is high and supply is low, the value increases.
>>Fees are more than just a tool to prevent spam, blockchain space is a very scarce resource
I know that block space are a very scarce resource, but still, if the requested txfee (that the client request per default) did follow the market price, I don't Think miners would have anything against it, because they would still get as much Money (in fiat) in transaction fee's.
As you might know, the surge and drop of bitcoin in the latest Days, and the volatility, is mainly because the txfee. Its just not resonable to pay like 20 USD to send a bitcoin transaction just because the value is so high.
txfee is a tool mostly to prevent malicious users from inserting garbage in the blockchain, thus you could have a txfee that stays roughtly constant (in value) over time, regardless of the value of the bitcoin.
Since the value is loosely pinned to the difficulty (higher difficulty = higher value), what about a txfee that is based on the inverse of difficulty?
Basically, a required txfee that is based on the inverse of the highest difficulty observed the latest 6 blocks, and clients will use a txfee that is calculated based on the inverse of the lowest of these 6 blocks.
This will gurantee that the txfee used in a transaction is always higher than required, and that the txfee follows the value (txfee drops when value become higher).
This also gives a opportunity to mine old blocks when value are rising (as old txfee's are more valueable as they are higher), and mine new blocks when value is dropping (as these have higher txfee)
txfee is a tool mostly to prevent malicious users from inserting garbage in the blockchain, thus you could have a txfee that stays roughtly constant (in value) over time, regardless of the value of the bitcoin.
Since the value is loosely pinned to the difficulty (higher difficulty = higher value), what about a txfee that is based on the inverse of difficulty?
Basically, a required txfee that is based on the inverse of the highest difficulty observed the latest 6 blocks, and clients will use a txfee that is calculated based on the inverse of the lowest of these 6 blocks.
This will gurantee that the txfee used in a transaction is always higher than required, and that the txfee follows the value (txfee drops when value become higher).
This also gives a opportunity to mine old blocks when value are rising (as old txfee's are more valueable as they are higher), and mine new blocks when value is dropping (as these have higher txfee)
The thing is that the PM says "To: litecoinstake" on the information, not in the body of the PM. So somewhere the software has done wrong, either in displaying the correct receiver, or in delivering the message.
What can be done to the ransomware problem?
I think Bitcoin is the seed that grown into the ransomware problem. What can be done to protect users?
My tought was some sort of list of "dishonest" adresses, like what have been discussed with stolen money, but that would not work in this case due to the possibility to create one adress per victim, as opposed to bitcoin theft where there is a few adresses involved where the money was stolen from (the victim).
Any ideas how bitcoin could be adapted to make it "toxic" to ransomware authors, while not burning legit users?
My second tought was some "Vote To Refund" scheme, applying to any transaction, but the problem would be that people could spread false screenshots of ransomware just to get free services/products.
Go brainstorm about ideas on how to prevent ransomware on bitcoin's end.
I think Bitcoin is the seed that grown into the ransomware problem. What can be done to protect users?
My tought was some sort of list of "dishonest" adresses, like what have been discussed with stolen money, but that would not work in this case due to the possibility to create one adress per victim, as opposed to bitcoin theft where there is a few adresses involved where the money was stolen from (the victim).
Any ideas how bitcoin could be adapted to make it "toxic" to ransomware authors, while not burning legit users?
My second tought was some "Vote To Refund" scheme, applying to any transaction, but the problem would be that people could spread false screenshots of ransomware just to get free services/products.
Go brainstorm about ideas on how to prevent ransomware on bitcoin's end.
Re: Is it possible to generate public keys using public info and other public info?
On this page:
https://gobittest.appspot.com/VanityMult
What does "modified base Point" mean? Anyone that have the exact mathematics involved?
https://gobittest.appspot.com/VanityMult
What does "modified base Point" mean? Anyone that have the exact mathematics involved?
Is it possible to generate public keys using public info and other public info?
⭐ Merited by ABCbits (1)
Imagine this:
I have a EC keypar Ks and Kp. (secret and public).
Now I have a system with access card for customers. I want them to be able to refill the cards. Each card contains a number, lets say "1013853254", which is denoted "n".
By publishing Kp, a customer should be able to combine Kp and n, in such a way he gains a public key Kp(1013853254).
If a customer sends Money to the associated adress of this public key Kp(1013853254), then the funds
should be spendable by combining Ks with n in such a way I gain Ks(1013853254).
How is this possible with lets say EC primitives?
I have a EC keypar Ks and Kp. (secret and public).
Now I have a system with access card for customers. I want them to be able to refill the cards. Each card contains a number, lets say "1013853254", which is denoted "n".
By publishing Kp, a customer should be able to combine Kp and n, in such a way he gains a public key Kp(1013853254).
If a customer sends Money to the associated adress of this public key Kp(1013853254), then the funds
should be spendable by combining Ks with n in such a way I gain Ks(1013853254).
How is this possible with lets say EC primitives?
I read about this XT addition, and wonder: Is it really a good idea?
A normal Ethernet frame do have a MTU of 1526, and with headers and other overhead, the resulting frame will be roughtly 1500 bytes large. Subtracting the IP header from this, which is normally 20 bytes, but lets be harsh and overdo a Little bit, and substract 30 bytes. Then we have 1470 bytes left.
Now lets add 1 MB of transactions: 446 bytes.
Also add the block header and block hashes and signatures, and you will scrape off a bit of that too.
Imagine then sandwiching this in a VPN or anything, and you understand why XT is a bad idea because a block will no longer fit into a single packet, and the packet needs to be fragmented.
Wouldn't it better to hardfork the chain to have a faster bliock distribution rate, lets say instead of 10 minutes you hash a block each minute. Then you get the same increased transaction capacity, but with still each block fitting into a single packet. I dont Think there is a risk of softfork due to a netsplit because I have never Heard about a link that takes more than 1 minute to distribute a packet.
A normal Ethernet frame do have a MTU of 1526, and with headers and other overhead, the resulting frame will be roughtly 1500 bytes large. Subtracting the IP header from this, which is normally 20 bytes, but lets be harsh and overdo a Little bit, and substract 30 bytes. Then we have 1470 bytes left.
Now lets add 1 MB of transactions: 446 bytes.
Also add the block header and block hashes and signatures, and you will scrape off a bit of that too.
Imagine then sandwiching this in a VPN or anything, and you understand why XT is a bad idea because a block will no longer fit into a single packet, and the packet needs to be fragmented.
Wouldn't it better to hardfork the chain to have a faster bliock distribution rate, lets say instead of 10 minutes you hash a block each minute. Then you get the same increased transaction capacity, but with still each block fitting into a single packet. I dont Think there is a risk of softfork due to a netsplit because I have never Heard about a link that takes more than 1 minute to distribute a packet.
Re: Received email from account NOT associated with bitcointalk
Could be suspicious.
It comes from:
198.251.81.170
which have a reverse of:
node-198-251-81-170.reverse.x4b.me
However, noticed that bitcointalk.org does resove to 198.251.81.170 too.
This could mean that the attacker still have Control of the server (?)
Perhaps he installed a backdoor... And he want everyone to change passwords, so they Think they're safe now, but he simply capture the new passwords.
It comes from:
198.251.81.170
which have a reverse of:
node-198-251-81-170.reverse.x4b.me
However, noticed that bitcointalk.org does resove to 198.251.81.170 too.
This could mean that the attacker still have Control of the server (?)
Perhaps he installed a backdoor... And he want everyone to change passwords, so they Think they're safe now, but he simply capture the new passwords.
Is this mail legit?
It has no DKIM signature, a invalid PGP signature and a valid SPF signature.
The host I received it from, does not seem to be asscoiated with bitcointalk either:
C:\Users\Sebastian>nslookup -type=PTR 170.81.251.198.in-addr.arpa.
Server: fw.sebbe.eu
Address: 2001:470:28:1c:1::1
Icke-auktoritärt svar:
170.81.251.198.in-addr.arpa name = node-198-251-81-170.reverse.x4b.me
C:\Users\Sebastian>
Checking the SPF:
C:\Users\Sebastian>nslookup -type=TXT bitcointalk.org.
Server: fw.sebbe.eu
Address: 2001:470:28:1c:1::1
Icke-auktoritärt svar:
bitcointalk.org text =
"v=spf1 mx a include:amazonses.com -all"
C:\Users\Sebastian>
WEEEEEEEEEEW..... Allowing all hosts in the amazon Simple Email Services seems to be a Little bit overly permissible. I don't know if they have any safeguards against fraudulent mail...
Return-Path: <noreply@bitcointalk.org>
X-Original-To: @sebbe.eu
Delivered-To: @sebbe.eu
Received: from server-desktop (localhost [127.0.0.1])
by dns2.sebbe.eu (Postfix) with ESMTP id 12FFF4C0291
for @sebbe.eu; Mon, 25 May 2015 22:23:27 +0200 (CEST)
Subject: Bitcoin Forum: Password change required [Invalid signature]
X-AntiPhishing-IP: [BEGIN][198.251.81.170][END]
Authentication-Results: unknown-host; dkim=none reason="no signature";
dkim-adsp=none (unprotected policy); dkim-atps=neutral
Received: from bitcointalk.org (node-198-251-81-170.reverse.x4b.me [198.251.81.170])
by dns1.sebbe.eu (Postfix) with ESMTP id F0F814C0291
for @sebbe.eu; Mon, 25 May 2015 22:23:25 +0200 (CEST)
Received: by bitcointalk.org (Postfix, from userid 0)
id AE9AACF1439; Mon, 25 May 2015 20:19:46 +0000 (GMT)
Date: Mon, 25 May 2015 20:19:46 +0000
From: noreply@bitcointalk.org
To: @sebbe.eu
Message-ID: <556383e2.+sWUE0Y0lRkm5AKP%noreply@bitcointalk.org>
User-Agent: Heirloom mailx 12.5 7/5/10
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Djigzo-Info-PGP-Encoding: PGP/INLINE
X-Djigzo-Info-PGP-Signer-KeyID: C6555693DAB591E7
X-Djigzo-Info-PGP-Signature-Valid: False
X-Djigzo-Info-PGP-Signature-Failure: Signer's key with key ID C6555693DAB591E7
not found.
X-SPF-Signature: pass (bitcointalk.org: 198.251.81.170 is authorized to use 'noreply@bitcointalk.org' in 'mfrom' identity (mechanism 'a' matched)) receiver=server-desktop; identity=mailfrom; envelope-from="noreply@bitcointalk.org"; client-ip=198.251.81.170
You are receiving this message because your email address is associated
with an account on bitcointalk.org. I regret to have to inform you that
some information about your account was obtained by an attacker who
successfully compromised the bitcointalk.org server. The following
information about your account was likely leaked:
- Email address
- Password hash
- Last-used IP address and registration IP address
- Secret question and a basic (not brute-force-resistant) hash of your
secret answer
- Various settings
You should immediately change your forum password and delete or change
your secret question. To do this, log into the forum, click "profile",
and then go to "account related settings".
If you used the same password on bitcointalk.org as on other sites, then
you should also immediately change your password on those other sites.
Also, if you had a secret question set, then you should assume that the
attacker now knows the answer to your secret question.
Your password was salted and hashed using sha256crypt with 7500 rounds.
This will slow down anyone trying to recover your password, but it will
not completely prevent it unless your password was extremely strong.
While nothing can ever be ruled out in these sorts of situations, I do
not believe that the attacker was able to collect any forum personal
messages.
I apologize for the inconvenience and for any trouble that this may cause.
It has no DKIM signature, a invalid PGP signature and a valid SPF signature.
The host I received it from, does not seem to be asscoiated with bitcointalk either:
C:\Users\Sebastian>nslookup -type=PTR 170.81.251.198.in-addr.arpa.
Server: fw.sebbe.eu
Address: 2001:470:28:1c:1::1
Icke-auktoritärt svar:
170.81.251.198.in-addr.arpa name = node-198-251-81-170.reverse.x4b.me
C:\Users\Sebastian>
Checking the SPF:
C:\Users\Sebastian>nslookup -type=TXT bitcointalk.org.
Server: fw.sebbe.eu
Address: 2001:470:28:1c:1::1
Icke-auktoritärt svar:
bitcointalk.org text =
"v=spf1 mx a include:amazonses.com -all"
C:\Users\Sebastian>
WEEEEEEEEEEW..... Allowing all hosts in the amazon Simple Email Services seems to be a Little bit overly permissible. I don't know if they have any safeguards against fraudulent mail...
Return-Path: <noreply@bitcointalk.org>
X-Original-To: @sebbe.eu
Delivered-To: @sebbe.eu
Received: from server-desktop (localhost [127.0.0.1])
by dns2.sebbe.eu (Postfix) with ESMTP id 12FFF4C0291
for @sebbe.eu; Mon, 25 May 2015 22:23:27 +0200 (CEST)
Subject: Bitcoin Forum: Password change required [Invalid signature]
X-AntiPhishing-IP: [BEGIN][198.251.81.170][END]
Authentication-Results: unknown-host; dkim=none reason="no signature";
dkim-adsp=none (unprotected policy); dkim-atps=neutral
Received: from bitcointalk.org (node-198-251-81-170.reverse.x4b.me [198.251.81.170])
by dns1.sebbe.eu (Postfix) with ESMTP id F0F814C0291
for @sebbe.eu; Mon, 25 May 2015 22:23:25 +0200 (CEST)
Received: by bitcointalk.org (Postfix, from userid 0)
id AE9AACF1439; Mon, 25 May 2015 20:19:46 +0000 (GMT)
Date: Mon, 25 May 2015 20:19:46 +0000
From: noreply@bitcointalk.org
To: @sebbe.eu
Message-ID: <556383e2.+sWUE0Y0lRkm5AKP%noreply@bitcointalk.org>
User-Agent: Heirloom mailx 12.5 7/5/10
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Djigzo-Info-PGP-Encoding: PGP/INLINE
X-Djigzo-Info-PGP-Signer-KeyID: C6555693DAB591E7
X-Djigzo-Info-PGP-Signature-Valid: False
X-Djigzo-Info-PGP-Signature-Failure: Signer's key with key ID C6555693DAB591E7
not found.
X-SPF-Signature: pass (bitcointalk.org: 198.251.81.170 is authorized to use 'noreply@bitcointalk.org' in 'mfrom' identity (mechanism 'a' matched)) receiver=server-desktop; identity=mailfrom; envelope-from="noreply@bitcointalk.org"; client-ip=198.251.81.170
You are receiving this message because your email address is associated
with an account on bitcointalk.org. I regret to have to inform you that
some information about your account was obtained by an attacker who
successfully compromised the bitcointalk.org server. The following
information about your account was likely leaked:
- Email address
- Password hash
- Last-used IP address and registration IP address
- Secret question and a basic (not brute-force-resistant) hash of your
secret answer
- Various settings
You should immediately change your forum password and delete or change
your secret question. To do this, log into the forum, click "profile",
and then go to "account related settings".
If you used the same password on bitcointalk.org as on other sites, then
you should also immediately change your password on those other sites.
Also, if you had a secret question set, then you should assume that the
attacker now knows the answer to your secret question.
Your password was salted and hashed using sha256crypt with 7500 rounds.
This will slow down anyone trying to recover your password, but it will
not completely prevent it unless your password was extremely strong.
While nothing can ever be ruled out in these sorts of situations, I do
not believe that the attacker was able to collect any forum personal
messages.
I apologize for the inconvenience and for any trouble that this may cause.
I looked at the U2F specification, and found out that its using secp256r1 EC as their inner cryptography.
I dont know if this is compatible for bitcoin, but I actually got a idea:
Since U2F tokens work in Three different ways:
1: Either storing a EC private key onboard, exporting a public key, and a key identifier.
2: Or, creating a EC private key onboard, wrapping it with a device-specific key, and exports the public key, and encrypted private key.
3: Or, using a nonce to create a EC private key onboard, using a MAC with a device-specific key, and then exporting the public key and the nonce.
After this, authentication is done by signing a challenge along with other parameters, with the EC private key.
Even if theres lots of "useless" parameters inside the signed response, I got a idea, where you carefully create a transaction such as you can extract a "challenge" out of this, send it to the U2F token, and what you get back, is a completely signed transaction that you can transmit to the blockchain.
This MIGHT include generating special adresses using "Vanitygen", (that ends in like touch=1 or such) or actually wasting small amounts of Money (that is destroyed) to send these coins to invalid adresses, but so it match the response format of a U2F token.
To register U2F keys to the bitcoin network, it could be contructed by sending the data returned by the U2F token, in a transaction to be embedded in the blockchain. This would also waste Money, but by sending a minimum transaction, it would only be a couple of cents. A U2F-bitcoin-client then only needs to download the blockchain to be able to recover the wallet.
Since U2F keys are effectively Anonymous, you would need a way to identify which wallet is "yours".
This could be done by simply you provide a public "username" string, that you use along with the U2F key to load your wallet. The wallet would simply be embedded in the blockchain.
Abuse (for example spamming U2F registrations with identical usernames as other users, which means a U2F-bitcoin client has to try them all) is prevented simply because you have to waste Money to register a U2F key. Also by making U2F registrations indistingushable from normal transactions (for example by hashing the username), it would be hard for abusers to find these transactions.
This would mean you could get secure key storage for bitcoin for just about 20$.
If anyone would want to experiment with U2F tokens and bitcoin, here is a token:
https://store.yubico.com/store/catalog/product_info.php?products_id=112&osCsid=itvjqcbekqvd6gvkao9i91gns2
Any toughts?
I dont know if this is compatible for bitcoin, but I actually got a idea:
Since U2F tokens work in Three different ways:
1: Either storing a EC private key onboard, exporting a public key, and a key identifier.
2: Or, creating a EC private key onboard, wrapping it with a device-specific key, and exports the public key, and encrypted private key.
3: Or, using a nonce to create a EC private key onboard, using a MAC with a device-specific key, and then exporting the public key and the nonce.
After this, authentication is done by signing a challenge along with other parameters, with the EC private key.
Even if theres lots of "useless" parameters inside the signed response, I got a idea, where you carefully create a transaction such as you can extract a "challenge" out of this, send it to the U2F token, and what you get back, is a completely signed transaction that you can transmit to the blockchain.
This MIGHT include generating special adresses using "Vanitygen", (that ends in like touch=1 or such) or actually wasting small amounts of Money (that is destroyed) to send these coins to invalid adresses, but so it match the response format of a U2F token.
To register U2F keys to the bitcoin network, it could be contructed by sending the data returned by the U2F token, in a transaction to be embedded in the blockchain. This would also waste Money, but by sending a minimum transaction, it would only be a couple of cents. A U2F-bitcoin-client then only needs to download the blockchain to be able to recover the wallet.
Since U2F keys are effectively Anonymous, you would need a way to identify which wallet is "yours".
This could be done by simply you provide a public "username" string, that you use along with the U2F key to load your wallet. The wallet would simply be embedded in the blockchain.
Abuse (for example spamming U2F registrations with identical usernames as other users, which means a U2F-bitcoin client has to try them all) is prevented simply because you have to waste Money to register a U2F key. Also by making U2F registrations indistingushable from normal transactions (for example by hashing the username), it would be hard for abusers to find these transactions.
This would mean you could get secure key storage for bitcoin for just about 20$.
If anyone would want to experiment with U2F tokens and bitcoin, here is a token:
https://store.yubico.com/store/catalog/product_info.php?products_id=112&osCsid=itvjqcbekqvd6gvkao9i91gns2
Any toughts?
Re: Bitcoin Core (Bitcoin-Qt) 0.9.1 released - update required
Can really the CLIENT KEYs be compromised by this bug?
What I have understand, its a bug in the OpenSSL Implementation of Heartbeat protocol of TLS 1.2, causing OpenSSL to leak contents of RAM in the server.
This means, the attack vector would be limited to:
impersonating a server and replacing a bitcoin adress in the payment protocol, by stealing the SERVER KEYs.
Thus any client-side wallets should be safe since those private keys are never transmitted or kept by the server? (except for webshops and online services running a server-side bitcoin client relying on a vulnerable OpenSSL)
The bitcoin core protocol (port 8333) is not using any form of SSL at all what I know?
If what the Bitcoin devs say is correct (that client keys can be compromised), would also mean that any website using SSL can steal RAM contents of client computers, which would mean my site can get my visitor's bank details, and that would make the security hole way more critical than it is today.
What I have understand, its a bug in the OpenSSL Implementation of Heartbeat protocol of TLS 1.2, causing OpenSSL to leak contents of RAM in the server.
This means, the attack vector would be limited to:
impersonating a server and replacing a bitcoin adress in the payment protocol, by stealing the SERVER KEYs.
Thus any client-side wallets should be safe since those private keys are never transmitted or kept by the server? (except for webshops and online services running a server-side bitcoin client relying on a vulnerable OpenSSL)
The bitcoin core protocol (port 8333) is not using any form of SSL at all what I know?
If what the Bitcoin devs say is correct (that client keys can be compromised), would also mean that any website using SSL can steal RAM contents of client computers, which would mean my site can get my visitor's bank details, and that would make the security hole way more critical than it is today.