It has already been proven, beyond a doubt, that terrorists are using Monero.
In what world? People barely even use Monero to play dice games. |
|
|
|
Someone wants to implement a contract protocol on top of Monero: Ive designed a very specific technical implementation to add trustless, tradable, contracts on the Cryptonote prototcol. The whitepaper can be downloaded from Google drive https://drive.google.com/file/d/0B75gaqtEgDR8UHU2UVJ6TkYzMnRkdFFsbklBd3hVMDV1eDQw/view?usp=sharingI am looking to implement this very soon on one of the existing Cryptonote coins. Looking for suggestions, criticisms, anything that will facilitate this implementation. Unlike most other suggestions or whitepapers I have the full technical ability and experience to implement these changes. I don't want to deal with the prospect of launching a new coin, nor should I have to as these changes would only improve the features of an existing Cryptonote coin. Roman Brown romanbrown54@gmail.com |
|
|
|
For anyone wishing to do the share compression, look here in the source code: https://github.com/spreadcoin-project/spreadcoin/blob/b05777db815d633a76aba5ef55ecb85390a4df7e/src/main.cpp#L1528-L1533 // Start with nonce, time and miner signature as these are values changed during mining.
BlockData << (nNonce & ~NONCE_MASK); // ignore lowest 6 bits in nonce to allow enumeration of 64 hashes without recomputing whole block hash
BlockData << nTime;
BlockData << MinerSignature;
BlockData << nVersion;
BlockData << hashPrevBlock;
BlockData << hashMerkleRoot;
BlockData << nBits;
BlockData << nHeight;
// Skip hashWholeBlock because it is what we are computing right now.
BlockData << vtx;
while (BlockData.size() % 4 != 0)
BlockData << uint8_t(7);
// Fill rest of the buffer to ensure that there is no incentive to mine small blocks without transactions.
uint32_t *pFillBegin = (uint32_t*)&BlockData[BlockData.size()];
uint32_t *pFillEnd = (uint32_t*)&BlockData[MAX_BLOCK_SIZE];
uint32_t *pFillFooter = std::max(pFillBegin, pFillEnd - 8);
memcpy(pFillFooter, &hashPrevBlock, (pFillEnd - pFillFooter)*4);
for (uint32_t *pI = pFillFooter; pI < pFillEnd; pI++)
*pI |= 1;
for (uint32_t *pI = pFillFooter - 1; pI >= pFillBegin; pI--)
pI[0] = pI[3]*pI[7];
BlockData.forsed_resize(MAX_BLOCK_SIZE); Nothing too crazy going on here from what I can tell, you start with the block header data/tx list and fill the block with crap going forward with *pI |= 1; (bitwise or operation), then iterate backwards through it multiplying with pI[0] = pI[3]*pI[7];. You should be able to regenerate this all by simply starting from the initial header state and list of transactions. |
|
|
|
First of all, lots of respect for you tacotime!
So roughly the method would be to have everyone send in their (solo) mined coins and then divide them up based on hashrate? And it sounds you would have a list of pubkeys to verify how much everyone mined.
But how would you know how much hash any given miner is supplying? Maybe some kind of custom software to monitor a miner's rigs? I'm somewhat ignorant on the specifics of pool mining and am just trying to wrap my head around this.
Yes, and yes. Have them submit their partial solutions, which are blocks that are below target and register that as a share. As mentioned before, you should be able to compress padded blocks that use the recursive padding described in the paper, then after they're piped to the pool decompress them. If you're using some kind of naive solution that doesn't compress blocks, you would use adaptive difficulty and set target share rate to something like one share every 5 minutes so your pool and miner bandwidth isn't crazy. One neat thing about this is that it does let whichever miner who wins the block pick the transactions in the block, instead of the pool itself. However, miners may wish to keep bandwidth usage low, which would encourage as small of blocks as possible (in the event that someone is able to get padding compression working). |
|
|
|
I think SDC is not just a copy of cryptonote. Its more complicated and cryptonote tech is just one of the pieces of the puzzle. When Satoshi built bitcoin, he didn't invent any new tech either. All he did was put existing technical puzzle pieces together in a way that created a powerful incentive system. The incentive system is the brilliance behind Bitcoin. ShadowCash is doing a similar thing, putting the puzzle pieces together in a brilliant way.
Also soon Isidor Zeuner will have his review out on ShadowCash, which compares Shadow to cryptonote and other schemes, showing their similarities and differences, so that may put an end to the debate.
ook |
|
|
|
In the event a miner started stealing coins, it'd be kinda a funny battle between the miner and pool to get the spending TX in the 121st block before each other for all of the remaining blocks (you would assume the pool would ban the miner at the first block stolen).
The pool wouldn't have access to the funds, only the miner would. Well, unless you make the miner give his private key to the pool as well, but you don't even have to. |
|
|
|
you have to account for variance. There is a non-zero probability (sorry, i missed that class so i can't say exactly how much) that the miner with 20% of the hashrate gets 120 blocks in a row. If that happens and he steals, then your collateral wont cover it.
At 20% of the hashrate, I believe the likelihood of getting all 120 blocks in a row would be (1/5)^120, or not very likely. Basically the math that makes 6 confirmations in the Bitcoin blockchain unlikely to be overwritten also makes it extremely unlikely that any single small pool miner will ever get 100% of the blocks after finding a block. The probability that the 20% miner will get approximately 24 blocks in that time period is relatively high; but I mean, why pool if you have 20% of the network? Assuming most miners have <= 1% network hash rate, it's unlikely that any small miner could take advantage of this to the full extent. And, okay, let's say worst case, someone does run off with a little money from the pool. The pool would then just raise fees to pay for the loss and set their deposit higher. This is more of a matter of actuarial science, but I think it's clear that the risks shouldn't be huge to running a pool. And finally, to further reassure the pool that the money will get to them, the miner can create the tx paying the pool from their coinbase immediately after the block is mined. The tx will then get mined into a block in CoinbaseMaturity many blocks unless the miner either (a) mines a block with a competing transaction or (b) create a doublespend tx with a significantly large fee that can instead be incorporated at a further loss to themselves. (a) is very unlikely given a small hash rate, (b) is possible but causes further loss to the miner and causes him to be banned from the pool immediately upon the doublespend at height CoinbaseMaturity. |
|
|
|
I think this quote from smooth summarizes SDC rather effectively.
There are no other cryptonote-based coins in the top 100 on coinmarketcap besides XMR and BCN.
SDC uses a cryptonote-based design for their anonymous tokens, which is a bit different in terms of coin design and doesn't share code but the cryptography is almost identical.
They call it "zero knowledge solution" though. Perhaps that is self descriptive. I didn't see "XMR" or "BCN" in the title of this thread. The shameless promotion "distills" the "essence" of your motives here. Interesting bit of information I found in the comment section of the recent SDC article regarding Cryptonote, which is why I'm glad SDC doesn't share it's codebase. https://en.wikipedia.org/wiki/CryptoNote#NSA_involvement"Darknote" is also a CN based coin in the top 100 Clearly from a reputable source: http://www.cryptobang.com/2014/10/05/what-nsa-created-cryptonote-forStuff the wiki has wrong: (1) Keccak was announced as SHA3 in 2012, BCN/CryptoNote was being developed in late 2013 https://www.schneier.com/blog/archives/2012/10/keccak_is_sha-3.html(2) CN doesn't use Chaumian blinding (signature blinding) (3) Bitcoin implementations up to this point use non-deterministic k values, talk of using an HMAC to generate them has been relatively recent. You could make your own implementation that uses it though. https://bitcointalk.org/index.php?topic=285142.0(4) "Being ASIC-resistant CryptoNote-based currencies can be easily manipulated by NSA possessing big computational resources." This is simply pure conjecturing |
|
|
|
So, for a pool, I think what you would do is just have people send the BTC equivalent of one block's reward to the pool (which isn't much), then if the miner's steal the reward, the pool still retains their deposit so net miner gain is 0. You would have the miners themselves mine to their own pubkeyhashes, and you'd submit partial solutions to these blocks to the pool itself. When the miner gets a block, they would be given n many blocks to get the coinbase from their block to the pool to redistribute to the other miners. If they didn't return the reward to the pool, the pool would then just take their deposit and ban them.
So, I don't think there's a big issue with pooling, just a slightly more complicated implementation. There's a small associated cost with joining a pool, but it's not really much.
coinbase mature is 120 blocks, pool have to wait that time, before spend the block reward. a big miner can mine more blocks during this time, so every miner sould pay a bigger guarantee (60 spr for 10 blocks, 120spr for 20 block guarantee), do you think they will do this? Probably, yeah. Considering 100 SPR is only $6 USD and assuming that that majority of miners probably have a cheeseburger worth of funds to spare, it should be fine. I mean, reward is like 6.66 SPR, *= 120 blocks (worst case, extremely unlikely) is ~800 SPR. But if you have enough to get 100% of the network's blocks, why would you be on a pool? More likely case is that a big miner gets maybe 20% of the network... That's a deposit of ~160 SPR to prevent a large loss. |
|
|
|
Are you saying that a pool can appear as two pools while working on the same block?
Pools won't show up at all, it'll look like solo mining followed by a tx spending all the coinbase to the pool sometime later. The pool could choose to give totally random addresses for a miner to send funds to, making it impossible to see which pool it went to. |
|
|
|
I would love to see such a propsed "escrow pool" that uses automated escrow by using multisignature on the SPR blockchain itself.
I wonder if this could work out.
I don't think multisig would work because I think that (a) coinbase needs to output to a single P2PKH output and (b) you'd have to have all members of the pools receive all blocks from each other and sign them before determining if they met difficulty, which would be super slow. You could maybe send the coinbases to a multisig account after, and have all the pool members sign off on payouts, but that seems overly complicated. Can this even be automatized? This all sounds we would need to trust someone to initiate all that, so this will just introduce a single point of failure again, which is what will prevent such pools from appearing in the first place. I don't know why you would, seems to make it overly complicated when it doesn't need to be. |
|
|
|
The collateral pool idea is not new: Hey guys, would it be possible to create a pool like this;
Each miner mines to a separate address. The pool (and the miner obviously) knows the private key.
The pool has insurance of lets say, 15 spr in a separate address for each miner. The insurance needs to be paid by the miner before he starts mining.
The miner submits shares and once he finds a block he publishes it to the network.
If the miner steals coins from his address then he gets banned from the pool and the pools uses his insurance to pay the other miners.
Could this work? Or is it not possible because it isn't how mining works for spreadcoin?
The problem here is that if you will find a block and will not try to steal its reward pool can still claim that you are trying to steal it and use both your funds and block reward. For external observer it is not possible to distinguish between situations when you are trying to steal money and when pool operators are just lying about this. Even if pool is operated by some legally registered entity with non anonymous owners they can steal your money and you wouldn't be able to prove anything. If you cannot find blocks consistently but are still mining that means that even one block's reward worth something for you. I don't think his argument is valid, because (1) The pool and other users know the pubkeyhashes that are mining. (2) If the miner pubkeyhash finds a block and then refuses to give the funds back to the pool within say, 60 blocks, it's totally clear to everyone mining on the pool that this has happened aside from just the pool itself. (3) Miners can mine to another pubkeyhash, but that's the exact same as solo mining. The pool could steal from the users, but that's the same as with Bitcoin. It's more profitable for the pool to allow people to mine honestly and take a percent fee than it is to steal a generated block. |
|
|
|
Anyway, the term "pool prevention" still applies to spreadcoin. And maybe we just need to step the pool prevention up a notch.
It's an active area of research; amiller wrote a paper about it recently that was pretty neat. https://cs.umd.edu/~amiller/nonoutsourceable.pdf |
|
|
|
I would love to see such a propsed "escrow pool" that uses automated escrow by using multisignature on the SPR blockchain itself.
I wonder if this could work out.
I don't think multisig would work because I think that (a) coinbase needs to output to a single P2PKH output and (b) you'd have to have all members of the pools receive all blocks from each other and sign them before determining if they met difficulty, which would be super slow. You could maybe send the coinbases to a multisig account after, and have all the pool members sign off on payouts, but that seems overly complicated. |
|
|
|
This solves the problem fairly elegantly I believe. It's still not the ease of running a "standard" pool, and there are additional considerations, like: how popular would a BTC pool be if you had to deposit 25 BTC to mine there (even considering that their wouldn't be any other pools where you didn't have to do this)? Edit2: this plays on the "(which isn't much)" above; what if it was a "lot"?
Edit: tacotime, why wouldn't you send the SPR equivalent of one block reward? BTC would be subject (I believe unnecessarily) to exchange rate volatility.
Oh, just to make accessibility to the pool easier. Mining a SpreadCoin block solo could be kind of a pain, and otherwise you'd have to buy the coins from an exchange (with BTC). Obviously you can just use SpreadCoins themselves too if you want to keep it 1:1, but more users will probably join a pool than only requires a tiny amount of BTC to join and the amount of risk losing SpreadCoins versus equivalent Bitcoins is probably pretty similar. If SpreadCoins were worth more you might want to use them instead I guess. As far as say, a block equivalent in BTC: right now that's about $220 USD * 25 = $5,500. But at Bitcoin's current market cap, the vast majority of small miners are being phased out anyway, so maybe a $5,500 entry fee (that you'd eventually get back) isn't such a big deal. It's hard to say. It's difficult to see SpreadCoin getting anywhere near that value in the short term, too. To make the pool ultra simple too, just make the username the pubkeyhash you're mining to with your coinbase/signing your blocks with. Given the recursive algorithm used to pad the blocks, I think it should be possible to code an imperative algorithm to pad the blocks and compress the block as well when sending back to the main server, so that bandwidth consumption isn't huge and you don't need to accept super high difficulty shares. |
|
|
|
X-posted from the other thread, by me... So, for a pool, I think what you would do is just have people send the BTC equivalent of one block's reward to the pool (which isn't much), then if the miner's steal the reward, the pool still retains their deposit so net miner gain is 0. You would have the miners themselves mine to their own pubkeyhashes, and you'd submit partial solutions to these blocks to the pool itself. When the miner gets a block, they would be given n many blocks to get the coinbase from their block to the pool to redistribute to the other miners. If they didn't return the reward to the pool, the pool would then just take their deposit and ban them.
So, I don't think there's a big issue with pooling, just a slightly more complicated implementation. There's a small associated cost with joining a pool, but it's not really much. |
|
|
|
you are talking about something like an "Automated Escrow", right?
Make everyone pay into a pot first, so should they dare to steal, you just keep what they previously payed.
Yeah, that's the idea. |
|
|
|
|
So, for a pool, I think what you would do is just have people send the BTC equivalent of one block's reward to the pool (which isn't much), then if the miner's steal the reward, the pool still retains their deposit so net miner gain is 0. You would have the miners themselves mine to their own pubkeyhashes, and you'd submit partial solutions to these blocks to the pool itself. When the miner gets a block, they would be given n many blocks to get the coinbase from their block to the pool to redistribute to the other miners. If they didn't return the reward to the pool, the pool would then just take their deposit and ban them.
So, I don't think there's a big issue with pooling, just a slightly more complicated implementation. There's a small associated cost with joining a pool, but it's not really much.
|
|
|
|
|
SDC is a reimplementation of the CryptoNote technology using secp256k1 instead of EdDSA Schnorr signatures (hence it can't do some things that CryptoNote coins can, like cryptographically indistinguishable multisignature transactions). Gmaxwell did this a while ago, but didn't release it to the public because he was concerned it would just generate scam coins with unfair distributions seeking to capitalise on technology that was borrowed. DarkNote uses a hybrid Proof-of-Stake system to do coin-joining. That is, a series of master nodes is selected, you send them your inputs and intended outputs, then they help you mix them with the outputs of others.
|
|
|
|
|
Show Posts
