Bitcoin Forum
September 24, 2018, 12:34:27 PM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. More info.
 
  Home Help Search Donate Login Register  
  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 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 ... 238 »
841  Bitcoin / Development & Technical Discussion / Re: Confidential Transactions, Content privacy for Bitcoin transactions on: June 11, 2015, 02:04:02 AM
Since the vast majority of transactions will be <42.94967295 BTC, almost all transactions will have exponent zero. So, transactions with exponent >0 will stand out and be much less anonymous. And the inputs and outputs to coinjoins will need to have the same exponent.
Nothing against it, the space saved is worth the loss of anonymity for very large transactions. But it is probably best to warn people about it so that no one uses confidential transactions incorrectly.
Also, if I have several inputs with different exponents (let's say 0,1 and 2) and I want join them into a single ouput, will the protocol force me to have two outputs (with exp 0 and 2) or will it round down the amount?

Inputs do not have an exponent.  The exponent is a property of the range proof, not of the values themselves. They work by scaling the basis the proof operates over.

Right now elements alpha wallet only lets the exponent be changed by a config file setting.   

Edit2: Speaking of which, is this going to make it to Bitcoin core or is this expected to remain on a sidechain?
This exactly?  No-- but some optimized, mature, and superior version... sometime in the future? I certainly plan to work towards that end. There are other people who work on software in this space which wouldn't support it, however.

Aside, as TierNolan pointed out-- this composes perfectly with coinjoin and coinswap, and the interface is setup to facilitate coinjoin already; in coinjoin the participants need not learn each others values.  And in the case of coinswaps the swap transactions can be made indistinguishable from ordinary payments to a single key due to the switch to schnorr signatures.
842  Bitcoin / Development & Technical Discussion / Re: Confidential Transactions, Content privacy for Bitcoin transactions on: June 10, 2015, 03:38:49 PM
It seems the public/blinding key operates on a per-wallet basis.  Doesn't that basically kill privacy?
No, because it doesn't show up on the network; though sure it's not ideal-- it was just an implementation expedient: that has no impact on the consensus behavior, and it can be fixed to have one blinding key per scriptpubkey.

Is the exponent also encrypted? And if so, could you give some more detail on how you deal with amounts with different exponents?
No-- it could be, but the overhead of that is quite considerable.  The exponent is public (note how it's shown on the getrawtransaction view), and just a property of the range proof, not the value itself-- so there is no complication in combining. It's set to whatever value the user wants, using it doesn't restrict the values you can send, though if your exponent is >0 your least significant digits are non-private.

843  Bitcoin / Development & Technical Discussion / Re: Confidential Transactions, Content privacy for Bitcoin transactions on: June 10, 2015, 03:51:01 AM
Interesting ~ this probably sounds anti-privacy a bit for me to ask perhaps at this stage :-) but do you have a screencap of what it looks like (GUI) when this process (confidential transactions as described thus far in your post) is being done?  
(Note:  I haven't dug into Elements... yet. :-) )
There is nothing much to see.

You just have an address. You send coins to it.  The fact that the world can't see the values is basically invisible to the user.  Looks just like testnet. From the CLI you can see more.

Here is an example where I send 0.25 testnet to myself.


$ ./alpha-cli getnewaddress
22E8QKHaTijFemPDwKvAk9qoTgagPfp8nBQiry87MMU1h2gQbF9xzLoyG8oWnakxEcPqQmhDtd2Wrut Cy
$ ./alpha-cli sendtoaddress 22E8QKHaTijFemPDwKvAk9qoTgagPfp8nBQiry87MMU1h2gQbF9xzLoyG8oWnakxEcPqQmhDtd2Wrut Cy 0.25
ab4201ee651c1396d35d799e68d59f3bb75581cc7fff1deed5efaf670973fbc9
$ ./alpha-cli listtransactions "*" 2
[
    {
        "account" : "",
        "address" : "22E8QKHaTijFemPDwKvAk9qoTgagPfp8nBQiry87MMU1h2gQbF9xzLoyG8oWnakxEcPqQmhDtd2Wrut Cy",
        "category" : "receive",
        "amount" : 0.25000000,
        "vout" : 0,
        "confirmations" : 0,
        "txid" : "ab4201ee651c1396d35d799e68d59f3bb75581cc7fff1deed5efaf670973fbc9",
        "walletconflicts" : [
        ],
        "time" : 1433908060,
        "timereceived" : 1433908060
    },
    {
        "account" : "",
        "address" : "22E8QKHaTijFemPDwKvAk9qoTgagPfp8nBQiry87MMU1h2gQbF9xzLoyG8oWnakxEcPqQmhDtd2Wrut Cy",
        "category" : "send",
        "amount" : -0.25000000,
        "vout" : 0,
        "fee" : -0.00005479,
        "confirmations" : 0,
        "txid" : "ab4201ee651c1396d35d799e68d59f3bb75581cc7fff1deed5efaf670973fbc9",
        "walletconflicts" : [
        ],
        "time" : 1433908060,
        "timereceived" : 1433908060
    }
]
#then we can see how the world sees it.
$ ./alpha-cli getrawtransaction ab4201ee651c1396d35d799e68d59f3bb75581cc7fff1deed5efaf670973fbc9 1
{
    "txid" : "ab4201ee651c1396d35d799e68d59f3bb75581cc7fff1deed5efaf670973fbc9",
    "version" : 1,
    "locktime" : 0,
    "fee" : 0.00005479,
    "vin" : [
        {
            "txid" : "76c4b906eaebdfc7685d1870aa3c4d57c8dce2fe7b924a7147c410ebffa8bee2",
            "vout" : 0,
            "scriptSig" : {
                "asm" : "0c0315abc52bced031a61ef1d8987470794540e46890b25b1f0f2b73b39d85ca37056e60fbf9a33 70c11ef7229575d937fd2935c9024ed2b1bc4a6fd473d3a9e01 0359134c3055c290a7a0499f0dfb78742ce964c1c4c8e17407898d5d05956c894e",
            },
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value-minimum" : 0.00000000,
            "value-maximum" : 42.94967295,
            "ct-exponent" : 0,
            "ct-bits" : 32,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 fd23ecdd4fb918bd88a319294b1f0ede5f701165 OP_EQUALVERIFY OP_CHECKSIG",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "n4bSHiZXaApHquce1KEB8tfCZH7ZpDnUYe"
                ]
            }
        },
        {
            "value-minimum" : 0.00000000,
            "value-maximum" : 42.94967295,
            "ct-exponent" : 0,
            "ct-bits" : 32,
            "n" : 1,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 fd5eff1963631488f624513719e866d92eae83e5 OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a914fd5eff1963631488f624513719e866d92eae83e588ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "n4cf44LWhzi5KtbTaA1YHFBLWtgn89TF4K"
                ]
            }
        }
    ]
}

