Bitcoin Forum
August 19, 2019, 09:15:20 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 [44] 45 »
861  Alternate cryptocurrencies / Announcements (Altcoins) / Re: IOTA on: October 22, 2015, 12:26:15 PM
2. Nodes don't need to continue to do hashing once their transaction is accepted, others will do that for them if the majority confirms those transactions that confirm others' ones.
Still I can't see why nodes would try to put more PoW into their transactions. Looks like it is enough to submit minimal PoW and have others confirm my transaction with their PoW. It is in the common interest of all users to have more PoW on the legit branch to secure the network against doublespends, but individual interest, it seems, is not aligned with the common one.

3. If a transaction happens to reference double-spending transactions then anyone can change the references.
I hope the change is deterministic? Otherwise we'll end up having many conflicting "fixes" of references.

Every transaction has 2 parts - essential data signed by the owner and references to other transactions, - the latter can be changed without transaction resigning.
This raises another concern. What if a malicious node changes references of a third-party transaction before forwarding it to peers? Different nodes will receive different versions of the same transaction that differ only in references to parents. Also, if references are not secured by signatures, nor by anything else, is it possible to reorder and even censor old transactions, thus changing the graph structure?

862  Alternate cryptocurrencies / Announcements (Altcoins) / Re: IOTA on: October 22, 2015, 12:00:37 PM

1. Could you explain in layman's terms, why capping the amount of work per transaction makes double-spend attacks less likely to succeed? It doesn't sound intuitive.

Consider two situations:
1. You need to generate 1 block with 10 zeros in front,
2. You need to generate 1024 blocks with 1 zero.

Let T be the time you need in the 1st case, R is the time you need in the 2nd. T, R are random variables, of course. Now, it is true that T and R have the same expectation, but it is *not* true that their distributions are the same. In particular, the variance of T will be much bigger. What is even more important, is the difference in large deviation probabilities.

 Assume that you need to complete you task within time (expected time)/10. What would you choose, 1 or 2, to maximize your chances? Well, better choose 1. That's quite intuitive. What is not intuitive, is how different these chances are. In situation 1, you will succeed with probability around 10% or so. However, in situation 2, it will be *very* low. Don't want to calculate, but it will be smth like 0.0000000000001... anyhow, practically zero. That's why, if you want to beat the rest of the network, it's much better to bet on "heavy" tx's, and so we avoid this kind of attacks by putting an upper limit on the own weight.

Excellent! This is perfectly clear now.
863  Alternate cryptocurrencies / Announcements (Altcoins) / Re: IOTA on: October 22, 2015, 10:41:15 AM
Are you going to produce a whitepaper?

Yes, you can see the draft here -

I'm working on a similar DAG based design and it was interesting to read your whitepaper. A few questions/concerns:

1. Could you explain in layman's terms, why capping the amount of work per transaction makes double-spend attacks less likely to succeed? It doesn't sound intuitive.

2. What is the incentive for honest nodes to keep PoW on the legit sub-tangle high enough, so that no single attacker (even ASIC-powered one) can create a fake sub-tangle that has higher cumulative weight and contains his doublespend?

3. The whitepaper says that the subtangle that contains a failed doublespend is discarded. Does it mean that all other transactions that happened to approve the doublespend transaction are also discarded? If so, an attacker would try to inject two conflicting transactions at nearly the same time. Since synchronization is not instantaneous, some users will unknowingly approve one of these two transactions before they learn about the other. If they were unlucky to approve the transaction that eventually dies, their own transactions are also discarded, correct? Then it sounds like poor user experience, since user's transaction can be effectively canceled for reasons that he doesn't control. Next, if the attacker continuously sends penny doublespend transactions, he will split the network into multiple branches, most of them will be discarded, and the network will be effectively stalled. This is DoS attack. Next, observe that when a subtangle is discarded, the PoW invested in its creation is also discarded. Then if the attacker tries to doublespend a more sizable amount at the same time, he will reduce the hashpower of the honest part of the network by DoSing it this way, and he will need less resources to produce a subtangle that overweighs this weak legitimate subtangle.

864  Bitcoin / Development & Technical Discussion / Re: Confidential Transactions, Content privacy for Bitcoin transactions on: October 11, 2015, 07:28:27 PM
You might find this doc I wrote useful if you're looking into the details: For example, the diagram at the end (page 20) of the transaction layout.

