|
Testnet is for testing bitcoin software development, so you won't find web services that use testnet, unless they are doing testing themselves.
|
|
|
|
Therefore, best practice is to not reuse addresses.
Can we tease apart "one time secret reuse vulnerability" with "bad random numbers"? Question 1: does the reuse of a bitcoin address make the blatant mistake of reusing the k value from the paper I linked -or- is this only a problem which arises if the random number generator is poor? Question 2: will you be in miami this weekend? Non-reuse is a preventative measure against generic unknown problems. The Android random fault was only exploitable when multiple sends allowed mathematical deduction of the private key, and so not reusing addresses after they have spent would have protected users. I won't be going anywhere unless you are buying the airfare and sunscreen. Full-strength ECDSA has a $1 billion bounty on it, in every unspent generate transaction that IS a public key. |
|
|
|
Different hosts may have random responsiveness lags in addition to different bandwidth. Here's a study showing that shared hosts may have random multi-second latency. http://www.wpsitecare.com/performance-of-7-top-wordpress-hosting-companies-compared/ IP doesn't guarantee delivery, TCP may have to retry until it gets data. However, the bitcointalk image proxy also will have resources consumed by waiting for multiple unresponsive hosts. One post in the "wall observer" can have 100 image hits in a few minutes. |
|
|
|
deepceleron, have you read this paper https://eprint.iacr.org/2013/734.pdfCan you help me understand the re-use of address problem and whether it applies to the "per message secret" denoted k in the above paper.. introduced in section 2.4 To avoid using the same per message secret, what are your recommendations for best practices? Your expertise would be appreciated, as the foundations educ. committee loosely suggested that I research this topic for publications for businesses. I do not wish to continue to bump this thread which has an explosive title. I want to discuss secp256k1 maturely somewhere, without frightening muggles. mods/heores/gmaxwell feel free to tell me where you'd prefer I go...The paper I posted refers to ways of covertly weakening elliptic curve cryptography by injecting and exploiting faults in use, such as causing off-curve points to be used. This is not a large concern with Bitcoin due to it's address hash protection, but exposes the ways that it can be subverted, such as by a corrupted address generator or a backdoored random number generator. It reminds us that we must not blindly trust the address generation of Bitcoin clients or other tools like vanity generators, and to be vigilant about the random number generator used when signing, spending money. The public key is not exposed until money is spent from a Bitcoin address. After that, there is only one layer of protection, ECDSA, and as we saw with the bad Android implementation where the random nonce is poorly implemented, address reuse may allow others to discover the private key. Therefore, best practice is to not reuse addresses. |
|
|
|
Welp, I have plugged away like a busy little beaver, and made a proper dice -> paper wallet app.
>>>If I'm not mistaken, your program still adds randomness. I know, even false randomness won't 'destroy' true randomness, but could one opt out of this feature? If your dice roll information is truly random, I can't make it less random by scrambling it. The only drawback is that you can't independently verify that the exe isn't doing something nefarious unless you have source code. You can simply comment out the four scrambling functions near the end of the source (surrounding rolls_to_hex64), and you will get the base6 decoding of your dice as output mod 2 256 (hindsight: could have been mod(N-1) + 1). I would recommend this address generator instead, if you want to type dice into it you can; just the time you take between entering dice rolls will be enough entropy: https://bitcointalk.org/index.php?topic=361092.0 |
|
|
|
It should be noted that this "app" requires the bitcoincharts server to do the heavy lifting of rendering the chart - it simply loads the web site's remote image. You can bookmark the desired image yourself in your mobile browser if you can't run (or don't want to or can't trust) the app. aka, the chart right now when you loaded this page:  |
|
|
|
It's been given to now. Lets see it work...  |
|
|
|
|
I have sent doolittle some testnet funny money.
Here are some addresses I will load up with 1 testBTC Please take in order and post which # you claim. Don't be a dick and spend them all, they have no value.
2
Address: mmmmmmSjiNZaTkFqc5aQgkog5t5bCCUKkQ
Privkey: 923zkXJ6bXyz9fHs9bKjxmqv88jfMB5tgZ8K2GsKwhhfVshzyKJ
3
Address: mmmmmmdWEKKJ8CXHMH3aW3kMxZRmuv4UWk
Privkey: 92sfVwG8bit5s1hkGjvL4foNeMtsMsJLKqKmFTM47kkqZFRt9Gi
4
Address: mmmmmmuBHMDs5C9PYMwgXHeCkqwdncVKRD
Privkey: 939mm87M2EVUojJPxaR3zFvbvtojk7ExHjMwmzm45biX9b19pWH
5
Address: mmmmmmXtEakmMM9nTHckRaBsdkoNPyVpDe
Privkey: 91oPjc9HRShU1ULNwphWseWEqr8YyvPzn8ghmyacwxedNQn6YaG
6
Address: mmmmmmgeestwwdDFmWzRRwXUUxGa5j5jRX
Privkey: 92qRt3GRk2X5KKbJwSsN7DseSvBhjuwdSPFjWzMLHdWfY9WpsrD
7
Address: mmmmmmdqS8mJ2fZHAXBZmPkWeq4NwuAXsb
Privkey: 93PiPHfEXiTtr1HV376dZ9Nmxy2UYTbsywtgVSAQnP88chxxbEZ
8
Address: mmmmmmdWg5bHUoqAu42pqYGhQ6pGFF4qh6
Privkey: 92gJPzpoYRwQLnD336aJB74SkzByT4tjoE2n3uAYSgvoR84njRo
9
Address: mmmmmmdYqCfSBWtc5cKF8y2LUmM3GTzabx
Privkey: 92RBL19SFNfhiXiJGmhiWe2uW4LF8nS7U1ybNbHEQzR3pC8gUfj
10
Address: mmmmmmQoSBynAntEBRs3pDEqBR8GYSpBpX
Privkey: 936Zv8dJaYwhbWXrXsEiPE18y2LW4CbMfDvEBMj3JLkbcXtfwBY
11
Address: mmmmmmLQfhavhoR5e5Hc5bx74ceDA2HAZ8
Privkey: 936KCYMqTg7ZHZUoQcSHhXqfbDqpskzrVGLY65KEMw8eT3DNWSK
12
Address: mmmmmmgHHdTdA8kNdSK3tpz8zPY228f9fX
Privkey: 93ChxdbtFaPGZkwyNYDDWiG7Bx1ZM8ftoedbHXWX3dep2XF6LvZ
13
Address: mmmmmmKAiEb7L8V5BD3ifvRm5BxGHWa69X
Privkey: 92d86AmaYj5QaVLSuaRFFGWNmgXJLMv2Mk87ZMVvi4v48i89Csu
14
Address: mmmmmmE4meyQdTMjzvToZjLse4o9ALUhu8
Privkey: 92ydJB92mQbgGh7zSQ6YEVeCH5DePgSHs9xJ44nBiJeAJ3Kwk76
15
Address: mmmmmmFxo9MprBovXJBFNdLcZrfWgPcZTz
Privkey: 935zr24Y8TDFm8e9Jkwfcfrgf6Ex3aUwL5AdKG6vsYQnHJPSfG1
16
Address: mmmmmmJD8gJirbnQEJM9bkYv11DGGYxmeZ
Privkey: 92127kNxbqgjDfBxWD1VRsS9jEz8LHMY7ZKiMPZR5zm7vdzAEfU
17
Address: mmmmmmd7jr2dipHHG34NFNjySxrLW8PSMH
Privkey: 92qRGJAwQz8nooKCEXZJixoGSRrnVt95cNxQpp1VjFhPcWSH2mq
18
Address: mmmmmmEUmWXWkjqibauHTRWgN1d2EUsghk
Privkey: 92teD6b5Fyg9KAQveDojSzHAVaCL69zxvrkakwgyBdeAGzMo5Fz
19
Address: mmmmmm2uuZDbFBAy8VnF8zM99WvbyAW7RN
Privkey: 93TDvzmfPFzULrHoE1G1h8mAdmsjQoAcVyCZzRgoRueAbpFJyq9
20
Address: mmmmmm5Lk4DkoRCYbp7YZ8xJUWBG53WPkN
Privkey: 926TWQUaqCiTkbWWzheYkMSb38inDtYP87wQqXrExVEGmqgDKoz
21
Address: mmmmmm383PV2ydiaZwaTqxqqTkLsPkrkgf
Privkey: 91z8pAAK2LcXvVyFoAzMWLuTp3V5Q6XBA4gZtnDtxwUmfNqZ3ro
22
Address: mmmmmmFg7mhEEw6Hvfyj7yktpG8HkDSbsM
Privkey: 93GdfXy4xQ5hvqr9Py4pUYDAdTQSfi67BQbwFTCArZPdz9qk6NF
23
Address: mmmmmmpNNB2vmyCkdJqdRVfmd563ZTEcfM
Privkey: 92GagauzPVXx85gDiJSco4WWtEhmYAJo1ogjYTEb1W6oWDE7EWu
24
Address: mmmmmmF1ud5Cosejg7YwMmaKgRco9gBCct
Privkey: 93PxhT1tvSEyo9ESBsycG9HR3VJRNhpbrStzJ4sJHik6fJSMxKm
|
|
|
|
First post out of noob jail - wants off-site Paypal exchange with obviously brand new anony-email. The only thing more suspicious would be the PayPal sender falsely claiming that their payment couldn't be charged back. Oh, wait, check! https://bitcointalk.org/index.php?topic=164254.0 |
|
|
|
Ben Milne (the Dwolla CEO) never liked Bitcoin because he wasn't in charge of it. End of story.
... didn't like Bitcoin because it exposed how little these midwest college students knew about banking, and then Dwolla defrauded exchanges and users when they were charged back by banks and therefore got sued. |
|
|
|
|
I see from the original post you thinking that you should backup when you receive payment, which is incorrect. The ownership of Bitcoins is recorded on the blockchain, not in your wallet. You only need your wallet to spend the bitcoins you own.
Every time you create a new Bitcoin address to receive bitcoins, and almost every time you send bitcoins, a new address is taken from the reserve pool of addresses - spare addresses that are in your wallet but not shown to you. When the reserve pool of 100 addresses is used up, new addresses will be created by Bitcoin that aren't in your backup. This will result in lost money if you need to restore your backup. Therefore you should make another wallet backup regularly, after sending ~50 transactions or creating ~50 new receive addresses.
To backup, simply use the "backup wallet" option in the file menu.
|
|
|
|
|
The Bitcoin-qt wallet has a default of 100 extra keys for future use in a key pool. It is only necessary to create another backup when this key pool is nearing exhaustion.
|
|
|
|
Transactions without the minimum fee will not be relayed. They will not be stored in the memory pools of miners. They will not be included in blocks. As they are ignored, a proper fee double-spend transaction will be included promptly.
The minimum fee rules have been simplified in 0.8.6, which is the network majority. A fee is no longer required just because any one output is smaller that 0.01 BTC (dust < 5.6mBTC invalid rule takes care of spam), but the minimum fee is now required for any transaction over 1kB in size. This is in addition to the requirement that input priority less than 57.6M (1 BTC, 144 blocks old; 0.01 BTC ~100 days old) include minimum fee.
|
|
|
|
It depends on which "varint" is being used... // Variable-length integers: bytes are a MSB base-128 encoding of the number.
// The high bit in each byte signifies whether another digit follows. To make
// the encoding is one-to-one, one is subtracted from all but the last digit.
// Thus, the byte sequence a[] with length len, where all but the last byte
// has bit 128 set, encodes the number:
//
// (a[len-1] & 0x7F) + sum(i=1..len-1, 128^i*((a[len-i-1] & 0x7F)+1))
//
// Properties:
// * Very small (0-127: 1 byte, 128-16511: 2 bytes, 16512-2113663: 3 bytes)
// * Every integer has exactly one encoding
// * Encoding does not depend on size of original integer type
// * No redundancy: every (infinite) byte sequence corresponds to a list
// of encoded integers.
//
// 0: [0x00] 256: [0x81 0x00]
// 1: [0x01] 16383: [0xFE 0x7F]
// 127: [0x7F] 16384: [0xFF 0x00]
// 128: [0x80 0x00] 16511: [0x80 0xFF 0x7F]
// 255: [0x80 0x7F] 65535: [0x82 0xFD 0x7F]
// 2^32: [0x8E 0xFE 0xFE 0xFF 0x00]
the DER-encoded signatures uses a data format with octet lengths specified in ASN.1 http://luca.ntop.org/Teaching/Appunti/asn1.html |
|
|
|
Since this thread will get read more because of its incendiary first post subject without problem or solution, I'll repost more prominently a paper that I've had a glance through. Essentially, implementation of the fault attack described on compressed keys may make a ECDSA secret discoverable to an attacker with few or even one signature and security reduced to 2^50 instead of ~2^128, but may effected from a very subtle implementation client code change, such as changing the sign of the y. http://perso.univ-rennes1.fr/reynald.lercier/file/FLRV08.pdfWith the curve secp256k1, the order of the twist is
3×197×1559×96769×
146849×2587814237219×375925338294461779×
101009178936527559588563023359.
So on implementations without protections, the attacker can compute the discrete logarithm in the twist with a cost of 250 and retrieve the secret scalar for n = 256. This, along with other platform-dependent concerns, would seem to be a good argument for Bitcoin to pull code out of OpenSSL and roll its own implementation of ECDSA and it's own entropy gathering non-deterministic random generator, so it is not affected by compiling against blindly-trusted user libraries. FIPS140 may be a reduced-security random, and it is a compile option in OpenSSL. It is also a good reason to send your own payments from a well-vetted Bitcoin client, and not reuse addresses or sign lots of stuff with a "money" address. |
|
|
|
gettransaction 0a529c16fb5503e5256bfa1ac74298834c996ff2585360d6b3d299d24e1af18c{ "amount" : 50.00100000, "confirmations" : 61773, "generated" : true, "blockhash" : "0000000004db9a0a3ea27828ff9b917afa621be19edc54c93152f5eac0dfc6f8","blockindex" : 0, "blocktime" : 1366491299, "txid" : "0a529c16fb5503e5256bfa1ac74298834c996ff2585360d6b3d299d24e1af18c", "time" : 1366491299, "timereceived" : 1366491306, "details" : [ { "account" : "", "address" : "mpjrcSevXAkUqC6n6CA24a4wkutJAiMRrj", "category" : "generate", "amount" : 50.00100000 } ] } getblock 0000000004db9a0a3ea27828ff9b917afa621be19edc54c93152f5eac0dfc6f8{ "hash" : "0000000004db9a0a3ea27828ff9b917afa621be19edc54c93152f5eac0dfc6f8", "confirmations" : 66773, "size" : 981, "height" : 67662,"version" : 2, "merkleroot" : "04e2e686553d6c10256b90775e14dfd7930f2ad0d1cfc263f3041d0bccb99012", "tx" : [ "0a529c16fb5503e5256bfa1ac74298834c996ff2585360d6b3d299d24e1af18c", "6def7395b1517005866105fe32c67fbc414a96e1c8e0f7f4a91de553c1511a47", "6a16a39a8b01cbdd8b8fe805877886805e3a2b66df971a14b85047746a1fcc44", "42a412d00f24e6dc676cb40a13eb436bc7dc6c30bd3e8fc507a57f8171ed1a34" ], "time" : 1366491299, "nonce" : 3844633920, "bits" : "1c061134", "difficulty" : 42.19345103, "previousblockhash" : "00000000035cf14e882f8352f972e1b2fe81d0e3a23b6cfe385576d09451db3b", "nextblockhash" : "000000009b0904c6f4d8462c871c0211eb9deac303382c3cda8c4711e7205c0e" } Here's a batch file to print a transaction number's block: @echo off
setlocal enableextensions
for /f "tokens=* delims=:" %%a in (
'bitcoind gettransaction %1 ^| find "blockhash"'
) do (
set trans=%%a
)
for /f "tokens=3" %%G IN (%trans%) DO (set bhash=%%G)
for /f "tokens=*" %%a in (
'bitcoind getblock %bhash%" ^| find "height"'
) do (
set blknum=%%a
)
echo %blknum%
echo %bhash% Programatically you could do "listtransactions", a bunch of these: {
"account" : "",
"address" : "mjF49o7VKpGhPVnqGFJDELPFCeNRbWFYvb",
"category" : "generate",
"amount" : 50.00170000,
"confirmations" : 100600,
"generated" : true,
"blockhash" : "0000000000fb8329a24631d59371ca52724ea15e488b225682ddf7e5a4ee3be8",
"blockindex" : 0,
"blocktime" : 1366486115,
"txid" : "c1d51852a50df9da5c73d7b3023b99018c8d21730efff2854cd6a1c398b406bc",
"time" : 1366486115,
"timereceived" : 1366486118
},then if category = generate, do getblock blockhash and extract height.
|
|
|
|
0.2 didn't have encryption. That was added in 0.6.0
0.4.0. Worked securely in 0.5.0. |
|
|
|
|
The most likely source is that these are non-confirming or double-spent transactions being sent to you. This is why you don't trust 0 confirmation transactions, and why they aren't added to your balance.
You can look up the transaction hash numbers of the individual transactions on blockchain.info to see if they have been included in a block or not.
If the transactions are in the blockchain, then your wallet.dat file is messed up. The best solution is to first backup the wallet through the file menu, and then close Bitcoin, then restart with the -salvagewallet option which builds a new wallet file only using the private keys and not old transaction data.
|
|
|
|
|
Show Posts
