The Private/Public key pair (aka asymetric cryptography) refers to a common cryptographic mechanism. Private and public keys are bounds together and also bound to a particular well known cryptographic algorithm like 'RSA', 'SHA', ...
Private and public key aren't just random string, in fact they have the following very interesting property :
If you ...
Sample how one-time signature works
Perhaps it helps with a short sample. Assume we are in a world where you do not need 384-bit security, but only 8-bit security (to make the example shorter). And I'll use a binary, not a ternary example.
Your private key consists of 16 parts, 8 for each bit of security (so you have 8 parts to reveal for a bit that is 1, ...
The Seed is your only local stored authentification and is never revealed in a transaction.
Private Key's are generated with your seed in combination with a key index and are needed to sign the transaction. Random 50% of the private key are leaked when signing a transaction. That's why u should never reuse an Adress.
In the most cases Private key is used as ...
First, the Coordinator is not forced to resort to key reuse. It could also issue
transactions from a new Coordinator hash (and anybody who did not update their iri would see no new milestones any more)
That being said, a new milestone is issued once per minute, meaning 1440 milestones per day. And during manual snapshots, the milestone number is rounded to ...
AFAIK, the current wallet don't support this kind of complex scenario (i.e. sending to multiple addresses simultaneously). You have to craft a proper Bundle to send funds to multiple addresses.
Case 1 :
Assume that you have 600 iotas in <MY_ADDRESS>
Assume that you need to send 200 iotas to Alice
Assume that you need to send 300 iotas to Bob
Short answer: No.
Long answer: Whether a public key can be used for encryption, verifying signatures, or both, heavily depends on the used cryptographic algorithm.
RSA is an algorithm where the same public keys can be used both for encryption and for verifying signatures. (To be honest, it is the only one I can think of right now).
Other cryptographic ...
Nobody knows that you are sending iotas to an address that was generated from the same seed, so the steps when you do that or you when send iotas to a third party are exactly the same.
(skipping steps before POW completion)
The node you are connected to receive your transaction and persist the transaction in it's local database
The node you are connected to ...
You cannot get parts of the private key using reattachments. To understand why, let's see how signing works.
First of all, there is an unsigned bundle consisting out of several transactins. To sign it, we first need to calculate the bundle hash. Only the address, value, obsolete tag, timestamp, current index and last index are used. Note, nonce, trunk/...
Your private key consists of a series of "chunks". The public key is generated by hashing each chunk 27 times.
So, 27 times hashed is considered public.
Every chunk that is hashed less than 27 times means that it reveals your private key partially (although it does not reveal any of the original trits of the private key).
For example, consider you reveal ...
A key digest is a string of trytes that is generated using a seed and a private key.
For multisig, each co-signer provides a key digest, and all of these key digests are used to create a multisig address.
The co-signers can safely share their key digest with other co-signers so that each one can independently validate the multisig address.
See this article ...
You must keep promoting the pending transaction. You should also select a properly sync fullnode. (see http://iota.dance/nodes/).
As you mention yourself, sending to a different address is a double spend, it will reveal another portion of your key... and there is absolutely no guarantee that this new transaction will confirm faster.