Bitcoin Forum
April 27, 2024, 03:15:53 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Bitcoin / Project Development / Re: [WHITEPAPER] Decentralized Bitcoin Prediction Markets on: May 26, 2014, 06:47:41 AM
Allows for the creation of ‘Trustless Dominant Assurance Contracts’ which allow financing of public goods such as lighthouse, roads, etc. with no counterparty risk.

Interesting. Still not prediction markets. But how? Also, I don't see the no counter-party risk part unless there is a big backer like AIG or a secondary market like Marsh-Mac, or a big-ass escrow account. Or a bond-type thing. Which ... has a counter-party.
Anyway: I like your enthusiasm. I like the applications you are pondering. I can not but help think (and yes, I've read your paper) that you haven't thought through the hurdles of implementation. Or are you simply looking at this as a theoretical economic game-theory model framework?

I don't think you read the document 3_PM_Applications.pdf, because it answers the vast majority of your questions. It explains how you can break up binary predictions into probability distribution functions over subsets of the domain (what are the chances btc will be 500 or above? $600? $650? $700?) all within the same market. It explains how to chain predictions together to define a matrix of probabilities for combinations of outcomes. So if Policy X is not enacted, will unemployment rise by Y%? What about the converse?

Those who do not have specialized knowledge should not be betting, as they will likely lose money in the long run. That is, unless they are hedging. For instance, if you're a farmer you can hedge against a drought occurring if a market exists to predict it. Another example would be for funding public goods. For instance, say you want a road to built from point A to point B and you think the community wants it also. You start a PM, specifying whatever level of detail is necessary, then release it onto the TruthCoin network. Everyone who WANTS a new road bets that it WON'T happen (it's a win-win situation for them), and those with expert knowledge of the local property rights, permits, etc will speculate. If enough capital is raised on the NO-ROAD outcome, then at some point it becomes profitable for anyone capable of actually building the road to go ahead and do it, buying up YES-ROAD shares beforehand.

Finally, the proposal is for a protocol, so it's up to the user to abide by local laws.
2  Bitcoin / Project Development / Re: [WHITEPAPER] Decentralized Bitcoin Prediction Markets on: May 22, 2014, 02:48:27 PM
I am a fan of prediction markets too, after the OP is there more developments on this issue

Narayanan's group at Princeton developed independently a similar concept using with competing arbiters: http://users.encs.concordia.ca/~clark/papers/2014_weis.pdf In their paper they compare their model with Truthcoin:

Quote

Voting as a Keynesian beauty contest. In this approach, each of N shares in a prediction market
confers one vote for market arbitration [7]. In the common case, a supermajority of voters ( k > 2N/3) vote
the same way, this is considered a consensus and the winning shares will be paid out.
Of course, voters holding losing shares have a nancial incentive to vote contrary to reality. To address
this dilemma, all market participants are required to post a bond in addition to the price of the shares
they purchase. Any voters who vote contrary to an outcome with reaches a 2N/3 consensus forfeit their
bond, disincentivizing voters to vote against the likely nal outcome. The market might still fail to reach
consensus if, for example, there are two possible outcomes and all participants holding shares in the losing
outcome form a coalition and refuse to provide any votes necessary for the market to reach consensus. To
disincentivize this, if the market fails to reach consensus after a certain time period then all participants
forfeit their bonds.

The functioning of such a system in practice is unknown. In the case of markets with a genuinely unclear
outcome, the system creates a \Keynesian beauty contest," with all participants incentivized to vote for the
outcome they believe others will consider correct, rather than their own fundamental beliefs.

Ignoring such cases though and assuming a market with a clear outcome, this system produces an iterated
game of chicken between coalitions of voters holding shares in each outcome. If either coalition is able to
convince the other that they are absolutely going to spend their
N/2 votes on their preferred outcome, the other side is incentivized to back down and concede to prevent losing their bond. It is only be repeated play, in which participants have a reputation to maintain that will be damaged if they vote for a patently incorrect
outcome, that this game can be avoided. Thus we think this approach is less desirable as it requires tracking
reputations for all participants in the market and not just a small number of adjudicators.
3  Bitcoin / Project Development / Re: [WHITEPAPER] Decentralized Bitcoin Prediction Markets on: May 22, 2014, 04:40:30 AM
I've really enjoyed reading your work. I'm a physicist, so the very idea that we can generate probability distribution functions for human actions is just mind blowing. I'm actually starting to learn some game theory because of it. Anyway, I have one question - do you think meta-predictions could counter attempts to game your system? For example, we could start a prediction market that predicts a consensus of voters will vote against the truth in one or more markets. The reason I ask is that Nash equilibria are supposed to make law enforcement unnecessary (For example, in the stop light game it's unnecessary to have a law against running the stop light because players have enough incentive not to). In the same way, doesn't the protocol act like law enforcement, and if so could such "second-order" predictions offload some of the work of ensuring players remain honest?
4  Bitcoin / Development & Technical Discussion / Re: Stealth address with SX (anonymous payments) on: January 17, 2014, 11:38:21 PM
My concern with the name Stealth Address is that it will end up being a niche feature that most people will not use.  Peter's "Ohh, privacy is good!" argument makes sense among his peers, but will fall flat on most common users.  Most people "Have nothing to hide" and aren't threatened by privacy, even with all the leaks and damage done.  This should be viewed as a standard and non-scary option, and not something for criminals and troublemakers only.  Stealth has those connotations, and I have a feeling it will become put in a corner.  I think he is also a bit biased in that the super-plugged-in people (aka meetup attendees) have heard of this term and it's too late to change it.  I disagree that it's really that well known, even within the Bitcoin community.

Names seem to fall out of describing how something is used or describing what it does.  We should also focus describing traditional addresses as well, to see if there might be a way to relabel them.

The way things are going with twister integration, it won't even matter whether we call them "stealth" addresses at all, because the average user won't even know they exist! When they make a payment it'll be to an identity - a person - not to some incomprehensible string of numbers. From that perspective, call them whatever you want.
5  Bitcoin / Development & Technical Discussion / Re: Stealth address with SX (anonymous payments) on: January 17, 2014, 08:10:05 PM
Cool  Roll Eyes Roll Eyes

If I understand it correct, the sender must know the stealth address from the receiver and the receiver must know the nonce from the sender, so information need to be exchanged both way, comparing with the standard way of only providing a receiving address?

This creates a strong use-case for Twister adoption: Put your stealth address in your twister profile. When you send a payment, send a direct message with the nonce to the receiver. DM's are encrypted in twister. Take it a step further: bake this feature into every bitcoin-twister client so the user never even sees their stealth address. Then, all bitcoin payments reduce to "1.5mB @bob". It takes all the centralization out of the current tipping schemes and makes them forward-anonymous by default.

ssshhhh you're giving away my secrets Wink

Sorry. I just can't help myself. Haven't even been sleeping since my mind exploded over this. What I just realized is that your client could by default display your balance in your local currency based on geolocation data. This means users wouldn't even know they're using bitcoin!

Alice: +$5.00 @bob
Bob sees his account balance is now 66.35 pesos
Carol: Hey @Alice, @Bob have you heard of bitcoin?
Bob and Alice: wtf is bitcoin?
Carol: it's what made your transaction possible!
Bob: yeah.. And?
Alice: @Carol stop being a smartass
6  Bitcoin / Development & Technical Discussion / Re: Stealth address with SX (anonymous payments) on: January 17, 2014, 09:07:33 AM
Cool  Roll Eyes Roll Eyes

If I understand it correct, the sender must know the stealth address from the receiver and the receiver must know the nonce from the sender, so information need to be exchanged both way, comparing with the standard way of only providing a receiving address?

This creates a strong use-case for Twister adoption: Put your stealth address in your twister profile. When you send a payment, send a direct message with the nonce to the receiver. DM's are encrypted in twister. Take it a step further: bake this feature into every bitcoin-twister client so the user never even sees their stealth address. Then, all bitcoin payments reduce to "1.5mB @bob". It takes all the centralization out of the current tipping schemes and makes them forward-anonymous by default.
7  Bitcoin / Mining / Re: How long should miners wait to start hashing? on: March 13, 2013, 10:36:45 PM
Thanks for clearing this up. It makes a whole lot more sense now. I'll tip you when I find your address.
8  Bitcoin / Mining / Re: How long should miners wait to start hashing? on: March 13, 2013, 09:58:22 PM
I think I see what you're saying. I had assumed that once a miner starts solving a block they can't incorporate new tx's that appear after they started. If everyone was solo mining that would make sense. If new transactions are taken into account by pooled mining, then I agree it doesn't help to wait.
9  Bitcoin / Mining / Re: How long should miners wait to start hashing? on: March 13, 2013, 09:39:25 PM
0 seconds.  Anything else is idiotic.

There is currently a block subsidy of 25 BTC.  Ever second you aren't hashing for that is a significant reduction in gross revenue.  Now maybe someday when the block subsidy is much much lower and fees are much much higher (say in 32 years = 8 block subsidy halvings) it may make sense for some miners to go offline but today the math is simple ... you wait 0 seconds.

So what you're saying is, miners should disregard any increase in potential payout? At what point exactly does the increase in payout become relevant, and can you prove it is irrelevant now?
10  Bitcoin / Mining / How long should miners wait to start hashing? on: March 13, 2013, 09:16:29 PM
I haven't been able to find information on this yet, so below I'm assuming miners don't do this.

Say the most recent block is solved and miner Bob finds out about it at t=0. Bob already has a pool of transactions to start hashing on. However, Bob could wait for transactions with higher tx fees to show up. If he does this, his probability of finding a block will be lower (having less time to mine), but wouldn't his potential payout be higher? If so, wouldn't there be an optimal time that Bob should wait to maximize his overall revenue? What strategy should Bob use to determine his optimal wait time?

Say Bob and Bill have similar hash rates, but Bob uses this strategy and Bill doesn't. Bob ends up using less electricity than Bill, so not only is Bob's revenue higher, Bob's profit margin should also be higher, no?

Taking this train of thought further, say Jill has twice Bob and Bill's hashing power. Will Jill's optimal wait time be longer than Bob's? In other words, if Jill can afford to wait even longer than Bob can, her payout will be even higher than Bob's. That's good news for her, especially since her electricity costs are also higher.

If every miner adopts Bob's waiting strategy, what effect would this have on confirmation times? For example, Jill will end up with transactions in her block that wouldn't be there if she didn't wait. Therefore, if Jill manages to solve her block, it will contain higher valued transactions that confirmed in a time significantly less than 10 minutes. If Bob solves his block, his set of transactions should be older than Jill's, but the tx fees in them will also be lower. Would this lead to tx fees becoming strongly correlated with confirmation times?
11  Bitcoin / Mining / Re: Confirmation time vs tx fee: Another reason to keep the blocksize where it is? on: March 11, 2013, 07:11:57 PM
I think I'm starting to get it. Alice's work gets ignored if Bob solves his block first, regardless of who has the faster hash rate? I had thought both sets of transactions could be merged into the blockchain, but I guess Alice has to include the hash of the newest block if she wants to get a reward+fees.

Well it isn't so much "ignored" as worthless.  How much are losing lottery tickets worth?  Just about as much as Alice hashes which don't solve a block.  I guess because the idea of mining for day, months, years without solving a block is depressing sometimes people have a tough time realizing there is no "progress" towards a block.  You either solve it or you don't.  

If you attempt 1 trillion hashes and none of them solve a block you are no closer to solving a block then before you started.


Still you are right there is no concept of "merging" transactions.  Even if there was Alice would be better served still going for the highest fee tx (no matter how painfully slow she is).  If Bob solves a block, Alice validates the block and removes all the included tx from the memory pool.  Alice then reselects the "best" tx, builds the merkle tree, and starts hashing a new block.  The amount of effort in constructing the blockheader is negligible compared to the trillions upon trillions of hashes (proof of work) it takes on average to solve the block.  It doesn't save Alice any time or energy to NOT include the most profitable txs.



Thanks very much for the explanation. It now makes sense that Alice should include the highest fees that she can, but doesn't she have to trade off waiting for higher fees to appear before she can start hashing? The longer she waits for higher fees to come in, the more likely it is someone else will solve the next block before she does, right? By not waiting for higher fees, she's effectively lowering the range of tx fees she can accept. EDIT: if that's true, it also means Bob can afford to wait for higher fees before he starts work. If Bob solves his block it will contain newer txs with higher fees, while Alice's block contains older txs with lower fees. So it is as though Alice and Bob are competing over different tx fee ranges. The market will still end up pricing confirmation times as I'd hoped, but for different reasons Wink
12  Bitcoin / Mining / Re: Confirmation time vs tx fee: Another reason to keep the blocksize where it is? on: March 11, 2013, 05:40:45 PM
I think I'm starting to get it. Alice's work gets ignored if Bob solves his block first, regardless of who has the faster hash rate? I had thought both sets of transactions could be merged into the blockchain, but I guess Alice has to include the hash of the newest block if she wants to get a reward+fees.
13  Bitcoin / Mining / Re: Confirmation time vs tx fee: Another reason to keep the blocksize where it is? on: March 11, 2013, 04:26:55 PM
This is wrong. It makes no sense to take the highest fees if you know you have no chance of getting them, since faster miners will always get there first.
I think you don't understand how mining works-- there is no such thing as a "faster" miner, just miners with more or less chance of creating the next block.


Please correct me, but doesn't it take longer to solve a given block if one has a slower computer? If so, wouldn't the transactions in the block just be older? Hence, confirmation times would scale inversely with tx fees.

wot?

Please explain if this doesn't make sense. Miner Bob is the fastest miner on earth and the blocksize limit has been reached. He collects as many txs sorted from highest to lowest and tries to solve his block. Miner Alice is twice as slow as miner bob. She collects txs with fees sorted from highest to lowest, but she tries not to include fees so high that Bob will be likely to have included them in his block. She begins mining. Bob finishes his block before Alice finishes hers. Bob's block has higher fees in it and they were confirmed faster than Alice's. Hence, those sending tx's with lower fees know that people like Alice are more likely to get them and can expect slightly longer wait times. Again this only happens if Bob has a reason not to include low fees - the blocksize limit forces him to choose only the highest fees. Does that make sense?
14  Bitcoin / Mining / Re: Confirmation time vs tx fee: Another reason to keep the blocksize where it is? on: March 11, 2013, 04:11:38 PM
This is wrong. It makes no sense to take the highest fees if you know you have no chance of getting them, since faster miners will always get there first.
I think you don't understand how mining works-- there is no such thing as a "faster" miner, just miners with more or less chance of creating the next block.


Please correct me, but doesn't it take longer to solve a given block if one has a slower computer? If so, wouldn't the transactions in the block just be older? Hence, confirmation times would scale inversely with tx fees.
15  Bitcoin / Mining / Re: Confirmation time vs tx fee: Another reason to keep the blocksize where it is? on: March 11, 2013, 04:02:30 PM
Thanks for the kind replies.

OP you logic doesn't make sense.  The slowest miner is going to take the highest fees.  If a miner solves the block they get the block reward (subsidy + all fees) if they don't then they don't.  There is no scenario where it makes sense to NOT take the highest fees and go for the lowest fees.  From the largest TH/s miners down to the single processor miners, if it is economical to mine it makes no sense to do anything other than take the highest fee tx first.

This is wrong. In a world where we've reached the blocksize limit, it makes no sense to take the highest fees if you know you have no chance of getting them - faster miners will always get there first. It makes more sense for a slower miner to find the maximum fee they can take while still maintaining the highest probability of success. Therefore, slower miners must compete for lower prices if they want to stay in business. This has nothing to do with "protecting" the business model of slower miners any more than raising the block limit protects the business model of faster miners. I'm simply stating that the blocksize gives us something we don't have: reliable confirmation times that scale according to the tx fee. IMO, the only reason this hasn't happened yet is that we haven't reached the blocksize limit. Again, please correct me if this is illogical. Thanks.
16  Bitcoin / Mining / Confirmation time vs tx fee: Another reason to keep the blocksize where it is? on: March 11, 2013, 03:03:25 AM
I posted this over at r/bitcoin, but I'd like to see more discussion on the topic here.

Right now, the cost of a transaction is arbitrary: you can pay the "recommended fee", a smaller fee, or no fee. Regardless, there's no reliable way of knowing when your transaction will be confirmed. In other words, the market has not yet been able to price confirmation times. I believe this is directly related to the blocksize issue, and that keeping the blocksize where it is should force the market to price transaction times. I would like to know if this reasoning makes sense:

The blocksize provides an artificial scarcity that will eventually force miners to prioritize based on transaction fees. However, slower miners know they can't compete with faster miners for the highest fees. Instead of simply shutting off their machines, a (rational) slower miner should instead optimize for a range of smaller fees that they have a reasonable chance of capturing (using their cheaper equipment). As a consequence, slower miners could stay in business, competing with each other in order to provide value for those who choose to pay less for longer wait times, based on the individual consumer or business' time preference. Competition at all tx price levels would result in a stable tx price as a function of tx time. Raising the limit will postpone the pricing of transaction times until the next limit is reached. Removing the limit entirely will prevent this state from being realized, and we will never know how long it should take to get a tx confirmed.

No other system of exchange has priced transaction times, so it's yet another feature bitcoin would have that others don't. What's more, we would get this feature for free, without having to do a hard fork. Please correct me if my reasoning is flawed or if I've missed some crucial aspect of the protocol that makes this impossible.

tl;dr I argue we should keep the blocksize where it is: the market will respond by pricing transaction times, which is a feature we could all use!
17  Other / Beginners & Help / Re: Cash deposit to BTC on: March 11, 2013, 02:26:24 AM
Localbitcoins is also good for trading cash for bitcoins locally
18  Other / Beginners & Help / Re: Best way to get bitcoins? on: March 11, 2013, 02:09:21 AM
If you're going to start mining, make sure you understand the cost of the electricity you'll be using and the equipment you'll be buying. You could easily end up losing more than you would if you had just bought bitcoins directly.
19  Other / Beginners & Help / Re: Introduce yourself :) on: March 11, 2013, 02:01:02 AM
Got into bitcoin a couple years ago. Decided to found a startup that accepts bitcoin. After more than a year of work, I think we finally have niche product that bitcoin users will love and will make life better for a lot of people. Very excited, to say the least.
20  Other / Beginners & Help / Re: Newbie restrictions on: March 11, 2013, 01:58:18 AM
Trying to graduate from newb  Roll Eyes
Pages: [1] 2 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!