Bitcoin Forum
May 09, 2016, 01:00:54 AM *
News: New! Latest stable version of Bitcoin Core: 0.12.1 [Torrent]
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [19] 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 ... 114 »
361  Other / Meta / Re: POLL: Sales of hacked, compromised, and/or unauthorized transfers of accounts. on: January 02, 2013, 08:01:32 PM
Seems to me account credentials are a kind of intangible property, and selling stolen property is illegal and shouldn't be allowed in the forums.

I am not a lawyer, so that might not actually be true.  But it seems to me that's the way the law should be, and the right thing to do.
362  Bitcoin / Bitcoin Discussion / Re: Try out "Memory Key" - a tool to help generate passwords (suitable for all ages) on: December 31, 2012, 07:38:16 PM
How will you know if people tend to pick the same types of events, and, therefore, create big non-random clusters of choices that might be easily brute-forced?

Taking an idea from https://gist.github.com/3840286...

.... you could store a small number of bitcoin at private key = SHA256(memory_key), store the bulk of bitcoin at scrypt(Name+PIN+memory_key), and tell users to choose a new memory key if the SHA256(memory_key) coins are either ever spent or if that key ever gets funds from somebody else.

Because that means somebody else chose the same memory key.


363  Bitcoin / Technical Support / Re: [PHP] Generate a sendmany with multiple outputs to the same address on: December 28, 2012, 09:09:11 PM
The bitcoind sendmany RPC call uses destination addresses as JSON Object keys, so you can't send to the same address multiple times in one transaction.

If you REALLY want to do that... first, why do you want to do that? I suppose if you want to use the blockchain as a messaging system then sending 0.123+0.567+etc might be an inefficient way of sending a message... but please don't do that.

Anyway, if you do REALLY want to do that, you'll have to write code to construct the transaction yourself. Then you could pass it to the signrawtransaction/sendrawtransaction RPC methods to broadcast it.  (you can't use createrawtransaction to create it, because it uses the same JSON syntax as sendmany for destination outputs).
364  Economy / Economics / Re: A really tough question on: December 28, 2012, 02:49:44 AM
Planet Money has done some great podcasts on dollar coins. Start here:
  http://www.npr.org/blogs/money/2012/04/20/151052399/cage-match-coin-vs-bill
365  Other / Beginners & Help / Re: bitcoind getbalance out differs from getbalance <account> on: December 27, 2012, 05:32:22 PM
There is a longstanding issue that might be related:
  https://github.com/bitcoin/bitcoin/issues/172

366  Bitcoin / Development & Technical Discussion / Re: How would 51% double spending work in the long term ? Thought experiment on: December 26, 2012, 06:13:48 PM
I sent ShadowOfHarbringer's some of my thoughts on this in this private message:
Quote
Take a look at Table 2 in Meni's paper:  "The maximal safe transaction value, in BTC, as a function of the attacker's hashrate
q and the number of con firmations n."

Lets go with a 33% hashpower attacker, at 6 confirmations you can assume any transaction up to about 300 bitcoins is safe.