844  Bitcoin / Development & Technical Discussion / Re: Confidential Transactions, Content privacy for Bitcoin transactions on: June 09, 2015, 04:35:23 PM
Taint tracking is inherently against the fungibility property of money.  
Perhaps you've not caught on that this makes coinjoins and coinswaps tremendously more private and useful; since joining with anyone at any time improves your privacy, with no need to coordinate values. Smiley

You can think of it in these terms:  CoinJoin and CoinSwap are efficient metadata privacy protection systems, but their effectiveness is undermined by the content not being private.  CT is a content privacy system. The two compose very nicely. (And the RPCs in elements should be all setup to integrate with external coinjoin.).

If this materializes, will we see two kinds of Bitcoins traded in exchanges, standard Bitcoins that trade at $x, and tainted Bitcoins that have been in the privacy sidechain trading at $x/2 or so?

OP, would you feel comfortable putting all your BTC through that sidechain?

Uh. Interesting position, (checks posting history), ah. Thanks for taking the time to step away from your ordinary posting in Dash/Darkcoin threads to chime in here.   I reject your premise: A bitcoin system where fungibility had failed enough to produce the situation you described would have already failed as a money. as that outcome would be untenable.  It's also not a theory that is well supported by current practices as there seems to be little such effect for coins moved through a variety of altcoin exchanges which are rumored to be primarily frequented for (inept) money laundering purposes.
845  Bitcoin / Development & Technical Discussion / Re: Elements Project testnet sidechain alpha released on: June 09, 2015, 02:25:02 PM
Does the standard client do that?  Could a non-functionary produce the fraud proofs?
It can! And it was mandatory that it did until right before the release, when we realized that syncing a new testnet node took a really substantial majority of the time it took to set it up and try it out.  Under an assumption that many people who would like to play with it don't already have testnet running, we thought that the ability to try it out trumps security for this application and added a switch and defaulted it off.

You can turn it on if you have testnet running;  in your config for alpha, add rpcconnect=127.0.0.1 rpcconnectport=18332 tracksidechain=all txindex=1 blindtrust=true  (assumes the same rpcuser/rpcpassword).



Quote
Does the federation just spend to a change address when done?
Yes, well multisig change.

Quote
So, 10 blocks is to protected against minor re-orgs on testnet and the 144 blocks is to protect against larger re-orgs and give a guaranteed window to broadcast the fraud proof.  There could be an added protection by requiring that 100 testnet blocks happen too.  That could be a federation rule though.
Correct. The ten you can think mostly as dos resistance where someone makes one block forks constantly just to force the network to constantly deal with fraud proofs.

Miners (or in this case the blocksigning functionaries) who happen to be watching both networks could also IsStandard-like enforce the integrity of the initial spends, which would prevent most of the potential fraud from showing up in the first place; but the design is such that the two networks don't generally need to be monitoring each other, or only do so in very very loosely coupled way.
846  Bitcoin / Development & Technical Discussion / Re: Elements Project testnet sidechain alpha released on: June 09, 2015, 01:47:53 PM
Peer coin had a system where they had a centralised block signing server (plus POW and POS for minting).  The plan was to remove the centralised server once the coin had matured sufficiently.  I am not sure if they still have it though.  A quick Google suggests it went from enabled by default to disabled by default.
They gave it the unfortunate name "checkpoints" and it's required in the system and can't simply be turned off, and was made much more fundamental over time due to attacks. Sad Also, it's a single key-- not a arbitrary scriptpubkey. 

Quote
Speaking of which, was the off-by-one bug in the difficulty code fixed?
well, its difficulty is always 1  sooo in some sense, yes? Smiley

