Bitcoin Forum
July 06, 2022, 07:17:32 AM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Development & Technical Discussion / [invalid idea] SPV mining full blocks on: August 29, 2015, 04:25:51 AM
EDIT: knightdk points out the obvious fatal flaw in this idea below. Leaving it up for reference only.

A couple months ago I talked to maaku about mining pool centralization and possible avenues to reduce it. Here's the problem:

Pools have an incentive to co-locate because it reduces the time to download blocks from each other, during which they need to SPV mine an empty block. Right now mining pools don't suffer a major penalty by not co-locating, but this penalty will increase as the subsidy shrinks and would get worse if the block size were to be increased.

Let's assume that SPV mining empty blocks is not a sufficient long-term solution. Full-block mining currently requires that miners download and verify the previous block, so they know which new transactions may be included.

BUT, what if we prohibit transactions which use outputs from the previous block? Miners would then be able to SPV mine a full block using only the header of the previous block, certain that it's valid.

Possible attack vectors: an evil miner could either
  • Upload a header for an invalid block, or
  • Upload a header but not upload the whole block
However, I'm not convinced that these would be cost-effective attacks. The invalid block would still need to reach the current difficulty just to forfeit its entire block reward, and not uploading the whole block would increase its risk of being orphaned. I think these attacks would be as expensive as a 51% attack; the miner is spending more than he costs others just to create a temporary disruption.

This unfortunately adds the annoyance of being unable to receive and spend your coins in adjacent blocks, but you could still do so within the same block. My hope is that coin control could make this limitation less of a problem until lightning channels do away with the issue entirely.

What are your thoughts, technically-minded bitcoiners? Could this work as-is to promote pool decentralization? Is there something you would change to make it better? Is it only worthwhile once low subsidy and/or block size make pool centralization a larger problem? Any input would be greatly appreciated.
2  Other / Politics & Society / How much health care should the government provide? on: July 25, 2012, 06:44:18 PM
I've seen a few people mention that the government has an ethical responsibility to provide health care to its citizens. So how much?

Let me know if you'd like me to add any more choices.
3  Alternate cryptocurrencies / Altcoin Discussion / Namecoin and Economic Rent on: July 13, 2012, 12:01:46 AM
I normally hate "OMG I discovered an econ flaw!" threads and can't be the first person to think of this, so please point me in the right direction if it has already been discussed.

Namecoin has a different "early adopter" effect than Bitcoin. Specifically, the only objects with value in Bitcoin are the coins themselves, which are fungible, while Namecoin also has domains which are non-fungible. "google.bit" is worth FAR more than "googlesearch.bit". In this respect names behave similarly to land; there are infinite spots available, but some are worth a lot more than others.

In part because of its fungibility, the market for Bitcoins has nearly perfect competition. Since names are not fungible and "rent" is extremely low, used Namecoin domains may experience monopoly pricing. So I can buy Bitcoins/Namecoins from Alice if Bob charges too much, but if I want Bob's Namecoin domain he can dictate the price.

As with any monopoly this incurs a deadweight loss, and is less efficient than if we magically knew the economic rent of a name and required name owners to pay it in their transaction fees (or whatever). Unfortunately, I have no idea how to determine the economic rent of a name without a central authority.
4  Economy / Trading Discussion / Decentralizing prediction markets - with Open Transactions on: May 16, 2012, 12:37:22 AM
Lately I've been investigating how to better decentralize prediction markets. Although custom smart contracts in a cryptocurrency blockchain would be nice, this isn't realistic yet and I'm not skilled enough to even define it properly.

So for now I've been messing around with Open Transactions. Although a server is trusted to process transactions, the server's power is limited. Eventually many servers will work in unison, storing your bitcoins in multisignature transactions to prevent one rogue server from stealing them. So it's not 100% decentralized, but this will improve with time.

One thing you can do is issue and trade your own "basket" currencies. For example, I can create a basket worth (1 BTC + 1 NMC) and sell them bundled together. This feature could really come in handy for predictions! Let's say I create two currencies...
(1 BTC if event X happens)
(1 BTC if event X doesn't happen)
... and then put them in an "event X" basket. I then sell these baskets for 1 BTC each. If Alice wants to bet that event X will happen, she buys a basket from me for 1 BTC and offers to sell the "doesn't happen" half. If Bob wants to bet event X won't happen, he can buy the "doesn't happen" currency from Alice. Once the statement reaches its conclusion, I place an offer to sell all the BTC 1=1 for the winning currency.

  • Separation of powers between issuer and server
  • Strong anonymity for bettors - even the bookie doesn't know what you're trading!
  • Better resistance against hackers (especially once OT supports multisignature transactions)

  • Bookies can still steal everyone's bitcoins and run away
  • OT is still brand new and isn't ready for prime time yet

In theory one can create a smart contract for multiple voting bookies (to reduce the risk of theft), but I haven't quite gotten there yet. The important part is that this can be done right now using existing software, reducing the barrier to entry for all you would-be bookies who don't want to run a website.
5  Other / Meta / Moderation of "Get Ready for "MicroCash"" on: May 11, 2012, 04:17:52 PM
Has someone been deleting posts?
6  Alternate cryptocurrencies / Altcoin Discussion / What defines a cryptocurrency? on: November 08, 2011, 09:31:13 PM
There has been some disagreement here as to what exactly constitutes a "cryptocurrency". Maybe we can establish a rough consensus here. I just added everything I could think of, so please let me know if I've missed any potential criteria.
7  Economy / Trading Discussion / Decentralizing prediction markets on: October 07, 2011, 03:05:10 AM
Lately I've been checking out prediction markets like Bets of Bitcoin and BTfuture. While they are a great start, what if some day they become unavailable like I think one possible direction this could go is to further decentralize prediction markets. So far I've got two ideas:

1) Many compatible markets, so bettors can spread out the same bet over multiple bookies. For example, an open-source prediction market like bitpredict would spawn many identical sites. Skilled traders or an automated script could place 1/100th of a bet with 100 bookies, thus averaging out the risk of loss. Right now every market operates differently so spreading out bets can be inconvenient.

2) Offline signed transactions could be distributed by bookies to trusted agents. For example, a bookie could manage a bet with three outcomes (yes, no, cancel) so he creates three signed transactions and sends them to his friend. If the bookie becomes unavailable to resolve the bet, this agent would broadcast the winning transaction. This is preferable to sharing private keys because it has a smaller risk of theft.

What I'm hoping for is a long-term solution for prediction markets that isn't vulnerable to the loss of one person or organization. Large webs of trust could even enable a market on a single event to have hundreds of bookies, each with multiple agents who can settle their small percentage.
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!