17
Fragments of the private key of that reused address are leaked. An attacker could find a bundle hash (via brute-forcing) that can be signed with the leaked fragments. Luckily for the user, the window for the attack is short (only while the spending transaction is not confirmed). But if more iotas come to the reused address the attacker can spend them right ...
15
To expand on CFB's answer, because IOTA uses Lamport signatures, half of the private key is leaked each time. This halves the security level of the address (from 54 trytes of security to 27 trytes for a typical address with security level 2), making it exponentially easier to brute force the remainder of the private key with each key reuse. While after a ...
12
You should never send iota to an address that was already spent. This will make it possible for an attacker to steal your iotas. This rule is uninfluenced by any snapshot.
The problem after a snapshot is, that every node deletes the transaction history, only the balances are saved. Usually your wallet doesn't show any spent addresses anymore (thus ...
11
First of all, there seems to be a misconception in your question. If you spend 2 iotas from an address with 10 iotas, that address will not then contain 8 iotas, the address will actually be empty and will be 'struck out' in your wallet history. The 8 iotas are instead sent to a new 'change address'. This is why users do not have to worry about address reuse ...
8
How can I safely withdraw the funds a second time ?
Second withdraw will be less secure. The security decrease exponential with every withdraw. There is nothing you can do against that.
How can I ensure that people do not emit transactions to an address that has already been used-up?
As far as I know, there is nothing in IOTA protocol that prevent an ...
8
Every double-spending is an address reuse but not every address-reuse is a double-spending.
Let's say you have an address with a balance of 100i
Double Spend
You send 100i from the address to another address and 100i from the address to yet another address.
or
You send 40i to from the address to another address and 70i from the address to yet another ...
7
No.
The data signed in a transaction don't include parent and branch transaction hash.
So when you reattach a transaction the signature is unchanged. It means that the portion of the private key disclosed when you reattach is exactly the same as the portion disclosed during first "attach to tangle".
This design choice (to not include parent and branch ...
7
According to this answer to another question, I can just reattach my transaction again without signing it, so the answer is no. I cannot be forced to reuse my address for spending this way.
7
M2M Payments
2 Machines: Alice and Bob
Alice wants to give 5 IOTAs to Bob
Alice sends an address request to Bob:
Depending on the kind of machines this can be achieved in various ways
via http GET: Web APIs
via Tangle: for Machines that only know each other through the Tangle
Alice sends 0-value-transaction from a previous address of Bob with message "...
6
The "problem" is, anyone is free to send funds to any address they want, even if this address has been emptied before (the protocol is agnostic to the source & destination address).
A partial solution/safeguard could be a warning message in the GUI wallet.
In any case, as noted here https://iota.stackexchange.com/a/441/249 there is a future plan to ...
6
No, because when you attach an address, a zero-value transaction is done to the address. I.e. it's an incoming transaction to the target address and doesn't reveal the private key.
5
Post-quantum cryptography is a fairly young field, and while there may be post-quantum signature schemes that are not one-time signatures, I don't know of any (feel free to correct me here).
A method to create "reusable" signatures from one-time signatures is the "Merkle signature scheme", which is also used by the Coordinator to sign its milestones. The ...
5
With every spend a random 50% of the private key is exposed. The reason that it is a one-time signature follows from what a second spend can reveal:
The overlap of the 2 random 50% reveals can be anywhere from 0% to 100%. Since it is random, the distribution for this will be on a bell curve.
Which makes 0% overlap (left/bottom of bell curve) and 100% (...
5
You should send as soon as possible all the IOTA from that specific address (say ADDRESS9X) to another address of yours from which you never sent (say ADDRESS9Y). If this transaction succeeds in being confirmed by the majority of the network (or by the COO as it is now) you are OK.
But how do you do this with the current wallet software?
Let's assume you ...
4
As far as I know
Lets say you were receiving donations on Address X, my recommendation is to not use this address till you REALLY need to withdraw from it.
After you withdraw from address X, make sure you never use it again to send/receive funds from/to address X.
Generate a new address Y and update donation address wherever you've posted it.
Another ...
4
In iri 1.4.2 an API call wereAddressesSpentFrom was introduced. This (and later) iri versions come with a list of previously spent addresses bundled. When the API function is called, both the current tangle (after last snapshot) and this list are checked to find transactions that spent from that address.
As a conclusion, your address is most likely on that ...
4
Disclaimer: I'm still learning Iota specifications, so take this answer with a grain of salt
We assume that you re-use your key for a transaction that is new and different from the previous (aka hash(tx1) != hash(tx2))
Best case scenario : only one new bit is revealed, leaving 49.8% of your private key to guess, reducing the computations needed to 2^255.
(...
4
When you press the button "Generate new address", this is what happens:
generate new private key from the seed
generate address from the new private key
send a 0-value transaction to the address
Your Iotas remain on the old addresses, where they were before.
If your old addresses are compromised for some reason, you can send all your Iotas to the new ...
4
The foundation has used snapshots in order to move at risk funds from vulnerable addresses to new addresses.
A snapshot, currently, is completely manual, and is basically a database of addresses and how much IOTA is stored at each of them that every node must agree to load. As the nodes are cooperative with the devs right now, they are willing to accept the ...
3
When sending a transaction, and another transaction of the wallet is still pending, you will usually have to wait.
In case your first transaction does not exactly use up the amount of your first few addresses, the change will be sent to a new address of your wallet, so that you do not have to reuse the key of the address for spending the second part. As ...
3
Sergey, there should be no serious risk.
Here is a step by step process:
1) On Wallet B, generate a new address.
2) Once it is generated, send that address to the computer with Wallet A, via email or otherwise. You are at no risk publically sharing the address.
3) In Wallet A, go to the send tab and send the amount of IOTA you want to send to that ...
3
Client ask to the service provider for a valid address. Service provider decide according it's own internal policy the address where this particular client can send funds (it can be a new one).
The client send funds to that address.
An interesting use case is presented in this video. In few words: a car charging station where all data related to the ...
3
As https://iotasupport.com/how-addresses-are-used-in-IOTA.shtml explains:
The generated addresses are part of a sequence of one time(!) keys generated from a single seed. Using multiple addresses of one seed in parallel is generally not a good idea and not the right way to use them. As @Zauz already explained, use one seed per "sensor" and transfer the ...
3
The coordinator uses Merkle tree based signature scheme which allows to sign multiple messages with the same public/private key pair. This Merkle tree contains 2^20 keys. That means that the coordinator is able to sign up to 1 048 576 milestones without key reuse.
To better understand how this signature sheme works look at here: https://www.imperialviolet....
2
For now, you need to make sure that you consider an address a temporary place to receive funds for the exact reason you bring up: You will be compromising your security by withdrawing from a static address multiple times.
There have been discussions for a future possibility of creating "alias" addresses. An alias would be able to dynamically move between ...
2
Obviously, there are a lot of solutions to your problem but I think best practice would be to give each device it's own seed and additionally store all the seeds in a local database in your company so that you can check their balances and withdraw from their account if needed. The withdrawal would work automatically.
e.g. you have an interface where you see ...
2
This is meant to be a temporary measure, until a better wallet comes along. Once everyone is using a "stateful" wallet that remembers the addresses used in the past and avoids their reuse, there will be no need for this global list anymore.
From https://github.com/iotaledger/iri/issues/503:
After a snapshot, old transactions are removed from the database,...
2
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/...
2
Zero value transactions don't need to be signed but you can sign them, either by mistake or by using a buggy library and in this case: it is unsafe to re-use the same address.
I can't find the reference right now, but I think that a bug like that was once reported with js library. (it was probably with the old js library)
Only top voted, non community-wiki answers of a minimum length are eligible
