text:
colored coin possible with ring signatures and stealth addresses?
It is understood that colored coin is possible with stealth addresses, but what about ring signatures such as how they are used in the cryptonote protocol (Monero, Bytecoin)?
I feel like coloring the destination would undermine the obfuscation of the stealth ring

There are several ways ring signatures could be used in a cryptocurrency. Can you be more specific about what you have in mind, or give a reference?

How they are used in the cryptonote protocol, @NateEldredge

Based on my understanding of Cryptonote's ring signature implementation, no, it cannot be used with colored coins.
With Bitcoin, there is a one-to-one correspondence between inputs and outputs of transactions.  Suppose there is a transaction X with an output X1 that sends 1 satoshi to Alice's address A, and everyone agrees that output X1 is colored so that it grants title to Alice's 1977 Chevy Nova.  If Alice decides to give the car to Bob, she creates a new transaction Y, with an input pointing to X1, and whose sole output Y1 sends 1 satoshi to Bob's address B.  Now Bob can prove, by creating a signature corresponding to his address B, that he is the rightful owner of the car.  If Mallory tries to claim the car by creating a different transaction with input X1, he will be found out, because he can't sign that transaction with Alice's private key, so it won't verify.  If Alice tries to give the car to someone else by creating a second properly signed transaction Z with input X1, it will be detected as a double spend because another transaction spending X1 precedes it in the block chain.
With ring signatures, this correspondence is broken.  When creating a transaction, in addition to the one output (of a previous transaction) that you really want to spend, you can list many others.  You create a signature that proves that you are authorized to spend one of the outputs you listed, but doesn't give any information about which one it was.  However, a linking algorithm ensures that any future attempt to spend that output again will be noticed and rejected.
In the above scenario, if Alice uses a ring signature on her transaction Y, including not only X1 but another output Z1, then her signature will not prove that she is entitled to spend X1 (and therefore is the rightful owner of the car and can give it away); it only proves that she is entitled to either X1 or Z1.
Furthermore, Mallory could create a transaction M that includes X1 and another output K1 that he is entitled to spend.  Since he has the private key corresponding to K1, he can properly sign the transaction M, but it won't be clear whether it is spending X1 (which would convey title to the car) or K1 (which won't).
Now, ring signatures are an optional feature in Cryptonote.  If you want, you can create a transaction with only a single input, which will make it unambiguous which previous output you are spending.  To avoid confusion such as Mallory's transaction above, a colored coin protocol for Cryptonote would probably specify that to convey title, you have to use a transaction with a single input; then Mallory's multiple-input transaction above would still be a legal Cryptonote transaction, but the community would agree it doesn't grant him title to the car.
In short, the whole point of colored coins is to create an unbroken chain of transactions that traces the title of the car, and the whole point of ring signatures is to avoid creating such a chain.  So if you want colored coins, you have to avoid using ring signatures in this way.

your second to last paragraph seems to contradict your topic sentence in some way, like perhaps the community could have a namespace that doesn't use ring signatures, perhaps segregated from the rest of the protocol via proof of burn? (although I extremely dislike intermediary coins)

I'm not sure what you mean. In order to use colored coins in a currency that has ring signatures, colored transactions would have to use just one input (one public key), even though ring signatures allow you to use as many as you want. That effectively reduces the ring signature to an ordinary signature. But there would be no need to "segregate" the colored coins.

I am thinking that a colored coin software package would just always tailor transactions this way.


text:
Have there been case studies of how anonymous bitcoins are?
The blockchain has a lot of information about all bitcoin transactions.
I've heard a lot of conjecture about how anonymous bitcoins transactions are, but I haven't seen a scientific study.
Are there any case studies that show how to track a bitcoin transaction to an individual person? I see IP addresses on blockchain.info so that information could be subpoenaed; on the other hand, you could use Tor which also has its documented weaknesses.

http://anonymity-in-bitcoin.blogspot.com/2011/07/bitcoin-is-not-anonymous.html

Yes, the most notable one being this one. It illustrates that it is possible to associate transactions and addresses with forum users' identities, as well as connecting them to some organizations (including WikiLeaks, MyBitcoin, Slush's Pool etc).
Tracking users by their IP is a bit harder, although during the work on my master thesis I was able to find an IP address associated with a Bitcoin Address and trace it correctly to the Bitcoin Faucet.

thanks for these resources, your master thesis was intriguing. I have previously read about how to disrupt a TOR network, and just imagining doing that to trace the owner of bitcoins made me think I should write a Tom Clancy novel spinoff instead!

Another interesting point of views, by Dorit Ron and Prof Adi Shamir (- The S from the RSA algorithm) :
https://eprint.iacr.org/2012/584.pdf
From the abstract: "...We downloaded the full history of this scheme, and analyzed many statistical properties of its associated transaction graph. In this paper we answer for the first time a variety of interesting questions about the typical behavior of users, how they acquire and how they spend their bitcoins, the balance of bitcoins they keep in their
accounts, and how they move bitcoins between their various accounts in order to better protect their privacy. In addition, we isolated all the large transactions in the system, and discovered that almost all of them are closely related to a single large transaction that took place in November 2010, even though the associated users apparently tried to hide this fact with many strange looking long chains and fork-merge structures in the transaction graph."

thanks, although this no longer concerns me, there are more sophisticated solutions to bitcoin's pseudonomy

