The descendant of this system is here:
https://bitcointalk.org/index.php?topic=1290358.0

Closing this thread

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.

^^^

freicoin

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

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.

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.txt

Please 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).

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.

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.

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.

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.pdf

It 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.

These types of DBs are popular lately, for example, btcwallet now uses boltdb, while Monero uses LMDB. They're all kind of similar: full ACID semantics w/ MVCC, data stored on disk in B+ trees, async read/update with scheduling and transitory state patches for reads, multiple namespaces, nested buckets, etc.

AFAIK, bitcore is moving towards adopting more DB agnostic architecture, so in the future you can plug and play whatever crazy DB type you want.

You can use stealth addresses to send the payment to a specific vendor with a stealth address, providing the extra data to recover the private key on a separate channel e.g. email. You can encrypt information like post address to the recipient using the ECDH shared secret and a symmetric key cipher.

So basically, the receiver posts
[recipient_email_address]&[stealth_address]

Sender sends this information to the receiver's e-mail address:
[shared_secret] (for encryption and recovery of private key)

then this other encrypted information in the e-mail:
[requested_items]
[txid_for_payment]
[where_to_ship_to]

Sender uses the derived pubkeyhash as an address and sends their funds there on BTC mainnet, receiver gets e-mail, decrypts all relevant information, recovers privkey for the address yet sent to.

I've been meaning to implement this (and indeed I've started a bit), but I've had other things to work on lately.