Quote
In seriousness, I think the big one would be UTXO set commitments (or just commitments in general).  That isn't a hard-fork, but would be much nicer if it was implemented that way (with a tweak to the merkle tree).
Yep, I wanted to avoid a bunch of scaling tools in this first cut to avoid this getting confused as itself some kind of response in the blocksize debate. So the only scaling related thing in it is the witness separation. It would be a fine thing for playing with some kinds of scaling tools; though the scaling ideas that are mostly centered around incentives alignment, not so much.  Things like txo commitments, sure.

Quote
You have to prove that it is buried deeply enough in the testnet chain before accepting?  
It's required to be 10 blocks deep in testnet.

Quote
Do the signers do any extra checking for re-orgs in testnet?
All nodes that have a local testnet node running (and enabled, e.g. with the blindtrust=false) setting, will watch for reorgs and generate special fraud proof transactions to advise the network of a transfer that got reorged out. They have 144 blocks on the sidechain to get a proof in to abort the transfer.

Quote
What is the point of the genesis block then?  This is to simulate minting fees?
It basically fits the "coins can appear magically when a script says so" into the existing Bitcoin Core software framework... (consider handling reorgs and such).  It was _much_ easier to implement was "well the potential coins were there all along, but they were just held in care of this magic script" than coins that appear out of nowhere.

Quote
Testnet to elements

You spend testnet coins to a special address
More or less, you perform a little ritual to generate a pay-to-contract p2sh address for the fedpeg functionaries.  Then you pay to that. It's an ordinary (p2sh) testnet address. At this point the only person in the world that can determine you are moving coins to the sidechain is you, because only you know the nonce used in your contract.

Then after its 10 blocks deep on testnet you show up on the sidechain and present a proof that coins were paid on testnet according to the rules, and barring no reorgs that break things; the coins are yours 144 sidechain blocks later.

Quote
Elements to testnet
Federation releases testnet coins?
Right, you make a special transaction on the elements chain and the functionaries follow its instructions and pay according to it.
847  Bitcoin / Development & Technical Discussion / Re: Elements Project testnet sidechain alpha released on: June 09, 2015, 12:54:28 PM
Why have signed blocks?  Is that just to ensure (roughly) 10 mins per block, without having to worry that someone hammers the experiment with ASIC hashing power?

Use of the fedpeg results a centralized trust.  OTOH, it gives security properties that are pretty good so long as that trust isn't violated.  Since the system already can't survive a violation of trust there that why not use a similar mechanism for the consensus?-- and gain security against the fact that very small POW secured networks are really only secured by the indifference of attackers.   People do frequently reorg testnet, which can be pretty obnoxious if you're not in the mood for reorg testing.  There are also some interesting ideas in the area of combining both kinds of consensus that haven't been fully explored or implemented yet.

It should be noted that the fedpeg federation and the blocksigning federation don't have to be the same participants, though they are currently in elements-alpha right now. The software implementing the two things is separate apart from sharing some config files.

Quote
When you say that this could used to try out other stuff, do you mean that you may try out other hard forking changes or that the framework could be used by other side chains for different hard forking modifications? 
Both.

Quote
Does the withdraw proof opcode mean that outputs can work as accounts.  The 21 million from the genesis can be drawn down without spending the entire 21 million coins.
No, the withdraw proof is the sidechain verifying the deposit into it from testnet the fedpeg functionaries are not trusted for that.
848  Bitcoin / Development & Technical Discussion / Re: Elements Project testnet sidechain alpha released on: June 09, 2015, 11:56:50 AM
On the sidechain side, a 21M UTXO entry is awarded to the functionaries, who transfer coins out of it whenever transfers on the Bitcoin side into the sidechain happen.
Actually that is not the case for the testnet->sidechain direction.

Here is the transaction in the genesis block on elements-alpha:


{
    "txid" : "0377d218c36f5ee90244e660c387002296f3e4d5cac8fac8530b07e4d3241ccf",
    "version" : 1,
    "locktime" : 0,
    "fee" : 0.00000000,
    "vin" : [
        {
            "coinbase" : "04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f7 2206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73",
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 21000000.00000000,
            "serValue" : "00000000000000000000000000000000000000000000000000000775f05a0740000000",
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 9eac001049d5c38ece8996485418421f4a01e2d7 OP_WITHDRAWPROOFVERIFY",
                "hex" : "206fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000149eac001049d 5c38ece8996485418421f4a01e2d7b3",
                "type" : "withdraw"
            }
        }
    ]
}


On the testnet side, the fedpeg is used for lack of enough smart contract support in testnet;  on the alpha side it uses the actual 2WP in the network.

The spend of this output looks like this:


