|
reserved
edit:
tl;dr
I approached c0 with the MC2 concept from 2013 and merged efforts to develop the system in 2014. I developed a working proof-of-concept for Decred at that time, and then let them refine it while I audit and provide feedback.
|
|
|
|
^^^  |
|
|
|
Using an AOS ring signature only works when you know the pubkeys, which you don't for most coins in the Bitcoin UTXO set.
In any case, the ring signature used to construct the CT range proof is just the AOS scheme when not used with any AND, so thats implement in secp256k1-zkp.
To avoid the proof size-- you're off in snark land-- e.g. the statement you prove "I know a private key for an adequate coin belonging to a utxo set with this hashroot". I previously suggested a scheme that lets you avoid doing 99% of the EC math inside a snark, so this could get a small under 400 byte proof and be implementable. I think it was in a forum post... I'll have to look. But the basic process have the snark instead prove "Pubkey P is a blinding of a pubkey that is member of this tree", and then you also prove you know P's discrete log externally to the snark. The verification of the blinding can be done with a single point addition in the prover.
A CDS ring signature works just as well, but obviously it would only be functional for currencies like Monero where the pubkeys are published instead of the pubkey hashes. |
|
|
|
I believe core version 0.10.0+ uses deterministic k-value generation following the guidelines in RFC6979. The code for this is in the newly used libsecp256k1. It you want to make random k-values, rollback to a version using openssl, or write your own code. Note that if you generate R-values or S-values that are too high, the network will or may reject them (as detailed in BIP0062). |
|
|
|
I would rather we stick to the stealth address format that exists and finalize it instead of switching to another construction stealth addressing, when it's being used in essentially the same way. Stealth addressing works OK as is, however we can transmit the extra data from that would normally be disclosed in an OP_RETURN out-of-band via an intermediary like Bitmessage. Essentially this appears to be your described protocol, and I think it'd be preferred if we worked within the established protocol as an extension of the proposed BIP0063, and backwards compatible with the described address format. Additionally, solicitation (Notification Transaction) should be done out-of-band, rather that by the use of the blockchain and OP_RETURN tagging. I think it's potentially wasteful, aside from being permanently embedded in the blockchain and by which causing a loss of privacy. A proper out-of-band solution for stealth transacting should never need to resort to blockchain access, as far as I am concerned. |
|
|
|
|
There are two Bytecoins, one is a Bitcoin clone, the other is an entirely different codebase, elliptical curve, difficulty algorithm, etc
|
|
|
|
I can't wait for the multitude of sidechain forks that all compete with each other. Sidechains themselves require incentives to operate securely, such as fees and the continued security of the Bitcoin network, so I'd guess we'll start to see a lot of the same issues in sidechain space as we do in altchain space. I really don't think there's any difference between the two. You can also issue your own assets already on Bitcoin (e.g. coinprism, counterparty), so the notion of token issuance for use in general scamming will surely appear on sidechains as well. You can't out-technology human speculation in finance.
There is no speculation incentive because all investments are denominated in BTC. Thus this will force consolidation. Unless there are revenue models and/or dividends for side chains. Ah... just like all alt coins are merge mined with Bitcoin to support the entire network hash rate? After Elements adds explicit tokenization it'll be easy for anyone to make a sidechain fork and issue "Sidechain Funbux" on their fork, pre-sale them, etc. Bilateral two-way peg also means that Bitcoin might inadvertently end up supporting a number of pre-existing alt. coins anyway; especially since we can now explicitly tokenize them in a 1:1 peg on the elements sidechain and transfer them there. You can change the tech, but you can't change the underlying issue. |
|
|
|
Now that I think about it, it seems to me there is another way to achieve the same thing. Since the payee needs to share his full public key (Q), it would be possible for the payer to encrypt data using Q and only the payee would be able to decrypt it. The payer can generate a random number (r), then use that in the same way as the shared secret to generate Q'. Then they encrypt r using Q and embed it as metadata. The payee can scan for transactions by checking if his private key can decrypt the metadata.
EDIT: or better yet, the shared secret is generated the normal way by multiplying the private and public keys together, but we use it as the key for a strong symmetric encryption algorithm to encrypt r instead of using Q to encrypt r, which should be a more secure approach.
There is no orthologous method for ECDSA that you'd use to directly encrypt data to a recipient key as you would with RSA. ECDSA is purely for signing. What you're describing (using the shared secret for a symmetric cipher) is known widely as Elliptic curve Diffie–Hellman (ECDH). It overcomes the above limitation. It is used to transmit messages in transactions in some CryptoNote coins, and is widely used in protocols such as SSH and TLS. http://en.wikipedia.org/wiki/Elliptic_curve_Diffie%E2%80%93Hellman |
|
|
|
Please refer to CryptoNote CNS006 for an explanation https://cryptonote.org/cns/cns006.txtPlease note that stealth addresses do not afford anonymity but rather forward privacy (they obfuscate where funds are being sent to). Recipients also must scan the blockchain to decipher if any outputs belong to them (and so thin clients become a bit more difficult, because they can no longer simply poll a server for an address balance). |
|
|
|
Because you still keep using bitcoin and its snet effect it is spread around the people in the world
you don't need to accept a bunch of altcoins,just accept bitcoin
Pretty much this. Altcoins are just a hindrance, people are creating them as pump and dump in order to earn quick money almost in 100% cases. Most of them are copy paste or existing code without any changes beside name of the coin. Instead on focusing our attention on altcoins why don't we focus and upgrade bitcoin? It would beneficial for us a lot more than creating new altcoin everyday. I think going pro sidechains are also not the way to evolve... Only pure bitcoin is the way. Stop deviations. Perhaps in the Soviet Union of Bitcoin. Economic outcomes are terrible when there are no competitors for any given market, for example, if there were a government monopoly allowing only a single car manufacturer. You might imagine that this single company would have the highest efficiency, but the reality is that efficiency actually decreases without competition. I doubt Blockstream and sidechains would ever have come into being without the pressure (and sometimes, innovation) afforded by altchains. |
|
|
|
|
Sidechains are altcoins, which use Bitcoins as their basis. By subscribing to the sidechain, you subscribe to the same ethos as Bitcoin... namely, the vast number of coins owned by Satoshi and now the core developers (some of whom were rumoured or seen to have made large purchases of Bitcoins with the formation of Blockstream).
I can't wait for the multitude of sidechain forks that all compete with each other. Sidechains themselves require incentives to operate securely, such as fees and the continued security of the Bitcoin network, so I'd guess we'll start to see a lot of the same issues in sidechain space as we do in altchain space. I really don't think there's any difference between the two. You can also issue your own assets already on Bitcoin (e.g. coinprism, counterparty), so the notion of token issuance for use in general scamming will surely appear on sidechains as well. You can't out-technology human speculation in finance.
The other issue with sidechains is that effectively everything can become a sidechain of anything else if you push foreign coins onto Bitcoin mainnet as coloured tokens. I've been calling this "bilateral two-way peg" for a while, and I'm not sure that there's any way Bitcoin mainnet could prohibit it after they add sidechain-related OP codes. The real (negative or positive) value of sidechains remains to be seen, and I think we haven't even touched the scale of redundancy that might occur in the future as a result of them.
The good thing is that the Blockstream guys are doing some pretty neat cryptographic research, in any case.
|
|
|
|
Furthermore, if the reward is (1 - penalty) * (minted coins) + tx fees, then in the future when the minted coins go down to 0, there is no penalty at all. That's the opposite of future-proof.
Monero is permanently inflationary, so there will always be an impact of the penalty. |
|
|
|
|
Well, I'm impressed. Why you went to the trouble to implement your ring signature scheme makes a lot more sense now.
|
|
|
|
Thanks for that, it was my reading also.
Thus TX fees that are not in the block but paid out of band are not subject to penalty...
It's an additive deduction, not multiplicative. You seem to be thinking the miner's reward is: (1 - penalty) * (minted coins + tx fees + collection from pool) Where it is really: minted coins + tx fees + collection from pool - penalty Having more fees in the txs included doesn't increase the penalty. There is no difference between adding 1 mBTC to the fee and paying 1 mBTC out-of-band. I don't see how this differs from in Monero? In Monero, addition of txs up to the median blocksize is free. As you surpass the median blocksize, a quadratic penalty is applied to the subsidy of the coinbase, but amounts obtained from tx fees are untouched. The subsidy of the coinbase is initially dependent of the number of coins in existence, and so takes into account the previous penalties to coinbases of any previously generated blocks (comparable to your "pool" method). Then, the miner is free to add transactions meeting some economic equilibrium that maximizes their overall income when taking into account the blocksize penalty to the coinbase subsidy. So, it's like this: (1 - penalty) * (minted coins) + tx fees where penalty is dependent on the size of the block above the median size according to the formulas found in the CN whitepaper. gmaxwell criticizes this as promoting out-of-band transactions, but the fact remains that to permanently and secure transfer money you must use the blockchain and have it included in a block somewhere. Thus, I never thought it was much of an issue. |
|
|
|
Isn't it precisely what is implemented in Monero? (except you don't have a rollover pool, the penalty is simply deducted from the block reward for good).
No idea what happens in Monero, but if so, more power to them. Yes. There is a quadratic penalty imposed for blocks above the median size (with a maximum size of 2 * median(size of last 400 blocks)), with a dynamic, elastic block sizing algorithm. Unlike Meni's suggestion, the reduction in block subsidy is not given to a pool but rather deferred to future miners because the subsidy algorithm is based around the number of coins. See section 6.2.3 of the CryptoNote whitepaper: https://cryptonote.org/whitepaper.pdfIt was one of the most criticized components by the Bitcoin core developers, but so far testing on the mainnet and testnet has failed to evidence any failures. 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. |
|
|
|
|
itt people attempt to make sense of speculators because occam's razor of "playing a game of financial chicken and trying to pump and then dump in sync with everyone else" isn't illuminati enough
|
|
|
|
|
Show Posts