(disclaimer: I haven't taken the time to digest Meni's analysis, I'm going to assume his numbers are correct).

If you're worried about that, then don't make multi-thousand-dollar bitcoin transactions with people you think might try to double-spend and rip you off OR wait for more confirmations.

Also: don't forget that "33% hashpower" means you have half as many (asics/fpgas) as the rest of the network combined:

Before attack:  lets say network has 100 Thash
You add 50 Thash, so during attack you have 50 of 150 Thash (== 33%)

I don't worry much right now about economically irrational, "I'm going to spend millions of dollars to disrupt the bitcoin network" attacks because I don't think anybody is going to spend millions of dollars to disrupt our tiny payment network.

I have no idea what bitcoin payments will look like in 5-10 years; I expect all sorts of trust mechanisms and relationships to develop that are independent of the bitcoin network, and I suspect some of those will make 51% attacks irrelevant.

And I have no idea what the mining landscape will look like in 5-10 years; if thousands of companies around the world are installing bitcoin mining hardware for free in every house built in cold climates (generate bitcoins and get a discount on your heating bill) then it may be completely inconceivable for even a government to amass enough hashing power to mount a 51% attack.

So while I encourage y'all to keep thinking about it as an interesting theoretical problem, it is only slightly higher on my personal priority list than worrying about quantum computers breaking ECDSA.
367  Alternate cryptocurrencies / Altcoin Discussion / Re: [PPC] [DISCLOSURE] Stake Generation Vulnerability on: December 22, 2012, 01:05:45 PM
We will accelerate the development schedule for this fix so stay tuned. I will give an update in my weekly update later this week on the progress of the release.
There are several smart people here who would tell you if your fix will work or not, if you listen to them.

Peer review is not perfect, but is much better than assuming that you will always come up with the best solution.
368  Bitcoin / Bitcoin Discussion / Re: Core Development Status Report #2 - Discussion on: December 21, 2012, 10:59:26 PM
For less-savvy supporters like myself, could you tell us whether these are fork-required upgrades or no-fork-required upgrades? I'm referrring now to the secure payment protocol stuff.

No fork required. The secure payment protocol stuff is all higher-level than the blockchain.
369  Bitcoin / Bitcoin Discussion / Re: Core Development Status Report #2 - Discussion on: December 21, 2012, 08:58:20 PM
When you get down to it news reports saying "hackers try to DoS attack Bitcoin network, Bitcoin running a bit slow, counter-measures are being deployed, no coins lost" are far less damaging to credibility than "thousands lose their Bitcoins due to new sophisticated malware attack"
Exactly.

My priorities are:

+ Network Security
+ Network Scalability
+ Network Stability

After those Big Three:

+ Wallet Security

Usability of the reference implementation is not on my priority list. I believe the vast majority of users will (if they aren't already) use bitcoin via a web-based service or an app on their mobile phone.

RE: the bitcoin.org homepage:  I think replacing the links to Bitcoin-Qt on the hompage with just a link to the clients page is a good idea. Somebody should get the consensus to do that and submit a pull request.
370  Bitcoin / Development & Technical Discussion / Re: [PROPOSAL] Secure Payment Protocol on: December 20, 2012, 09:55:32 PM
And even allow several PKIs in parallel. The bitcoin client should then display to the user for which PKIs authentication was successful, and for which not.

On one hand:  "Complexity is the enemy of security."  Several PKIs in parallel is more complex.

On the other hand: "Security In Depth."  Several PKIs in parallel could be more secure. But I'd insist that ALL PKI authentications MUST be successful, otherwise you're just giving an attacker the ability to attack the least secure PKI. It would be a mistake to show users a dialog box:

Quote
DNSSEC authentication failed, but X.509 certificate authentication succeeded.
Proceed?
(Yes) (No) (Just shoot me now, please)

BUT: I think it is unlikely people will be willing deploy and keep secure multiple PKI systems, and I think the incremental security is small, so I think the right decision here is Keep It Simple, Stupid.

For example, I re-ordered the fields of SignedPaymentRequest so the entire structure doesn't have to be in memory at once to be processed, which is a suggestion from somebody considering implementing the payment protocol on a very memory-constrained hardware device. There are real tradeoffs if we make this more complex.

371  Bitcoin / Development & Technical Discussion / Re: Protecting merchants from compromised webservers on: December 20, 2012, 09:21:23 PM
Since Mike laid out the advantages of moving to DNSSEC for the PKI as soon as possible (in the other thread), an SSL "hack" may just be what we need for know, rather than designing anything "serious" based on SSL which is then later discarded. I like this hack and don't see any problem with it. Bitcoin pubkeys can be encoded case-insensitive in base32. And the merchant can decide if the security benefit is worth it for him or not. Small merchants won't have that kind of monitoring.

I'm liking the hack the more I think about it, too. Encoding a compressed public key (257 bits) in base32 would be 52 characters, which is comfortably less than the 63-character domain name limit.

Anybody buying a multi-domain (not wildcard) certificate sometime soon? I'm curious to find out if CA's blink if you ask them to issue a certificate valid for something like BTC8df4rfkbmeopl49vvfgkjgtimb84k9gtredsxfr9fekspclen493.mydomain.com
372  Bitcoin / Development & Technical Discussion / Re: Proof of Proof - an alternative to proof of ___ systems on: December 18, 2012, 05:39:00 PM
Standard disclaimer first:  I am often wrong.

But I've got a nagging feeling that all of the pure Proof-Of-X (where X != Work) systems would set up a dynamic of "the rich and powerful get more rich and more powerful."

The more coins you have, the more you get, as far as I can see in all of the proposed schemes (another disclaimer: I only vaguely pay attention to all of the Proof-of-X schemes, so feel free to tell me how I'm wrong). Seems to me that would end up being a destructive feedback loop, where your decentralized currency naturally gets more and more centralized over time.

373  Economy / Service Discussion / Re: no wonder why bitcoin fails on: December 18, 2012, 03:07:17 PM
I sold my bitcoins because I want to buy a new pc I had like 300 BTC
There are now lots of PCs for sale for Bitcoin at bitcoinstore.com. You don't HAVE to sell your bitcoins to get a PC.

374  Bitcoin / Development & Technical Discussion / Re: Bitcoin design contract on: December 18, 2012, 02:07:07 PM
This is part of it, though I also want to specify which major changes are "allowed" to the core Bitcoin design in the future. Obviously this contract can't be enforced by the network, but it would be useful to write it down to make sure that all developers and users are on the same page.

I'm feeling grumpy this morning, so my reaction is "good luck with that."
375  Bitcoin / Development & Technical Discussion / Re: [SUCCESS] Double Spend against a satoshidice loss on: December 17, 2012, 04:24:53 PM
Double-spends have always been possible. That's why we count "confirmations". The number of confirmations reduces the risk of double-spends.
Yes -- 0/1-confirmation double spends are certainly possible. A successful 2-confirmation double-spend would be more interesting. I would love to see if real-network experience matches the theoretical results from Meni's paper.
376  Bitcoin / Bitcoin Discussion / Re: Bitcoin-Qt/bitcoind version 0.7.2 released on: December 14, 2012, 11:39:42 PM
so nothing to fix Hal's find?
No, that will be fixed in the 0.8 release.

If you think the single-send-not-randomizing-the-change-address-bug gives you significantly less privacy... well, you're probably wrong, it is easy to cluster addresses if you have the right network analysis tools. But you can workaround the bug by adding an extra output to all of your transactions (add a new receiving address and then click the 'add recipient' button in on the Send Coins tab in Bitcoin-Qt and send some coins to yourself).
377  Bitcoin / Bitcoin Discussion / Re: Bitcoin Economic Growth - What do you want? on: December 14, 2012, 04:27:27 PM
I'm planning on renting a house near Cairns, Australia from June until December of next year.

I'd love to be able to pay the deposit and rent in bitcoin.

I think paying for international vacation rentals could be a "killer application" for Bitcoin.

378  Bitcoin / Bitcoin Discussion / Re: Bitcoin-Qt/bitcoind version 0.7.2 released on: December 14, 2012, 03:47:04 PM
Quote
Gavin, I swear I had your public key and can't find it. Where do you keep it so I can verify the sums signature?
PGP links are on the bitcoin.org homepage; http://bitcoin.org/gavinandresen.asc  will get it.

The source for the bitcoin.org homepage is at github, so you can get it from there, too:
  https://github.com/bitcoin/bitcoin.org/blob/master/gavinandresen.asc

It is also stored at the MIT pgp keyserver under email 'gavinandresen@gmail.com':
  http://pgp.mit.edu:11371/pks/lookup?search=gavinandresen%40gmail.com&op=index
379  Bitcoin / Bitcoin Discussion / Bitcoin-Qt/bitcoind version 0.7.2 released on: December 14, 2012, 03:28:29 PM
Bitcoin version 0.7.2 is now available from:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.2

This is a bug-fix minor release.

Please report bugs using the issue tracker at github:
  https://github.com/bitcoin/bitcoin/issues

How to Upgrade
--------------

If you are running an older version, shut it down. Wait
until it has completely shut down (which might take a few minutes for older
versions), then run the installer (on Windows) or just copy over
/Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux).

If you were running on Linux with a version that might have been compiled
with a different version of Berkeley DB (for example, if you were using an
Ubuntu PPA version), then run the old version again with the -detachdb
argument and shut it down; if you do not, then the new version will not
be able to read the database files and will exit with an error.

Explanation of -detachdb (and the new "stop true" RPC command):
The Berkeley DB database library stores data in both ".dat" and
"log" files, so the database is always in a consistent state,
even in case of power failure or other sudden shutdown. The
format of the ".dat" files is portable between different
versions of Berkeley DB, but the "log" files are not-- even minor
version differences may have incompatible "log" files. The
-detachdb option moves any pending changes from the "log" files
to the "blkindex.dat" file for maximum compatibility, but makes
shutdown much slower. Note that the "wallet.dat" file is always
detached, and versions prior to 0.6.0 detached all databases
at shutdown.

Bug fixes
---------

* Prevent RPC 'move' from deadlocking. This was caused by trying to lock the
  database twice.

* Fix use-after-free problems in initialization and shutdown, the latter of
  which caused Bitcoin-Qt to crash on Windows when exiting.

* Correct library linking so building on Windows natively works.

* Avoid a race condition and out-of-bounds read in block creation/mining code.

* Improve platform compatibility quirks, including fix for 100% CPU utilization
  on FreeBSD 9.

* A few minor corrections to error handling, and updated translations.

* OSX 10.5 supported again

----------------------------------------------------
Thanks to everybody who contributed to this release:

Alex
dansmith
Gavin Andresen
Gregory Maxwell
Jeff Garzik
Luke Dashjr
Philip Kaufmann
Pieter Wuille
Wladimir J. van der Laan
grimd34th
380  Bitcoin / Development & Technical Discussion / Re: [PROPOSAL] Secure Payment Protocol on: December 14, 2012, 02:37:04 PM
For these and other reasons we already made the decision to go with SSL certs for v1 despite their many problems. Later on, we can build either extensions to the SSL PKI or entirely new parallel ones.

What Mike said.

Building a new PKI infrastructure is most definitely out of scope right now.

But if somebody wants to spearhead an effort to get CAs to allow extra public keys in the certificates that they issue... that might be worthwhile.

Then again, maybe not-- DNSSEC/DANE might make the CAs obsolete.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [19] 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 ... 114 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!