[For SINGLE output the following formats DO work with copy-paste]

Is it possible to "pay to many" in ANDROID(!) Electrum?

I tried to "paste from clipboard" the invoice string in many different ways, but none of it worked.

For SINGLE output the following formats DO work with copy-paste:

1BitcoinEaterAddressDontSendf59kuE

bitcoin:1BitcoinEaterAddressDontSendf59kuE

bitcoin:123AnditsGone111111111111111Ymiao1?amount=0.0008


For MULTIPLE outputs NONE of the following works:

1BitcoinEaterAddressDontSendf59kuE,123AnditsGone111111111111111Ymiao1

1BitcoinEaterAddressDontSendf59kuE
123AnditsGone111111111111111Ymiao1

1BitcoinEaterAddressDontSendf59kuE,0.0008
123AnditsGone111111111111111Ymiao1,0.0009

1BitcoinEaterAddressDontSendf59kuE,0.0008;123AnditsGone111111111111111Ymiao1,0.0009

bitcoin:1BitcoinEaterAddressDontSendf59kuE?amount=0.0008,123AnditsGone111111111111111Ymiao1?amount=0.0009

bitcoin:1BitcoinEaterAddressDontSendf59kuE?amount=0.0008&123AnditsGone111111111111111Ymiao1?amount=0.0009

bitcoin:1BitcoinEaterAddressDontSendf59kuE?amount=0.0008&123AnditsGone111111111111111Ymiao1&amount=0.0009

bitcoin:1BitcoinEaterAddressDontSendf59kuE?amount=0.0008,bitcoin:123AnditsGone111111111111111Ymiao1?amount=0.0009

bitcoin:1BitcoinEaterAddressDontSendf59kuE?amount=0.0008
bitcoin:123AnditsGone111111111111111Ymiao1?amount=0.0009

bitcoin:{1BitcoinEaterAddressDontSendf59kuE?amount=0.0008},{123AnditsGone111111111111111Ymiao1?amount=0.0009}

{bitcoin:1BitcoinEaterAddressDontSendf59kuE?amount=0.0008},{bitcoin:123AnditsGone111111111111111Ymiao1?amount=0.0009}

{bitcoin:1BitcoinEaterAddressDontSendf59kuE?amount=0.0008},{bitcoin:123AnditsGone111111111111111Ymiao1?amount=0.0009}


Now I am running out of ideas what other formats I should try. Any ideas? Or is it not possible on the Android version?

[[UPDATE: SOLVED, MY BAD: By error I tried to broadcast an unsigned TX]]

[UPDATE: SOLVED, MY BAD: By error I tried to broadcast an unsigned TX]

I created a raw transaction with an older electrum version (1.7x or so). It verifies correctly on "https://coinb.in/#verify", it is a TX with 1 input and 4 outputs and it has sufficient TX fee and has in- and outputs that are larger than just dust.

I cannot broadcast it anywhere. I always get error messages like these:

https://coinb.in/#broadcast
--> the transaction was rejected by network rules. scriptsig-not-pushonly

https://blockstream.info/tx/push
--> RPC error

https://www.blockchain.com/de/explorer/assets/btc/broadcast-transaction
--> "Code: -26, Error: scriptsig-not-pushonly"

https://www.viabtc.com/tools/broadcast
--> Raw transaction send failed

https://live.blockcypher.com/btc/pushtx/
--> Error validating transaction: Rejected script for input 0 referencing ......

https://blockchair.com/broadcast
--> An error has occurred, please verify the transaction hash and selected network and try again.

https://bitaps.com/broadcast
--> Mempool accept test failed: scriptsig-not-pushonly

Finally I tried Electrum on Android with the "paste" button from clipboard. Again same problem (I translate error message to English):
--> The server has answered with an error. Try to select another server or to install an update of Electrum. scriptsig-not-push-only
(I tried about 10 different servers - all the same problem, then I gave up)

What can I do to broadcast this TX?

[Abstract]

I wrote another (much simpler!) proposal for combining the best of BIP-100 and BIP-101, so I called it "BIP-100.5" for now.

I focussed on...

* Decentralization
* User adoption over time
* Technological progress over time
* The uncertainty of the two above
* Interests of the eco-system
* Interests of the miners
* Reasonability and pragmatism
* Likelihood of adoption
* Simplicity of implementation

Although I used BIP-100 as the template, there are too many changes for making it a pull request to BIP-100 I think.


Abstract
This BIP proposes to replace the fixed 1 MB block size limit with an adaptive limit that can float between 1 MB and 61 GB (temporarily 1..32 MB) based on a default growth rate and miner voting. This combines the merits of BIP-100 and BIP-101 within a new generalized mechanism. Both BIP-100 and BIP-101 can be considered special cases of this BIP, depending on the choice of hard-coded parameters.

Full description here: https://github.com/1MichaS1/BIP100dotFive

Fierce proponents of BIP-100 and BIP-101 respectively will probably not like any other proposal than "their's" - for the vast majority I am hoping it can be a reasonable compromise that can achieve wide consensus.

Illustration: Possible block size limit evolutions for certain miner majorities (for comparison the growth rates of 17.7% and 41.4% are included) - log scale:

Note: With BIP-100, the "red default" line would be at 0.0% growth (horizontal), the 80% and 90% lines would be about where the 90% lines are in above figure, and all other lines would be 0.0% (horizontal) like the red default line. With BIP-101, all lines would be collapsed to where the +41.4% line is in above figure.


The reason why in this BIP the default growth rate is not 0.0% but some moderate positive value is that the default should, at least in tendency, follow the "bathtub":

Centralization
of Bitcoin system
  .
 /|\
  |*                                                                     *
  |*                                                                     *
  | *  (a) More users                                                   * (b) Technol. progr.
  |  * ----> time                                                      *  ----> time
  |   *                                                               *
  |    *                        ----> time                           *
  |      *      Area of best Bitcoin system decentralization       *
  |        *    |<----------------------------------------->|    *  
  |             *   *   *   *   *   *   *   *   *   *   *   *
  '--------------------------------------------------------------------------->
                                                               block size limit

Left edge = centralization due to too low capacity (tx per second, congestion, users pushed off-chain).
Right edge = centralization due to too high bandwidth + storage requirements.
Both edges move to the right as time passes, this BIP's default growth tries to stay in the flat area of the bathtub.
Voting enables deviation from the default growth.

Looking forward to your opinions!

Hi,

after having read BIP100, 101, 102 and 103(?), after having seen many discussions, after having heard many arguments, after weighing many pros and cons, after having read study reports about the effects of congestion in the transaction queues, after thinking for myself what other solutions might exist, I made a write-up about a solution that combines and considers many ideas and concerns. I have made several iterations of improvements before releasing the first version to the public today.

Unfortunately(?), the document has become larger than planned, it has 37 pages, but for a quick read you already get an impression when reading only page 1 (abstract) and pages 7+8 (overview).

Fortunately, it is well structured and full of information. It does not only give some basic ideas but specifies the solution down to a very detailed level close to implementation. It also has a separate chapter giving the rationale for many design decisions, and it provides simulation results (incl. simulation code) to see how the method behaves in certain corner cases.

Now I hope you have the time to read and understand the paper, and I am looking forward to hearing your thoughts. I think the interested reader will find an inspiring mixture of known and new ideas, combined in a way and detailed down to a level as it has not been seen before.

[Last update 5 Sept 2015, ~15:30 CEST]: OVERVIEW DOCUMENT in BIP Format / Github:

• BIP mediawiki format at Github

[Last update 5 Sept 2015, ~2:00 CEST]: FULL SPECIFICATION (39 pages):