$ ./alpha-cli getrawtransaction eabe26aba6286e1ee439baedeb75094ec0bcdaf54ed9481d9d2183e8a6424755 1
{
    "txid" : "eabe26aba6286e1ee439baedeb75094ec0bcdaf54ed9481d9d2183e8a6424755",
    "version" : 1,
    "locktime" : 0,
    "fee" : 0.00000000,
    "vin" : [
        {
            "txid" : "0377d218c36f5ee90244e660c387002296f3e4d5cac8fac8530b07e4d3241ccf",
            "vout" : 0,
            "scriptSig" : {
                "asm" : "75029000a1 81 5032534894ffbf32c1f1c0d3089b27c98fd991d5d7329ebd7d711223e2cde5a9417a1fa3e852c57 6 0300000042e1a5148148b706b3418aea0e2ed0fe49919439553429a828ed1a000000000091dab31 b6897b3a6e50ce86914ae69e4b7a39a600c128c9df5718a78075f8b32d7707555c0ff3f1abf1e48 92c708000010b163fb32006e22e1956cb50d15d75f55d68b36ce089bf56e8739b72c6b4c1c4910f 7e449e7779bfebe825eea12559dc48ec09633551c9516447be79b84b1113dbb09a75b2bd2031b19 fed231f5c8dda7a4aef7319a9dd6b0bba425bddc270f2c03bb2c3fad7fe303d2fff3adeec4d7771 5d78b642e8b0751346774e0e00f50901dd3779d3a7a7d9f04c3b8853c0fa94e9951fd18ccd2912d fbb53ea243ccc713d0e24e2be9e544119a73807c2188ee3b374bd8eb109537253102b61087b801b f8c9dc00bddca2cf573851222de0915b143c5048c625b515271771a9e19512e6ba455ed29011b2e f070015a2fe10fc4baa5478503e9853733168c240929e0ba05ff5247d55530039e023110c7411ff 46025947347162beff471e1c1ee9086f6b522234147d959379d4c03bd0ef089dbb7352c6bb8c273 4318ea14f3b0fbb04327cb2a0322955ea8b8c2511b62e5e3b055253164243b4572d6580bbda4858 cc00c53306fab6fbde55eea4f43e67a34ec2f461e259c4b2c47835e6d813efec769b8ef2ff38db2 5c32567e191886702a7e49277601465b68fe008b682b1885a20d44ba2021630ec49c17089b794c5 c7d1d5b6ee83f f494d11a11637bb2debec3f4f9d6c7c7efe9995a6a3f35fd46e6ea1edc3315f48115bc6526ca2d1 7b96480e2f065efe8c01d03b378dab1e2eab8da6dfd0a815117f6ff1fcad2597ed7b480dd2d04ff 1f1b00 2 01000000024be4804596920c8de3a710978a90afa750fa25a723e67c1bf2b8e1802aab7f4c00000 0006a47304402200975c7747078f5d6712ab5cb513c0a0eff039595b2a1866d631700fc469162c5 022046322286c516bd02c4f74b24009ee8d74c46778c0f391a0a030e632752be4fde012103eb6fb 439cb6c013f5d167d3a3c3effe4ae6a60a52887889782a24662ce12d789feffffffcaee3571009f f7d46b541350210c4e4b7a131218bb7fb474fb3c93599a2ea424000000007000483045022100b3c c96b65e3ef6887966ef6b65ea901b2259862d93b37e7bbc2cd7ea5f6130f702205107f1b523363c 5fe8488fb50b5c8a7981d8da09a1ddf6ac68e10f9591620a6a0125512102fc960ac6ef2feff9439 275bd187061908e738943c6517180ff954861e12f41d051aefeffffff02c08df602000000001976 a914164c0f03d4c8fe45596d1c67a1f8115196618da088ac00e1f5050000000017a91475e1f5636 6999fa7060d943a45ba42e065b097958759d30600 1 1 01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff270365d3061a4d696e656420627920416e74506f6f6c200f5fbc1620557570d70100000000b3 0800ffffffff0188cfb557000000001976a91424e677cc1018907dc33dc8945aa35d2704ef090a8 8ac00000000 1",
            },
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 1.00000000,
            "serValue" : "000000000000000000000000000000000000000000000000000000000005f5e1000000",
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_IF 447333 bf01b88710b6023125379510ebd84b373bee88217c80739a1144e5e92b4ee2d0 1 0 9eac001049d5c38ece8996485418421f4a01e2d7 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_REORGPROOFVERIFY OP_ELSE 144 OP_NOP3 OP_DROP OP_HASH160 d7329ebd7d711223e2cde5a9417a1fa3e852c576 OP_EQUAL OP_ENDIF",
                "type" : "withdrawout"
            }
        },
        {
            "value" : 20999999.00000000,
            "serValue" : "00000000000000000000000000000000000000000000000000000775f054115f000000",
            "n" : 1,
            "scriptPubKey" : {
                "asm" : "6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 9eac001049d5c38ece8996485418421f4a01e2d7 OP_WITHDRAWPROOFVERIFY",
                "type" : "withdraw"
            }
        }
    ],
    "blockhash" : "a94f95cc47b444c10449c0eed51d895e4970560c4a1a9d15d46124858abc3afe",
    "confirmations" : 1708,
    "time" : 1433792346,
    "blocktime" : 1433792346
}


Which encodes a testnet transaction, which is pay-to-contracting the fedpeg federation, and shows it is a member in a testnet block, most of the separate pushes you see are it walking the hashtree for that membership proof.
849  Alternate cryptocurrencies / Altcoin Discussion / Re: Anonymity in the Mini-Blockchain scheme on: June 09, 2015, 10:40:01 AM
Hi, All-- 

