I have been meaning to post this publicly for a while but.. lol This is a release of my CPU miner mod for SRC / QRK. Windows x64 SSE4 only so far.. so have been too busy to worry about Linux support so far  It was coded in notepad and Visual Studio 2010 and compiled with MingW x64 It comes with a variety of bug fixes and new features and speed enhancements. Please read included documentation ..I'll update this post with more info later. Where is the source code? If this is a modification of the previous CPU miner, you are required by the GPL to release the full source for your version. (Plus, anyone who downloads and runs prebuilt binaries from this forum with no source available is a bit dim, IMHO) |
|
|
|
|
Also, the known issues a while ago with QRK/SRC share difficulty might be a reason for the client and pool displaying different hash rates.
The coinmine pool does not allow too-low difficulty share submission.
The rate accepted by the pool is the reality.
|
|
|
|
Amazon and Walmart together control a large chunk of transactions in the USA. If they jumped in early (e.g. 2016 or so) before most other merchants had, they could command a huge percentage.
Which is of course why Amazon and Walmart have formed a cartel to control credit card payments, denying their fees to existing players like Visa and Mastercard, with such low payment costs that other merchants have been forced to join their cartel. Oh wait, they haven't done that, have they? |
|
|
|
The cartel profits along the way because customers leave the non-cartel because the transactions for non-cartel customers are delayed by an ever increasing delay as the cartel's % of the hashrate rises. The cartel starts with less than 50% of the hashrate, therefore their transactions are delayed on average longer than non-cartel transactions are, therefore, by your argument, customers should leave them for the non-cartel parties. You have handwaved at this by saying that the cartel can just accept transactions without waiting for confirmation, but that non-cartel merchants can't, without giving any good reason why. The cartel profits by keeping all their transaction fees to themselves starving the network of them, thus reducing the network hashrate due to lower funding for all the other miners, thus increasing the cartels % of the mining hashrate (did you forget to read upthread that the cartel is mining?). The cartel loses money because they refuse to process transactions (and thus take transaction fees) from other parties. Other parties profit because they are (unwittingly) withholding their own transactions from the cartel. The cartel has less than 50% of transactions, therefore they lose more fees than they withhold from the non-cartel parties. Therefore, by your argument, the cartel mining hashrate will reduce due to lower funding. I hope you see I just described a spiral in favor of the cartel. Exactly the opposite. Take away all the cartel fluff, and what you are basically saying is that someone who can fund a major portion of the network hashrate, and take constant losses due to refusing transactions, can delay transaction processing. That isn't a new idea. You've really failed to show any link between that, and a rational reason for Amazon et al to attempt such an attack. The purpose of the attack would be to damage Bitcoin. The purpose of Amazon is to make money. Damaging Bitcoin does not make Amazon money. |
|
|
|
Got to be in it to Win it. Joshua: A strange game. The only winning move is not to play. |
|
|
|
... and you can refund up to shipment Which we know was a lie last time around. Not exactly, you were able to refund to the point the list was sent to the facility to process your order for assembly. So... not until shipping then? Assembly is not the same as shipping. If they had said you can refund until assembly, they would have been truthful. They said you could refund until shipping, and were not truthful. |
|
|
|
... and you can refund up to shipment Which we know was a lie last time around. |
|
|
|
|
So you have no answers, and just refer to your previous non-answers.
People can see that, you know?
(And you'll write 10 more pages, either in this thread or another, because you can't seem to help yourself)
|
|
|
|
A few of the points against offchain:
* cartel can't scale up by leveraging the existing network What does that actually mean? Simply paying yourself fees that you could just pocket in the first place doesn't leverage anything. * cartel can't delay non-cartel transactions to force their customers to the cartel That makes no sense. Generating empty blocks would delay other transactions just as much as generating blocks with their own transactions. * cartel can't prevent the customer from spending the BTC else where if cartel doesn't process onchain, thus doesn't deprive non-cartel of revenue Of course they can. In the off-chain scenario, customers would deposit funds to addresses in a cartel wallet, and therefore would have no opportunity to later double-spend them. If you wanted to buy a dozen things from Amazon over the course of a week, rather than a dozen separate on-chain transactions, you would buy Amazon points up-front, with a single on-chain transaction, then spend those points off-chain. This isn't exactly a new idea. It is how existing stored-value systems work, like Apple gift cards, Microsoft points, Sony PSN wallets, existing BTC exchanges... * transaction fees are paid by customers thus it is revenue They can take the fees from the customer either way, it makes no difference whether they then actually spend them as transaction fees. (Plus, they would gain more customers by instead waiving the fees and offering cheaper processing than non-cartel merchants) * they generate profit by growing the cartel, using the above factors The above factors don't make sense, so this doesn't add anything. |
|
|
|
You are confusing the cartel's transactions with the non-cartel transactions. The later are the ones that get delay. The cartel's miner excludes them when adding a block solution to the block chain.
So basically you say the cartel will for bigger future profits, now not reap the profits of non-cartel transactions. (that do give transaction fees, transaction without fees I now disregard, as i find it normal nobody wants to work for free...) So analogy in the ´real´world in the sense that a cartel of shops somewhere lower their prices substancially, running losses, to outdo other shops to bankrupcy, and after that raise prices and earn a lot of money ? Also I noticed you talk about 2 things: firstly a cartel not forwarding transactions to other miners, secondly a cartel not accepting transactions from non-cartel members. And realize that because of those 2 things, this is horrific case where the cartel can both continue to profit on the transaction fees, i.e. it doesn't have to sacrifice by offering lower prices, and depriving the non-cartel miners of (increasingly greater share of) income while also depriving the non-cartel merchants and their customers of fast transactions. The only transaction fees they will receive are from transactions they generate. They are just paying themselves, that can't generate profit. Exactly the same result would be achieved by just mining their own transactions for zero fees, or processing them off-chain. |
|
|
|
a) There will only be 1000 shares ever, so 1/10th of shares are being sold right here right now. put up or shut up, you know we're legit. we came to flip the alt scene. b) Site share model breakdown
5000 shares total, non dilutable.
20%(1,000) publicly traded, non dilutable.
20%(1,000) site operational costs.
60%(3,000) staff.
So actually there are 5000 shares, not the 1000 you first said. c) Fully Functional: Yes**
**-Moderator class/functions do not exist yet. withdrawals are a work in progress.
You have an exchange with no way of withdrawing money, but consider it fully functional? |
|
|
|
I don't see the problem with mining. You don't need to give the pool a payment address until it's time for you to take your balance. You can put *MONTHS* or even *YEARS* of mining output in a single tx, in a single address Which is a really bad idea, and one that I imagine most pool operators would strongly advise you not to do. Bitcoins in your account with a pool are not really yours, not yet. They are just a ledger entry saying that the pool owes you money. If the pool is hacked, or just vanishes, those Bitcoin are gone. And it isn't as though that hasn't happened, more than once. |
|
|
|
Let me get this straight, JR won't quit his job unless he's worth $100M,  . After btc rally last week I guess many of us here are already millionaires, real jobs are getting less and less relevant, we should be doing this for passion. My wife doesn't care one fig about internet money which isn't in our bank account. That's the real hurdle. The other half of the problem is I don't want to sell MSC at today's prices. I think I have found the ideal solution though, which I just posted in David's thread about project money this morning: I think perhaps it is time to convert more of our BTC to MSC. I'd rather have MSC in a rainy day fund than BTC anyway. As you say, giving away BTC attacts people more interested in BTC, and I'd rather the foundation hold MSC than BTC. Here's my crazy proposal: 1) Keep only the 1000 BTC we've already moved into offline wallets 2) Use the remainder of our BTC to purchase MSC over the next few months on the distributed exchange 3) Pay all future bounties exclusively in MSC 4) Keep half of our MSC money for a rainy day and/or future distributed bounty system 5) If our rainy day fund becomes excessive, we can always vote to lower the ratio later I realize that this would potentially make all of our existing investors absurdly wealthy, but, well, the stated purpose of the Mastercoin Foundation is to serve the holders of Mastercoins, and I'm having a hard time seeing this course of action as anything but a huge positive for them, as long as we do it transparently and over a long enough period of time that nobody who wants to sell to us is left out. Also, MSC prices would probably go up to the point where I'd sell 1% and quit my job to work on MSC, which I hope would also be in the best interests of our investors.  If you guys think that's a good idea, please go there and help me convince the board that: 1) It's not market manipulation, it's a stock buy-back over a long period of time, with complete transparency 2) It doesn't make MSC more centralized, because we'll be giving this money away in bounties rather quickly I think it gives the appearance of qute a large conflict of interest, when you hold such a large proportion of MSC, and so would be the primary beneficiary. |
|
|
|
Yup. I had mentioned both of these upthread. What took so long. Well thanks for joining the party. You've mentioned lots of things. Noone seems to have found a coherent, logical threat in what you have said though. And you still haven't answered my question from above, why would the cartel go through all the hassle of creating on-chain transactions simply to withhold them from the rest of the network, when they could accomplish the same things with off-chain transactions? |
|
|
|
The reason is because the cartel needs to gradually consume the hashrate of the network, so it can delay the transactions of non-cartel customers who are on the blockchain. To force them to join the cartel or lose customers to the cartel. Why? You think they will create transactions that don't need to exist, just so that they can not send them out to the rest of the network? You are confusing the cartel's transactions with the non-cartel transactions. The later are the ones that get delay. The cartel's miner excludes them when adding a block solution to the block chain. I agree that one of us is confused, but I'm not sure it is me. In your original post, you said: But a cartel (e.g. Amazon.com) could for example harvest transactions from its vast network and keep them without forwarding them to other miners. Then put them on the blocks found by its own mining servers. ie. The cartel would withhold their transactions from other miners' blocks. Now you are saying that they would withhold other peoples' transactions from their blocks. That is a completely different issue. |
|
|
|
The reason is because the cartel needs to gradually consume the hashrate of the network, so it can delay the transactions of non-cartel customers who are on the blockchain. To force them to join the cartel or lose customers to the cartel. Why? You think they will create transactions that don't need to exist, just so that they can not send them out to the rest of the network? From the network point of view that is the same as the transactions not existing in the first place. Why bother with all the hassle, just to pay yourselves transactions fees that could be totally avoided by doing offchain transactions in the first place? They need to gain hashrate in order to withhold transactions. They need to withhold transactions in order to gain hashrate. Phase 3: Profit? |
|
|
|
This line of thinking was already refuted. See my replies to JoelKatz.
If by refuted you mean: waved hands at, blustered and ignored, sure. If Amazon control the wallet, there would be no reason for them to have on-chain transactions in the first place, they would do the entire accounting in-house. Just like exchanges do already. |
|
|
|
The cartel can give 0-confirmation transactions to its customers, because these are going to be repeat customers because the cartel covers so much commerce.
Everyone can give 0-confirm transactions to their customers. That's a question of business risk, not capacity. It happens now. Please search for the fast-transaction problem and/or the vending machine problem. Don't play dumb just to obfuscate the point. The point is the cartel doesn't have delay transactions for its customers when it withholds them from the other miners. The nature of the protocol requires that the cartel delay transaction processing for it's customers because it withholds them from other miners. There is no way to avoid it! That's what you can't wrap your head around! You still didn't get the point. The customer will never care that the transaction is delayed into the blockchain (delayed until the cartel's mining servers wins a block in the proof-of-work), because Amazon will give their customers 0-confirmation access to what they purchased. So that delay is irrelevant. That only works if the customer does not have control of their wallet, otherwise they could double-spend the money away from Amazon. So Amazon must control the wallet. In which case it could instead just manage everything off-chain instead, as current exchanges do. So there are no transactions to withhold. |
|
|
|
Sorry but you don't understand the technology well enough. The reason most readers dismiss my posts, is because they lack knowledge to ascertain how correct I nearly (as in 99.9%) always am if I've studied some matter for a sufficiently long time. The reason the core developers won't debate with you is that you appear to be a know-all blowhard who simply ignores any posts that don't agree with your views, and repeatedly tell the entire world how much smarter you are than them. You raise an irrelevant point about double-spends You raised it, not me. |
|
|
|
Miners have ALWAYS had the freedom to pick which txs they want to include in blocks. If you feel miners shouldn't have that freedom then you probably should have done more research before getting involved in Bitcoin.
[...]
If you have done so little research that this didn't occur to you, well I would recommend some critical thinking. I know that, I'm not sure why you feel the need to be condescending in every reply. Does that also mean that people shouldn't debate the rules that miners use, for example in an attempt to persuade or dissuade other miners from adopting the same policies? Isn't that what this thread is for? |
|
|
|
|
Show Posts