• BIP10X_Block_Size_Limit_Adaptation_v02.pdf from scribd.com
• BIP10X_Block_Size_Limit_Adaptation_v02.pdf Dropbox Download

Further sources (will not be updated as frequently as Github format above, with same content as in Github repository):

[Last update 5 Sept 2015, ~2:00 CEST]: Overview Document as PDF file (5 pages):

• BIP10X_Block_Size_Limit_Adaptation_Overview_v02.pdf from scribd.com
• BIP10X_Block_Size_Limit_Adaptation_Overview_v02.pdf Dropbox Download

Looking forward to hearing from you!  
Michael

PS: I have not yet tried to apply for a BIP number (but will probably do so later), that's why I put a placeholder and am calling it "BIP10X" for now.

[Bitcoin Trade-Manager]

Hallo,

ich habe ein Tool geschrieben, in das man alle seine Bitcoin Trades (Käufe, Verkäufe) eingeben kann.
Das Tool berechnet dann alles Mögliche und stellt es übersichtlich tabellarisch dar, inkl. Gewinn und Verlust (G&V) pro Kalenderjahr, optional auch steuerlich relevanter GuV pro Kalenderjahr nach Berücksichtigung des > 1 Jahr Haltedauer [Deutschland]), etc.

Das Bitcoin Trade-Manager getaufte Tool ist eine Datei im *.ods Format und muss mit LibreOffice Calc (das kostenlose Microsoft-Excel-Pendant) geöffnet werden - gibt es kostenlos für Linux (standardmäßig vorinstalliert in allen großen Distributionen), Windows und Mac OS.
[Mit MS-Excel wird's wohl wegen einer nicht identischen Makro-Sprache (BASIC/VBA) nicht funktionieren]

Ich habe das Tool ausgiebig bis in alle(?) Ecken hinein getestet und konnte keinen Fehler mehr finden. Es ist auch reichhaltig dokumentiert und erklärt, und mit viel Liebe zum Detail versehen.

==> DOWNLOAD (zip-File mit *.ods Datei, Checksummen und PGP-Signatur)
Update: Version 1.1 jetzt verbessert in Sachen Geschwindigkeit und Features!
 

Kurzbeschreibung / Features:

- Für jeden bitcoin Trade (Kauf/Verkauf) kann der EUR/XYZ-Wechselkurs der „XYZ“ Fiat-Währung angegeben
  werden, gegen welche BTC gehandelt wurde (z.B. XYZ = USD). Praktisch für Börsen, die nicht in EUR handeln.
- Berechnung des kumulierten Cashflows, des Gesamt-bitcoin-Bestandes und anderer Informationen, pro Transaktion.
- Es ist sichtbar, wie alt die ältesten noch nicht veräußerten bitcoins sind und wie viele es davon gibt – praktisch zur
  steuerlichen Planung zukünftiger Verkäufe.
- Steuerlich: Anwendung der FIFO-Methode (die ältesten bitcoins werden zuerst verkauft)
- GuV steuerlich nicht anrechenbar bei Verkauf nach > 1 Jahr Spekulationsfrist (optional)
- Korrekte Berücksichtigung von Schaltjahren bei der Haltedauer
- Ausgabe der kumulierten gesamten und der steuerlich anrechenbaren Gewinne & Verluste pro Kalenderjahr. Ein
  Jahresgewinn ab einer Freigrenze (default=600 EUR) wird farblich hervorgehoben (gelber Hintergrund) (optional).
- Ausgabe aufschlussreicher Zusatz-Infos für jede (Ver)Kaufs-Transaktion
- Wahlweise Bearbeitung der Transaktionsliste entweder „alles auf einmal“ oder „schrittweise interaktiv“:
  Im interaktiven Modus gibt es verständliche Info-Ausgaben für jede Teil-Transaktion. So lassen sich Berechnung
  und Funktionsweise des Tools sehr transparent nachvollziehen.
- Keine Probleme durch Rundungsfehler des Computers (z.B. „-2.153908375e-15“ statt Null), Vergleiche auf ==0
  werden unter Berücksichtigung dieser Toleranzen stets korrekt ausgeführt (Verwendung von „epsilon“). Beträge
  werden nach Zwischenschritten auf 2 bzw. 8 Nachkommastellen gerundet, so dass sich Rundungsfehler des
  Rechenwerks gar nicht erst akkumulieren.
- Automatischer Check, ob die Transaktionen in chronologischer Reihenfolge aufgelistet sind.
- Eingabe der Netto-Daten von bitcoin.de Transaktionen (ohne Gebühr oder Abzüge) möglich – auf Knopfdruck
  werden die Brutto-Daten ausgerechnet und eingetragen. Dabei wird exakt so gerundet wie bei bitcoin.de, auf den
  Satoshi und auf den Cent genau!
- Einfache Bedienung durch vordefinierte Schaltflächen zum Löschen/Einfügen von neuen Zeilen oder Starten der
  Auswertung. Manuelles Einfügen von Zeilen oder Kopieren und Einfügen von Zell-Referenzen NICHT notwendig, also
  keine Kenntnisse in Tabellenkalkulation notwendig.
- Starke Verbesserung der Bearbeitungsgeschwindigkeit bei langen Listen durch Entfernung fast aller bedingter
  Formatierungen und durch Vermeidung von LibreOffice-spezifischen Fragmentierungen der verbleibenden bedingten
  Formatierungen.
- Es darf im Daten-Eingabebereich (=blaue Spalten und Kommentar-Spalte) nach Belieben mit Copy&Paste oder
  Cut&Paste gearbeitet werden (z.B. um Zeilen zu kopieren, umzusortieren etc.), ohne dass Cross-Referenzierungen
  durcheinander kommen! --> Dadurch ziemlich Idioten-sicher.
- Workaround für einen sporadischen LibreOffice Bug, wonach manchmal Inhalte ungesperrter Zellen bei einem
  geschützten Arbeitsblatt nicht per Makro gelöscht werden können.
- Navigations-Schaltflächen ergänzt.
- Reichhaltige Dokumentation, Hilfetexte, oder Hilfe-Dialoge bei unterschiedlichsten Operationen.

Und außerdem:
- Ausführlich getestet – auch alle erdenklichen Grenz- und Fehlerfälle wurden berücksichtigt.
- Vorkonfiguriert mit Beispiel-Transaktionen, um alle wichtigen Features dieses Tools zu veranschaulichen.
- Mit viel Liebe zum Detail - vor und hinter den Kulissen.

So sieht das Tool aus - Dateneingabe in die blau hinterlegten Spalten links - der orange Bereich wird sofort berechnet, der grüne Bereich wird durch ein Makro berechnet, wenn man die "Auswertung starten"-Schaltfläche klickt:


...Fortsetzung nach rechts:


Hoffe es ist nützlich. Viel Spaß!

Gruß
Michael

PS: Die bereits eingetragenen Transaktionen sind natürlich Beispiel-Transaktionen, um die Features des Tools zu demonstrieren, und nicht meine eigenen Trades!  :-)

[TUTORIAL: Setting Up Your Linux PC for Browsing *.bit Domains and *.onion Domains]

I was searching for an All-In-One Tutorial about how to setup your PC for surfing *.onion addresses via TOR and surfing Namecoin *.bit addresses that may point to *.onion or to regular web addresses or IP addresses.

Since I did not find such a tutorial, I collected all information, tried it out and wrote a tutorial myself. I am now sharing this tutorial:

TUTORIAL: Setting Up Your Linux PC for Browsing *.bit Domains and *.onion Domains
(How to Combine Namecoin and TOR Features for your Web Browser)

This tutorial has been created for Linux Ubuntu 14.04
(or more precisely: Linux Mint 17 with default Cinnamon Desktop)
in October 2014