By an interesting coincident of timing bffranca asked me two days ago to comment on his latest document.   I pointed out some problems with the variable selection in the description of the range-proofs that was making it hard for me to follow what he was describing, and that the particular discussion didn't appear secure (the hashes only occurred once in the verification equation so the proof appeared to be vacuous), this may just be a misunderstanding on my part caused by the equation markup mistake; I'd elaborate further but the document is down. I certainly don't blame Bffanca there-- Adam's post that described these proofs was dense and not easy to decode. My own approach was to first reinvent them from scratch, along the way I came up with a new ring signature generalization and a construction that is highly efficient.

At the same time, I've been working for some time on a similar system for Bitcoin which I've posted about here: https://bitcointalk.org/index.php?topic=1085273.msg11572844#msg11572844 which may be of some interest to some.

I had no idea that Bffanca was continuing this work after the first pass where Adam and I pointed out the need for range proofs until his recent contact.  Had I know about it previously I would have shared my progress earlier!  In any case, all my work is public now, along with a reasonably high performance implementation of the crypto and an integration into a testnet sidechain.

I'm not convinced that I've extract all the efficiency possible from this scheme yet; I was still exploring the use of balanced signed digit encoding (e.g NAF) to try to get the a further decrease... but wanted to get a working system out for people to play with and that meant I couldn't just keep optimizing forever.

850  Bitcoin / Development & Technical Discussion / Confidential Transactions, Content privacy for Bitcoin transactions on: June 09, 2015, 10:18:56 AM

I mentioned that I was using the new Borromean ringsig as a building block for a larger cryptosystem, Here it is:

Confidential Transactions

One of the most powerful new features being explored in the Elements sidechain is Confidential Transactions, a cryptographic tool to improve the privacy and security of Bitcoin. This feature keeps the amounts transferred visible only to participants in the transaction (and those they designate).

The security of the Bitcoin ledger is made possible by universal verification: each participant individually and autonomously verifies that each transaction is valid, without trusting any third party.  An unfortunate side effect is that all the transaction data must be conspicuously public so it can be verified, which is at odds with the normal expectation of privacy for traditional monetary instruments.

Insufficient financial privacy can have serious security and privacy implications for both commercial and personal transactions. Without adequate protection, thieves and scammers can focus their efforts on known high-value targets, competitors can learn business details, and negotiating positions can be undermined. Since publishing often requires spending money, lack of privacy can chill free speech.  Insufficient privacy can also result in a loss of fungibility--where some coins are treated as more acceptable than others--which would further undermine Bitcoin's utility as money.

Bitcoin partially addresses the privacy problem by using pseudonymous addresses. If someone does not know which users own which addresses, the privacy impact is reduced. But any time you transact with someone you learn at least one of their addresses. From there, you can trace out other connected addresses and estimate the values of their transactions and holdings. For example, suppose your employer pays you with Bitcoin and you later spend those coins on your rent and groceries. Your landlord and the supermarket will both learn your income, and could charge you higher prices as your income changes or target you for theft.

There are existing deployed techniques that further improve privacy in Bitcoin (such as CoinJoin, which merges the transaction history of users by making joint payments), but the utility of these techniques is reduced by the fact that it's possible to track amounts.

There have been proposed cryptographic techniques to improve privacy in Bitcoin-like systems, but so far all of them result in breaking "pruning" (section 7 of Bitcoin.pdf) and result in participants needing a perpetually growing database to verify new transactions, because these systems prevent learning which coins have been spent. Most proposed cryptographic privacy systems also have poor performance, high overhead, and/or require new and very strong (and less well understood) cryptographic assumptions.

Confidential Transactions improves the situation by making the transaction amounts private, while preserving the ability of the public network to verify that the ledger entries still add up. It does this without adding any new basic cryptographic assumptions to the Bitcoin system, and with a manageable level of overhead.

CT is possible due to the cryptographic technique of additively homomorphic commitments. As a side-effect of its design, CT also enables the additional exchange of private "memo" data (such as invoice numbers or refund addresses) without any further increase in transaction size, by reclaiming most of the overhead of the CT cryptographic proofs.


The technology behind Confidential Transactions
A high level technical primer


This work was originally proposed by Adam Back on Bitcointalk in his 2013 thread "bitcoins with homomorphic value". To build CT I had to implement several new cryptosystems which work in concert, and invented a generalization of ring signatures and several novel optimizations to make the result reasonably efficient.

The basic tool that CT is based on is a Pedersen commitment.

A commitment scheme lets you keep a piece of data secret but commit to it so that you cannot change it later. A simple commitment scheme can be constructed using a cryptographic hash:

  commitment = SHA256( blinding_factor || data )

If you tell someone only the commitment then they cannot determine what data you are committing to (given certain assumptions about the properties of the hash), but you can later reveal both the data and the blinding factor and they can run the hash and verify that the data you committed to matches. The blinding factor is present because without one, someone could try guessing at the data; if your data is small and simple, it might be easy to just guess it and compare the guess to the commitment.

A Pedersen commitment works like the above but with an additional property: commitments can be added, and the sum of a set of commitments is the same as a commitment to the sum of the data (with a blinding key set as the sum of the blinding keys):

  C(BF1, data1) + C(BF2, data2) == C(BF1 + BF2, data1 + data2) C(BF1, data1) - C(BF1, data1) == 0

In other words, the commitment preserves addition and the commutative property applies.

If data_n = {1,1,2} and BF_n = {5,10,15} then:

  C(BF1, data1) + C(BF2, data2) - C(BF3, data3) == 0