Hi slouis! You can improve the answer by adding some more information about what the paper says. It's better if people can get at least a basic idea without having to follow the link.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
multiple parties to sign a transaction before being broadcast (or after, but either way be associated with)
Lets say someone was writing a transaction solely to denote the existence of something, or a timestamp, or writing something in OP_RETURN
Could that transaction be signed by other addresses, kind of as a "I agree with this statement" way, or a way that future analysis of that transaction showed that particular parties agreed with the transaction
(I'm imagining something that does not require the sender to have a multisignature address created with other parties. Or some way of having multiple outputs from different parties going to one input)
For example, Tom requested the location of Atlantis, many parties are watching these requests on the blockchain and can collaborate on the answer. Eventually Tom received a transaction containing the location in the OP_RETURN and it came from NOAA. Tom doesn't trust NOAA's use of GPS and much prefers GLONASS, so this transaction was also 'signed' or endorsed in some way by the Hydrometeorological Center of Russia. "Wow both agencies agree on this, I'm convinced now"

You could do something along those lines:

Create a transaction to a multisig address with private keys that the different parties control.
The parties sign a transaction having for input that multisig (which shows they agreed and signed) and for output the OP_RETURN.

interesting, but they would need to also reply to Tom in the proposed scenario, so then two outputs would be necessary? (I thought OP_RETURN can be extra data in an otherwise normal financial transaction between two parties)

(in theory Tom could also listen for a reply, where Tom's question had 1 hash associated with it and the signed reply had the same hash)

A problem with this solution is that the two institutions have no way of knowing they would both want to create a multisig address. But if they were listening to the question, they could both reply separately and the requestor could aggregate responses. Still a bit different from what I had in mind

Been brainstorming this still: How about the initial institution makes their message in the OP_RETURN and the outputs include the addresses of other institutions that should also be able to answer/confirm the message. Then those institutions would be notified that either their presence is requested.

..... OR maybe Tom makes an output that notifies all those institutions, such as by referencing the OneName.io namespace on Namecoin, somehow. OR the first institution's response does that... ah, so many possibilities with so little understanding of how non-financial transactions can be formed

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
following coins between blockchains
Question: is it possible to further obfuscate ownership/origin of bitcoins by trading it for another cryptocurrency at an exchange? (as it is easier to do this for large amounts than it is with cash)
Lets start with 10000 bitcoins. The point here is to make the size a large and conspicuous one.
You have 10000 bitcoin that you would like to obfuscate the origin of. Right now those 10000 bitcoins are at an address you control. The object here is to move around that value between addresses.
Just sending them to another address would have a record of all the addresses they were sent to.
Sending them to an exchange and back would still have the record as well as the exchange's records.
Even breaking it up into smaller transactions just makes it more tedious to follow the pieces but it is all still easily browsable using existing services.
But what if they were traded for another cryptocurrency at an exchange?
This gives you the initial transfer to the exchange, everyone and the exchange can see that. But then they are exchanged, probably nominally, on the exchange for a different crpytocurrency. A completely different blockchain. For someone doing an analysis on the trail of these coins, how would they be able to account for switching blockchains? Would it even be possible at all?
Going to a different blockchain, and even then going back to the bitcoin blockchain at a different address seems like an impossible thing to follow.
Is there a way to follow coins exchanged between blockchains? Is there a way to know that the owner of the 10,000 bitcoins exchanged them? since on the bitcoin blockchain, it will all have happened on the exchange and the coins will simply look like they have been broken up between addresses, but you wouldn't know that the original owner is no longer holding those coins at all.

Sorry but there's no difference between your examples of an exchange giving you different bitcoins on the same blockchain, and an exchange giving you different currency on a different blockchain, they're both equally as traceable.

okay @jgm so why was this question downvoted?

Possibly because the actual question was buried way down in the text, and/or this is a specific question that isn't likely to be useful to others long-term.

I think there is a valid question in here. One of the possible means of discovering ownership of bitcoins is by blockchain analysis. The question here is asking if moving bitcoins into another alt-coin and then back to bitcoins does this prevent the "follow-the-coins" type blockchain analysis. My guess is that it would make tracking the ownership of the coins harder but I don't know enough about the various alt-coins and exchanges to know if it's possible to move in and out of the alt-coins and be sure of anonymity.

If you want to hold bitcoins anonymously then the only thing you can easily do is a cash transaction.  In the good old days you could just have mined some, but that's not an option available to most people today.
To answer the specific question, the exchange will have records of the receiving and sending transactions, so if you consider them to be compromised then there is no additional security available in using an exchange regardless of if you are moving currency within a blockchain or  between blockchains.


text:
Is the otherwise promising Ripple set to become a great currency fraud?
The Ripple system is really interesting, but on one point I can't help thinking part of it is a great scheme to make the founders (and OpenCoin) ridiculously rich. The reason that makes me wonder is that 100 billion XRP were initially created, and of these 20 billion are kept by the founders and 80 billion were given to OpenCoin (from their wiki). OpenCoin plans to give away some XRP, and sell some XRP, but it's not clear in what proportions or how much. No new XRP will ever be created, and the value of XRP will increase gradually as more people demand it for transactions (and XRP is the native currency of Ripple and will be the most convenient transaction medium inside Ripple). XRP also have intrinsic value in that they are strictly necessary to perform transactions, and because XRP used for transactions are destroyed the total amount of XRP in the system will decrease steadily.
So we have a system where the founders and OpenCoin have control over almost all purchasing power. Moreover, because of this, they can keep exchange rates of XRP as high as they like by keeping supply low. If Ripple would take off and be widely adopted, the founders and OpenCoin would get unimaginably rich because of the big shares in the fiat currency they created.
It makes me think of the famous quote: "Give me control over a nation's currency and I care not who makes its laws." It doesn't apply in full because the founders and OpenCoin won't create more currency, but owning all currency from the beginning will have the same effect over the foreseeable future.
So is this nothing more than a smart fraud that's incredibly big in scope? Are there any indications that the supply of XRP will get some kind of fair distribution?

Hi 5th and welcome! I believe that this question is better suited for a discussion forum as it invites to a lot of discussion/speculation. Can it really be called fraud when they have made the initial distribution open for everyone to see? What is a "fair distribution"? etc. I'll let the community decide but in my opinion this should be closed.

You're quite right -- it's better suited for a discussion. I think I'll post another, narrower and more answerable, question instead. Or should I do a complete edit of this one?

While that's an interesting approach, this isn't really a place to discuss open-ended questions like this.

it's funny, no one is bothered by the fact bitcoin's early adopters up to end of year 2012 are controlling a 50% stake there, when all most of them ever did for it was to run a mining program on the CPU or something. Yes some did put an effort into kickstarting the economy but most haven't. Yet it's still a 0.001% world minority that controls 50% of the bitcoin wealth. Talk about "we are the 99.999%". And nobody's challenging the fairness of that model anywhere. Meanwhile a virtual payment system issued by a VC funded startup that's doing all the development and kickstarting doesn't deserve 50

@yonil - Because BTC has had open and equal access from pretty much day one.  They didn't pre-mine all 21 million bitcoins and say "we'll give away half and keep the rest for ourselves".  Instead they launched it and anyone who wanted to could start mining.  There was equal opportunity for anybody who wanted to get involved.  Yes it paid off well for early adopters.  But in bitcoin's case, "early adopters" wasn't artificially restricted to being just the founding members/developers.  Not so with Ripple.

Opencoin plans to give away 50 billion XRP. It is actually in Opencoin's best interest to make this distribution as wide as possible as the system will only be successful if it can gain a critical mass of users. Giving away enough XRP to keep the system as cheap as possible for as many people as possible for as long as possible is the only strategy they believe will work.
A lot of people have suggested possible nefarious schemes and conspiracy theories around Ripple. But you have to remember, if the Ripple payment network doesn't become popular, nothing else matters. It is simply a better strategy to give away lots of XRP as fairly as possible to drive adoption. Not to mention, not doing what they said they would do would reduce confidence in the system.
Billions of XRP will be distributed as widely as possible. The system will be fully open source. There will be no central authorities. That's what's in the founder's best interests, that's what's in Opencoin's best interests, that's what Ripple was designed to be, and that's what Opencoin intends to do.
The founders get 20 billion XRP. OpenCoin gets 80 billion XRP -- 50 billion of which can be given away to promote widespread adoption. That's the deal that was struck.
Note: I'm an employee of Opencoin and one of the architects of the Ripple payment system. I am speaking only for myself.

Thanks David, that was the type of answer I was looking for, and kudos to you for disclosing that you are affiliated with Opencoin and Ripple. 50 billion XRP (half of the entire currency's units) shared between Opencoin and Ripple sounds like (and is) a lot, which is why people speculate. One may think of an established currency and imagine the fantasy figures half of the currency's units would amount to. Of course the people involved should be paid though, and it's hard to imagine what exactly those amounts of currency will be worth in terms of purchasing power.

I'm also thinking that the system will be unbalanced with that much currency in the hands of a small number of people, but perhaps people will simply stick to agreements with other currencies until XRP seems stable enough.

What's the difference between the founders (20%) and opencoin (30%)?
Aren't the founders and opencoin the same thing?

@jtimon: No. The founders are the people who originally conceived and developed Ripple starting in late 2011. Opencoin is a for-profit corporation formed in September of 2012 to dramatically increase the resources available to develop and promote Ripple.

It is so confusing when you say that you are both an employee of OpenCoin and an architect of Ripple (presumably a founder). Because this blurs the distinction between OpenCoin and the original authors.

@VinnieFalco: I am not one of the founders. I worked for the founders before Opencoin was formed.

I'm sure you see the concern.  If Ripple doesn't become popular, nothing happens.  But if it becomes even marginally successful (like LTC with its $70 million market cap), OpenCoin and the founders wind up sitting on a massive pile of cash (or cash equivalent).  They're holding a full 50% of the currency for themselves.  That's ridiculous.

@aroth: Usually people keep 100% of the value they create. I'm not sure why you think 50% is ridiculous.

@DavidSchwartz - Because a pile of pre-mined coins/ripples is not the value being created.  Pretty much anyone can trivially create such a thing.  It's like if I told people I wanted them to start using my discarded coffee grounds as currency, and oh by the way I'm going to hold onto half of the total supply.  There's no value in the grounds, and my motives for holding half the supply as a personal reserve can only be self-serving.

(continued) If I understand Ripple correctly, the value created is in the payment network infrastructure itself, not the cryptocurrency/pile of ripples that was generated to support it.  And yes, the founders are entirely entitled to hold onto 100% of that value, both in terms of IP rights and any transaction fees that are collected in association with it.  But you can't precompute 100 billion cryptocurrency units and call it "creating value".

@aroth: The currency has almost no value that doesn't come from the payment network.

From Jed, one of the principal architects:

Vinnie:  ...What's the OpenCoin business model?
Jed:  ...we hold xrp and hopefully they gain value

Remember that OpenCoin can give away 50 billion XRP and yet, this will not affect the price. If OpenCoin gives a user exactly 200 XRP this will not increase the total XRP in circulation because of the reserve requirement. In theory, the entire 50 billion can be given away in such small amounts that all of these XRPs are sequestered as reserves.

To send money to a friend in Ripple, you don't have to convert the money into XRP. You send the money as dollars, Bitcoins or whatever and spend XRP just as a transaction fee. That's why they won't be (and don't need to be) very valuable.


text:
Bitcoind server spontaneously shutting down
I'm running the latest version of the headless bitcoind server on an Ubuntu micro instance on AWS and every hour or so it spontaneously shuts down. It's hard to get any meaningful data from the debug log because it seems to happen completely randomly. This is a brand new install on a brand new AWS box. I'm also running the testnet, by the way.
If you can think of meaningful data I can provide, please tell me, but I'm at a loss here! Does anybody know what could be going on?
Edit:
After some more research, I think it's because of the limited memory in a micro EC2 instance:
https://bitcointalk.org/index.php?topic=21451.0

Add some swap space and your problems will disappear.

I think you choose the micro instance because that is for free for one year :)
You need definitely more RAM on the ec2 instance, here's how:
http://www.cyberciti.biz/faq/linux-add-a-swap-file-howto/

bitcoind uses a ton of memory while it's downloading the blockchain. Check out these steps on how to set up your swap space correctly on Ubuntu:
https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04
Additionally, you can check out the torrent download of the blockchain. As long as you trust the file, this can help speed up the time to download the blockchain.
http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/bootstrap.dat.torrent/download

Indeed, adding more swap will keep your coin from having a panic shutdown. Here's how to add swap on Ubuntu 12.04.4 (tested) and likely other versions:
sudo dd if=/dev/zero of=/swapfile bs=64M count=16; sudo mkswap /swapfile; sudo swapon /swapfile;

This command will create 16 64MB blocks of swap, totalling 1GB of extra swap, which should be plenty if you're just running bitcoind. If you are running multiple coins I would have at least 2GB.
sudo dd if=/dev/zero of=/swapfile bs=64M count=32; sudo mkswap /swapfile; sudo swapon /swapfile;


text:
Anyone concerned that, by individuals getting rich too fast, crime towards cryptocurrency holders will also increase?
Given the potential for such a gigantic paradigm shift, something so accessible and so global could displace enormous amounts of value to large groups of people that previously had very little capital. Not everybody may understand the underlaying technology and how to protect their assets making them easy targets for fraud or exploitation. It's everyone's responsibility to protect them selfs but it on the other side there will be equally or smarter people trying to gain access to their entries on the ledger.
I guess anyone has the ability to protect their wealth in the digital network, but I wonder if we will start seeing more cryptocurrency thefts in the more physical violence context (kidnapping to make someone release their private keys, hardware seizures,...).
Anyone thought of how this will have an impact in terms of crime in the coming 5 or 10 years? Is there going to be a lot of money to protect and a lot of incentive to steal it?

The title of the question does not really match it's content : Will crime raise due to cryptocurrency? What is your question exactly


text:
Help analyzing this color coded hexdump of the Bitcoin blockchain
Sample of genesis, growth, and current height

Sample of the latter part and the end of blk02655.dat. This probably covers parts of the last 10000 blocks.

Process here:
https://twitter.com/bitcoinanatomy/status/1416891318232551428?s=20
$ pip install pixd
$ python -m pixd path/blk00000.dat

https://pypi.org/project/pixd/
Trying to understand:

How many bytes per line and how 1MB looks
Recognizing block headers, transaction data,
Categorizing the patterns found
Confirm order of blocks
Locate special blocks and transactions (first segwit block, first transaction, batch transactions, multisig, coinjoins, LN channel opens)

Anyone else curious?
Thanks!
Edit:

Hex only. Different patterns left behind by the miners.
Diversity in ways of constructing blocks causes the transaction signatures of the transactions align in and creating geometric and organic patterns.
Each line has a ~32bytes or 64 hex characters. Changing this changes the frequency.

Details

Zooming out of the hex

Bigger sample

That is a very difficult way of looking at this data, especially as it's a well defined binary format that we can just, load with a parser of our choosing. Blocks files are just a bunch of blocks concatenated, and block files are just a bunch of transactions concatenated with a header.

We're not trying to validate the blockchain. The goal is to find and understand new ways of looking at the data.

Right but it’s a useless representation that has no ability to convey information. I didn’t say anything about validation.

The patterns you're seeing are just related to the length of transactions.

My understanding is that these patterns are mostly influenced by the order in which miners build their blocks. They vary in big chunks of the hex, sometimes they all read as noise but if you change the line length, you can get those blocks into focus and see that the configuration also produces a pattern but a very different one.

Here we see the adjustment of the number of bytes shown per line by changing the size of the terminal window. https://twitter.com/bitcoinanatomy/status/1417353713027518464?s=20

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Security of ChaChaPoly (IETF rfc7539) in the noise protocol framework of the Lightning Network
According to this paper ChaChaPoly is secure against chosen known plaintext attacks. I wonder however if that security assumption is weakened by a lot since messages sent on the transport layer of the lightning network start with a 16 bit length field with an HMAC coming from ChaChaPoly. (They are then followed by the actual lightning message, followed by an HMAC for the payload which I don't care about at this time)
As there is only a small fixed set of potential lengths of lightning messages, we can guess the plaintext of the length field. In particular, I wonder what is the impact of doing a block cipher like ChaChaPoly as defined here

on 16 bit data for which the plaintext is potentially known?
As mentioned before, I am not an expert on cryptography but I am not sure if this particular setup does not yield a compromise of security of the Transport layer, potentially exposing session keys which would allow an attacker to decrypt up to 500 messages or even spoof data. Has anyone ever looked into this or can give me a reason why our setup does not yield a security problem?

The paper you cited proves that ChaChaPoly is IND-CCA secure. This notion of security seems to perfectly cover your attack if I read the definition right  (https://en.wikipedia.org/wiki/Ciphertext_indistinguishability):
"A cryptosystem is considered secure in terms of indistinguishability if no adversary, given an encryption of a message randomly chosen from a two-element message space determined by the adversary, can identify the message choice with probability significantly better than that of random guessing (1⁄2).".
That is, even if just two such lengths existed, the adversary cannot guess which one is encrypted here significantly better than randomly.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
How to generate Ed25519 public key from private key using libsodium?
Not all crypto currencies are using secp256k1 technology for keypair generation and digital signatures. Curve25519 technology (frequently used to support ECDH key exchanges) is being used by a few other cryptocurrencies. Ed25519 cryptography (meant to support EdDSA functionality) and Curve25519 cryptography are closely related through transformations and the trend is to start with Ed25519 keys and transform them to Curve25519 key pairs.
Been using this reference as a source of eight ED25519_SECRET_KEYS and corresponding ED25519_PUBLIC_KEYS to use as test vectors for applying Ed25519 package implementations.
Got floodyberry/ed25519-donna to function as expected. However, I could not compute the ED25519_CURVE25519_PUBLIC_KEYS from the reference using ed25519-donna using its curved25519_scalarmult_basepoint() function to match. This pushed me towards trying jedisct1/libsodium. Got crypto_scalarmult_base() function results from libsodium to match those from ed25519-donna:-)
However, it is unclear how jedisct1/libsodium can be applied to generate public Ed25519 keys only from secret Ed25519 keys that are natively in an ASCII hexadecimal format:-( It seems that jedisct1/libsodium requires keys to always be generated from it native keypair generation process, opposed to an externally supplied private key.
Used the sodium_hex2bin() to stuff an ASCII hex encoded private key from the reference into the 64 unsigned char ed25519_skpk variable:
sodium_hex2bin( ed25519_skpk, 32, ED25519_SECRET_KEYS[ii], 64, NULL, NULL, NULL );
Results from the following libsodium function were as expected:
crypto_scalarmult_base( curve25519_pk, ed25519_skpk )
Was a bit frustrated when I discovered that crypto_sign_ed25519_sk_to_pk() was coded to extract the public key from ed25519_skpk that was never initialized.
crypto_sign_ed25519_sk_to_pk( ed25519_pk, ed25519_skpk );
Becoming a bit disappointed not locating a libsodium function to compute the ed25519_pk key when ed25519_skpk is loaded with a working private key from an external source. Any assistance will be greatly appreciated.

Small nit: the Ed25519 curve is used to implement EdDSA, not ECDSA.

Fantastic eye for detail! Reflected the EdDSA change.

FYI - numerous flavors of ed25519 exist. https://tools.ietf.org/html/rfc8032#section-5 documents ed25519, ed25519ph, and ed25519ctx. Monero and I2P use red25519. See https://geti2p.net/spec/proposals/146-red25519 for an I2P perspective.

It's not possible to directly compute the ed25519 public key from the private key.  Instead, use the deterministic private key to create a seed, then use the seed to re-create the private key with its corresponding public key. The following code snippet assumes ed25519_skpk is already initialized:
char           hex_ed_pk[65];
unsigned char  seed[crypto_sign_SEEDBYTES];
unsigned char  ed25519_skpk[crypto_sign_ed25519_SECRETKEYBYTES];
unsigned char  ed25519_pk[crypto_sign_ed25519_PUBLICKEYBYTES];

// COMPUTE ED25519 PUBLIC KEY, REQUIRES ESTABLISHING A SEED
(void)crypto_sign_ed25519_sk_to_seed( seed,ed25519_skpk);
(void)crypto_sign_seed_keypair( ed25519_pk, ed25519_skpk, seed );
(void)sodium_bin2hex( hex_ed_pk, 65, ed25519_pk, 32 );

On libsodium > 1.0.15, the crypto_scalarmult_ed25519_base() can do this.

authors: Владислав Владислав


text:
What is BIP32-style derivation?
I am reading the technical "specification" for stealth addresses, available here. The core idea is described in the following paragraph:

Using Elliptic curve Diffie-Hellman (ECDH) we can generate a shared
  secret that the payee can use to recover their funds. Let the payee
  have keypair Q=dG. The payor generates nonce keypair P=eG and uses
  ECDH to arrive at shared secret c=H(eQ)=H(dP). This secret could be
  used to derive a ECC secret key, and from that a scriptPubKey, however
  that would allow both payor and payee the ability to spend the funds.
  So instead we use BIP32-style derivation to create Q'=(Q+c)G and
  associated scriptPubKey.

I understand everything except the last sentence. As far as I can tell, Q and c are known to the payee and payer so the keypair Q'=(Q+c)G is also known to both. How does Q' allow for only the payee to spend the funds? How does BIP32-style derivation work?

I believe there is a typo. It should instead read Q'=(d+c)G=Q+cG. The private part d+c is an offset of the payee's private part d, so only known to the payee. The public part is an offset cG, known to both.

maybe this will help? https://bitcoin.org/en/developer-guide#hierarchical-deterministic-key-creation
or check the various BIP32 implementations (bitcore for example)

This algorithm generates a public key, which both parties know. It's just a public key, though, so only recipient has the ability to spend the funds.
According to the paper, Q is the recipient's stealth public key and c is the shared secret. The calculation Q'=(Q+c)G creates a shared public key derived from the receiver's stealth public key.
If the receiver's private stealth key is d, they can unlock the funds by calculating the new private key (d+c). The sender doesn't know d, so they have no way of calculating this value.
BIP32 HD wallets use the same idea. You can start with a private key, k, and a public key K = kG. Then, you start adding random numbers (hashes, actually) to both keys. As long as you add the same number to both the private and the public key, you maintain a working keypair. You can reveal your public key K, which allows others to addresses, but they cannot spend from those addresses without knowing the private key k.


text:
Intuition for Simplicity's CheckSigHashAll
So, I downloaded Simplicity and started a REPL using cabal new-repl Simplicity. Then I enabled type applications using :set -XTypeApplications.
Consider these invocations:
> (pkwCheckSigHashAll @CommitmentRoot @() lib (Schnorr.PubKey True (read "0")) (Schnorr.Sig (read "0") (read "1")))
CommitmentRoot {commitmentRoot = Hash256 {hash256 =
"\CAN\r\201\231\SO0:1\183\130a\DC3m4u!\193\247e\EOT\194nO\US\208\150\&2\182\ACK\203\151>"}}

> (pkwCheckSigHashAll @CommitmentRoot @() lib (Schnorr.PubKey True (read "1")) (Schnorr.Sig (read "0") (read "1")))
CommitmentRoot {commitmentRoot = Hash256 {hash256 =
"\215\222oj\251&\134\SOZ\202@N\161(\185j2\DELt\156\147\136Nz\183\179\EOTH\166\FS\141F"}}

> (pkwCheckSigHashAll @CommitmentRoot @() lib (Schnorr.PubKey True (read "1")) (Schnorr.Sig (read "0") (read "0")))
CommitmentRoot {commitmentRoot = Hash256 {hash256 =
"\215\222oj\251&\134\SOZ\202@N\161(\185j2\DELt\156\147\136Nz\183\179\EOTH\166\FS\141F"}}

If I understand correctly, the commitment root goes into an transaction output. Since the signature shouldn't play a role, the output from Haskell makes sense since I change the sig and it doesn't affect the commitment root. The example above seems consistent with this intuition. Are both my intuition and the example code correct?
Now, I can call the same method with WitnessRoot:
> (pkwCheckSigHashAll @WitnessRoot @() lib (Schnorr.PubKey True (read "0")) (Schnorr.Sig (read "0") (read "0")))
WitnessRoot {witnessRoot = Hash256 {hash256 =
"\185\FS\176\179\b{Xc2\216\n\240\186\205v\208\164NW\\\DLE\193:\ETB\bMO\211\152*I%"}}

> (pkwCheckSigHashAll @WitnessRoot @() lib (Schnorr.PubKey True (read "1")) (Schnorr.Sig (read "0") (read "0")))
WitnessRoot {witnessRoot = Hash256 {hash256 =
"\240h\NUL\188z4\ACK\200\ETX\151\DC1&Y\253\t\152\176P\146\186\137\NAKm!\STX\DC3\182\148\193\246\172O"}}

> (pkwCheckSigHashAll @WitnessRoot @() lib (Schnorr.PubKey True (read "0")) (Schnorr.Sig (read "0") (read "1")))
WitnessRoot {witnessRoot = Hash256 {hash256 =
"\205\DEL\132Q\245\166!\196\178\248\136\194aO\243+\145T\200E\129I#\253F\134\173i\243K\154J"}}

Again, if I understand correctly, the witness root goes into the spending transaction input. It seems like the witness root is affected if I change either signature or public key, which corresponds to my intuition. Simplicity uses BIP-Schnorr which doesn't allow for pubkey recovery. Again, is my intuition consistent with the above code?
I assume these hash values contain mock transaction metadata like nLocktime, embedded in the lib, correct?
Now, let's say I wanted to do a 2-of-2 MAST-based multisig with Simplicity, how would that look like? There must be a way to compose two different calls to CheckSigHashAll. And the spending transaction would surely need to provide a MAST path through the script, how do I pass that to Simplicity? With oooh?

Your understanding of the commitment root is correct.  Taking advantage of Haskell's laziness, feel free to put undefined into the signature when computing the commitment root.
At the moment, the witness root is not used in the protocol.  There are some ideas on how to use it in more sophisticated protocols, but those ideas haven't been realized yet.  However, the witness root has some uses in testing and development regardless.
Simplicity doesn't use BIP-Schnorr per se.  Rather checkSigHashAll is a Simplicity expression that implements an old draft of BIP-Schnorr.  If you want a signature scheme that supports key recovery, you could implement such a scheme in Simplicity.
Neither the commitment nor witness roots contain any transaction data, mock or otherwise.  Instead the checkSigHashAll Simplicity expression contains primitives that, during Simplicity execution, return the transaction's locktime and version
To make a simple 2-of-2 multisig you could write something along the lines of
 pkwCheckSigHashAll <pubkeyA> <sigA> &&&
 pkwCheckSigHashAll <pubkeyB> <sigB> >>>
unit

Since both branches are used in a 2-of-2 multisig, there are no MAST branches.
To make a 1-of-2 multisig you have some options.  One way is
 witness <value of type (Bit, Sig)> >>>
 cond (scribe <pubkeyA> &&& iden) (scribe <pubkeyB> &&& iden) >>>
 checkSigHashAll

However, even after pruning (turning the case within the cond into an assert), the program appear a lot like a 1-of-2 multisig.
Another implementation could be
witness <value of type Bit> &&& unit >>>
cond (pkwCheckSigHashAll <pubkeyA> <sigA>)
     (pkwCheckSigHashAll <pubkeyB> <sigB>)

In this case after pruning it looks like a 1-sig-or-something else.  Pruning transforms the above expression into something like
witness <0> &&& unit >>>
assertl (drop (pkwCheckSigHashAll <pubkeyB> <sigB>))
        (commitmentRoot (drop (pkwCheckSigHashAll <pubkeyA> <sigA>)))

where only the commitment root of the untaken branch is revealed.
Be aware that as of the time of writing this, pruning has not been implemented, nor is it the case that pruned expressions are yet enforced by the implementation.  You can still prune expressions by hand though.


text:
Can ECDH peers waste each other's time at will?
Peter Dettman notes that ECDH peers can waste each other's time at will. What does he mean? Can this be weaponized against Lightning nodes?

Could it be that he is referring to not being able to use Montgomery ladders?

It was in the context of the peer sending an invalid point. The proposed scheme would not detect that immediately, and so would do extra (wasted) work.
However the peer could equally waste your time by sending a valid point (possibly without knowing the private key) and just abandoning the protocol after you've done the work anyway.


text:
What are the implications of Schnorr signatures?
Adam Back (adam3us) explained in March, 2014, but it is all math. There's another short post with advantages, though.
This answer on crypto.SE claims that Bitcoin considered using Ed25519 which is based on Schnorr signatures, but decided against it. Even if it is not going to get used, I'd still like to know the implications.
There's a pull request adding them to libsecp256k1. [edit 2019: that pull request used a flawed approach]
Gavin mentioned them on his wish-list for Bitcoin.

advantages listed by the Elements project

it also enables a more efficient Lightning Network

non-interactive partial aggregation

See also https://bitcoin.stackexchange.com/a/77235/3347

Warning: I've never actually worked with the Schnorr signature scheme.  The
following is my analysis based on reading the Wikipedia
article, the ed25519
page, and some discussions between devs in
#bitcoin-dev.
Likely Changes

Changed op code behavior: we will need an op code to check
Schnorr signatures. With a hard fork, we can redefine
op_checksig and
op_checksigverify to also check Schnorr signatures. With a soft
fork, we can redefine one of the reserved no-op op codes to check
Schnorr signatures.

Increased P2SH usage (maybe): I think it's highly unlikely
that a new address format will be introduced to do the same thing
for pubkey scripts paying Schnorr public keys that
P2PKH does for
ECDSA public keys. That means people who want an address to use
Schnorr even with just one key (non-multisig) will have to use
P2SH. Of course, for applications that don't need addresses (like for
mining or when using the
BIP70
payment protocol), they can just use op_checksigverify_schnorr (or
whatever) directly in their pubkey scripts.

Smaller multisig transactions: one of the most widely touted
advantages of the Schnorr scheme is that it can allow multiple
signers to combine their signatures into a single signature which can
be authenticated against a single public key created by all the
authorized parties. This accomplishes the same thing current Bitcoin
multisig does but uses fewer bytes. This may be especially useful if
dozens or hundreds of signatures are required, such as in a
crowdfunding situation.  Note: if I understand correctly, this is
also possible also with ECDSA, but in a less flexible way. (2018 note: there's now a paper out that details how to do script-less scripts on ECDSA, including 2-of-2 multisig)

Slightly smaller for all transactions: assuming Bitcoin uses the
ed25519 curve, which has a similar key
strength to the secp256k1 ECDSA curve Bitcoin currently uses,
compressed Schnorr public keys and signatures will be (respectively)
32 bytes and up to 64 bytes compared to current compressed Bitcoin
secp256k1 public keys and (non-compressed) signatures that are 33
bytes and up to 75 bytes.

Plausible deniability for multisig: using Schnorr threshold
signatures it
may be easier to prevent multiple signers or third-parties from knowing who else
signed or didn't sign. That's because the individual signatures are
merged into a unified signature that doesn't directly reveal who
signed it. This can be used in situations where the signers are
afraid of reprisals for spending funds in a particular way.

Plausible deniability of authorized parties using a
third-party organizer (which doesn't need to be trusted with private
keys), it's possible to prevent signers from knowing whether their
private key is part of the set of signing keys. Although not
directly relevant to Bitcoin transactions, I seem to recall[1] Greg
Maxwell saying he'd like to see this property used for distributed
forum moderation: choose a bunch of senior forum members, get a
public key from each of them, create a threshold public key from
some of the individual public keys, and then let individuals submit
a signature when they think a post should be removed. The
third-party organizer (probably an automated program) will combine
the signatures without leaking whose signature actually contributed
towards meeting the threshold. If nobody knows whose signature
actually matters and the pool of possible moderators is large,
effective reprisals against moderators become very expensive. [1]: #bitcoin IRC about 4 months ago; unfortunately that chatroom is not
publicly logged.

Theoretical better security properties: the experts agree general
Schnorr signatures have better theoretical security
properties
than equivalent ECDSA signatures. The most notable of these
improvements is that the hash function used in Schnorr doesn't need
to be as collision resistant as the hash function used in ECDSA.
(Bitcoin would likely use the same hash function for Schnorr that it
uses for ECDSA: SHA256.) Also, the ed25519 page linked above
describes several ways it is resistant to side-channel attacks, which
can allow hardware wallets to operate safely in less secure
environments.

Faster signature verification: it likely takes fewer CPU cycles
to verify an ed25519 Schnorr signature than a secp256k1 ECDSA
signature. This is probably only a tiny improvement for Bitcoin:
Bitcoin Core verifies signatures before adding a transaction to its
mempool. When a block is received containing transactions already in
the local mempol, Bitcoin Core does not re-verify those transactions,
so as long as the local node and the mining node have identical
mempools, no signature verifications need to be performed. (Recall the
coinbase transaction doesn't have a signature.) However, signature
verification is currently a bounding factor for nodes during initial
blockchain download (assuming a high-speed connection and Bitcoin
Core 0.10.0), so "faster would be better."

Multi-crypto multisig: with two (slightly) different
cryptosystems to choose from, high-security users can create 2-of-2
multisig pubkey scripts that require both ECDSA and Schnorr
signatures, so their bitcoins can't be stolen if only one
cryptosystem is broken.  Unless we hardfork in Schnorr (see point #1),
they won't be able to use standard op_checkmultisig---but they can do
something like <ecdsa pubkey> OP_CHECKSIGVERIFY <schnorr pubkey> OP_CHECKSIGVERIFY_SCHNORR

Uncertainties (To Me)

Maybe changed TXIDs: I'm not familiar enough with Schnorr
signatures to know how they might be malleable (changeable by
third-parties without invalidating them), but crypto expert Adam Back seems to think they'd be pretty malleable. His solution would be to change how TXIDs are calculated from hash(<whole transaction>) to hash(<almost everything except the signature>).  This would fix some current malleability-based problems, such as slow micropayment channel creation, but it also be a major hard fork that affects effectively all Bitcoin software.  The last fork of that scale---the soft-fork P2SH implementation---still doesn't have support for it from all Bitcoin programs after three years of discussion, two years of implementation, and fairly widespread use.

Public key recovery from signatures: I don't know whether a Schnorr public key can be recovered from a Schnorr signature the way an ECDSA pubkey can be recovered from an ECDSA signature.  This could be important: the Bitcoin Core verifymessage RPC uses key recovery to verify messages signed with the signmessage RPC or by another client's sign message implementation.  (Note: this point left unnumbered because it was added after the original posting.)

Non-Changes
Just to be clear, here are some things that don't change.

Deterministic signatures: there has been a drive towards
deterministic ECDSA signatures
in Bitcoin software. For example, Bitcoin Core will begin using them
in the upcoming 0.10.0 release. Schnorr signatures can also be
generated deterministically. With deterministic signatures, you
don't need a high-quality source of entropy (randomness) to create
secure signatures. However, you do still need high-quality entropy
to generate private keys or root seeds (see point below).

HD wallets: it looks to me like the hierarchical deterministic
(HD) key generation
protocol
will work for Schnorr key pairs with a few small modifications. You
can even use the same root seed for both ECDSA and Schnorr
hierarchies.

Key (address) reuse: as with properly-implemented ECDSA, it's
possible to securely create multiple Schnorr signatures for different
transactions, meaning it's secure to receive multiple outputs to the
same address or public key. This is in contrast to
some signature
schemes which
only allow you to securely use a one signature per public key.  However, key reuse
can still be less secure than using unique keys for each transaction,
and key reuse will always be much less private for you and your
trading partners.

Priority
Just as a matter of my opinion: Schnorr seems to provide some nice
advantages over ECDSA for power users, but nobody seems to be begging
for those features---so adding Schnorr signatures is probably low
priority. I'd guess that Schnorr signature support might be one of the
first improvements that will be fully tested in a sidechain (PDF
link) before being ported back
to Bitcoin.
P.S. Sorry for the long post, but thanks for asking such a fun question!

Do Schnorr signatures support public key recovery from the signature? And are you saying in 13 that Schnorr signatures would be more quantum-safe?

@StephenM347 good questions!  I don't know about key recovery; I'll try to do some research.  Schnorr ed25519 is definitely not significantly more quantum safe than ECDSA secp256k1---they're both based on the difficulty of a discrete logarithm problem and are both susceptible to Shor's quantum factorization algorithm; I'll edit that point to make it more clear.  Thanks!

Thanks. And that's what I figured with regards to Schnorr signatures being quantum safe, just wasn't sure if that's what you were saying.

RE:  "fix some current malleability-based problems, such as slow micropayment channel creation, but it also be a major hard fork" ... SegWit is a soft fork, and does the same thing, so if you do SeqWit first, or at the same time, you eliminate malleability issues - no hard fork needed.

Bitcoin Core has written a post on segwit that covers some Schnorr stuff too: https://bitcoincore.org/en/2016/06/24/segwit-next-steps/ Including some stuff not mentioned in this post, like signature aggregation and its use with coinjoin.

How does Ed25519 multi sign work? Can't seem to find any references on it.

Would it make sense to also mention cancellation/de-linearization?

A lot has changed since this answer was written.  Now that we have SegWit, item # 10 is a non-issue. Also appears item # 1 is a non-issue as Bitcoin script can be upgraded via softfork, correct?  Also seems that sepc256k1 is considered faster than ed25519, so there doesn't seem to be discussion on changing that.

Yes you can do public key recovery with EC Schnorr. Consider
R = kG, [r = R.x, s = k + H(r, m)d], Q = dG

verify:
sG = ?R + H(r, m)Q

recovery:
sG = kG + H(r, m) dG = R + H(r, m)Q

so
Q = 1 / H(r, m) * (sG - R).

(And to compute R from r if R is point-compressed, R = (r,f(r)) R' = (r,-f(r)) and try both R and R' by checking if the signature is valid with the resultant public key).

but you can't do key recovery with BIP-Schnorr

The primary design goal for DSA was to avoid infringing the Schnorr patent.  Now that the patent has expired, there aren't really any good mathematical reasons to go with DSA.  With Schnorr, the algorithm and analysis are simpler and often more efficient.  It's also easier to split Schnorr private keys, create threshold variants, etc.  However, DSA and ECDSA are standards, and have been for a while.  As a result, library implementations are everywhere.  You can find hardware security module support, etc.  Someday the same will hold of either Ed25519 or some other Schnorr variant.  People are unlikely to standardize new DSA variants.  But for the moment ECDSA is still the algorithm to use if you want something standard and widely supported.


text:
What are the pros/cons of preferring sending the latest commitment or the oldest commitment?
Roasbeef mentioned on IRC that the Lightning specification allows a client to either assume that the latest co-signed commitment has been received by the counterparty, or that it hasn't. (as far as I understand that linked discussion. If I got it wrong, please edit the question)
For an implementation, what are the consequences of preferring to send the oldest co-signed, or sending the newest co-signed? (both unrevoked)

Can you please clarify further what you mean by "preferring to send the oldest co-signed, or sending the newest co-signed?". I'll update my answer after that.

When you receive commitment_signed, you have the signature for a new commitment transaction. But you havn't revoked the old one yet, so it will still be valid. Therefore, you will have two co-signed commitment transactions. One is older than the other. The counterparty cannot know if you received commitment_signed unless you acknowledge it. So if you reconnect and send channel_reestablish you can choose the value of next_commitment_number. If you send a low value, the counterparty might conclude that you lost data, in which case it could breach the channel without fear of repercussion.


text:
How does Elements integrate Simplicity?
Greg Maxwell noted that there are two ways to integrate Simplicity into Bitcoin. One is to make only a few select high-level constructs available (like SHA256, CheckSigHashAll), the other is to expose a full bit machine as specified in the Simplicity Technical Report.
Now that Simplicity is being integrated, presumably a decision must have been made on how it will work.
Which approach was chosen?

It has always been the case that the full Bit Machine would be "exposed"[1] by allowing arbitrary Simplicity.  This is because the combinators that let you compose the high-level jets are exactly the same combinators that define low-level Simplicity.  Thus even if only a few high-level jets are chosen to be exposed, it would still be the case that the low-level combinators could be used to define any function (at great expense, of course).
The real question is, what selection of jets will be made available and at what cost?  That question, while really important, gets decided near the end of development, so technically it hasn't been addressed yet.  I'm inclined to be quite liberal on accepting lots of jets.  For example, I'd like to have all functions from fiat-crypto extracted (both as Simplicity and as C) and implemented as jets.
That said, Elements is a platform, and users of that platform will have the ability to choose whatever selection of jets they wish, which may vary depending on how far along the proofs of correctness are and how comfortable they are with the risk-level for greater or fewer number of jets, or even add their own jets.  Furthermore, as Maxwell noted, we really need to get some experience with using Simplicity to understand what are and are not useful jets.  We will want this experience this before Simplicity would be integrated into Liquid.
[1] Just to be clear, the Bit Machine is never directly exposed.  The Bit Machine can only be run through interpreting well-typed Simplicity programs.  This is important because the Bit Machine relies on the type-safety of Simplicity for its memory safety. Otherwise the Bit Machine could crash.


text:
How does a Drivechain output work?
It is said that Drivechain works by sending a transaction output to a miner/hashrate-controlled escrow. I know it works by allowing miners to vote over a large number of blocks on transactions, that want to spend from these outputs. Only after a transaction has acquired a number of votes can it be published.
However, how is that supposed to work practically in Script? Is there a new proposed opcode like OP_CHECKTRANSACTIONHASENOUGHVOTESVERIFY or something like that?


text:
Sending confidential transaction amount to the receiver
In confidential transaction proposed by Maxwell, instead of transaction amounts we use pedersen commitments to hide the amount and add the range proof to the transaction to prevent overflow. A simple commitment with one input and one output C1 and C2 is as follow: (Ignore the fee for simplicity)
C1 = C2 => BF1*G + a*H = BF2*G + a*H

where in this example BF1 = BF2 obviously since it only has one input and output.
How does the sender send the amount and blinding factor to the receiver? Receiver can check if the amount is correct! I noticed Maxwell said they use ECDH. I assume there is no additional communication channel for ECDH. Then how does the sender get receivers public key? and does sender need to reveal both blinding factor and amount in the ECDH?

In Elements Alpha, output "amounts" consist of 3 pieces of data:

The Petersen commitment to the value, blinded by the blinding factor.
The range proof, which can publicly prove that the value is within range [0..2^32-1] units (satoshis) without revealing anything about the blinding factor.
An ECDH ephemeral public key of the sender.

The latter is where the solution lies. Every confidential transactions address contains an ECDH public key of the receiver (the blinding key), in addition to normal P2PKH or P2SH data.
When a CT transaction is sent, the sender chooses an ECDH ephemeral private key, and combines it with the blinding key to derive a blinding seed. This seed is used as a basis for the random number generator to create the range proof. The public version of the ephemeral key is then written in the 3rd field of the amount.
When the receiver sees this ECDH ephemeral public key, he combines it with his private blinding key, to derive the same seed as the sender used. Using this same seed, he can "unwind" the range proof, and decode the secret information that was used when creating it: the value and the blinding factor. There is in fact space for another 2 kilobytes of data in the range proof, only visible to the receiver (or anyone holding the private blinding key).

By the random number for creating range proof you are referring to the commitment's blinding factor? Blinding factor in the ring signature proves the range proof as far as i know. If so then the blinding factor is generated from the seed? May I know what the seed is exactly?

If the range proof only covers values up to 2^32-1 does that mean you can't send more than ~42.9… bitcoins with CT?

@abeikverdi No, the seed value is not the blinding factor. It is the base for the randomness that goes into the ring signatures inside the range proofs. By making the randomness deterministic, the receive can "undo" the range proof by knowing what randomness goes into it.

@Murch The range can actually be chosen to be anything between 2 and 64 bits of randomness, but that range is public. So you can use a larger range, but that gives an indication you're transacting more. Of course, you can always use larger ranges even when transacting small values, but this increases the price.


text:
How can I avoid transaction malleability consequences?
Please note that this question is NOT a duplicate of other questions regarding transaction-malleability.
My question is regarding a following scenario, that could happen on an exchange that uses on-chain wallet management:

user deposits funds on address A, belonging to his account on an exchange. Exchange waits n confirmations before it credits user account.
user then moves funds from address A to address B, which also belongs to his account on the same exchange. Exchange doesn't wait for any confirmations here, because the it knows it won't double-spend itself. Exchange thus notes the TXID of this transaction for future use.
while transaction is unconfirmed, someone exploits transaction malleability issue and pushes its tweaked version, which gets picked up by miners instead.
in the mean time, user wants to withdraw funds to address C, which is another exchange or external wallet. Exchange creates this transaction using TXID that it stored earlier. Unfortunately, Blockchain doesn't know this TXID because it was rejected by majority of miners. The exchange though doesn't get immediate feedback about that, because it doesn't know that a tweaked version of that transaction exists (since both are still unconfirmed)
in effect, funds are not withdrawn, and exchange operators are left wondering why this happened.

Now the following situation has NOT happened to me (yet), but I'm wondering:

is it realistic enough that it could happen, or is there something I missed?
how I can guard against this? For me it seems that the best fix for this would be use of the new NTXID instead of TXID in transaction inputs. But that will probably not be possible in near future, because required quite a big change in the protocol.

For what I understand about the normalized transaction ID (NTXID), you can use it as a "helpdesk identifier" for transactions you created yourself. In your example you should also detect the changed TXID of B, to be able to use its outputs in the C transaction. The answer to how to do that: http://bitcoin.stackexchange.com/questions/24048/anti-transaction-malleability-patterns

This is the new issue, the one that's causing all the trouble. You basically have two choices:

Don't spend any of your own outputs until you're quite confident they're fully confirmed. For example, you could wait for three confirmations.
Be prepared to deal with this problem by monitoring your outstanding transaction chains and re-issuing any orphaned transactions with new input transaction IDs.

Both solutions have their flaws. Number one implies that user will need to wait between taking actions with his wallet, which isn't the end of the world, but far from ideal. Number two is impossible to automate in my case, because I use multi signature wallets, which means user has to confirm every transaction from his wallets, so I cannot resend the tx automatically if an orphan is detected.
As I said, the best way to deal with that would be to use NTXID as an input. Any idea if that's even remotely possible in near future?

@mav Yeah, it's a real issue. Allowing NTXID to be used as an input would be a painful hard fork that would require everyone to reindex all unspent outputs. I guess another way to do it would be to have a way to specify in a transaction that this specific transaction be referenced by NTXID and still allow "legacy" transactions to be referenced by TXID. Then you could set this option in all your transactions. I don't know if the community has considered that.

@Gracchus The complexity of the transition depends on the nature of the implementation. But basically, the procedure you outlines is how you would do it.

@Gracchus, What do you mean by "abrupt"?

@David, then wouldn't the whole idea of "green addresses" (accept as confirmed if coming from respected address) be rendered unusable?

Here is a workaround that doesn't solve the core issue but it will solve your problem.
Before you make the transaction check if the destination address is also an address that belongs to the same user. If so, don't create the transaction. Warn the user that the destination address belongs to him and that he cannot make this transfer.
This can also happen if address B belongs to another user on your site. Do the same check and make the transaction off the chain. Just update users' balances but do not create a bitcoin transaction.
Assuming that this scenario actually takes place in an exchange, I think you can comfortably draw the line like this.
Moving balances between two addresses that belong to the same user sounds like a wallet functionality. But you are running an exchange.
Some users might complain, but hey, better to be safe than goxed. They will understand.

I run a multi signature wallet scheme, I cannot just "update users' balances" here. It's a full-reserve, on-chain solution with much better security, but has this downside that I'll need to wait for the confirmation between every action to be safe against malleability.

I see. Sounds interesting. May I ask which site?

it's called Bitalo. We launched last month.


text:
What is an SPV client?
I've seen SPV client mentioned in several places.
What exactly is a SPV client? How is it different from a standard client?

Simplified Payment Verification:

A Bitcoin implementation that does not verify everything, but instead
  relies on either connecting to a trusted node, or puts its faith in
  high difficulty as a proxy for proof of validity. BitCoinJ is an
  implementation of this mode.

http://en.bitcoin.it/wiki/Scalability#Simplified_payment_verification

Also read:

https://en.bitnovosti.com/2018/07/06/jonas-schnelli-current-and-future-state-of-wallets/
https://github.com/bisq-network/bisq/issues/1062
http://en.bitcoin.it/wiki/Thin_Client_Security#Simplified_Payment_Verification_.28SPV.29

MultiBit, Bitcoin Wallet for Android, and Electrum are examples of SPV clients.

So "SPV" is contrasted with "full" node? Or is there a third class?

@Pacerier Yes. The comparison is with full node.

SPV is Simplified Payment Verification and it is typically contrasted with "running a full node". SPV is around since bitcoin's original incarnation, it has been there since the beginning. It is a perfectly fine way to operate a wallet.
The bitcoin network relies on certain "consensus rules" to operate. One of these rules is that you can not spend something you own twice. When you send a transaction into the bitcoin network it will eventually be written into the blockchain. Full nodes download the complete blockchain and check every transaction in it to conform to the rules. This is important for you receiving funds also, as it makes sure that what was spent by someone by sending it to you was legitimately spent and is therefor yours.
An SPV wallet only downloads a certain part of the block chain, the "block headers". Every block in the block chain points to the previous block. The identifier used to identify a block is a "hash" of its header. Finding that hash is often referred to as the "cryptographic puzzle" or "proof of work challenge" that a miner has to solve in order to append a block to the chain. The hash has to conform to a certain difficulty which is dynamically adjusted in the network. In order to make sure that you are not being fooled you have to scan the most recent history of the blockchain to understand what the current difficulty is and whether new blocks that you see are actually valid according to that difficulty. This is way less data then the full blockchain.
Another thing a full node does is relaying transactions. Bitcoin is a P2P network which means everybody talks to everybody else. In practice not all 10000 notes talk to all other nodes (that would require 100000000 connections!) but to a subset of nodes. So for your transaction to reach a miner who puts it into a block eventually it might have to be relayed by a node.
An SPV wallet is not any less secure for an end user. It will correctly tell you what amount of bitcoin you can spend and whether an amount of bitcoin that was sent to you can actually be spent reliably (i.e. whether you own it). My wording might seem a little weird, that is because technically you never own anything, except for some cryptographic keys that allow you to spend certain funds that were sent to you.
You might have read that it's better to run a full node. This statement is true with regards to the network as a whole: The more nodes enforcing the rules of the system the better. The more nodes operating and relaying transactions the better. Think of the four-eyes-principle on steroids. But it is not feasible or even possible for every user to run a full node. For example if you have a wallet on your mobile device which might not have enough resources to validate each and every transaction in the network, or not enough bandwidth to participate.
To summarize: If there were no full nodes there would not be a bitcoin network. But for using bitcoin to send/receive funds it is not required to run a full node. Your own security is not affected. IMHO it is better to participate and thereby grow bitcoins value as a utility than not participating at all. It is also better to use your own wallet than for instance a web wallet at any given exchange.
Further readings:

https://medium.com/@jonaldfyookball/why-every-bitcoin-user-should-understand-spv-security-520d1d45e0b9

"I would not recommend keeping funds in a SPV wallet," - Jonas Schnelli https://en.bitnovosti.com/2018/07/06/jonas-schnelli-current-and-future-state-of-wallets/

@StephenGornick FYI, it's offline and the internet archive doesn't have a copy. (This is why link-only answers (and by extension, comments) are discouraged...)


text:
What are Green Addresses?
What are Green Addresses? Is it true that they can solve the "confirmation delay" problem, and how does that work? Are there any drawbacks?

The green address is a third party trust trick and can help resolve most problems related to the need to wait for confirmations (slow transactions).
To make it very simple :
Service A publishes its green address, service B decides to trust service A.
When someone send bitcoins from service A to service B, he will send from the service A green address.
The service B knows he can trust the service A, he knows A won't double spend, so B can credit the sent bitcoins immediately, without waiting for confirmations ( or waiting for just one confirmation, which is probably wiser ).
This is mostly useful for transferring bitcoins b2b (business to business), typically it would help making arbitrage easier and faster between 2 bitcoin exchanges, if both decide to trust each other's green address.
This can also be useful to allow for POS (Point of sales) with instant transactions if the POS can trust the green address of your bitcoin bank (or online wallet)
As an individual, I could also negotiate with my local supermarket to trust my green address (providing them my IRL address, ID number and more if needed).  Once they decide to trust my green address, I can pay immediately with bitcoins at my local supermarket (they trust me and won't need to wait for confirmations).
The green address is just a bitcoin address, but it's a "from" address people decide to trust and accept transactions from this address without waiting for confirmations.
Possible drawbacks are :

Less anonymity, or even no anonimity at all ( always using the same public from address), which is not a problem for a business, and its even great for public accounting/auditing ( yes bitcoin can also help fighting corruption ! )

Blockchain spam (more transactions for the bitcoin network), which is a good thing if the blockchain can scale.

Encourages people to use trusted wallet providers (some kind of bitcoin banks). Here too, this have good and bad sides.

It's not enough to create a green address, you still need to be trusted so that your green address is useful

For now, afaik, only mtgox.com, btcpak.com and instawallet.org support the idea.  To be useful, green address system needs to be widely adopted by bitcoin pools, exchanges, online wallets, businesses, etc.
See also https://en.bitcoin.it/wiki/Green_address
( edit 11 years ago, october 2020 , this reference is no more very relevant, some people completely rewrote the wiki page years later,for obscure reasons . . . they even replaced the first line with a blockstream ad . . . but you can still go and check the earliest versions of this page, around 2011-2012 , by clicking the "history" tab of the wiki page )

Encouraging people to use eWallets might not be bad, if the eWallet is set up so it cannot still your money. See for example https://bitcointalk.org/index.php?topic=49689.msg591574#msg591574 and the following discussion.

agreed ! I also think people will need to use eWallets anyway when the blockchain will be 1GB size and more. the only thing is that we need serious, secure, trusted eWallet providers . I added this to the possible drawbacks only because many people in the bitcoin world are hating centralization . . . and there have been a big scandal with an anonymous eWallet service / mybitcoin affair, but yes, secure and trusted eWallets are needed for sure !

@MeniRosenfeld.  eWallets where the operator isn't in control of your balance by definition can't be greenaddresses.  So you can either have decentralized eWallets or "green address" eWallets.  You can't have both at the same time.

@theUnhandledException - Not so. Read the link. The point is that sending coins requires signatures by both the eWallet and the client, so the client can't double spend and the eWallet can't steal the coins. What's novel about the suggestion (with my improvement) is precisely that it does allow you to have both.

@neofutur - the size of the blockchain doesn't necessitate an eWallet, only a lightweight client (which is better for availability).

I gave the wrong link (to a specific not so important comment in the thread), what I meant is https://bitcointalk.org/index.php?topic=49689.

@MeniRosenfeld the size of the blockchain is already more than 1 GB : ls -alh .bitcoin/blk* : .bitcoin/blk0001.dat-> 1011M ;  .bitcoin/blkindex.dat 384M . total more than 1 GB, its already too big for my small eepc, raspberrypi or phone, people not having 2 GB free diskspace cant use bitcoin until we have 1- a client able to use a blockchain provider 2- a trusted blockchain provider . personally I d already be ok to pay a ( really trusted ) blockchain provider 1 btc/year to save my diskspace

"a client able to use a blockchain provider" is probably what you called a "lightweight client", but until now and afaik this lightweight client is not existing, and there are no blockchain provider the lightweight client could use, and the blockchain being already more than 1 GB, my only option is to use a online wallet . . . I do it myself, using ssh and having the wallet on a dedicated sserver of mine.

@neofutur: Yes, a lightweight client is one which does not store the entire blockchain. I think some form of it exists already. There are several variants - one variant stores only private keys (and puts significant trust on providers to confirm transactions. StrongCoin et al are basically web-based clients of this type), another stores block headers and relevant Merkle branches to have more control over confirmation. Block headers are about 20MB now and only scale linearly with time, not with the number of transactions on the network.

well explained!

As a few have suggested, Green Addresses '1.0' had issues.
Some improvements that were suggested as early as in 2011 which you can see implemented in GreenAddress prevents users from double spending transactions via multisignature thus allowing zero confirmation for third parties that trust the GreenAddress provider, yet preventing users from risking their funds in someone else's online wallet.
See also this blog post about 0 confirmations or the design/'whitepaper'

Why does the wiki say that green addresses are not advised? https://en.bitcoin.it/wiki/Green_address

The wallet linked here has serious UI issues, beware: http://mhluska.com/blog/why-you-should-avoid-green-address-bitcoin-wallet


text:
What was the last life sign of Satoshi Nakamoto?
I heard that the name may be a pseudonym and that very little is known about the initiator of bitcoin. Also it seems that he has stopped working on the main client.
When was his last verifiable life sign? Did he ever mention or announce his retirement?

I'd say this is substantially different from the "who is" question.

@nealmcb While it is substantially different, it only matters that it's sufficiently different to not be an exact duplicate.  It clearly meets that threshold (although whether it is off-topic is a separate issue).

It's off topic. This site is about Bitcoin. It doens't need to become fodder for Who-is-Satoshi-Nakamoto trivia. Any biographical information you feel the need to expound on can easily be contained in the other thread. No need to perpetuate this this content of dubious value through the site.

In my opinion, a security relevant and trust demanding software like bitcoin, needs that nearly all questions about their developers should are allowed. More on meta: http://meta.bitcoin.stackexchange.com/questions/32/should-we-allow-question-about-the-developers

@Robert You claimed (probably rightly so IMO) that it was off-topic, yet you closed it as "exact duplicate."  It's a pet peeve of mine that far, far too many questions on SE are closed as exact duplicate when they are NOT exact duplicates.

Michael McGowan: It is off topic, but I was trying to compromise by providing a reference to the other Satoshi thread to provide an outlet for that content (closing as dupe provides a link to that content). But since the other thread has been closed, too, might as well make a clean break of it and close this one as off topic, too.

@Robert- I say this is on topic.

Why this question was closed? I really didn't understand the reason. I had the same doubt of the author of the question. It is very important to Bitcoin history and community. Seriously, this question is basic and if it is "off topic" I don't know what can be said or questioned about Bitcoin here. The Bitcoin wiki should be enough. This is definitely not off-topic and must be re-opened.

Don't look at the man behind the curtain...

No one knows for sure as he could still be involved with Bitcoin in some way. Around late 2010/2011 was the last public appearance. I think Hal and Satoshi had some convos after, but he has effectively disappeared. I'd speculate that Satoshi is Wenbo Mao, but no one knows

This was his last post on the Bitcoin Forums, December 12th, 2010. The day after he wrote this to the mailing list. As far as I know he did not (publicly) announce his retirement.

The creator of Bitcoin Satoshi Nakamoto sent his final emails to fellow developers in which he was transparent that he had moved on to other projects, during the time of handing over a cryptographic key he had utilized to send network-wide alerts.


text:
Why are Bitcoin addresses hashes of public keys?
Currently, Bitcoin addresses and their checksums are constructed from the public key by a using repeated hashing with SHA256 and RIPEMD160. Now I understand the reasoning behind using hashing for constructing the checksum, but why wasn't just the original public key with a checksum added used? Is it just because of the shorter addresses or are there other privacy/security implications of using hashes of public keys instead of just public keys?

It's just to get shorter addresses. Regular public keys are 65 bytes long, which is much too long to be convenient. Compressed public keys are 33 bytes and could potentially be used instead of hashes, though these are a little longer than 20-byte hashes. It also seems likely that Satoshi didn't know about compressed public keys or wasn't comfortable with using them when he designed Bitcoin.
Hashes seem to help against certain attacks (some attacks against ECDSA, for example), though they also open up the possibility of other attacks (such as attacks against RIPEMD-160). It's not clear to me that they do improve security overall.

Satoshi didn't envision send-to-address as the normal way of doing payments either, they were something that could be used instead of send-to-IP when the recipient was offline. That said, they do help security a bit (though Satoshi may not have been aware of that either), an attacker cannot start attacking ECDSA (which has only 128-bit security) before the public key is known (and finding the public key from an address requires a 160-bit preimage).

To elaborate on Pieter's comment: it may have been an intentional part of the design to strengthen the security of the network. In case of a flaw being found in elliptic curve cryptography, that would allow someone to derive the private key from the public key, someone could send their bitcoins to the hash of a newly generated 'replacement' public key of another algorithm (RSA for example) and it would be valid behaviour. Later when the network fully supports the 'replacement' algorithm the coins can once again be used, without ever being vulnerable to theft/hacking.

@liamzebedee Isn't that point moot once a transaction has been made since it includes the full public key? Then again that's a strong argument for never using the same key twice, though it's impossible to stop someone from transferring funds to you...

As far as security goes, could one figure out the public key corresponding to someone's pubkey hash by looking at the scriptSig the first time they do a transaction?

@liamzebedee does it mean it's unsafe to expose our public keys?


text:
safely delete the blockchain from .bitcoin directory
I have bitcoind installed and I'd like to free up space by deleting the blockchain from my .bitcoin directory. What set of files and directories should I delete such that the next time I start bitcoind it will recover gracefully by downloading the blockchain again?

related: Can the blk0001.dat and blk0002.dat files be deleted?

Delete the "blocks" and "chainstate" directories.


text:
Why so many warnings about importing private keys?
Blockchain.info and other products make you read dire (but vague) warnings that "you must be an expert" before you can import private keys.  What's that all about?

Importing a private key can lead to non-intuitive behaviour, and that can be exploited by an attacker.
Imagine I'm evil. I give you a paper wallet with 1 mBTC on it. You're happy and import it. I keep the private key and wait. Depending on the client/user, maybe someday you'll put some real money on there as change/received funds. Then I can swipe them right off from you. If you don't bother moving the original money off the key, I can also steal that back.
If not, then at the very least I can trick you next time into thinking you were paid by sending funds to that address. Then I can steal them right back.
Importing also tends to break backups, especially deterministic key schemes. Armory gives you one line of text for all your keys, and then 1 line per imported key. Every time you import, you'll need to redo all your backups.
Because most users don't understand these implications, wallets tend to discourage importing, and instead offer sweeping (moving the funds to an address that was generated by the wallet itself). Supports 90% of the use cases with none of the issues.

In other words, you should only import private keys that are only known to yourself.

If that's the reason for the warning, the warnings should be re-written to specifically say that any coins in the wallet are still accessible to anyone who has the private key.  It's confusing that many sources say "users should never import private keys", but then don't say why and leave users wondering how they're correctly supposed to spend coins from their own private paper wallets.

because exposing your private keys on your computer will expose them to all the viruses and keyloggers on your computer that non-experts tend to have.
thats one reason

This is not specific to Bitcoin, though. It's true of all financial authentication.

authors: Андрей Аршинов


text:
Scanning QR codes with Electrum 3.0.1
When trying to scan QR codes with Electrum 3.0.1 it asks for zbar software. I'm not sure which one to download as some of them might be unsafe. Which Zbar QR scanner should we download?

I tried to scan a QR code using Electrum 3.0.2 on Mac OS, and it told me "Cannot start QR scanner; zbar not available.". I tried it in Electron Cash 2.9.4 and the same thing happened.

Electrum does not support QR code scanning on Mac OSX as stated on download page:

Note: The QR code scanner is not supported in OSX binaries

There has been several related bugs, but as of v3.2.2 the issue has not been resolved by anyone.  Some related discussion and attempts to debug.

Ubuntu 18.04:
sudo apt-get install zbar-tools


text:
How do i get my Bitcoin Cash from Mycelium wallet?
I kept my BTC in a mycelium wallet and am looking for a way to get BCH out of it. I need instructions on how it's possible, please.

I think that this article https://en.bitcoinwiki.org/wiki/Mycelium_Wallet can help you.

I just finished following the instructions at this link
https://steemit.com/btc/@libert/step-by-step-guide-on-claiming-bitcoincash-from-mycellium-wallet-201783t112141477z
and it worked quite easily. Much easier than the previous comment.
On a side note Coinomi has very clear instructions that did not work for me on how to sweep your mycelium wallet into your coinomi wallet by obtaining the private keys from your mycelium addresses butt only the first private key had a tiny bit of funds in it I checked through over 1000 more private keys and could not find any other funds so that's when I went back to Google searching and searching and found the link above.
I think how it works when you're sweeping the funds I think you're actually moving them. As opposed to when you restore your mycelium wallet with the coinomi app using the 12 words You're simply gaining access to funds without actually moving them.

I tried that link's directions but nothing's showing up on the coinomi wallet after I input my master seed from the mycelium wallet.  Any suggestions?  Also tried the sweep feature but it isn't recognizing the format of the keys.

What if you have mycelium single bitcoin address. Its got a different back up and they dont give you the private key.

Just download Mycelium Bitcoin Cash Module. It'll add Bitcoin Cash sending functionality to your wallet.

Mycelium Bitcoin Cash Module is the first module implementing the new modular architecture.
  The module introduces limited Bitcoin Cash(BCH) accounts support which allows to discover BCH on your BTC accounts and instantly exchange it to BTC.

Sorry I can't find the link right now but the Mycelium Team stated in an answer to one of their app reviews that they'll soon also support bitcoin cash!

mycelium by default uses the seed to generate private keys. you must have this seed of 12 words (available when creating wallet, not sure if you can get it later).
you recreate the wallet in any other wallet program supporting seeding (most of them out there), then export private keys from the new program (as far as i know mycelium does not export private keys).
once you got those private keys, before you attempt to import them into bcash supporting wallet, send all your old bitcoins to completely new address. right after that, you can continue importing those old keys into a bcash supporting wallet, but in some virtual machine or completely other computer, as the wallet software of bcash can still scan your computer and do stuff with it it (there where cases reported already about this).
in short:
-use the mycelium seed to recreate wallet in other wallet software
- export private keys from that new wallet
- send old btc to completely new adress
- move to another computer
- import keys into bcash wallet

it should be possible to import the seed directly into bcash compatible wallet without doing stuff with keys though, too. in that case you must send your old btc to completelly new adress, not the HD generated one in mycelium


text:
Are desktop wallets transferable?
I know you can make a transaction across the blockchain to move your Bitcoins from say Bitcoin-QT to Multibit, but is it possible to import my wallet.dat file from Bitcoin-QT to another desktop wallet without preforming a transaction?

I think it's possible but importing private keys would work better.
All you need to import an address to a new wallet is the private key. Get the private keys of your addresses from the QT client and import them into Multibit.


text:
Why doc says importing private keys is so dangerous?
There are a lot of applications when someone would like to import a private key. However in wiki documentation they say it is very dangerous: https://en.bitcoin.it/wiki/How_to_import_private_keys

WARNING Before reading this page, users should note that messing with
  ECDSA private keys is very dangerous and can result in losing
  bitcoins, even long after the import. It is recommended that outside
  of self-generated vanity addresses, users should never import (or
  export) private keys.

and

Note that importing a key to bitcoind and/or Bitcoin-Qt may be
  dangerous and is not recommended unless you understand the full
  details of how it works.

Why is it that dangerous and what are the alternatives if you are using cold storage, a paper wallet or generating vanity addresses?
Related: Why so many warnings about importing private keys? (but it is about warnings on blockchain.info and not bitcoind). I'm not sure if the warnings are due to the same reason.

Key import by itself (from a trusted source of keys, such as your own cold storage or backups) isn't a dangerous thing. However, the vast number of ways one can cause problems for themselves through key import leads to these warnings.
Many such warnings appear to address more complex situations beyond bitcoind's scope. In this case, there can be many situations in which a weak key (e.g. from a brainwallet with bad password), or leaked key (suspicious origin, or generated by someone else) might be imported into bitcoind.
For example, the following may happen (with sample keys, of course):

5KVFiYbW5qbFfuDwrhPdsA3ALH3PmrEdQnQrpDWrqpygncbpPY4 is generated insecurely someplace (used on a physical coin, or otherwise bad origin), translating to address 1CD2nyv22gAGs8GAsdNa1rW3KinkCHgTFd.
User imports 5KVFiYbW5qbFfuDwrhPdsA3ALH3PmrEdQnQrpDWrqpygncbpPY4 and uses it in their wallet, as 1CD2nyv22gAGs8GAsdNa1rW3KinkCHgTFd in the UI.
Dumpster-diver digs up improperly-erased hard disk owned by FooPhysicalCoinForge, digs up 5KVFiYbW5qbFfuDwrhPdsA3ALH3PmrEdQnQrpDWrqpygncbpPY4 and sweeps it. Even if the address had 1 BTC on it originally and received 20BTC more, the attacker now has access to all of the funds received to it and currently spendable.

This doesn't seem to answer the OP's question, as you don't really mention why /importing/ is dangerous... rather you talk about why leaving a key unerased is dangerous.

@nmz787 That's precisely the danger of importing a key provided to a user in any way except for an immediate sweep followed by never using said key again. It can be unerased at the level of the sender/party that generated it.

what if the private key was dumped by your own system (i.e. you created a new wallet locally, transferred in funds, then put that priv key into cold storage), and later you want to revive that by importing?

@nmz787 I specifically state I am speaking about situations where weak or compromised keys are imported from outside. Although this answer is quite old I can edit it for you if you'd still like.

Perhaps a distinction between importing and sweeping a key needs to be considered. The aforementioned warnings deal with the importing of keys, and does not refer to the sweeping of keys, which moves all the coins to a new address. This method is inherently secure.

Why is the sweeping of keys insecure?


text:
Blockchain over 36GB and causing disk space issues
I want to install the bitcoind daemon on a computer with relatively little free space (about 35GB available). I thought that the blockchain was some 20 GB in size and figured that would be no problem, but I'm running into disk space issues. What I did was:

First I tried the torrent file to bootstrap the blockchain. I downloaded the whole dat file and then tried importing, but on importing it I ran into disk issues. About half of it was imported before the disk was full.
I then removed the bootstrap file and let bitcoind load the blockchain from peers. I seems that it did use the half-imported bootstrap file so the first bit was quite fast.
However, I now have 36GB in the blocks directory, and my drive is full. Still not all is downloaded!

My question is:

Is the blockchain really this big?
Are there any files I could remove, given my particular way of going about this?

I have a blk00001-00253, and rev00001-rev00253 in my blocks directory. Can I remove those rev files perhaps?

Forget about the torrent file completely. It's slower and actually requires double the disk space while it's being processed (as you've discovered).

The answer given is correct but I would add that you can also move the blockchain to external storage if you have a spare drive. You can specify the data directory like so: -datadir= on command line launch but there is no similar setting for the bitcoin.conf file so running bitcoind that way you might want to write a simple shell script to launch it for you.

Depends what you want to do. Remember, to use bitcoin you don't necessarily need a full-node. You can use many of the lightweight clients that exist out there which rely on Simplified Payment Verification (SPV). But if you want to be a full node (perhaps you're mining or you want to verify transactions yourself), then you need to download the entire blockchain which is almost 35GB large: https://blockchain.info/charts/blocks-size

Thanks. I need the full blockchain for my purposes. Weird that it is 35GB and mine is already 36GB and not yet fully downloaded.

@user on disk a few indexes are created in addition to just the blockchain data. Also depending on how you look at it, you might be comparing 1 GB as 1,000,000,000 bytes in one place to 102410241024 in another. You could consider running a pruning node, which is practically the same as a full node (including security), except it throws away some of the old history. Version 0.11 will make that possible.

Yeah I guess that accounts for the small difference. In any way the answer is: yes, the blockchain is currently ~35GB, so I'll mark this answer as accepted. Thanks!


text:
bitcoin-qt does not add blocks anymore
I am trying to catch up/synchronize the blocks in my blockchain with bitcoin-qt. However, the last block time is stuck for hours at Feb 15 04:29:18 2017 since I started bitcoin-qt the last time.

What is the reason?
The debug.log doesn't show anything supsicios.
When I start bitcoin-qt with -testnet, it does catch up.
Appendix, as per Pieter Wuille's comment, the output of getchaintips is
[
  {
    "height": 473710,
    "hash": "0000000000000000007eaaf0899877f5317cd2a480477bde88d9e0a9b57a93c8",
    "branchlen": 20592,
    "status": "headers-only"
  },
  {
    "height": 473064,
    "hash": "00000000000000000006cdfe729e4aa498a0c03f1e9810fb002e7a36a780f4d1",
    "branchlen": 19946,
    "status": "headers-only"
  },
  {
    "height": 472975,
    "hash": "00000000000000000067a24962827bc94d347066a2acec324625da67a0b10168",
    "branchlen": 19857,
    "status": "headers-only"
  },
  {
    "height": 453118,
    "hash": "000000000000000000e1823cc186c494caaced15c7761844010362e8bd280bd3",
    "branchlen": 0,
    "status": "active"
  },
  {
    "height": 229636,
    "hash": "00000000000000c42b95e4714032ca09b245830b8299d8cf5dda46f75c3755ff",
    "branchlen": 1,
    "status": "valid-fork"
  }
]

Can you post the output of the getchaintips RPC? This will not reveal any private information, just a list of which chain forks your node knows about.

@PieterWuille I've added the getchaintips output.


text:
What does "replaying blocks" mean?
When I start up bitcoin-qt, the screen says: replaying blocks...0%.
The debug.log's tail contains messages
2017-07-07 11:02:03 Rolling forward 0000000000000000010ac1a0c2f1003ae71457077a3a814a756f0b2b494e03d6 (472746)
2017-07-07 11:02:29 Rolling forward 00000000000000000124599553a07decfe065cc04f22a12fa5e5490e116242e5 (472747)
2017-07-07 11:02:45 Rolling forward 0000000000000000011da8f83f23856222693954dc38a0a203391cf51d3f1a52 (472748)
2017-07-07 11:03:04 Rolling forward 00000000000000000f382b835d682afbcbd2c248f85cbc4944bd8a3609455d3 (472749)
2017-07-07 11:03:17 Rolling forward 00000000000000000036c823c344ece1ca712257b7ed13a8fcea28f087f0a200 (472750)
2017-07-07 11:03:35 Rolling forward 000000000000000000048dbd7fa8b2732a2a1a22a5d8b9ebeaf938a96d52da41 (472751)
2017-07-07 11:03:53 Rolling forward 00000000000000000030d6c28b5cd8b7133c8a7fabc60f6ae65c646115e26237 (472752)
2017-07-07 11:04:16 Rolling forward 000000000000000000e4c2e323230fd6a266741f42aa965c86fae8205e2309ef (472753)

What does that mean?
Edit
The debug.log also says:
2017-07-07 10:50:35 LoadBlockIndexDB: transaction index disabled

I assume the transaction index should be enabled. Because it's not, this is the cause for the slow start up of bitcoin-qt.
If this is the case, how can I enable the transaction index?

I think it means it is re-validating those blocks to ensure it has the proper blockchain history. I'm not sure why this is necessary, however.

The transaction index is unrelated, and would only make things more slow.

This happens when bitcoind has processed a large amount of blocks in its dbcache but has not written them to disk before the process is exited.
See here for more details.


text:
Did Satoshi know since its publication all the applications that the blockchain would enable?
Or he only thought about Bitcoin?

Did Satoshi knew since its publication all the applications that the blockchain would enable?

I doubt it. Even the phrase 'blockchain' was coined long after the Bitcoin paper was published. However, Bitcoin uses primitives like HashCash to do something that their creators never envisioned, so I don't think he would be surprised by the ideas of Bitcoin being used for things that he didn't think of.

Did Tim Berners-Lee know all the applications that HTML would enable? No, not even close. Why? Because his invention made it possible for millions of people over the past 30 years to build upon it to create breathtaking and marvelous web applications.
Like HTML, Bitcoin is merely the foundation upon which a massive structure is being built. The core technology of Bitcoin -- the blockchain -- is the key feature Satoshi was trying to build. "Bitcoin" is simply marketing... its a name. His goal was to release the Bitcoin network as a proof of concept. He knew it would have value on its own, but he also knew that, because the project being open-source, the resulting innovation was going to be beyond his ability to predict.
If you go back and read his original correspondence on the cryptography mailing list, his ideas and attitudes leaned heavily towards a Libertarian / Austrian Economics school of thought. He wanted to build something that would empower creative and talented people to use the blockchain to create breathtaking and marvelous fintech applications.

hi, do you have a url link to cryptography mailing list?