Thanks, the doc was very useful for understanding the details.
865  Bitcoin / Development & Technical Discussion / Re: Confidential Transactions, Content privacy for Bitcoin transactions on: October 08, 2015, 10:00:55 PM
x is private by virtue of being the conveyed by an ECDH key negotiation. No external communication is required. 
Do the wallets still need to connect directly, without touching the blockchain? How the receiver would learn the amount then?

(E.g. go build elements alpha, and give me an address from it and I'll send you some coins!).
Do I have to be online at the same time as you?

They're required for outputs only, and technically only when there are multiple outputs. Inputs are already known to be in range by virtue of having been created as outputs.
This is about range proofs but I asked about commitments.
866  Bitcoin / Development & Technical Discussion / Re: Confidential Transactions, Content privacy for Bitcoin transactions on: October 08, 2015, 08:29:12 AM
Given our two generators we can build a commitment scheme like this:

   commitment = xG + aH

Here x is our secret blinding factor, and a is the amount that we're committing to.  

Does it mean that x and a are to be communicated privately (off-chain) from sender to recipient of coins? Anything else that is communicated privately?

Also, are commitments required for outputs only or you need to include input commitments as well in your transaction data? If including input commitments, I wonder if it makes sense changing their blinding factors, not just copying them from source outputs.
867  Bitcoin / Development & Technical Discussion / Re: One-time signatures to prevent double spends on: July 21, 2015, 10:45:03 AM
How would this work with address reuse?

It won't.

This is normally called a single show signature.

If you search the #bitcoin-wizards logs for that term you'll see some instances of this proposal-- you might find it informative.

Found it now. #bitcoin-wizards is not high enough in google search.

Also, I don't see how this discourages double spends. If a double spender sends out his two transactions in the traditional race attack, then one will reach some miners, the others will reach other miners, if at all. However, only those nodes that receive both will know that a double spend occurred and only they can get the private key. Those nodes will not broadcast the double spends (unless they are Bitcoin XT) so the double spend transaction won't reach some of the miners. Those who do know the private key after receiving those transactions are at a disadvantage since two transactions have already propagated faster than their own double spend can. Unless they are a miner, then knowing the private key would be pointless.

And with miners, if they don't receive the double spend transaction, how do they know that a double spend occurred? A smart attacker could simply broadcast the transaction to specific nodes, nodes that he controls, so that the miners only get one transaction and other nodes before them filter out the double spend. That way, the miners can't get his private key and anyone who does get it can't do anything with it.

Quote from: gmaxwell link=
E.g. they take 1 BTC, spend it 15 times, miner takes the coins, they get 4 BTC worth of goods from the three successful double spends.

This assumes the current relay rules stay as they are, that is nodes stick to the first version of a doublespend they received (unless they implement replace by fee). If we amend the rules and make nodes accept and relay all conflicting spends (it's up to miners to decide which version eventually gets into a block), then as soon as one honest node learns about a doublespend, all others, including the merchant, will also learn about it within seconds. So if each merchant is connected to at least one honest node and waits for typical propagation latency before recognizing an unconfirmed transaction, the attacker won't be able to get 4 BTC worth of goods. 1 BTC at most, which is the same he would've achieved by acting honestly.

If the attacker is mining, or colludes with a miner, he still can get his doublespend through.

868  Bitcoin / Development & Technical Discussion / One-time signatures to prevent double spends on: July 21, 2015, 12:25:56 AM
It is well known that unconfirmed transactions are not safe because of the risk of double spend. Below is a proposal how to mitigate (not totally eliminate) this risk.

Imagine if the owner of the coin were not able to use his private key more than once, then he wouldn't be able to create another conflicting spend. We cannot take this ability away from him, however we can try to create a strong incentive (like all of Bitcoin which is built upon incentives) not to sign a conflicting transaction.

The good news is it is possible.

Bitcoin's ECDSA private keys can be used to sign any number of transactions. If you use the same address to receive coins and pay from this address for multiple purchases, you are already legitimately using the same private key to sign multiple transactions.

There is another class of signature schemes called "one-time signatures", which sounds like exactly what we need. Lamport signature is the most well known example. By nature of Lamport signature, every time you sign something you reveal a part of your private key, and security level of your second signature is half of security of the first signature. You see that despite the name, Lamport and similar signature schemes are not strictly one-time: if you take a Lamport private key with 128-bit security, your second signature will have security level 64 bit which is still moderately secure. Such slow degradation of security is not suitable for our purpose.

My idea is to modify the plain old ECDSA signature scheme and make it one-time. Here is how we can do it.

Standard ECDSA signature depends on a number k which should be kept private and never reused. ECDSA prescribes that this number should be generated anew for each new signature (randomly or deterministically per RFC 6979). If the same k is used to sign two distinct messages, the private key will be revealed. It is this nice property of ECDSA that I'm going to make use of: require that every signer commits to k at the same time that he generates his private key (and bitcoin address). That is, make k part of private key in the new signature scheme, and the commitment -- part of public key.

Below is full description of one-time ECDSA signature scheme.

Key generation:
Generate standard ECDSA private key as usual.
Generate random k.

oneTimePrivateKey = (standardPrivateKey, k)

Standard public key is x-coordinate of curve point standardPrivateKey x G, where G is generator, x is point multiplication.
Also calculate r as x-coordinate of curve point k x G (it is exactly the r from standard signature (r, s) ).

oneTimePublicKey = ( standardPublicKey, (k x G).x ) = ( standardPublicKey, r )

oneTimeAddress = base58( hash_and_checksum( oneTimePublicKey ) )

Standard ECDSA signature is (r, s). r is already known from the public key. Calculate s as usual. Since r is already known from the public key, we can drop it from the signature and keep only s.

Reconstruct the standard public key and signature by moving r from public key to the signature and apply standard ECDSA verification procedure.

The end result is, if the user tries to sign a second unconfirmed transaction with one-time private key described above, he will have to reuse k, hence disclose his private key. After his private key is disclosed, anyone can take his coins, the miners are, of course, in the best position to do that (they will not honor transactions that send the spilled coins to any address but theirs).

If the first signature is already deep in the blockchain, the second signature is harmless (unless the user had other unspent outputs on the same address).

This one-time signature scheme is most useful for securing unconfirmed transactions as any potential attacker has to consider the risk that the system strikes back and he loses his coins. Then all potential attackers without access to mining resources are probably out of the game.

Obviously, it is not compatible with address reuse. Also, wallet software has to be redesigned to treat creating a second signature on the same key as silly as posting the private key to facebook. If not forbidden in software, users can be tricked to think their transaction didn't come through for some reason, need to send it again ... private key exposed, coins lost.

Since making address reuse impossible in Bitcoin would require major modifications, and also because PoW already solves double spend problem fairly well, I don't see one-time signatures coming to Bitcoin any time soon. However, they may be a good fit for altcoins and sidechains, especially those that already have stealth addresses.

PoS currencies can use one time signatures to address nothing-at-stake issue and make double-voting too risky (double voting is essentially the same as double spending). To sign more than one block, one can derive consecutive private keys in BIP32 style from a master private key and block number.

I made ECDSA signatures one-timed by having signers commit to k. The same trick can be applied to other signature schemes that involve k, e.g. DSA, Schnorr.

This idea is not quite new, I searched and found a few publications where it was also mentioned:;jsessionid=057011325AE4FA29DFE5401D31C9AD04?doi=

869  Bitcoin / Development & Technical Discussion / Re: Replace by fee cannot solve the double spend issue on: July 13, 2015, 10:08:01 PM
Consider an instant exchange such as which processes transactions at 0 confirmations. Once they decide to accept a transaction at 0 confirms (based on some network confidence metric), they send funds in exchange for bitcoin on a different blockchain to the original sender of the transaction.

For them, replace by fee completely destroys their ability to work with 0 confirmation transactions because they cannot ever recover the funds from the other blockchain. If they counter double spent the incoming bitcoin transaction after they originally processed it, it makes no difference to the attacker at all - he still got his coins on the other blockchain.

Well, they can try to recover the funds by double spending on the other blockchain. This will be a doublespend war.

There is another point why replace by fee is dangerous:

Quote from: jedunnigan on July 06, 2013, 11:39:57 PM
....However we can make zero-confirmation transactions safe without complex trusted identity systems, ironically by making it easier to double-spend. If we implement replace-by-fee nodes will always forward the transaction with the highest overall fee (including parents) even if it would double-spend a previous transaction. At first glance this appears to make double-spending trivial and zero-confirmation transactions useless, but in fact it enables a powerful counter-measure to an attempted double-spend: the merchant who was ripped off creates a subsequent transaction sending 100% of the funds to mining fees. All replace-by-fee miners will mine that transaction, rather than the one sending the funds back to the fraudster, and there is nothing the fraudster can do about it other than hope they get lucky and some one mines their double-spend before they hear about the counter spend. The transaction can also be constructed such that the payee pays slightly more in advance, with the merchant refunding the extra amount once the transaction confirms, to ensure that a double-spend will result in a net loss for the fraudster.

Miners will love this idea. This is a huge difference to what they receive today as mining fees. Perhaps miners would secretly initiate such double spends to provoke users to send the entire transaction amount to them.
870  Bitcoin / Development & Technical Discussion / Pruning OP_RETURNs with illegal content on: February 09, 2015, 11:52:34 PM
Just researching another possible threat.
What if an individual who is angry at Bitcoin for whatever reason tries to insert some illegal content into blockchain?
There are a lot of content types that are illegal in one or many jurisdictions, for example Charlie Hebdo cartoons in Pakistan, suicide instructions in Russia, Sony PS3 signing key in the US, etc. This person would inject illegal content into OP_RETURN outputs, maybe spreading large content over several 40 bytes OP_RETURN outputs, and this content would be stored forever. He would inject it in the most open and self evident form possible, no encryption, no steganography, no fancy encoding. The content would be stored and distributed by full node operators. Their activity might not be automatically illegal while they store and distribute this content **unknowingly**. In the pre-blockchain world, it is common practice that if you run a web site that unknowingly stores and distributes some copyright infringing or otherwise illegal content and you receive a take down notice, you comply and you are ok after that. But you can't remove anything from blockchain without destroying its integrity. So a full node operator can only comply by ceasing operations, and if he doesn't comply after receiving a take down notice, he would **knowingly** store and distribute illegal content which places him in bad terms with the law.

This thread discusses pruning the offending transactions, which is not a simple thing as it would require changes to verification procedures. I understand it was never really necessary and never implemented. Even if it were implemented, it would create a mess if some nodes pruned a transaction while others did not. Also, the inputs of fully pruned transactions could be double spent.

As Bitcoin grows and becomes a business for many, the risks of illegal content become more important.
Any other ideas how to mitigate these risks (if they even exist)?
871  Bitcoin / Development & Technical Discussion / Re: How are UTXOs stored? on: January 26, 2015, 09:59:12 AM
You don't benefit but just harm the miners. Even if one of the poisoned miners find a block, it will be checked by every other full node in the network. Therefore it will be rejected as soon as the miner tries to push out his block.

The vast majority of nodes will reject the block indeed, but it is mining power that is the point of reference here, not the number of nodes. Since most of the hash power was poisoned, the offending block will be accepted by miners who control more than 50% of the total hash power. Then there are more than 50% chances that the next block will be built on top of the offending one, and so on.

The merchant who would accept the payment typically waits for 3 confirmations, that is 30 minutes. It'll likely take longer before someone notices that almost the whole network boycotts the longest chain, identify the cause, and persuade the poisoned miners to manually orphan the bogus chain.

There is one more "if" though: the merchant must be directly connected to one of the poisoned miners and not running a full node himself.
872  Bitcoin / Development & Technical Discussion / Re: How are UTXOs stored? on: January 26, 2015, 08:28:50 AM
Please describe step by step the actual attack, which things would the attack do to whom and how would they profit from doing so.  AFAICT people are just handwaving here. Actually spelling it out can help clarify your thinking or help me understand (whichever is needing improvement).

1. Obtain access to a miner machine through a vulnerability.
2. Open his LevelDB database that stores UTXO set.
3. Insert a record that contains output to one of hacker's addresses. Alternatively, find a legitimate record that contains output to one of hacker's addresses and modify its value, say from 1 BTC to 100 BTC.
4. Cover your tracks by deleting logs that show the intrusion etc.
5. Repeat the steps above against other miners until the total hash power of the poisoned miners exceeds 50% (as of today, it is 4 mining pools). You don't need to hack all of them at the same time, the attack can span months.
6. Spend the output in step 3. Make sure the transaction goes directly to poisoned miners, not through clean non-mining nodes.
873  Bitcoin / Development & Technical Discussion / Re: How are UTXOs stored? on: January 25, 2015, 09:56:36 PM
Checksum of what? Of levelDB files?
Are you sure that levelDB is perfect and immutable forever?
What if I want to use another database for storing blockchain or anoher levelDB version?

Checksum (or rather hash) of UTXO data in some standardized format independent of storage engine.

The checksum is *already* stored in blockcahin. This is a hash of latest block  Grin
It is about securing UTXO set, not the latest block which is already safe.
874  Bitcoin / Development & Technical Discussion / Re: How are UTXOs stored? on: January 25, 2015, 09:33:24 PM
This doesn't do anything to answer the OP's proposed situation though, since someone who can modify that can modify _anything_. 

Not quite anything. The safest place to store a checksum is blockchain itself since it cannot be modified without re-mining blocks.

How about this:
1. Include a hash of the current UTXO set in an OP_RETURN output of coinbase transaction.
2. Keep UTXO set strictly in memory so that it can't be manipulated by other processes.
3. Before loading UTXO set from disk (e.g. after restart) calculate its hash and check against the value stored in coinbase. Also, re-verify the block where the hash is stored.
875  Bitcoin / Development & Technical Discussion / Re: How are UTXOs stored? on: January 25, 2015, 06:06:26 PM
So, before any of the proposals is implemented, if someone manages to poison UTXO databases of a few biggest miners or mining pools that hold more than 50% of hashing power combined, he'll be able to later spend a fake output that never existed (or had smaller value) and it'll get into a block? Other miners will reject the block but they are a minority. Non-mining nodes will also reject but who cares.
876  Bitcoin / Development & Technical Discussion / How are UTXOs stored? on: January 25, 2015, 04:12:36 PM
As far as I understand, when bitcoin client starts it parses the whole blockchain back from genesis block to build UTXO database. Later when it verifies a new transaction it uses the UTXO database and doesn't read the actual blocks where the outputs come from. Correct?

How does it store the UTXO database? In memory or on disk? If on disk, are there any integrity checks to protect from a hacker silently breaking into the node machine and modifying the UTXOs to whatever he wants?
877  Bitcoin / Bitcoin Discussion / Re: Sending change to a different address, does it help much? on: January 24, 2015, 03:19:06 PM
In many cases you can ask the person paying you to split up the payment.  In other cases, you can split it up yourself.

Well, asking the paying person to split the payment might not be practical as that would force him to pay higher transaction fees.
Splitting it up yourself, I agree that would work, at the expense of blockchain bloat and UTXO bloat though.
878  Bitcoin / Bitcoin Discussion / Re: Sending change to a different address, does it help much? on: January 24, 2015, 10:39:47 AM

If you have 10 BTC (say, you received it from an exchange) and want to pay 1 BTC, your transaction will have two outputs:
1 BTC - the payment,
9 BTC - the change to another your address.


What if you received your 10 BTC in 3 separate transactions to 3 different addresses, first a transaction for 1.1 BTC, then a second transaction for 3.5 BTC, and finally a transaction for 5.4 BTC?

To make it clear, I am referring to a single 10 BTC UTXO.
This could be the case if you received it from an exchange.
This could be the case in the hypothetical world where bitcoin replaces fiat money: you would receive your pay in big chunks every week or two, then spend it for coffee, utility bills, etc.
This is not the case if you are a retail merchant: you would receive multiple small payments, then join them to pay to your wholesaler.

To significantly improve your privacy, receive your transactions as smaller amounts and use a new address for every transaction.

The new address part is easy. The problem is, when you receive a payment you rarely control how it is composed of smaller outputs.
879  Bitcoin / Bitcoin Discussion / Re: Sending change to a different address, does it help much? on: January 23, 2015, 04:45:15 PM
I know about CoinJoin but not sure people will widely use it unless it is integrated in most wallets and on by default. The majority always tends to take the easiest path no matter what it means for security and privacy.
880  Bitcoin / Bitcoin Discussion / Re: Sending change to a different address, does it help much? on: January 23, 2015, 03:57:55 PM
If you were worried about this, you could always split up the BTC before sending into equal amounts. If you wanted to make a payment of 1 BTC, you could always send 2 BTC to a new address, then send 1 BTC to another person, with 1 BTC going to a new change address.

Then the 8 BTC change from the 1st transaction is still tracked to the payer.

Additionally, it would be difficult for someone to tell for sure that you made a 1 BTC payment vs a 9 BTC payment. They could assume but won't always be correct.

Of course, it is high probability rather than certainty.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 [44] 45 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!