and so on.

Our specific Pedersen commitments are constructed using elliptic curve points. [The reader need not understand elliptic curve cryptography, beyond accepting the black box behaviors I describe here.]

Normally an ECC pubkey is created by multiplying a generator for the group (G) with the secret key (x):
  Pub = xG

The result is usually serialized as a 33-byte array.

ECC public keys obey the additively homomorphic property mentioned before:

   Pub1 + Pub2 = (x1 + x2 (mod n))G.

(This fact is used by the BIP32 HD wallet scheme to allow third parties to generate fresh Bitcoin addresses for people.)

The Pedersen commitment is created by picking an additional generator for the group (which we'll call H) such that no one knows the discrete log for H with respect to G (or vice versa), meaning no one knows an x such that xG = H. We can accomplish this by using the cryptographic hash of G to pick H:

    H = to_point(SHA256(ENCODE(G)))

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.  You can verify just using the commutative property of addition that all the relationships given for an additively homomorphic commitment scheme hold.

The Pedersen commitments are information-theoretically private: for any commitment you see, there exists some blinding factor which would make any amount match the commitment. Even an attacker with infinite computing power could not tell what amount you committed to, if your blinding factor was truly random. They are computationally secure against fake commitment, in that you can't actually compute that arbitrary mapping; if you can it means you can find the discrete log of the generators with respect to each other, which means that the security of the group is compromised.

With this tool in hand we can go and replace the normal 8-byte integer amounts in Bitcoin transactions with 33-byte Pedersen commitments.

If the author of a transaction takes care in picking their blinding factors so that they add up correctly, then the network can still verify the transaction by checking that its commitments add up to zero:

    (In1 + In2 + In3 + plaintext_input_amount*H...) -
     (Out1 + Out2 + Out3 + ... fees*H) == 0.

This requires making the fees in a transaction explicit, but that's generally desirable.

The commitment and its checking are quite simple. Unfortunately, without additional measures this scheme is insecure.

The problem is that the group is cyclic, and addition is mod P (a 256-bit prime number that defines the order of the group). As a result, addition of large values can 'overflow' and behave like negative amounts. This means that a sums-to-zero behavior still holds when some outputs are negative, effectively allowing the creation of 5 coins from nothing:

 (1 + 1) - (-5 + 7) == 0

This would be interpreted as "someone spends two bitcoins, gets a '-5' bitcoin out that they discard out, and a 7 bitcoin output".

In order to prevent this, when there are multiple outputs we must prove that each committed output is within a range which cannot overflow (e.g. [0, 2^64)).

We could just disclose the amounts and blinding factors so that the network could check, but this would lose all of the privacy. So, instead, we need to prove that a committed amount is within the range but reveal nothing else about it: we need an additional cryptosystem to prove the range of a Pedersen commitment. We use a scheme similar to Schoenmakers’ binary decomposition but with many optimizations (including not using binary).

To build this we start with a basic EC signature. If a signature is constructed so that the 'message' is the hash of the pubkey, the signature proves that the signer knew the private key, which is the discrete log of the pubkey with respect to some generator.

For a 'pubkey' like P = xG + aH, no one knows the discrete log of P with respect to G because of the addition of H, because no one knows an x for xG = H----_unless_ a is 0. If a is zero then P = xG and the discrete log is just x; someone could sign for that pubkey.

A pedersen commitment can be proven to be a commitment to a zero by just signing a hash of the commitment with the commitment as the public key. Using the public key in the signature is required to prevent setting the signature to arbitrary values and solving for the commitment. The private key used for the signature is just the blinding factor.

Going further, let’s say I want to prove C is a commitment to 1 without telling you the blinding factor. All you do is compute

   C' = C - 1H

and ask me to provide a signature (with respect to G) with pubkey C'. If I can do that, the C must be a commitment to 1 (or else I've broken the EC discrete log security).

To avoid giving away the amount we need yet another cryptographic construct: a ring signature.  A ring signature is a signature scheme where there are two (or more) pubkeys and the signature proves that the signer knows the discrete log of at least one of the pubkeys.

So with that we can construct a scheme where I prove a commitment that C is either 0 or 1--we call this an "OR proof".

First, I give you C, and you compute C':

    C' = C - 1H

