Curious, what standard of whitepaper creation are you referring to when making these claims?
The standard I'm using is to give clear credit to other's work when using it. There's nothing wrong with using the work (especially in the case of open source which is designed to be reused and built upon). Just give credit clearly, and don't take credit for something that is not original. or leave the impression of originality where none (or significantly less) exists. I've been looking into whitepapers vs research papers and found various sources that don't mention in-text citations for whitepapers as they are mainly used as marketing tools to explain how a problem was solved by the subject of the whitepaper. For research papers, I fully agree but I don't think either of SDC's papers fall within the realm of research.
In-text citations seem to be more of a courtesy when it comes to whitepapers.
Child_harold, you're welcome to reply to this but I will not respond to you.
I agree that: 1. "Whitepapers" are often primarily a marketing tool, and 2. They don't always make specific in-text citations. However, that's different from failing to make clear what is actually new or different about the solution being sold. Failing to do so can be reasonably criticized on misleading, vague, and/or overly-hyped sales grounds in addition to plagiarism. But ultimately it doesn't matter what you think of 'standards' and 'ethics'. What really matters is not what the white papers say about it, it is fact that ShadowChat is fundamentally a rip-off of Bitmessage with little to no differentiation and ShodowSend is fundamentally a rip-off off Cryptonote with little to no differentiation, both of which are well-recognized now, and even somewhat acknowledged by the developer. If people want to continue to dig into the history of where the project came from, how it operated, and the motives of why it was presented in that manner, I guess it can't be prevented. People have "hobbies", as CH calls it. |
|
|
|
|
Please get this off topic crap off my hate thread.
Thank you.
|
|
|
|
[13:17:23] Rynomster (ShadowCoin): shadowchat is bitmessage? [13:17:32] Rynomster (ShadowCoin): shadowcash was written from scratch..
[13:19:02] Rynomster (ShadowCoin): bitmessage is written in python...[13:19:49] Rynomster (ShadowCoin): http://www.shadow.cash/downloads/shadowcoin-p2p-em.pdf <--- [13:19:56] Rynomster (ShadowCoin): bitmessage is in there in the references As I explained earlier, "in the references" is not good enough if you don't explain how your work relates to prior work. (And in the case of bitmessage, it wasn't even in the references at all until called out on it, as I cited above, though cryptonote was always in the list of references for shadowsend, but also without explaining the relationship). On the matter of "written from scratch" and "written in python": Electrum is written in Python Multibit is written in Java btcd is written in Go Bitcoin Core is written in C++ The code for all of these (or their underlying libraries at least) were written from scratch. None of them claim to innovative new systems (other than Bitcoin Core in its earliest versions of course) nor anything other than implementations of Bitcoin or wallets built to work with Bitcoin using the Bitcoin protocol. They don't have their own ripped-off white papers, that describe the Bitcoin protocol as if it is something new, without explaining the relationship to prior work. In cases where the above systems add something new, it is clearly documented which part is new (for example SPV and bloom filters in the case of Multibit/bitcoinj or Electrum's servers) and which part is based on Bitcoin itself (blockchain, transactions, etc.). Where is it documented which parts (if any) of ShadowChat and ShadowSend are new and which parts are implementations of existing systems or clones of existing systems? Certainly not in either white paper, that's for sure. See the difference? |
|
|
|
|
Updated with a bit more staking and a withdrawal.
EDIT: In reviewing the accounting on the latest withdraw I noticed some minor rounding errors (<0.0001 CLAM) in the share amounts. The CLAM amounts are not affected, at least not by a significant amount if at all. I'll clean that up when I get a chance. The error cropped in when I moved the official record from the thread to a spreadsheet that calculates running share amounts and values automatically, instead of rounding each time as I was doing before.
|
|
|
|
|
Updated staking, though a bit later than usual.
Unfortunately we had a bit of downtime on the node. By the time I noticed it and was able to restart, we missed about something like 18 hours of staking.
To help make up for the loss I have donated 10 CLAMs to the pool. As a reminder, "donations" (as opposed to "tips") add to staking and benefit all pool members.
|
|
|
|
...
gmax and peter todd don't see monero as a threat to bitcoin so that's why they hate on and fear DASH but push monero.
Dash is not a threat to any alt-coin let alone Bitcoin ever since the Evolution announcement. I mean 12- 18 months for a stable prototype with estimates in the 3-5 year range for a "gold" release. This is an eternity in crypto currency. We will be writing the software for this project in stages, the first stage will take about 2 months to have a very early prototype for Dash Evolution that includes a basic implementation of DashDrive, Primitives, DAPI and a simple T3 wallet. In six to eight months, we should be entering testnet phase with most basic functionality. In 12-18 months, we plan for the first release version (a stable prototype). https://www.dash.org/evolution/DASH is already a top 5 altcoin. after evolution it will be second under btc. monero will have been totally replaced by then by a solid zerocash implementation. in 3-5 years DASH will be like google to btc yahoo. The Monero Marketing Team thinks it is a good Tactic to quote this one for posterity. |
|
|
|
However, voting on development priorities is useful, as a means for the developers to get some idea what coin owners (somewhat an indicator of coin users) think is important. No one really wants to work on things that aren't wanted.
I see your point, but I mostly add the features that I want the most. If that happens to correspond with what lots of other people also want then that's nice. I guess probably more people use the Qt client than the command line but I don't like working on it and so avoid it as much as possible. If lots of people want a better Qt client then I expect one of them will make it happen. If not, I guess it isn't really that important, and if they do that's cool with me - it doesn't affect the client I use, or the network as a whole. You're right. A lot of open source gets done (especially when being done by volunteers) because the developer doing it wants the feature. Nothing wrong with that. |
|
|
|
It strikes me that this isn't a consensus issue, and so you are free to add it to the client any time you like. We don't need to 'vote' on this.
There's lot of things that aren't consensus issues, but would be great to have votes on anyway. e.g. Take my earlier idea that in a block-race stakers would randomly select a block (rather than use the first-seen) to minimize the orphan-risk for honest miners who produce big-blocks. I don't think that's a consensus issue, but seems like it'd be crazy to adopt something without knowing what everyone thought? (Or another good example is mempool policy in bitcoin (Current vs FSS-BRB, Opt-in RBF, Full RBF) which seems wildly controversial, but with the shilling and censorship around it, it seems impossible to get a feel for support of each) Consensus issues don't need to be voted on either, nor is it particularly useful to do so. If there is consensus, it will be obvious. If there is a real need for a vote, there is very likely no consensus. However, voting on development priorities is useful, as a means for the developers to get some idea what coin owners (somewhat an indicator of coin users) think is important. No one really wants to work on things that aren't wanted. |
|
|
|
I do not support due to high potential for various perverse incentives and unintended consequences. The most natural and robust interpretation of fees is an incentive for block-creators to include truncations in a block (payment for scarce block size). There are better mechanisms to in turn control block size and limit spam, such as a reward penalty. These will naturally pull fees higher via a market mechanism. Trying to go the other direction is akin to pushing on a rope. Reward penalties are especially suitable for CLAM since the block reward is fixed, unlike Bitcoin. @dooglas you can (and will) still have a fee market if any portion of the fee, even 1%, is kept by the block creator. It will dramatically drive up the price of block space though, probably to levels above the social optimum. Though you still face the issue of hidden fees being paid out of band, and the incentive to do so will be large. Again, none of this is likely what is intended. Tx fees are a round peg trying to be shoved into a square hole here. |
|
|
|
Why is it advantageous to have most of this done by the node itself rather than independent chain explorer and analytics type tools, similar to what you get on blockchain.info? IMO, if it can be done outside the node, it should be done outside the node. The node itself being critical to the functioning of the network. What if a bug is introduced that introduces a crash of every node on the network when some statistics counter overflows? I'm not saying this is likely, but the risk is entirely unnecessary. Obviously per-node mempool data needs to be collected by each node, but I don't really see the network as even remotely large enough for that to matter. Bitcoin only reached that point recently. |
|
|
|
ok when i think about it its not so bad at all, since timestamps are visible no?
Yes. so if i want to declare my potential xmr salary, it is difficult to fake because i would need to make real transactions every month so it looks plausible, correct? Sure but not sure why you would do that. You could also be asked to show where you spent money on mortgage, taxes, etc. If you did that you wouldn't have enough left unaccounted to send the same money back to yourself. |
|
|
|
Your bid consists of a number of shares and a price per share. The bids will be ranked by share price. The highest bidders will all pay the same winning price totaling 1000m
Crichton bids 140 shares @ 720,000 Bid in game please. Agora marketplace item S-SQC EDIT: Current bids (see in-game for latest)540,000 2 Cryptonic 530,000 50 goin2mars 521,000 12 Cryptonic 520,000 200 Crichton 510,000 50 goin2mars 500,000 500 noms 500,000 100 luigi Current results (if auction ended)914 shares sold at 500k for a total of 457m raised (14 Cryptonic, 100 going2mars, 200 Crichton, 500 noms, 100 luigi). |
|
|
|
i did not know this about the viewkey.
doesnt this take all the magic away? i mean maybe i misunderstood, but if you cant see outgoing transactions with the viewkey, how is it usefull at all?
the information that something was there once is not enough for auditing.
It isn't sufficient for proof-of-solvency. To do that you need a more interactive protocol where the site moves the coins or discloses key images. It is sufficient for general auditing because you can demand that the owner account for everything that was received. The owner can prove what was spent and can then disclose that proof (either publically or privately to an auditor). wow sorry guys i did not know this... have to say i find the information about this (the picture above or what fluffy sayd in that presentation the other day) very missleading when it comes to this to be honest.. but maybe its also good like that, more like sitzerland, declare whatever you like so..if i send the same money to the same account again and again, what balance does the viewkey show? all incoming transactions combined? Yeah it would show that. View-only wallets really should just disable the balance display instead, or maybe change the label to "Total amount received". It is somewhat misleading the way it is now. I'd say the picture is more confusing than misleading. All of the auditing use cases are still supportable as voluntary transparency. I'm not sure what is meant by the last item about parents monitoring spending though, that seems a bit misplaced. |
|
|
|
Just for reference, this has been discussed somewhat in depth quite some time ago, so it's not a new discovery. It might not be widely known outside this thread though.
Yup. Agree on this and your entire comment. Not everyone reads the thread all the time, and new people arrive so it is reasonable to summarize and/or address the same common questions more than once. We are still getting questions about the emission curve (though that was speculation thread). Nothing wrong with that, it is a good sign. |
|
|
|
You still don't have a clue that I don't need any promotion in this forum. Good, then please try to stay on topic which is chess and cryptonote, and avoid dropping in additional mentions to your own coin, as you just did. Thanks. |
|
|
|
To expand, it is theoretically possible to, when sending a tx, create the tx in such a way that the tx key is derivable by the owner of the view secret key. That way, the watch only wallet would see both incoming txes, and those outgoing txes. If your goal is to view your normal wallet usage, then it'd work fine. I had a patch to do that, which worked IIRC. However, this requires that the spender is not an adversary, as the spender is free to build a tx that does not follow this scheme, in which case the watch wallet user will not see the spend. So in that sense, it is voluntary, and works if the user of both wallets is you, which is a common use case.
If you hold a spend key, and want to give the view key to an adversary, such that the adversary can be sure you can't spend without it being able to tell, there are roundabout ways. A prominent one which was dissussed involves making an unspendable tx (or several) with all your allegedly unspent coins, and give it to the adversary, which can then check the blockchain for the key images. Unspendable in this case means that the tx must be valid, but unredeemable. The easiest way is to double spend an extra output I guess.
That method has the advantage that such snooping is only done at the particular time the spender sends that checking tx. This means that, should a company change auditors, the auditor will not be able to see spends in the future, since no "checking tx" will be sent to them later. Though they will still see incoming txes as they have the view key.
Maybe sending a signed bunch of key images would also just work, not sure.
Bolded above: this should be the proper way to do it. 0-mixin ring sign a hash of the viewkey (or anything else) for all of your inputs. For creating a "monitor friendly" wallet, we should probably put a bit more thought into it, but mooo's general idea should work. More work needs to go into the bolded portion as well. It has the same negative effects as any other 0-mixin transaction if widely used and disclosed these key image lists are disclosed. The original purpose for which this was proposed at the end of MRL-0004 was for an auditor to verify privately and then destroy. Even that is somewhat dangerous if the same auditor is auditing many clients. |
|
|
|
i did not know this about the viewkey.
doesnt this take all the magic away? i mean maybe i misunderstood, but if you cant see outgoing transactions with the viewkey, how is it usefull at all?
the information that something was there once is not enough for auditing.
It isn't sufficient for proof-of-solvency. To do that you need a more interactive protocol where the site moves the coins or discloses key images. It is sufficient for general auditing because you can demand that the owner account for everything that was received. The owner can prove what was spent and can then disclose that proof (either publically or privately to an auditor). |
|
|
|
Smooth QC secondary stock offeringSmooth QC (which will likely be renamed, database permitting) is selling stock to raise 1000m M in order to open and operate a brewery The brewery license will be purchased from smooth at cost which was 360m M. The remainder of the funds will be used to build and operate the brewery, and other corporate purposes as deemed appropriate. The current financial position of Smooth QC is as follows: Assets
100m M
3-W-C3 - Office Building, Rentals (800 sqm lot, 744 sqm Office, 330 sqm Backyard Residential)
1 MIR (no bid)
325 SCI (bid 170k)
18 W1603A (bid 251k)
180 CUL (no bid)
1 RM1600B (bid 100k)
Liabilities and Equity
500 common shares outstanding
Current stockholders:
100 SIF
306 smooth
50 OZ
25 kronicblazer
10 binaryFate
9 Hokusai
Your bid consists of a number of shares and a price per share. The bids will be ranked by share price. The highest bidders will all pay the same winning price totaling 1000m I vote to move this to the agora marketplace, where we can still have an auction, but it's all handled by the system and we don't have to sort through forum posts: https://cryptokingdom.me/marketplace/item/S-SQCI have put 500 shares @0.5mil per there so far. That is okay as a place to collect bids. I won't be selling shares via that market mechanism (unless there is a structured auction command of which I'm unaware) because I the entire lot will be sold at once. We can use the in-game bid book for bidding though. Summary: If you want some of the secondary offering shares, place a bid in-game on S-SQC. Everyone winning will still pay the lowest winning price, once the auction is over(The current bids are well below book value, I think) |
|
|
|
Smooth QC secondary stock offeringSmooth QC (which will likely be renamed, database permitting) is selling stock to raise 1000m M in order to open and operate a brewery The brewery license will be purchased from smooth at cost which was 360m M. The remainder of the funds will be used to build and operate the brewery, and other corporate purposes as deemed appropriate. The current financial position of Smooth QC is as follows: Assets
100m M
3-W-C3 - Office Building, Rentals (800 sqm lot, 744 sqm Office, 330 sqm Backyard Residential)
1 MIR (no bid)
325 SCI (bid 170k)
18 W1603A (bid 251k)
180 CUL (no bid)
1 RM1600B (bid 100k)
Liabilities and Equity
500 common shares outstanding
Current stockholders:
100 SIF
306 smooth
50 OZ
25 kronicblazer
10 binaryFate
9 Hokusai
Your bid consists of a number of shares and a price per share. The bids will be ranked by share price. The highest bidders will all pay the same winning price totaling 1000m How many shares total and when does the auction end? *What percentage of profits are paid in dividends (from quarry, from brewery)? The number of shares will be determined by the price, such that the total share sale sale will be 1000 mil. I don't know the an estimated value of the above assets, especially 3-W-C3. If we estimate the entire thing (including 100 mil in cash) to be worth 700 mil then a book-value share price would be 1.2, meaning new 833 shares sold. My 60.3% interest would be diluted to a still-substantial but not majority interest of about 45%. If you don't think that's an accurate valuation (and I really have no idea) then adjust accordingly. Dividend policies will be determined by available opportunities to reinvest profits. There are no quarry activities at the moment, and if profits are not reinvested in quarry or something else, then the initial plan would be 100% of brewery profits to be distributed. |
|
|
|
So first i heard way back Monero was a Cryptonote fork. / clone coin from the cloning platform. You were mistaken. AFAIK the cloning platform didn't exist until months after Monero was launched. Original thread is here I think (July 1; Monero launched April 18): https://bitcointalk.org/index.php?topic=673203.0Then the story changed to it was a Fork of ByteCoin..
Now we have other news.. Monero was a community take over coin LOL
Both are correct. |
|
|
|
|
Show Posts
