Any updates on this "stalemate", or on how the ASIC's are doing? Has a unit been shipped to Meni?
I haven't received anything. I believe that Alberto didn't demonstrate sufficient good faith (to say the least) and his request is not reasonable (at least not without a satisfactory repayment plan), I'll try talking with him again. |
|
|
|
|
In this case the network is in disagreement, each node chooses the branch it learned about first. The tie will be broken when another block is found.
|
|
|
|
I've hit so many short blocks in a row the fee is up to about 10%. I can't see miners appreciating that, even if in the long run it will all even out. (My fee on a recent long block was 0%.)
This sentence doesn't make sense. You're reducing the miners' variance and taking it on yourself. In PPS with similar luck your fee would have been 300% and miners would still appreciate giving them variance-free payouts. So I might retool a bit to move from c=3% to f=3%.
If I have c=0 though, what should I use for r since I can't divide by zero?
If c=0 then o must be 1, and then you can choose anything for r. r = 1+p is a good choice, more generally you can use r = 1 + a p, where larger a gives more variance and less maturity time. |
|
|
|
it is still in the miner's best interest to keep a block size limit in place.
Miners are not a monolithic entity. If miners try to keep a grassroots size limit, every individual miner has an incentive to mine a bigger block and scoop up all those floating transaction fees. This is a classical tragedy of the commons scenario. There needs to be a good tx fee mechanism that properly sponsors both the amortized cost of hashing and the marginal cost of processing (storage, verification, communication). To sponsor hashing you need to limit (or charge for) the total value sent in a block; to sponsor storage and communication you need to limit the block data size; to sponsor verification you need to limit the total script complexity. Can you tell me where I can research various entities and see if they pay fees? I wanted to see how much people like dice and gox pay back into the system since they are the largest users of capacity. I am not familiar enough with everything to know how to do this. SatoshiDice is easy - their addresses are constant and public, and you can look them up. In fact if you go to the blockchain.info homepage you'll see that almost half the transactions are SD, and labelled as such. AFAICT they always pay a fee. For Mtgox it's a bit harder. |
|
|
|
it is still in the miner's best interest to keep a block size limit in place.
Miners are not a monolithic entity. If miners try to keep a grassroots size limit, every individual miner has an incentive to mine a bigger block and scoop up all those floating transaction fees. This is a classical tragedy of the commons scenario. There needs to be a good tx fee mechanism that properly sponsors both the amortized cost of hashing and the marginal cost of processing (storage, verification, communication). To sponsor hashing you need to limit (or charge for) the total value sent in a block; to sponsor storage and communication you need to limit the block data size; to sponsor verification you need to limit the total script complexity. |
|
|
|
Hi Adam, it was great meeting you in SJ. I've discussed block withholding attacks in section 6.2 of https://bitcoil.co.il/pool_analysis.pdf. I think there are a few things you've missed here: 1. There are PPS pools, and they will likely be more common in the future. You can withhold blocks from such pools with no consequence to yourself; you gain the advantage of reduced difficulty, and you can harm the pool operator (e.g., if he is a competitor). 2. Withholding completely is not the only thing you can do; you can also delay the reporting and use your additional knowledge for an advantage. This is profitable also against non-PPS pools. I call this "lie in wait". I thought eligius CPPSRB seemed like a nice way to allocate funds fairly.
Eligius originally used the proportional method. I explained that it's broken and suggested that they use a hopping-proof method instead. Then they switched to MPPS. I explained that it's broken and suggested that they use a hopping-proof method instead. Then they switched to SMPPS. I explained that it's broken and suggested that they use a hopping-proof method instead. Then they switched to CPPSRB, and I gave up. It's not as broken as the other methods, but there's no reason to use it over the hopping-proof methods PPS, PPLNS and DGM. |
|
|
|
There is now also a PowerPoint presentation about this subject, prepared for the conference in San Jose. I had to make it fit in an half-hour slot so not a lot of material is covered. |
|
|
|
This offer is no longer valid since each bitcoin is now worth much more than back then; and there's no sufficient demand to justify coming up with updated values. In case this wasn't clear, this offer was heavily inspired by Knuth reward checks. |
|
|
|
...
* The colored coin concept is HUGELY powerful - I had thought it an interesting diversion before I came but, after it was explained a few times, it made me realise just how versatile the core "distributed ledger" metaphor really it.
Of course. Everyone likes a free lunch and sees a way to get rich by sponging off the work of others. Not sure I understand. What are you objecting to? The repupurposing of the bitcoin network for the tracking of real-world assets? something else? Essentially that, yes. I'm bummed out that it takes so much overhead already that users (including my friends) are discouraged from running a full node. In other words, are no longer reasonably capable of being 'peers' the the supposedly 'peer2peer' solution. That lie is finally starting to be deprecated it seems...years after I suggested that it might be intellectually honest to start doing so... Anyway, the issue will only get worse when they need to process data for everyone who wants to use Bitcoin as a reliable messaging and storage solution. It does seem that there is a significant overlap in the groups of people who bitch most loudly about the fees/block size are they who are all ga-ga about colored-ish utilization. The idea that end users will not hold the entire blockchain, but rather use SPV clients, dates back to Satoshi's original whitepaper. In a communist society you are limited in how you can use the shared resources. In a capitalist society you pay for the resources and use them however you see fit. It does not make sense to limit what you can use the blockchain for as long as a fee is paid to compensate. Essentially that, yes. I'm bummed out that it takes so much overhead already that users (including my friends) are discouraged from running a full node. In other words, are no longer reasonably capable of being 'peers' the the supposedly 'peer2peer' solution. That lie is finally starting to be deprecated it seems...years after I suggested that it might be intellectually honest to start doing so... Anyway, the issue will only get worse when they need to process data for everyone who wants to use Bitcoin as a reliable messaging and storage solution.
It does seem that there is a significant overlap in the groups of people who bitch most loudly about the fees/block size are they who are all ga-ga about colored-ish utilization.
Iw under the impression that colored coin making and tracking was done entirely from the client, not touching the Bitcoin network other than to send Satoshis back and forth? This is correct, the argument is that sending satoshis back and forth allegedly bloats the blockchain. |
|
|
|
I enjoy meeting people from the forum in person to finally put a face to a name. So far the forum members I've talked to include:
cypherdoc
mindtomatter
aantonop
etotheipi
maaku
JoelKatz
CoinHoarder
Gavin Andresen
misterbigg
gmaxwell
Luke-Jr
...and several others whose handles I can not remember.
OMG - Luke-Jr is there! Does he really look like his photos? That's the one person I would really like to meet. LOL Gah. I haven't seen 2/3rds of those people yet. I feel you, it's so big and with so many things to do it's hard to find everyone. I hope to grow my own list today, I'll be wearing a red buttoned shirt in case anyone tries to locate me. |
|
|
|
Hey Meni, with f=0.0 and c=.03 I'm assuming in long rounds the pool makes little/nothing and in short rounds it makes more than 3% to offset that. However, it seems so far (now that the first few blocks are out of the way and the miners have plenty of score) that in a really long round I'm making a hair over 0% (which is ok) but in a really short round I made a hair under 3%. The short round making 3% of the pool is what had me confused. I was figuring in short rounds (CDF was 2.2%) the pool would make well over the value of c.
Any thoughts? It's possible I have something wrong, although my java and php implementations resulted in the same values and it seems to be functioning correctly for actual miner payments.
There's cross-round leakage, so the pool's proceeds depends not only on the length of the last round but the previous rounds as well. If the short round you looked at followed a succession of long rounds it's normal to have low revenue. |
|
|
|
If I do relaunch, I intend it to be using a decentralized platform such as colored coins. |
|
|
|
i'll be staying at the Marriott, arriving Thursday noon. There's a meetup in the evening, perhaps a few of us can hang out before that at the lobby of the Marriott or Hilton. Meni! I'm finally making it to a Bitcoin conference--even if it is two years later. We'll have to touch base! Certainly! I was very happy to see you back in the community, looking forward to meeting you. |
|
|
|
|
Awesome! I've been waiting 2 years for this.
|
|
|
|
Excellent suggestions!
Do you or someone else on the forum have time over the next week to get these contacts up on the site?
We're already getting dozens of media requests in anticipation of the bitcoin conference next week.
PM sent. |
|
|
|
A few suggestions: Myself (Meni Rosenfeld), Ron Gross, Gil Assayag, Eli Sklar. (I don't currently have the time to offer more detailed descriptions).
|
|
|
|
i'll be staying at the Marriott, arriving Thursday noon. There's a meetup in the evening, perhaps a few of us can hang out before that at the lobby of the Marriott or Hilton. |
|
|
|
I am not sure if I would call it cheating. In the case of Teracoins, some kind of algorithm that makes hash rates more even would actually benefit the entire community.
Not sure what you mean but IIRC the formulation in AoBPMRS treats difficulty changes properly, it will work even if the difficulty changes frequently. |
|
|
|
|
Show Posts