But Windows users should find it useful as well, most parts are OS independent.

1. Introduction

TOR is a protocol and a software by which you can surf the web anonymously, and also other programs that access the internet, like Bitmessage, Bitcoin clients, chat programs etc. can access the internet anonymously via TOR. In terms of web browsing, you can surf normal websites, but you can also surf websites that are only available through TOR. These websites have the domain name *.onion and have rather cryptically looking sequences before the ".onion", like e.g. "http://3g2upl4pq6kufc4m.onion".

Namecoin is a cryptocoin that is working very similarly to Bitcoin, but it's main purpose is to register internet domain names in its ledger, the so-called blockchain, in a completely decentralized manner. These domain names have the domain name extension *.bit and are used as "pointers" to the actual web site. A *.bit address can for example point to an IP address, to a normal web address, or to a TOR web address (*.onion).

The combination of Namecoin and TOR is particularly useful. This way, a host of a website in the TOR network can register a meaningful *.bit domain which points to his *.onion web address. The web site's visitors only need to remember the *.bit domain name.

Summary overview:

   -------------------           -----------                  ---------------
   NAMECOIN Blockchain           TOR Network                  Public Internet
   -------------------           -----------                  ---------------
  
   name1.bit  ---------------->  3g2upl4pq6kufc4m.onion

   name2.bit  --------------------------------------------->  some-domain-name.com
  
   name3.bit  --------------------------------------------->  123.45.678.90


To make use of these features and domain names, you as the end-user and web-surfer have to set-up a few things on your PC, and there might be different solutions how to achieve this.

This tutorial explains one such solution, probably the most common one. It will explain how to enhance the capabilities of your normal "everyday" firefox browser!

WARNING:

Note that for highest security surfing via TOR e.g. under oppressive regimes, it is recommended to only use the "TOR Browser" but not your normal firefox browser. The reason is that your identity could leak from your browser's individual footprint, even when you surf via TOR. The dedicated "TOR Brower" on the other hand is configured for maximum security (albeit lacking many comfort features like cookies, JavaScript, flash, bookmarking capabilities or browsing history).

However, if you are not deeply worried about your privacy, e.g. if you just want some improved privacy to prevent your ISP from tracking your surfing behaviour, and if you live in a free country whose jurisdiction you generally trust, you may opt for using your "normal firefox" for TOR browsing. You can still install the more secure "TOR Browser" on top, for "mission critical" surfing.

2. Overview

The following has to be installed:

Mandatory:

• Firefox
• Firefox Add-On "freespeechme v0.12" or later
• tor (or the "TOR-Browser", or both)

Optional (recommended):

• Firefox Add-On "Toggle Proxy 1.8" or later
• Firefox Add-On "QuickJava 2.0.4" or later

3. Installation

Mandatory:

• Firefox is normally already installed on your Ubuntu PC
  
  
• The freespeechme Add-On can be installed here:
  "http://www.freespeechme.org/download-and-install/"
  --> Direct install link: "https://dot-bit.org/files/FreeSpeechMe.xpi"
  
  
• Install "tor" from the Software Center (GUI: e.g. Synaptic), or from the command line:
   $ sudo apt-get install tor
  
    Note: alternatively (or in addition) you may also want to install the "TOR Browser":
   $ sudo apt-get install tor-browser

Optionally, you can also install these two firefox Add-Ons, they will improve your surfing experience and are therefore warmly recommended:

• Firefox Add-On "Toggle Proxy 1.8" or later
  "https://addons.mozilla.org/de/firefox/addon/toggle-proxy-51740/"
  
  
• Firefox Add-On "QuickJava 2.0.4" or later
  "https://addons.mozilla.org/de/firefox/addon/quickjava/"

4. Configuration

4.1 Configure Firefox

Preferences --> Advanced --> Network --> Connection - "Settings..." button --> Configure the following Manual Proxy:

• SOCKS Host = 127.0.0.1 (or "localhost")
• Port = 9050 (or 9150 when you want to use the TOR Browser's Proxy service instead of the background "tor" service)
• [ x ] check the box for External DNS Server
• Press OK button

NOTE:

If you want to surf the normal web without TOR, and if you only want to surf TOR .onion addresses for those web sites that are translated from *.bit addresses, you do not need to make above changes, then it is sufficient to make the TOR proxy settings in the FreeSpeechMe Add-On as described below.

4.2 Configure Firefox "FreeSpeechMe" Add-On

Place the Add-On's button to the menu bar, if not already there.
Then click the little "down-arrow" of that button and select "Options". Make the following settings:

• In the tab "Namecoin", ...
  
  • ...For the question "What Namecoin software do you already have installed?" select "I don't have namecoind or nmcontrol;use the bundled version"
  • ...Further below in the section "Choose the priority [...]", move the "Tor hidden Service (.onion)" just above the "cut-line" via the "Increase Priority" button.
  
  
• In the tab "Proxies", fill the Tor line with Host = 127.0.0.1 (this is your own PC, also called "localhost") and Port = 9050 (note: If you have NOT installed "tor" but only "TOR Browser", set Port = 9150 instead, to use the Proxy service of the TOR Browser rather than that of the tor service)

IMPORTANT:
The first time that firefox with freespeechme Add-On is active it takes several hours to download the complete Namecoin blockchain which is the ledger of the registered *.bit domain names. This is currently about 2 GByte in size and will be located at

       /home/<username>/.convergence-namecoin/

FreeSpeechMe does NOT work before that process has finished, so give it some time, e.g. leave your PC on over night the first time.

In the "Status" tab of the FreeSpeechMe options, the field "Output from namecoind" should look something like this:

         {"version":37200,"balance":0,"blocks":202187,"timeoffset":-3,
         "connections":8,"proxy":"","generate":false,"genproclimit":-1,
         "difficulty":20963602995.997684,"hashespersec":0,"testnet":false,"keypoololdest":
         1413601214,"keypoolsize":101,"paytxfee":0,"mininput":0.0001,"errors":""}

Only then the Add-On is operational to browse *.bit domains.

Moreover, every time you start firefox, the Add-On needs some time to download the latest part of the blockchain, so also then it may take some seconds or minutes until it is operational.


4.3 Configure the Two Further Firefox Add-Ons (optional, recommended)

For the two optional Add-Ons, add the corresponding buttons to your menu bar e.g. next to the address field (via right-click on the menu etc...):

Add-On "Toggle Proxy": There is only one button to select.
Via "Menu -> Extras -> Add-ons" go to the settings of "Toggle Proxy" Add-On and set as follows:

• Toggle One = Use System Proxy
• Toggle Two = Manual Proxy
• Click OK

Add-On "QuickJava": I recommend to select these two buttons:

• The "QJ" button for toggling JavaScript, Java and Flash
• The "C" button for toggling Cookies.

4.4 Configure TOR

Start "tor" from a terminal window or type "tor <Enter>" after pressing Alt-F2.

For the future, you may want to put "tor" to the autostart group so you do not have to care about it every time you start your PC.
With Linux Mint 17 and its default "Cinnamon" desktop manager this can be found via

    Menu -> "Startprogramme" (in case of the German language version )

There you click "Add" and just put tor (three small letters) in the "command" field and any descriptive text of your choice in the other fields.


5. Enjoy Surfing

Now test if everything works as desired:


5.1 Test 1: Check TOR


5.1.1 Toggle TOR On/Off

Use the button from the "Toggle Proxy" Add-On to toggle your proxy settings. This way you can switch between browsing normally, or browsing via TOR.

Surf to the following web-site to check if your are surfing "normally" or via TOR:

   "https://check.torproject.org"

Hint:

The buttons from the "QuickJava" Add-On are convenient for easily (de)activating functions critical to security. Especially *.onion web sites might contain malicious material, so it could be wise to deactivate JavaScript and Flash, to avoid a website exploiting potential browser vulnerabilities.

You may also want to deactivate cookies sometimes.
      
Of course these buttons can also be used when surfing the "normal" web without TOR.

5.1.2 Check TOR *.onion Addresses

Go to a list of *.onion addresses, click them and see if it works.
You can find such a list e.g. here:

  "http://thehiddenwiki.org"

Example link: "http://3g2upl4pq6kufc4m.onion" (DuckDuckGo Search Engine)


5.2 Test 2: Check Namecoin *.bit Addresses

One example address that should normaly work:
  
  "https://dot-bit.bit"

A list of *.bit addresses that should work to the most part can be found for example here:

  "http://www.meowbit.com/list-of-working-dot-bit-websites/"

Further addresses can be found here
  
  "https://dotbit.me/"  --> choose the "Surf .Bit" tab.
  
Note that quite a lot of *.bit addresses generally do not work, so try several different links before assuming that something is wrong with your computer's configuration.

If it does not work, ...
  ...make sure you have not accidently disabled the FreeSpeechMe Add-On via its menu button.
  ...make sure that the complete Namecoin blockchain was downloaded and the status is ok,
     compare section 4.2 above --> "Status" tab of the FreeSpeechMe options.


6. Supplemental Info

• As said before, for the most secure surfing experience, use the dedicated "TOR Browser". This is a fork of firefox tweaked for most secure browsing via TOR without leaving a trace. The author of this tutorial has not yet checked whether it is possible to install the FreeSpeechMe Add-On into TOR Browser and whether it works there.
  
  
• You do not need to install "tor" (the service) if you have installed the TOR Browser. In that case, the TOR Browser can not only be used as an "all-in-one" standalone browser solution to browse the web via TOR, but it can also be used as a TOR proxy service by other programs. This means, as soon as you start the TOR Browser, a TOR proxy service is running in the background that can be used by other applications via SOCKS5 / IP 127.0.0.1, Port 9150. Such an "other application" can be e.g. the normal firefox browser, IRC chat clients or any other programs that access the internet and that can be configured to use a SOCKS5 proxy.
  
  
• If you install the Namecoin client (= Namecoin wallet) on the same PC, note that it does not currently work together with the FreeSpeechMe Add-On, which runs an own version of namecoind
  (a future version of the freespeechme Add-On should be capable of reading the blockchain data from the standard Namecoin client, but currently this does not yet seem to work).
  So, only run one at a time:
  
  • If you want to run firefox with the freespeechme Add-On, first close your Namecoin wallet and wait ca. 10 seconds until that process has really terminated.
  • If you want to run your Namecoin wallet, first close firefox and wait ca. 10 seconds until the namecoind process of freespeechme has really terminated.

[immune against brain wallet brute force attacks]

This is a suggestion for a best practice key management technique for everybody, using tools available today!
At the end I am also suggesting a corresponding feature enhancement for clients/apps that support key control.

The situation:
You are printing a paper wallet and store it somewhere in your house or flat.

The Problem:
A thief may rob your paper wallet and steal your bitcoins, just the same way he could steal your gold treasure.

A first solution today:
You print an encrypted paper wallet (BIP38), see e.g. bitaddress.org, current version 2.6.5 (or later)

But the Problem:
The thief may hold a gun against your head and kindly ask you to disclose the password. Now the encryption is of little help for you, the only thing you could do is to say you forgot the password, but this may not seem plausible to the thief.

The SOLUTION:
Combine the concept of "paper wallet"  with the concept of "my own password" and "brain wallet", as follows:

1.) You print out your paper wallet, with e.g. Private Key = "5MyPrivatePaperWaLLetKey"

