Bitcoin Forum
May 09, 2016, 01:01:02 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 70 ... 114 »
381  Bitcoin / Development & Technical Discussion / Re: Protecting merchants from compromised webservers on: December 14, 2012, 02:14:14 PM
CAs will issue you multi-domain certificates for not a WHOLE lot more than a single-domain certificate, which suggests to me a possible short-term workaround/hack until DNSSEC/DANE is widely deployed.

Get a certificate that is valid for these subdomains:
   merchant.com
   www.merchant.com
   BaseBitcoinAddress.merchant.com  (e.g. 1gavinR2Y6RiHnEbf3sJBGbbKTc5t66do.merchant.com )

(in X.509 speak: Subject Alternative Names)

Payment requests from the merchant would include that certificate and the full public key (or script) that corresponds to 1baseBitcoinAddress.

Bitcoin clients would have to notice that the merchant's SSL certificate included a bitcoin address as one of the top-level domains, and would need to reject any payment requests that didn't include the full public key/script (and would always pay to BaseBitcoinAddress*hash(payment_request) where '*" is whatever hierarchical deterministic wallet scheme we decide we like).


Reasons not to do this or why it might not work:

* It is a hack.
* domain names are not case-sensitive (GOOGLE.com and google.com are the same); bitcoin addresses are.
* The extra cost to the merchant for the multi-domain cert might not be worth the incremental security benefit; if they have good monitoring (which they should), then they should detect an attacker's intrusion within minutes and so their potential loss might be tiny.


Edited, to add references to relevant standards:

X.509 certificates for the Internet:
http://www.rfc-editor.org/rfc/pdfrfc/rfc5280.txt

Subdomain names must be less than 63 characters and start with a letter:
http://www.rfc-editor.org/rfc/pdfrfc/rfc1034.txt

382  Bitcoin / Development & Technical Discussion / Re: How to detect the change output? on: December 14, 2012, 02:30:16 AM
bitcoin-qt tries to randomize the position of the change output, but I believe the code has a flaw...
Ay carumba, how did we not notice that for over two years?

I introduced that bug with the 'sendmany' command two years ago (commit b9d1ed85). This is why programmers should not be trusted to test their own code (I probably carefully tested to make sure the change position looked random when I send to more than one destination, and never tested the degenerate send-to-one case; sigh).

383  Bitcoin / Bitcoin Discussion / Re: Will bitcoin replace today's fiat? What are the advantages / disadvantages? on: December 14, 2012, 01:51:42 AM
Disclaimer: I'm bad at predicting the future.

Will governments create a crypto-currency to try to compete?

The "network effect" is really important for money. Any form of money gains value as more people use it.

It is possible that Bitcoin (or any future crypto-currency) will never be able to gain enough use to overcome big, existing currencies, that already enjoy huge network effects.

But... the potential users for Bitcoin is greater than any national currency because Bitcoin doesn't care about arbitrary political borders. So maybe at some point in the future a distributed, borderless crypto-currency will have a bigger network effect, and will start to replace zlotny or euros or dollars.

At that point, I don't think any one government would be able to compete. Other governments won't voluntarily give up the ability to control their own currency, so even if a government came out with their own crypto-currency how would they overcome the network effect and get people all over the world to use their newfangled solution?

It is possible that there will be some type of worldwide government; a currency from THAT government could, I think, compete with a decentralized crypto-currency.

I have no idea how likely any of this is.

RE: consequences of the dollar not being the world's reserve currency any more: I'd take a look at the history of Britain. The Pound was the world's reserve currency for a long time, before being replaced by the dollar.  England seems to be doing OK, and I'm not aware of any radically huge consequences of the transition from Pounds to dollars.
384  Bitcoin / Development & Technical Discussion / Re: [PROPOSAL] Secure Payment Protocol on: December 13, 2012, 03:28:02 AM
Wow, great paper!

I like the idea of the "bill" (aka contract aka "PaymentRequest") determining the payment address, and the merchant's private bitcoin-signing key or keys being stored off their web server.

I'll append some half-baked thoughts below on melding the current PaymentRequest proposal with your ideas.

Using a Merkle tree to reveal (or not) parts of the bill is a nifty idea, but I think that is orthogonal to the payment protocol, and could be a generic way of encoding any document. I tend to agree with Mike, it feels like a complex solution to something that really isn't a problem right now (maybe if we ever have CyberCourts to adjudicate disputes between anonymous customers and merchants it will be useful).

PS: I was amused by:
Code:
An implementation with bitcoin would require little effort.
Writing the code should be fairly straightforward; getting everybody to agree to the dozens of details we'll need to work out will be more than a little effort.



So in the PaymentRequest protocol, a SignedPaymentRequest contains a PaymentRequest that you know came from the merchant's web server (leveraging the SSL/TLS/PKI/X.509 certificate system that we all agree is the worst PKI system there is, except for all the other that have been tried):

Code:
SignedPaymentRequest
  pki_type = "x509"
  pki_data = ... certificate chain...
  signature = ...
  serialized_payment_request = ...PaymentRequest containing Outputs where payment will go...
  etc

As your paper points out, if an attacker compromises the webserver then they can redirect bitcoins to their wallet.

It would be nice if that was impossible, and your paper shows how to do that.  In the PaymentRequest scheme, one way of doing that might be:

Code:
SignedPaymentRequest
  pki_type = "x509_homomorphic"
  pki_data = ... certificate chain...
  signature = ...
  serialized_payment_request = ...PaymentRequest containing no Outputs...
  etc

The merchant's certificate in the certificate chain would have to contain their base bitcoin public key (or as you point out in the paper, generalized to a "base script"). I think that could be done using an X.509 extended attribute (anybody know if certificate authorities will sign certificates that contain non-standard extensions?).

The customer would hash the serialized_payment_request, combine it with the base key/script, and pay to that address/script.


The TODO list for implementing the simpler "x509" payment requests is fairly long (help appreciated by the way, see https://github.com/gavinandresen/paymentrequest/blob/master/TODO.txt ); implementing "x509_homomorphic" would make it even longer. I think we need to implement the simpler protocol first, because I think small merchants will want to re-use their existing web server certificates instead of paying for a new "x509_homomorphic" certificate that contains their "bitcoin identity" public key.

385  Bitcoin / Press / Re: 2012-12-09 Forbes.com - Bitcoin's Greatness Not Realized By Succumbing To Regul- on: December 09, 2012, 05:06:59 PM
Did John Matonis lose some of his objectivity when he partnered with MtGox through the Bitcoin foundation ?

I think Jon has been pretty consistently on the "less regulation is better regulation" side of the debate. Given that the big criticism of the Bitcoin Foundation (and Mt. Gox) around here was that it is on the "more regulation" side of the fence, I find your comment kind of amusing.

As for it being "a big pile of fail" :  I think reasonable people can disagree here.  I have no idea whether trying to work inside the existing system or working around the existing system is a better approach. You have your opinion, Jon has his, I think we'll be arguing about it for years to come; happily, there doesn't have to be One True Answer.  I just hope we don't spend all our time sniping at each other over the best One True Way to reach the goals that we all share.
386  Economy / Games and rounds / Re: Circle of Trust [Game/experiment] on: December 09, 2012, 04:53:02 PM
12r6DPnX5TNK4PhnTiShmuK6o4jE8Yh28C

Received, rounded up to 3.11 BTC (because eleven is my favorite number) and sent:
  https://blockchain.info/tx/e44db3d7cf05098bfe1a8961a8c805f3e8c94a55e7911699e37ae6227095121f
387  Bitcoin / Armory / Re: Building Armory on OSX on: December 06, 2012, 01:01:57 AM
RE: building the .app bundle:

https://github.com/bitcoin/bitcoin/blob/master/contrib/macdeploy/macdeployqtplus
... is python code with lots of useful stuff for building a nice .app (including making a pretty-looking .dmg).
Lots of Qt-specific stuff, too, but it might be a good starting point.
388  Bitcoin / Development & Technical Discussion / 0.7.2rc2 needs a little testing on: December 05, 2012, 05:51:59 PM
The main reason for this release is to fix a nasty bug in the RPC 'move' command that was introduced in 0.7.0.


Bitcoin version 0.7.2rc2 is now available from:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.2/test

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
389  Bitcoin / Development & Technical Discussion / Re: All BIPs should contain a link to a discussion thread on: December 04, 2012, 10:24:48 PM
No, you probably won't get a response there, either.

"All BIPs should" ... is too rigid, in my humble opinion.

If the person championing the BIP thinks that a link to a discussion thread helps clarify or convince, then they should include a link.  But I don't think a hard-and-fast rule is the right thing to do, we'll just waste time arguing over WHICH discussion thread or threads should be linked...
390  Bitcoin / Development & Technical Discussion / Re: Help wanted: Mac developer with OSX 10.5 on: December 04, 2012, 07:48:13 PM
Can you please let me know if this works on OSX 10.5:
   https://s3.amazonaws.com/gavinandresen-bitcoin/bitcoin-0.7.2rc2-macosx.dmg

I set up a new build environment on an old, 32-bit OSX 10.6 laptop, and I think I fixed the 10.5 compatibility issue.

(some MacPorts maintainers don't seem to be terribly good at making sure their ports honor BOTH the -arch AND the -isysroot settings...)
391  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: December 02, 2012, 04:03:09 PM
Receipt has got a flaw. As a merchant I won't be sending receipts of funds without any confirmations. FYI Wink

I would urge you to return a receipt with a memo that says:

"your order will be shipped as soon as your payment has three confirmations."

Explicitly telling your customers what they can expect to happen next is a great feature of the proposal, I think.
392  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: December 01, 2012, 01:00:17 AM
Why does anyone need identities when invoicing? Or more accurately, why must every invoice have an identity attached?

You will be able to generate and send unsigned invoices that has no identity attached.

But they are much less secure than signed invoices, because a "man in the middle" attacker could rewrite the Invoice so the bitcoins go to him.

Or if you have a dispute with the merchant and all you have is an unsigned Invoice, the merchant can claim that "your machine must have been hacked, you sent the bitcoins to an address that isn't mine!"

393  Bitcoin / Development & Technical Discussion / Re: Can governments spam or ddos the bitcoin network to death? on: November 30, 2012, 04:48:52 PM
Yes, if they have an infinite amount of money to pay in transaction fees.

I'm not sure why governments would want to give all of their money to miners, though. And buying up bitcoins to pay all those fees would just push up the price, so it would probably be counter-productive as a way of trying to ddos the network.
394  Bitcoin / Bitcoin Discussion / Re: Can Bitcoin Foundation succeed lobbying Valve to use Bitcoin as ingame currency? on: November 30, 2012, 02:28:36 PM
I should talk with Valve?

I'm not an expert in video game economics, and I haven't yet seen a strong argument for why a game company would give up control of their own in-game currencies for a currency that they do not (and cannot) control.

If you've got a strong argument for why they should, then YOU should talk with Valve*. They're rational and profit-driven, so if it is in their best interest they should be willing to do it.


*Cue a flood of armchair-game-economists posting their half-baked thoughts here...
395  Bitcoin / Bitcoin Discussion / Re: Is Ripple a Bitcoin Killer or Complementer? Founder of Mt Gox will launch Ripple on: November 29, 2012, 11:01:44 PM
I think Bitcoin has shown rather conclusively that trust just doesn't work. Thus, I think Ripple will become rather chaotic, and may fall apart, when large trust "nodes" (people with a lot of connections that ripple payments go through) decide to take the money and "exit the network," filling the web with holes.

I don't think we'll know if it can work until it is tried; it does seem to me that the incentives point the wrong way (if my doctor tells me I have six months to live maybe I decide I deserve to run up my Ripple credit to the max....) but maybe I'm just cynical (maybe there will be an equal or greater number of people who decide to give away all their money through Ripple instead of leave it to their deadbeat children).

Good luck to Joel and Jed and the rest of the Ripple team!
396  Bitcoin / Development & Technical Discussion / Invoices/Payments/Receipts proposal discussion on: November 29, 2012, 10:53:28 PM
For those of you not subscribed to bitcoin-development@lists.sourceforge.net :

We've been having a productive discussion of a proposal for a simple payment protocol to get a much better user experience than is given by bitcoin addresses:
  http://sourceforge.net/mailarchive/message.php?msg_id=30147926

This is the next big "lets all agree to do things the same way" thing I think we should tackle. Latest pseudo-spec is: https://gist.github.com/4120476

I'd prefer to keep the discussion on the mailing list (I think this forum is a great place for brainstorming, but I think the mailing list is a little better for getting consensus on all the nitty-gritty details of a proposal).
397  Bitcoin / Development & Technical Discussion / Re: New wallet file ideas on: November 29, 2012, 01:35:41 PM

I was under the impression that P2SH was intended for all multi-sig transactions, though you are right there is no reason plain-text multi-sig can't be used (is there? they were probably never added to isStandard...).  One reason for desiring P2SH, in general, is that very long scripts become part of the TxIns instead of the TxOuts.  This means that they will never bloat a pruned version of the blockchain.  If everyone only used P2SH, then no TxOut script would ever be longer than 22 bytes.
You can use plain multisig if you like, they WERE added to IsStandard.
398  Bitcoin / Development & Technical Discussion / Re: Couple of questions about the raw tx API commands on: November 21, 2012, 02:54:08 AM
listunspent output is designed to be read by machines, not people, and its output is designed to go directly into createrawtransaction.

If you need all the human-friendly details of a transaction, use getrawtransaction <txid> 1

I'm against adding "address" to the listunspent output, because most of the time it will be unused and sometimes it would just not appear at all (because not all scriptPubKeys are bitcoin addresses).
399  Economy / Service Announcements / Re: Blockchain.info - Bitcoin Block explorer & Currency Statistics on: November 16, 2012, 04:51:47 PM
What about this... The owner of a website puts a file on their website called bitcoin_tags.json or something like that. This would server a similar purpose to sitemap.xml but instead contains a number of bitcoin addresses and labels.

For example http://wikileaks.org/bitcoin_tags.json

{
 "tags" : {
  "address" : "1HB5XMLmzFVj8ALj6mfBsbifRoD4miY36v",
  "tag" : "Donations",
  "sig" : "signature of concatenated tag and domain"
 }
}

Once the owner of a website has added the file they can suggest that blockchain.info indexes it, once indexed blockchain.info will display the new tag accordingly. This has the advantage of.

* maintainable, webmaster can update bitcoin_tags.json as they choose. Deadlinks will be removed from the database.
* Decentralised, any service can index tags.
* More secure, both the domain and the address signature is verified. Tags can be independently verified if necessary and little moderation is needed.

You should only trust tags fetched via https, otherwise a man-in-the-middle could hijack the .json file and replace the address and signature.

(and I think you'd want "tags" to be an Array of Objects...)

RE: adding data to the blockchain: Did you see Stefan Thomas' nifty idea for using ECC math to tie a hash to a transaction without any blockchain bloat?
400  Bitcoin / Development & Technical Discussion / Re: bitcoind security best practices? on: November 15, 2012, 07:35:18 PM
i suppose we don't need to buy certificates for this server to server connection, how do we generate the needed files on our own?
See: https://en.bitcoin.it/wiki/Enabling_SSL_on_original_client_daemon
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 70 ... 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!