Then I provide a ring signature over {C, C'}.

If C was a commitment to 1 then I do not know its discrete log, but C' becomes a commitment to 0 and I do know its discrete log (just the blinding factor). If C was a commitment to 0 I know its discrete log, and I don't for C'.  If it was a commitment to any other amount, none of the result will be zero and I won't be able to sign.

This works for any pair of numbers, just by suitably pre-processing the amounts that are put into the ring... or even for more than two numbers.

Say I want to prove to you that C is in the range [0, 32). Now that we have an OR proof, imagine I send you a collection of commitments and OR proofs for each of them:

C1 is 0 or 1 C2 is 0 or 2 C3 is 0 or 4 C4 is 0 or 8 C5 is 0 or 16.

If I pick the blinding factors for C1..5 correctly then I can arrange it so that C1 + C2 + C3 + C4 + C5 == C.  Effectively I have built up the number in binary, and a 5-bit number can only be in the range [0,32).

Numerous optimizations are required to make this more efficient:

First, I propose a new ring signature formulation, a Borromean ring signature
Instead of expressing the amount directly, CT amounts are expressed using a decimal floating point where the digits are multiplied by a base 10 exponent.  This means that you can prove large amounts with small proofs, so long as they have few significant digits in base 10: e.g., 11.2345 and .0112345 can have the same size proof, even though one number is a thousand times larger.

There is also a non-private "minimum amount" sent, which allows a smaller proof to cover a larger range if the user doesn't mind leaking some information about the minimum amount (which might already be public for external reasons); this also allows the least significant digits to be non-zero when an exponent is used. Minimum amounts are supported by first subtracting the minimum, then proving that the result is non-negative.

The mantissa of the floating point is encoded using rings of size 4 (base 4) rather than binary, because this minimizes the number of commitments sent while not using any more signature data than base 2.

The final mantissa digit commitment can be skipped, backwards constructing it from the value being proven and the other digits, etc.

Finally, by careful use of derandomized signing in the prover, it's possible for the receiver of the coins--who shares a secret with the sender, due to ECDH key agreement with the receivers pubkey--to 'rewind' the proof and use it to extract a message sent by the sender which is 80% of the size of the proof.  We use this to signal the value and blinding factor to the receiver, but it could also be used to carry things like reference numbers or refund addresses.

The result is that a proof for a 32-bit value is 2564 bytes, and simultaneously may convey 2048 bytes of message. A 32-bit proof can cover a range of 42.94967296 BTC with 1e-8 precision, or 429.4967296 BTC with 1e-7 precision, and so on. My implementation is able to verify over 1300 32-bit range proofs per second on an i7-4770R, and there are many performance optimizations still possible.

The implementation supports proofs of any mantissa size or exponent, with the parameters controlled by the sender. Performance and size are linear in the number of mantissa bits, and odd numbers of bits are supported (by switching to radix-2 for the last digit).

In Elements, the range proofs are only required in cases where there are multiple confidential value outputs (including fees).  Transactions that merge multiple confidential amounts into a single output do not need range proofs since the fact that all the inputs were in range is sufficient.

By sharing the scanning key used to establish the shared secret used by the rewindable range proofs, this approach is completely compatible with watching wallets; users can share these keys with auditors to enable them to view their transaction amounts.

Future work may use the fact that proofs can support a minimum value to also allow skipping the range proofs when there is a single confidential output even when fees are being paid, or allow nodes to skip or delay verifying most range proofs by using fraud proofs.

The system presented here depends on no new fundamental cryptographic assumptions, only the hardness of the discrete log problem in the secp256k1 group and a random oracle assumption, just like the normal signatures in Bitcoin.

While the size of the range proofs are non-trivial, they are still an order of magnitude smaller and faster to verify than some alternatives (like Zerocoin), and most of their space can be reclaimed to communicate additional data between users, a feature which is often requested but hard to justify in a public broadcast network. Similar to signatures, the range proofs can be placed on separate tree branches in blocks to allow clients that don’t care about (e.g. historical ones) to skip receiving them.

Most importantly, this scheme is compatible with pruning and does not make the verification state for Bitcoin grow forever. It is also compatible with CoinJoin and CoinSwap, allowing for transaction graph privacy as well while simultaneously fixing the most severe limitation of these approaches to privacy (that transaction amounts compromise their privacy).

Unlike some other proposals, this system is not just speculation or pure cryptography without integration with the Bitcoin system.

Confidential Transactions is enabled in Elements and used by default by all ordinary transactions.

The source code for the just the underlying cryptosystem is also available.

851  Bitcoin / Development & Technical Discussion / Elements Project testnet sidechain alpha released on: June 09, 2015, 10:16:27 AM
I'm surprised that there isn't a thread on this yet.

I'm pleased to announce the publication of an experimental bitcoin-testnet sidechain and the software that implements it:

There is a fair amount of description and more coming at the Blockstream website: https://blockstream.com/developers/

... Including a video of a talk I prepared for the t the SF Bitcoin 'dev' meetup tonight (the video was pre-recorded, I think the presentation in the meetup went better but I work with what I've got. Smiley )

You can get the code and use the sidechain from the github repo: https://github.com/ElementsProject/elements


The sidechain includes some powerful new features... but beyond that, I hope that this opens up new avenues for experimentation and innovation In Bitcoin, providing a way to try things out without either rebooting the network effect or unduly imposing on people who aren't interested in the benefits (or risks) of something new.
852  Bitcoin / Project Development / Re: Quick Question about bitcoin on: June 07, 2015, 11:49:04 PM
It's also what I thought (specifically: "Hm. well what category are ponzi schemes in?", amusingly enough.  But I thought it a bit too mean to say it! Just because many of them are, and the whole space is harmful to Bitcoin's security model when not a scam ... isn't a reason to assume any particular instance is up to no good.
853  Bitcoin / Development & Technical Discussion / Re: Idea for new client. on: June 06, 2015, 10:39:33 PM
Well having this ability to archive wallet address makes it simpler to find addresses in wallet that you want to use
You don't normally 'find' addresses in Bitcoin Core. You generate new ones when you ask for one. It does not normally give you a list of your own addresses.

Quote
This could free up resources used within client or loading time. If someone has tuns of addresses in it and has to rebuild or load up
Resource usage per address is very neglgible. Even with tens of thousands of addressees it doesn't take a noticable amount of time.

Quote
and if one of the old addresses receives payment it then gets auto shifted to active and a little notice popup saying you received payment on archived address that has now been made active.

Well if it does that, it's not actually deleted!
854  Bitcoin / Development & Technical Discussion / Re: Idea for new client. on: June 06, 2015, 05:33:35 PM
You haven't said anything about the motivation, it's not self apparent.

How would a wallet with this behavior be noticeably functionally different than without it?
855  Bitcoin / Development & Technical Discussion / Re: Antminer is "attacking" the testnet on: June 03, 2015, 04:11:06 PM
These issues obviously come from the
Testnet reorgs and most of those services not handling reorgs correctly.  Why would you assume otherwise?
856  Bitcoin / Development & Technical Discussion / Re: Thinking about ways to make it more difficult to link IP address to txn creator. on: June 03, 2015, 06:06:44 AM
I assume the sidecar daemon needs to be notified somehow? So it doesn't have to poll.
Would -walletnotify fire?
I believe it would-- but I wouldn't bother with wallet notify. Why not poll? the whole idea is to be private-- obscuring exact timing would help, and polling even once per few seconds would be inconsequential work.

Pond protects its users from traffic analysis by running every (IIRC) 10 minutes against the server (connecting over Tor, of course) and moving a constant amount of data, regardless of if there are any messages. There is also a transact-now button if you're being impatient.
857  Bitcoin / Development & Technical Discussion / Re: Elastic block cap with rollover penalties on: June 03, 2015, 05:55:35 AM
I expect a fee pool alone will increase block verification cost.
It would not, in any meaningful way.
858  Bitcoin / Development & Technical Discussion / Re: Elastic block cap with rollover penalties on: June 03, 2015, 04:31:48 AM
There is a major shortcoming I can see in the rollover fee pool suggestion: miners are incentivized to accept fees out of band so they can obtain all the highest fees instantly, thus defeating the entire purpose of that feature.
That is the main aspect of what monero/bytecoin does that I complained about-- that you can simply pay fees out of band and bypass it as the subsidy declines (even with the constant inflation the subsidy might be inconsequential compared to the value of the transactions if the system took off).  In Bitcoin this is not hypothetical since 2011 at least pools have accepted out of band payments and its not unusual for varrious businesses to have express handling deals with large pools; and this is absent any major reason to pull fees out of band.

My proposal (on bitcoin-development and previously on the forum) is effectively (and explicitly credited to) the monero/bytecoin behavior, but rather than transferring fees/subsidy it changes the cost of being successful at the work function.

I haven't had a chance yet to read and internalize the specifics of what Meni is suggesting (or rather, I've read it but the complete, _precise_ meaning isn't clear to me yet).  The main things to watch out for solutions of this class are (1) bypass vulnerability (where you pay fees, or the like, out of band to avoid the scheme)  and (2) scale invariance  (the scheme should work regardless of Bitcoin's value).  My proposal used effort adjustment (it's imprecise to call it difficulty adjustment, though I did, because it doesn't change the best chain rule; it just changes how hard it is for a miner to meet that rule).

I think this kind of proposal is a massive improvement on proposals without this kind of control; and while it does not address all of the issues around larger blocks-- e.g. they do not incentive align miners and non-mining users of the system-- it seems likely that proposals in this class would greatly improve a some of them of them; and as such is worth a lot more consideration.

Thanks for posting, Meni-- I'm looking forward to thinking more about what you've written.
859  Bitcoin / Development & Technical Discussion / Re: [Crypto] Borromean ringsig: Efficiently proving knowledge for monotone functions on: June 02, 2015, 11:58:24 PM
Yes, it could replace the construct used in Monero (though I am pretty sure it would have to be a hard fork there) for an efficiency gain (or a privacy gain at a given efficiency). Though I've not implemented the tracability required for that particular application.
860  Bitcoin / Development & Technical Discussion / [Crypto] Borromean ringsig: Efficiently proving knowledge for monotone functions on: June 02, 2015, 07:07:36 AM
Some here may be interested in a new cryptosystem I've been working on which efficiently and privately proves the knowledge of secrets according to an policy defined by an AND/OR network:

https://github.com/Blockstream/borromean_paper/raw/master/borromean_draft_0.01_34241bb.pdf

This new ring-signature is asymptotically 2x more efficient than the one used in Monero/Bytecoin: It needs n_pubkeys+1 field elements in the signature instead of 2 * n_pubkeys. In particular, it retains this 2x efficiency gain when doing an AND of many smaller rings, because the +1 term is amortized across all of them.

The paper also describes a new way to think about ring signatures; which might be helpful to anyone who has looked at them before and found them confusing. (If we were successful, you'll think the new construction was so simple that it was completely obvious; I can assure you it was not... fortunately Andrew Poelstra came up with an especially good way to explain it.)

While the connection to Bitcoin may not be immediately obvious, I've used this as a building block in a much larger and more applicable cryptosystem which I'll be publishing, complete with implementation, shortly  (I'm trying to not flood people with too many new ideas built on new ideas all at once, and I'm still working on the description of the other constructions). I think this construction is interesting in its own right, and I'd be happy to learn if someone knows of this being previously published (though I was unable to find anything prior).
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 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 ... 238 »
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!