2.) You are making up yourself a 1st (easy) dummy password, e.g. "MyFirstSimplePW" and create the following concatenated string "5MyPrivatePaperWaLLetKeyMyFirstSimplePW"
2b.) You use this as the input of the brainwallet tool (which just calculates priv key = SHA256(input). This gives you (after format conversion to WIF) the second private key "5MySecondPrivateKey"

3.) You are thinking of a 2nd (difficult) serious passphrase, e.g. "My_very-s3ri0UsP4s5PhRA5e" and create the following concatenated string "5MyPrivatePaperWaLLetKeyMy_very-s3ri0UsP4s5PhRA5e"
3b.) You use this as the input of the brainwallet tool. This gives you the third private key "5MyThirdReaLLySafePrivateKey"

4.1) You transfer a very small amount (e.g. 1% of your total BTC savings) to the Address of Key 1.
4.2) You transfer a bigger amount (maybe 10% of your total BTC savings) to the Address of Key 2.
4.3) You transfer the vast amount (e.g. 89% of your BTC savings) to the Address of Key 3.

Note: Of course you print out at least two copies of this paper wallet and deposit them at very different places.

With this best practice you now enjoy the following nice features:

• Your keys are immune against brain wallet brute force attacks, even if your password/passphrase is weak, because it is salted with the "private key 1"!
• Theft detection and avoidance: In case that your paper wallet gets secretly stolen, you will still realize this theft as soon as the thief redeems the balance of "Key 1" (you can configure a watch-only wallet on your smartphone, e.g. Android app "wallet balance" or "bitcoin balance", to monitor this "indicator address")! Now you will have enough time to move the funds of Key 2 and Key 3 to a new safe address. Probably the thief will never know that there exist further keys that can be derived from that paper wallet's private key and a password, so you would not have to bother about key 2 and key 3 at all. But even if he knew, he would have to brute-force and check against the blockchain every time he tries a new password, because any password that he tries yields a valid key. So he does not know when to stop because he does not know how many times you have performed "step 2" (see above) with different password. So this would be a hopeless task for the poor thief.
• If a thief puts a gun at your head and asks you for the paper wallet, you give him the paper wallet and he is probably happy.
• Plausible deniability: If the thief knows about this "best-practice trick", he may ask you for the password/passphrase that is to be salted with this paper wallet's private key to yield the "hidden" private key. So you tell him your "simple password" from step 2 above. There is no way the thief can tell how many other such passwords exist. There could be none, or only one. There could be two. There could be hundreds. So you will for sure never tell the thief your third safe passphrase, so the 89% of your BTC savings (in this example) are save against even violent theft.

Finally, the same scheme can also be applied to electronic wallets of course. One suggestion for bitcoin client developers: It might be nice and really useful to incorporate this in any bitcoin client that supports key control (coin control), i.e selection of the keys were to spend from:

• In the "spend" dialog, user selects the own address from which to spend.
• Then there is an optional field called something like "salt priv key with a password". If this field is filled with some content, then the client will create the concatenation "<WIF_format_of_selected_key><password>" and calculate the SHA256 hash from that. The resulting 256 bit sequence is the new private key! The client checks the balance of this key's address, and if there is indeed a balance, it can spend from it.
• This is nice because I can carry with me an ARBITRARY number of hidden keys per each "obvious key" in my wallet. And nobody can prove how many keys I really have.

[mBTC]

I am announcing Version 10 (GPG signed zip file) of my tool with mBTC or mBTC or ₥ denomination support and some cleanups! (11.8 MByte).

