|
v1.1.9 pushed to github, testnet and beta users.
features (compared to 1.1.6)
*) new feature: message signing
*) Hebrew, French, Korean translation
*) canonical S-values in signatures.
*) improved handing of exchange rates
*) remove Mtgox
*) added Kraken, Bitpay, Coinbase
*) new high-res launcher icons
homepage mycelium.com will follow soon.
now it is possible to test prodnet message signing. please test how you could or could not verify signed messages from mycelium
|
|
|
|
I seriously can see withdrawals coming back Monday, would be typical Gox Style. Funniest will be when they act like nothing ever happened. We shut down withdrawals for a week? so what? No harm done, ohh wait you got scared and sold you life's saving for pennies on the dollar... ohh sorry?
this would be typical for gox.. this fits so well. oh well, we created a massive arbitrage between our exchange and the rest? oh, too bad you couln't profit, because we are too slow to verify you.. rest assured our frontrunning team handled the situation professionally. |
|
|
|
|
how far are you in the prototyping process? do you have a shipping estimation?
|
|
|
|
|
i'd really like to know more since i am preparing a talk on this general topic. the video is now set to "private" on youtube.
|
|
|
|
|
viel spass euch. das wäre was für mich, habe aber erst bei der insidebitcoins davon erfahren. nächstes mal macht sowas direkt im anschluss an eine konferenz, dann lässt sich das super verbinden.
freue mich schon darauf, von spannenden projekten zu erfahren.
lg
|
|
|
|
"Lets talk bitcoin" said this was already active but I can not find the “Transaction Confidence” graph and no update in google play app?
no it is not active yet. we will publish testnet versions soon™ |
|
|
|
When the user of the Android Wallet wants to do a backup he has to give a password otherwise the application won't do the backup. Should the application really force the user to give a password? I mean one of the biggest security risks when it comes to losing bitcoins is in my opinion forgotten passwords. Why not make it optional.
Yes, forgotten passwords are a risk. However, if you backup without or with a weak password, its extremely easy to leak your private keys. Backups need to be stored on public storage (the SD card aka "external memory"), otherwise you would not be able to move them to a safe place (off the device). Thus, any app can read your backup. In future, you will be able to encrypt your wallet. This means you'll need to enter your password each time you want to sign a transaction. Thus will hopefully help to remember your password. you can share custom URIs that your app provides to specific apps that can consume those files. (think google drive, email, etc) this is not perfect but it is better than requiring SD card storage (which google wants to remove anyways for usability reasons) |
|
|
|
|
(deliberately ignoring the hairsplitting between currency/money here)
money emerges if there is no backing. the fact that it is considered valuable without backing MAKES it money.
only very few assets have achieved this in the past. silver, gold, fiat paper money, bitcoin. are about the only things that come to mind.
|
|
|
|
|
apparently it was / is possible to have short positions / leveraged longs on MT4 and bitfinex.
the plausible explanation is that a bunch of long positions were forcefully liquidated during a margin call. this caused ridiculous market orders to be executed.
additionally, the total market depth on those two platforms is not spectacular, so "only" about 8000 coins were needed for these two spikes.
this in itself was not "criminal" - this is the risk of leveraged trading. what was problematic was that the platforms went down, with people trapped in their positions unable to trade. this should trigger an investigation by a business consortium or a government agency.. but since this is Bitcoin, nothing will happen.
|
|
|
|
|
looks like you didn't get the memo about mtgox...
|
|
|
|
|
I implemented message signing for mycelium. It is very very likely that it is part of the next feature release.
We also use signing for other stuff internally
|
|
|
|
Bump. Would like to hear opinions on bloom filter.
The Mycelium Wallet on Android already uses scrypt for its password-protected backups, and for BIP38. On very old devices we have trouble running this, so we will have to introduce a "weaker" version for devices with < 20MB per process. For a future standard for HD wallet, non-hardcoded scrypt parameters would be preferable, depending on password length and device speed and usage frequency, and usecases (offline device) the desired parameters could be different. I like scrypt, though. If it turns out that scrypt is broken, there should be a V2 of this spec, with a new hashing algo, or the ability to specify the KDF algo. Some comments on what i have read so far: 1) direct encoding of scrypt parameters would be preferable as direct values as opposed to versioned parameter lists (up& downwards compatible) 2) The generation date is not really that important. Maybe other wallets need it but out software would ignore it with the current scheme, but i see how it potentially speeds up initial syncing for a fresh backup. but thinking long-term it will not help much, since the time between backup and restore will always increase. 3) If the KDF is offloadable, make sure that the "non-offloadable" part does not strictly require a scrypt implementation, so that it may run on devices with very limited resources. (think future revisions of embedded devices) 4) We absolutely want the checksum with bloom filtering in future, so that the user may specify additional passwords/pins for multiple identities. Our non-trivial job will be to design a wallet format that preserves the deniability with the stored metadata. again, the chosen parameters should not be hard-coded, but i can imagine that default values like 4 bytes with 6 hash functions (optimum for N=4, p=0.02) would make sense. the question is, do we want to push the plausible deniability so far, as to obfuscate the fact how many additional passwords possibly exists? if so, we would hit a limit after adding 4 passwords, 5) what i do not fully understand, is how bloom filtering impacts the preH entropy. can you elaborate on this? |
|
|
|
|
just wanted to tell you - it does not scan with my apps. running Nexus 5/ ZXing Barcode scanner scanning from big computer screen.
|
|
|
|
Question: I have an app that allows users to buy things from my store, how can i interface with Mycelium for payments? Is there an API or something?
First, please test this using our testnet builds.of course,there you must use testnet addresses. https://play.google.com/store/apps/details?id=com.mycelium.testnetwalletthe code samples were written without running them once  - so there might be an error The most straightforward way to do it, is create a bitcoin uri. see https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki for example bitcoin:15f3mXNSY1oBnhaZDb7ifEYJvfg62XTtYe?amount=0.12345678(we currently ignore label and message, this is a planned feature) next, you send out a URI intent String uri = "bitcoin:15f3mXNSY1oBnhaZDb7ifEYJvfg62XTtYe?amount=0.12345678";
Intent intent = new Intent(Intent.ACTION_VIEW, Uri.parse(bitcoinuri));
this.startActivityForResult(intent,SOME_RESULT_CODE);
after a successful transaction you can check the transaction id in onActivityResult String transaction = data.getStringExtra("transaction_hash");i just wrote a full sample for you ready to copy-paste. also, note that the same code should work with any decent android wallet, it is not mycelium-specific (note: this should go into the FAQ) import android.app.Activity;
import android.content.Intent;
import android.net.Uri;
import android.os.Bundle;
import android.view.View;
import android.widget.Button;
import android.widget.Toast;
public class SimpleBitcoinIntegration extends Activity {
private static final int MY_RESULT_CODE = 2;
@Override
protected void onCreate(Bundle savedInstanceState) {
//todo create UI as usual
Button button = (Button) findViewById(R.id.btSend);
button.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
String bitcoinuri = "bitcoin:15f3mXNSY1oBnhaZDb7ifEYJvfg62XTtYe?amount=0.12345678";
Intent intent = new Intent(Intent.ACTION_VIEW, Uri.parse(bitcoinuri));
startActivityForResult(intent, MY_RESULT_CODE);
}
});
}
@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
if ((requestCode == MY_RESULT_CODE) && (resultCode == RESULT_OK)) {
String transaction = data.getStringExtra("transaction_hash");
Toast.makeText(this, "received bitcoins with txid: " + transaction, Toast.LENGTH_LONG).show();
} else {
//something else happened..
}
}
}
|
|
|
|
I personally wouldn't expect it anytime soon if at all. now to derail the tread: this remindet me to check up on http://www.bitcoincard.org. Is the mycelium bitcoincard officially dead? No. I am sitting right in front of the desk with the latest prototypes. We are working furiously on delivering the hardware, we are just not taking preorders when we don't KNOW when we are going to deliver. |
|
|
|
Hi!
First, congratulations to Mycelium devs! It's really a nice piece of software.
This post just to let you know of a minor kind of issue, in case it wasn't already known (I skimmed briefly the thread, but I may have missed it).
I noticed a big slow down showing the details of a transaction that I just got, to the point that Android asked if I wanted to terminate the app. Never happened before. Turn out it was a payment from a mining pool, and to tone down the fees it had a big amount of outputs (about 2500 or so). The entire transaction size was about 100KB.
So, surely an unusual situation and not really a problem. Maybe if a transaction is especially big / compex, Mycellium could just show up a brief summary and point to Blockchain.info, or something like that.
can you give me the Txid? or the address that you watched? what we can do is reduce the amount of data shown that is interesting (for example only show the watched address and add +2500 extra addresses) for example, we show payouts of eligius mining pool in a nice way, where you only see your own info. with further effort it is possible to write "endedless lists" in android where you have to scroll huge amounts. |
|
|
|
Hi, newbie mycelium question: I have two identical, ultra cheap chinese phones running 4.X. Factory reset, no sim and wifi turned off. Only added app is mycelium. I want to use them as (identical) dedicated offline cold storage devices and send one to my brother as backup. I'm just running tests at the moment.
When I start mycelium up, I have the option to backup and export/share my private key as an encrypted PDF. But if I don't want to go online, how can I get that PDF from the phone to a printer? I would prefer to save the PDF directly to the SD card (after writing down the password) and then take the SD card to my laptop and print the PDF. And then import the key into the second phone. Is that possible? I only see online options for sharing. I don't really want to expose the private key and take a photo.
Sorry if I've missed this in another discussion. Note that I'm also in china right now with no vpn so I can't watch the instruction videos on youtube.
we will be adding features to support this. meanwhile, you can - either install a "share to sd card" app
- or take a photo of the private key using a plain old digicam.
- or create a private key using any other means offline and scan it.
|
|
|
|
|
Show Posts