(I got inspired here [₥ is Unicode #20A5])





Let me shortly re-capture the benefits of this tool:

* Purpose:

• Empower EVERYONE to print your own bitcoin bills or vouchers and to allow for personal customization if required.

* Ease of Use:

• Requires no IT knowledge, no command line skills, no technical pre-requisites except Firefox
• Tested with Firefox on both Windows and Linux
• Setup procedure = extraction of a zip file - that's all !
• Start procedure = opening a local html file in Firefox - that's all !
• Well documented "user manual" and readme files
• The GUI has many "?" buttons providing detailed explanations were necessary

* Features:

• Hi resolution printout when using Firefox (but NOT with Chrome!)
• Many pre-defined templates are available as best-practice examples for many purposes (English & German)

(including denominations in "₥")

• Highly customizable...
• Many pre-defined bitcoin bill designs available
• Also for the reverse side different designs are available (see also here)
• You can use your own customized images if you want (just the aspect ratio and the coordinates of QR codes, denominations, public address etc. are given)!
• Save/Load your complete GUI configuration settings to/from a text string
• Use self-generated private keys or your own (vanity-)keys (support for bulk processing of many keys and pages at once)
• Support for small private QR code (to allow being covered by 1 inch temper-evident holographic sticker)
• Support for large private QR code (e.g. for paper wallet)
• Support for print of black rectangle if no holographic sticker available
• ...

* Possible use cases:

• Christmas present: Customized bitcoin note with somebody's personal picture in the design, and the private key containing ... (m)BTC
• Tips: Give voucher with expiry date as supplemental tip in a restaurant/pub. Keep a copy and redeem yourself after the deadline passes.
• Educational game competition: Print 10 Bitcoin vouchers with the *same* private key - the team who redeems it first wins.
• Game Lottery: Most bills have zero or only few mBTCs loaded, but one is the main price...!
• Game Quest/Treasure Hunt/("Indiana Jones' search for the holy grail..."): Teams must put pieces of a "puzzle" together... after having solved all pieces they get the solution - this is the passphrase of a brain wallet! The team who finds the solution first and redeems the corresponding coins wins! (well ok, for this one you do not really need printed paper notes - but nice idea anyway  )
• Geocaching: Populate your geocache with some mBTCs
• ...

Screenshot of the GUI:



I hope you enjoy it as much as I do!

Donations and new image designs fitting this format (aspect ratio, coordinates of print elements like denominations, QR codes, BTC address, ...) are always welcome!

Merry Christmas!

PS: More info about this tool e.g. in this thread from 2012. The tool is based on bitaddress.org, I stripped away what is not needed and enhanced the part for the paper wallet. The bitcoin note designs are reused from tools of salfter and casascius from this forum.

Hello Wallet developers and POS solution makers,

hello coinbase, bitpay, blockchain.info, inputs.io, Andreas, Jan, apetersson, etc.

I just want to let you know that I have submitted a proposal for an amendment of BIP 0021 in the "discussion" section of the wiki
https://en.bitcoin.it/wiki/Talk:BIP_0021.

This should make tipping in real-world situations really effortless for the customers. Hope it will be adopted to BIP 0021, and then also to the wallet apps and merchant/POS SW.

Note: I don't know the exact process  of the BIPs, but I assume that since this is a minor downward compatible enhancement, and since extensions of this kinds have anyway be expected in todays description of BIP 0021 ("otherparams"), I assume this change does not require a new BIP but can be incorporated in the existing BIP 0021.

[Use your OLD worn-out SMARTHPONE as OFFLINE STORAGE!]

[Android, iPhone, old smarthpones, offline wallet, hardware wallet, HW wallet, offline storage, bitcoin, secure, private key, sign transactions, mass adoption, mainstream]

Hello,

I use an EeePC with Electrum bitcoin client as offline storage. But the EeePC is expensive and difficult to set up, so this won't be done easily by a "normal person" from the street. On the other hand, installing a smartphone app is as easy as a click, and more and more people have old smartphones that they do not use any more.

So today there already exist solutions for secure offline storage of private keys on offline computers. On such an offline computer you are able to sign transactions created on a corresponding online computer. The transfer of the (un)signed transaction data back and forth between the two computers is typically done via USB stick. (examples: Armory or Electrum bitcoin clients, or the "S-Electrum" Linux user front-end for Electrum).


The problem that avoids mass-adoption of this scheme: People need to own an extra computer (the offline PC). This is an investment that most don't want to make (e.g. a Linux EeePC >= 200 USD). Also, such an extra EeePC needs some space in your flat (at least more space than a small smartphone), and you might be tempted to use that neat new netbook for other purposes than just "bitcoin-banking", which you shouldn't.

On the other hand, more and more people (me included) have old "worn-out" smartphones that they do not use any more, because too little memory, or too slow, or a scratched screen. So the solution is quite evident:

Use your OLD worn-out SMARTHPONE as OFFLINE STORAGE!

Idea: Create an open-source Android app (preferable compatible with OLD versions of Android down to version 1.6 or 2.0) that has the following features:

• Generate new private key(s) [by collecting random data from physical sensors, like mic/gyroscope/compass/camera/touch-screen input, or a combination thereof, compare how "TrueCrypt" is doing it when creating a new encrypted container!]
• Store the private keys encrypted (AES256) on this smartphone
• Display the (encrypted) private keys on screen (plain text or QR code) for backup purposes
• Export the encrypted(!) private keys to micro-SD card
• Import an (encrypted) private key (or many together) from reading a QR code, or from µSD-card (to restore the same instance on a second (old) smartphone)
• Export of the corresponding Bitcoin Addresses, to be used in a corresponding "online version" of this app (or another app) - via QR code or µSD card
• Ability to detect if this smartphone has ever gone online any time since the app was installed (I suspect there are some data from the Android/iOS system that can be queried to find this out). If yes show a BIG warning message to indicate to the users that this is not what he/she should have done and that the private keys could be compromised now. (see end of this posting for what the app should do in this case)

And then, of course these features:

• Import of an "unsigned" transaction, by reading a corresponding QR-code or via ASCII file from µSD-card
• Display the transaction details of the imported unsigned transaction on the screen
• Sign the unsigned transaction with the private keys (requires entering the passphrase to unlock the private key(s) [offline wallet]).
• Generate an ASCII string of the signed transaction and display it as QR code, or export to text file on µSD-card.

The import/export format of ASCII strings for the list of bitcoin addresses, the "unsigned" and the "signed" message should be STANDARDIZED, such that other apps (that are the online-counterpart only running the online wallet without the private keys) can interoperate with this app!
So this interface should be documented somewhere. An example is to use today's Electrum format as the standard, I don't know if Armory uses the same.

So furthermore, there must be a corresponding ONLINE-instance of a bitcoin client that is used by the user to administer his/her wallet, watch his/her current balance, administer his/her address book, and last but not least initiate unsigned transactions or send out signed transactions. Before sending out a signed transaction, the client should show the user in human readable format the details of the signed transaction that he/she is about to send out to the bitcoin network.

This online instance of the client could be for example...
- the same app, just running in "online-mode" instead of "offline mode",
- any other app that supports the standardized interface for exchange of (un)signed transactions and bitcoin addresses,
- an interface-compliant client on any personal computer.

I hope that such a project starts some time in the near future - this would make mass adoption of SECURE bitcoin usage possible, and make sure people make reasonable use of their OLD smartphones, and people won't have to bother about any malware on their online PCs stealing their bitcoins!



Note that after installing this app on the old smartphone, it should go offline FOREVER! Remove SIM card, delete the WLAN password (to avoid unintentionally going online) etc., and the app should push the user to do so by corresponding screen displays in a very naggy and paranoid way, and it should check as much as possible that the user has done so, e.g. check if the user has not yet deleted all WLAN passwords or has not yet removed the SIM card, the app shall reject creating or importing any private keys until this is the case! Also, when the app detects any time later (when everything has been set-up) that the user has again entered a WLAN passsword, entered a SIM card or has been online ANY time since (e.g. in Android the 2G/3G/WLAN data counters could be queried), the app should from this moment ALWAYS display a NAG SCREEN that tells the user that this app is not safe any more because the phone was online in the meantime.

If this happens, there could be a way that the app proposes the user to re-establish secure operation: It asks the user to go offline and delete all WLAN passwords etc., then to create NEW private key(s), and initiate a transaction that transfers all funds of the current (possibly compromised) private keys to the new generated address(es). Also it should ask the user to create a new passphrase for protecting the private key(s). This is a new special operation that requires an additional specific signed message to be transferred from the offline to the online client instance, such that the online client can then actually initiate this transfer as a new normal unsigned transaction (only the online client knows the current balance and can actually initiate the transaction). So this extra message also needs to be STANDARDIZED, as a signed message (signed by the old and NEW private key(s), and including the bitcoin address(es) of the new private key(s)) that acts as a "transaction creation request" from the offline PC (=old phone's app) towards the online PC.


PS: The offline-storage app I am talking about could ideally save the private keys in encrypted containers that can (optionally!) have hidden volumes. This would provide plausible deniability, like in TrueCrypt, i.e. if someone forces you to give the password to your offline keys, you disclose this "alibi password" for the outer volume containing only some keys with a fraction of your overall savings, while the hidden volume contains all your keys.

I did not find anything, but maybe someone thought this up already...

I always read everywhere: A 51% would kill bitcoin. Sure it would kill today's bitcoin protocol.

So I am wondering, what would happen then? Will all bitcoiner's just say "sorry" and go home? Will people accept their bitcoins are gone and switch to litecoin or "XYZcoin"?

No, there is too much market cap in bitcoin. So I think "some developers" will pull out a new client "bitcoin 2.0" that implements a new protocol (based on a new hashing algo incompatible with today's bitcoin ASICs, and maybe also adding some Proof of Stake component) but builds on the bitcoin 1.0 blockchain, adding a checkpoint to the last block before the attack.

This way, after some outage time, the bitcoin network, will be operational again, and all the bitcoin funds are safe. Only those users who have received BTC payments after the checkpoint (i.e. after the attack started) will have these bitcoins lost.

I hope that those "some developers" are the bitcoin core developers. I don't expect them to answer here, I just hope that they read this and have the "Plan B" already in the drawer, ready for launch if needed.

[DKB]

Hallo,

dieser Thread soll allen Usern, die bei bitcoin.de handeln und auf Sicherheit bedacht sind, eine Hilfestellung liefern.

Es geht um Folgendes: Bei bitcoin.de wird man ja als BTC-Verkäufer dazu aufgefordert, beim Geldeingang auf sein Konto genau zu überprüfen, ob das eingehende Geld auch wirklich vom Konto des Käufer kommt, so wie bei bitcoin.de angegeben.
Als Verkäufer sehe ich bei bitcoin.de ja, wer meine Bitcoins gekauft hat, und zwar sehe ich Name und Kontodaten des Käufers!
bitcoin.de sagt nun, diese Daten soll der Verkäufer beim Geldeingang auf genaue Übereinstimmung überprüfen, und erst danach den Geldeingang per Mausklick bestätigen und somit die Bitcoins freigeben.

Grund: Es hat wohl schon Betrugsfälle gegeben, bei denen ein betrügerischer Käufer per Überweisungsträger und falscher Unterschrift von einem ahnungslosen Dritten den Betrag überwiesen hat. Dieser hat oft erst nach Tagen oder Wochen die Überweisung storniert, woraufhin der BTC-Verkäufer den sicher geglaubten Geldeingang auch wieder storniert bekommen hat. Damit stand der Verkäufer dann ohne Geld und ohne Bitcoins da.

Darum also obige Empfehlung von bitcoin.de.

Das Problem ist nur: Bei sehr vielen Banken werden die Kontodaten des Überweisenden gar nicht angezeigt!! So kann ich als BTC-Verkäufer gar nicht erkennen, von welchem Konto eine Überweisung stammt und somit obiges Betrugsszenario auch nicht überprüfen.


Dieser Thread soll nun sammeln, welche Banken den Absender einer eingehenden Überweisung inklusive Bankdaten anzeigen, und welche nicht, oder nur teilweise, damit sich Benutzer ggf. ein neues (kostenloses) Girokonto besorgen können, um als Verkäufer besser abgesichert zu sein.

Ich fange einfach mal an, und ihr könnt dann nach der gleichen Vorlage euer Wissen ergänzen:


Bank: DKB
Absendername wird angezeigt: JA
Absender-Bankdaten werden angezeigt: Inland und SEPA JA (im normalen Online-Banking) *
Quelle: Eigene Erfahrung (Inland und SEPA)
* Nur Online! Auf den papierhaften Kontoauszügen "darf aus datenschutzrechtlichen Gründen weder die Kontonummer noch die Bankleitzahl erscheinen." (lt. Auskunft der DKB)


Bank: 1822direkt
Absendername wird angezeigt: JA
Absender-Bankdaten werden angezeigt: Inland JA; SEPA: "JA+NEIN" (s.u.)
Quelle: Auskunft der Bank
Info: Bei SEPA werden die Daten nicht angezeigt, werden aber auf Wunsch mitgeteilt


Bank: Commerzbank
Absendername wird angezeigt: JA
Absender-Bankdaten werden angezeigt: JA (beim HBCI-Banking, v.3.0.0)
Quelle: Auskunft der Bank


Bank: Sparda-BW
Absendername wird angezeigt: JA
Absender-Bankdaten werden angezeigt: NEIN (weder per Online-Banking, noch per HBCI-Interface mit Android-App "123Banking")
Quelle: Eigene Erfahrung


Bank: netbank AG
Absendername wird angezeigt: ?
Absender-Bankdaten werden angezeigt: NEIN (Zitat: "aufgrund des Bankgeheimnisses")
Quelle: Auskunft der Bank


Bank: norisbank
Absendername wird angezeigt: ?
Absender-Bankdaten werden angezeigt: NEIN (Zitat: "aufgrund des Bankgeheimnisses")
Quelle: Auskunft der Bank


--------

TEMPLATE für copy-paste:

Code:

Bank:  [b][color=redODERgreen]BANKNAME[/color][/b]
Absendername wird angezeigt: JANEIN
Absender-Bankdaten werden angezeigt: Inland [b]JANEIN[/b]; SEPA: [b]JANEIN[/b]
Quelle: xxxxxxxx

[UPDATE: https://dl.dropboxusercontent.com/u/18219492/Bitcoin/S-Electrum_v1.3b.zip.zip]

I know that current version of Electrum (1.7.3) supports offline transactions already, which is very good.

But anyway, I have (apparently in parallel) created a collection of Linux bash scripts that provide a very comfortable and fairly noob-proof front-end to do offline transactions on a pair of offline & online PC (& a USB stick of course).

You can download my PGP-signed file at https://dl.dropboxusercontent.com/u/18219492/Bitcoin/S-Electrum_v1.0.zip.zip
UPDATE: https://dl.dropboxusercontent.com/u/18219492/Bitcoin/S-Electrum_v1.3b.zip.zip
(recommended to be used with Electrum 1.7.2 or 1.7.4, as of today, 17 May 2013)

After having installed Electrum and having extracted all files of that zip container to a folder of your choice, you just need to call
   ./selectrum.sh
in a terminal window. That's all. (whatever you want to do, you never ever need to call any other script than "./selectrum.sh")

The user will be guided through all steps, be it the

• initial steps of selection of whether this is your online or offline PC, the creation of the offline wallet, the deseeding of the offline wallet and saving to USB stick, the import of the deseeded wallet on the online PC, or
• the later regular steps of initiating (online), signing (offline) and sending (online) the transaction to the network, incl. facilitated/automated read/write operations to/from the USB stick.

Everything is kept as fool-proof and comfortable as possible - despite this being a script running on the console.

I am using it now myself (a new EeePC is my dedicated Offline PC...) and find it very comfortable, so I wanted to share it with the community. Personally, I find it more comfortable than the Electrum GUI's built-in function for offline transactions, because you cannot really do anything wrong if you use it.

The script will know if this is your online or offline PC, it will show you only that menu options that are applicable in the given situation, it remembers the mounting point of your USB stick from last time and reads/writes there by default using default file names instead of querying the user where to load/save transaction files, it has many consistency checks, etc. So overall, there is less clicking, because e.g. it reads and writes from/to USB stick automatically, using default file names.


Some "screenshots", so you get an idea...:

When you start ./selectrum.sh the VERY first time on your respective PC, you'll see this:

Code:

=====================================================================
*********************************************************************
                  Secure Electrum BTC Transactions              v.1.3
                  --- MAIN MENU -- USER WIZARD ---
*********************************************************************
=====================================================================
Do you want to use this computer as your
  1- (OFF)LINE PC (i.e. a special PC just used for "bitcoin banking"), or
  2- (ON)LINE PC (e.g. your 'normal' PC)

Press <Enter> to continue...

Later, the "Main menu" of your offline PC e.g. will look like this:

Code:

=====================================================================
*********************************************************************
                  Secure Electrum BTC Transactions              v.1.3
                  --- MAIN MENU -- USER WIZARD ---
*********************************************************************
=====================================================================
                     OFFLINE Computer Main Menu
=====================================================================
Please make your choice:

   (2) Sign transaction(s) created on your Online PC


   (i) Import private key(s) to your offline wallet
       (single key or bulk import of many keys from a text file)

   (d) Make a de-seeded wallet file from your fully seeded offline
       wallet and save it to internal disk or USB stick
       (to be imported afterwards to your Online PC)
       Note: You have to do this only once, or after further key import


   (G) Start the Electrum GUI to view your wallet's addresses


   (Q) Quit

Your choice?

Hope this is useful for some of you.

[UPDATE]

I have written a 12-pages whitepaper with best practice examples on how Bitcoin related web services
holding user funds can implement a mechanism by which they can prove that they are not running
a fractional reserve system.

I am curious to see when the first service will implement this.

http://de.scribd.com/doc/137653644/Bitcoin-prove-not-fractional-v01-pdf
https://dl.dropboxusercontent.com/u/18219492/Bitcoin/Bitcoin_prove_not_fractional_v01.zip (incl. PGP-signature)

UPDATE: version 0.2b:
http://de.scribd.com/doc/143811117/Bitcoin-prove-not-fractional-v02b-pdf
https://dl.dropboxusercontent.com/u/18219492/Bitcoin/Bitcoin_prove_not_fractional_v02b.zip (incl. PGP-signature)


Abstract

Many Bitcoin related web services, like Bitcoin exchanges, online wallets and many others, allow
their users to open accounts and store Bitcoins with them. The question arises whether these web
services always have liquidity over all the funds that users have deposited, or whether they have
withdrawn (i.e. embezzled) some user funds for other purposes like investment, speculation or
straight fraud.

Such unauthorized withdrawal of a certain percentage of the user funds would remain undiscovered
as long as the users keep their funds with the web service. However, as soon as users start to
withdraw their funds at large scale, the fraud would become evident.

This paper suggests a mechanism by which a Bitcoin-based web service can publicly prove at
regular intervals that it is still in possession of all user funds (=Bitcoins) - a monthly interval is
recommended. Also between these "publication times" the web service can show in a plausible
manner that it does not lend/share its funds to/with other web services.

Thereby, such web services can create substantial trust and credibility with their clients and get a
significant competitive advantage over similar web services that do not implement this mechanism.

In the long run it is desired that the outlined mechanism becomes a quasi-standard amongst all
reputable Bitcoin web service providers that hold user accounts with Bitcoin funds.

[1 millibitcent = 0.00001 BTC]

I read in different sources different definitions of the term "millibitcent":

I found definitions of 0.01 BTC, 0.0001 BTC or 0.00000001 as a "millibitcent". There seems to be no consent about the definition of this term.

How is this possible?
When I take the term literally, the only possible definition of "millibitcent" can be
1/1000th ("milli") of 1/100th ("cent") of a bitcoin, i.e. 1 millibitcent = 0.00001 BTC = 1000 Satoshis.

1 bitcent = 0.01 BTC
1 millibitcoin = 1/1000 BTC = 0.001 BTC

Hence
1 millibitcent = 0.00001 BTC

Because
1 something-cent = 1/100 of something
1 milli-something = 1/1000 of something

[[update: Ooops, I found the link, it is "https://www.bitcoin.de/en/faq" - I missed this small link at the bottom of the page...]]

I could not find any information on the homepage of bitcoin.de. I found the registration field, but before I am registering I would like to know what I am registering for.

Does anyone know how bitcoin.de works?

In particular, I have the following questions:

• Is it necessary to diclose the true identity for participating?
• Does the Buying/Selling work like MtGox (i.e. I have to pay in some Euros before being able to start), or rather like BitMarket.eu (i.e. I transfer the Euros directly to the person I am buying the Bitcoins from)?
• In the latter case: How do I know the other is a trustworthy trader?
• Are limit orders possible for buy/sell orders? Do such limit orders expire?
• Any fees for buying/selling BTSs?
• Any fees for placing orders?
• Any Fees for transferring EUR to bitcoin.de?
• Any Fees for withdrawing EUROs from bitcoin.de?
• Any Fees for transferring BTCs to bitcoin.de?
• Any Fees for withdrawing BTCs from bitcoin.de?
• Any Fees other fees?

Any URL that describes this?

Thanks for any hints.
Michael

[update: Ooops, I found the link, it is "https://www.bitcoin.de/en/faq" - I missed this small link at the bottom of the page...]

Hi,

I have an idea about how a reference field could be added to Bitcoin transfers very neatly and comfortably from the end-user perspective.
Today the usage of reference fields in bank wire transfers is quite useful to link small messages to a money transfer.
I am missing this with Bitcoin.

My Idea now is to do something on top, WITHOUT changing the Bitcoin protocol, that serves exactly this purpose! It would work like this:

Idea:

• Every Bitcoin transfer has a source A and destination B address, a time stamp, and maybe some further unique identifier (I do not know the BTC protocol in detail, other people here in the forum know better and they will understand what I mean)
• Now, after having filled my target address B and amount of BTC in the "send" field of my client software, I am able to compose a message (=free text, like an SMS) and the client will encrypt this message with the public key of B (i.e. with the destination address) in the way that normally emails are encrypted with PGP public key mechanisms.
• After pressing "send", the bitcoin client SW is uploading this encrypted message to a central "Bitcoin-Transfer-SMS" Server (in the sequel called "SMS-server" for brevity).
• Of course, the functions of the two bullets above should be incorporated in the Bitcoin client SW, eventually, for the user's convenience
• And of course, the bitcoin client SW can be configured with more than just one such "Bitcoin-Transfer-SMS"-Server, because we do not want a monopoly of course. Maybe there will be 3 or 4 or 5 such big service providers eventually, and many more (10? 20? 30?) in the beginning
• They all use the same protocol, such that the Bitcoin client SW just needs to be configured with the URL of the server (somebody should write an RFC or something for this protocol - or open source SW stack for this protocol...)
• When I compose this message and make my upload of my public-key-encrypted SMS to this server, I do not even need a login to that server, no password, no registration! Instead, I will transfer a tiny fee to that server's BTC address, and for this the server will do the service for me, i.e. to store the message for some time (e.g. 2 years) in its publically retrievable database.
  How does the server know that the fee is dedicated to this transfer from A to B? Simple! in the background, the client SW just composes another message (SMS) in the same format that is associated to my transfer of the fee to the service provider's BTC address. The content of that message is simply the unique ID of the transaction from A to B, so the SMS-service provider knows where this belongs to.
• The client SW of the recipient B will receive the Bitcoins, and will query the SMS-server(s) to check if a SMS is associated with this transfer. If yes, this client SW can read the message because it possesses the suitable private key for "B" (otherwise it could not receive the money in the first place), and it can display the message neatly in the client's GUI, so all this runs transparently in the background for the end-user.
• Additional idea: To lower the burden (load) of the SMS-servers that they would experience if every client checked every server for every BTC transfer that it receives, there could be an "SMS-server flag" incorporated in the amount of BTCs that are sent, in the least significant bit. Idea: The transfer from A to B is 1.00 BTC, plus e.g. 0.005 BTC for the miners, PLUS 0.00000something BTC additional fee (that would also go to the miners), where "something" in the simplest embodiment of this idea is simple the LSB set to ==1. This would tell the receiving client that this BTC transfer has an associated SMS at one of the SMS servers, and the client would query them. This would significantly reduce the load to the SMS servers, because probably still the majority of BTC transfers will not have any "reference field" (SMS) populated.
  If this LSB is ==0, then the receiving client knows that an associated SMS-message does not exist for this transfer, and it will not query any of the SMS-servers.
  [In a more complex embodyment, we could use e.g. the 5 LSBs to also specify WHICH SMS server was used (or group of SMS servers if number of SMS servers globally active is >32)....just an idea]
  
• ---
• From the end-user perspective, the client's GUI has the following fields:
  * Amount of BTC to send (like today already)
  * Destination address (like today already)
  * Optional fee to the miners (like today already[?])
  * New: Text field for the reference field (SMS), use of this field is optional for the user
  * New: An additional info-field that indicates the extra fee that goes to the SMS server - could also be dependent on the length of the text (like SMS) - depends on the policy of the chosen SMS-server
  * New: A pull-down list to choose the SMS-server (unless this is configured in the "settings" part of the bitcoin client)
  * ---
  * At the receiving side, the end-user will see the incoming transfer, and associated with it another new field with text, that says either "<empty>" (greyed out), or it say "retrieving reference text..." (if the BTC payment amount (LSBs) indicated that an associated msg exists), or it displays the reference text (if the client succeeded in retrieving the SMS text), all this automatically in the background from user perspective
  

I do not think and do not expect that such services will develop soon and that such feature goes into the official BTC client soon - first more important issues especially around security (wallet.dat encryption/export/sync with cloud/FTP, or split of wallet and client etc.) and maybe also around general usability are on the agenda I think. But I wanted to share with you that such feature could eventually be incorporated one day.
Michael

[Friday August 5th 2011]

Hello,

I want to add EUR funds to my MtGox account, but a strange and obsolete message appears:

Euro deposits are currently offline until Friday August 5th 2011 in worst case. The bank account should have been opened on Tueday July 19th, however the new bank needs approval from higher up due to the large amount of funds, and the nature of the business. They said they would have an answer by Thursday, which should allow them to open the bank account Friday, however if they don't make it, the next business day will be the next Tuesday (they are closed on monday).

tl;dr: A new EUR bank account will be announced on Friday August 5th 2011 in worst case.

If you have an urgent need of depositing funds, it is possible through our GBP account, for a 2% exchange fee.
Bank details:
Account Owner: TIBANNE LIMITED
Bank Name: BARCLAYS
[...]

Today is the 11th of August, so the message is obsolete since a week. Seems that everyone at Mt.Gox is in summer vacation...

Do you know if fee-less SEPA Euro Bank Transfers are possible at the moment?

Hello together,

I have made up my mind on how to set up a really secure environment for the Bitcoin client, such that the private keys (wallet.dat) are always safe, under all conceivable scenarios of attack.

As a result, I make three concrete best-practice proposals on how to setup such systems. They all have in common that they are based on 100% open source Linux systems, and the boot medium is a Live CD (preferably), or a USB stick having no contact to another potentially insecure operating system running on the same computer.

The full concept is put together in a 23 pages PDF file that explains all the details and shows illustrations by screenshots and block diagrams.

I hope that many people here in this forum find the time to read it - hopefully it will help making the Bitcoin users more aware of potential threads, and the Bitcoin world a little safer.

The download can be found here:
http://www.woofiles.com/dl-253068-gCx93FSj-BitcoinSafeUsagev02.zip (Update: Link does not seem to work)
http://www.filedropper.com/bitcoinsafeusagev02 (Update: This Link should work)
http://www.scribd.com/doc/59238311/Bitcoin-Safe-Usage-v02 (Update: This Link should work)
--> updated version 0.3:
 http://www.filedropper.com/bitcoinsafeusagev03 (zip file with PDF and PGP signature)
 http://www.scribd.com/doc/59249642/Bitcoin-Safe-Usage-v03 (PDF only)
--> Updated version 0.4:
   PDF:  http://www.scribd.com/doc/59318844/Bitcoin-Safe-Usage-v04
   ZIP (PDF&SIG):  http://www.filedropper.com/bitcoinsafeusagev04_1


Abstract/Overview:
A Practical (and Paranoid) Guide: Setting up a Secure System for the Bitcoin Client
- keep your private keys (wallet.dat) secure – and do not loose them -

Version 0.2 (July 2011) by Michael_S (forum.bitcoin.org), OpenPGP KeyID=0xCC7E7C99, Bitcoin donations to 14ajM1BHY7E8GJ4DGGvtFFGmE15hSSSRJR

This Guide shows how to set up a practically 100% secure computer system for the Bitcoin client.
Three concrete examples with a detailed step-by-step guide make the topic very tangible. At the core of each of these three examples is a 100% open source GNU Linux system that is booted from a Live CD or a USB stick.

[0.3.21]

Whereas the bitcoin client up to "bitcoin-0.3.21-linux" works fine, there is a problem with "bitcoin-0.3.22-linux" and  and version 0.3.23:

It produces the following error message in many Linux systems (including mine):

Code:

./bitcoin: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./bitcoin)
./bitcoin: /lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)

Systems that are affected by the error include (list would be much longer, but I haven't tried out any more...):

• Ubuntu 8.04 LTS: A system still under support
• Knoppix 5.3.1 or 5.1.1: The most recent Knoppix that still supports the combination of LiveCD and knoppix.img file for saving changes system information persistently (also 256 bit AES encrypted img file supported) - Knoppix 6 does not support this any more
• Slax Linux 6.1.2: The latest version of this really small (200 MByte) but still good and fast GNU-Linux Distribution, which has similar capabilities in terms of persistent info storage as Knoppix 5, although w/o encryption.
• Damn Small Linux 4.4.10: Most recent version of this 50 MByte Linux Distro
• gNewSense 2.3: Another ubuntu-based GNU-linux Distro
• Puppy Linux 5.2.5: Another small (30 MByte) GNU Linux Distro

Systems that do work with bitcoin 0.3.22/23 include:

• Knoppix 6.4.4 (it lacks the encryption and persistent image feature for Live CDs that Knoppix 5 posseses)
• OpenSuse 11.4
• CrunchBang Linux 10-20110207

Therefore, my proposal and request to the developers/builders would be to use another system for creating the binaries, to improve compatibility, unless there is a good reason why this is not possible. Or to distribute two sets of binaries for Linux, e.g. something like "bitcoin-0.3.23-linux_older_distros.tar.gz" and "bitcoin-0.3.23-linux_recent_distros.tar.gz".