Bitcoin Forum

I wanted to throw out a draft proposal titled Instant Partial Confirmation, and solicit comments.

https://en.bitcoin.it/wiki/BIP_Draft_-_Instant_Partial_Confirmation

This (draft) BIP proposes a scheme to enable parties to a transaction to receive a reliable confirmation of their transaction from miners in a deterministic predictable timeframe, and compensates miners financially for providing this service.

With the service described by this (draft) BIP, instead of waiting an average of 10 minutes for 1 confirmation, a transactor could potentially receive 0.51 or more confirmations within 10 seconds of issuing it (representing 51% of the mining power on the network), and have a much higher level of confidence that the transaction will be confirmed as compared to a zero-confirmation transaction.

VERY BRIEF SUMMARY:

It describes miners putting "calling cards" (IP:PORTs) in their coinbases.  Connection to the miners is done via UDP datagrams, not TCP.

Transactors interested in instant partial confirmations must pay an elevated market-based transaction fee in order to receive the service.  These transaction fees are paid the same way transaction fees are paid today - awarded to any miner who includes the transaction in a block.  They are not payments/outputs payable to any individual miner.

Assuming their fee is high enough, the sender and receiver of the funds is welcome to blast out UDP packets to all miners within the last 2016 blocks, asking them to confirm the transaction.  The miners may send back a confirmation that the transaction was not a doublespend.  That confirmation is considered a "partial confirmation".

The partial confirmations are informal but signed, typically by coinbase keys.  They are also returned via UDP.  Clients can figure out how much of the hashing power each partial confirmation represents - for example, if a partial confirmation can be determined to come from the same miner who mined 20% of the last 2016 blocks, the transaction essentially has 0.2 confirmations.

tl;dr: The core benefit is it provides a solution for those who want higher confidence in zero-confirmation transactions, as well as providing an opportunity to raise transaction fee revenue for the mining community as a whole.

Related: https://bitcointalk.org/index.php?topic=62137.0;all

tl;dr: instead of trying to connect to every miner everywhere, you simply send your transaction over the network with a generous fee.  Miners include a pubkey with each block, and if they consider your fee sufficient, they use that key to pre-confirm your transaction, and flood that signature.  Pro: simpler and faster; con: more p2p traffic.

Couldn't the attacker just wait 10 seconds to send the other transaction that double spends.  Is there a way for miners to revoke their confirmation?

By sending your transaction directly to the miners, you can typically have a response in under 1 second.  Time is of the essence, and UDP traffic is tiny, as fast as a ping, and well suited to being blasted to a thousand simultaneous peers, some of whom might not be listening or available.  There is no sense in burdening the P2P bandwidth (a limited resource) on a wide-open internet when the message can be communicated directly and quickly via UDP.  Peers sending direct UDP messages to other peers is still peer-to-peer!

EDIT: This would also rip to shreds Microsoft's silly whitepaper assertion that Bitcoin will "fail" when peers stop relaying traffic due to lack of incentive.  Blast your traffic to thousands of miners yourself, and never worry that "no one" will hear your transaction due to greedy relays wanting your fee for themselves.

I believe that bitcoind will not accept a conflicting transaction into its memory pool, so once the first reaches a miner, the double spend will not replace it.

Oh, duh.  Thanks guys.

Obviously you have to be careful with how much faith you put in the results.

Even if you got confirmation from 100% of the miners who mined the last 2016 blocks, you are still vulnerable to a Finney attack where the block has already been mined by someone else.

Also you are still vulnerable to corrupt mining pools who say one thing and do another!

Would be interesting to know SatoshiDice input on this as they are the more experienced by factors of 1000's than anyone else with the issue.

But as you say it increases the size of transaction that is safe to accept based on zeros confirms.

It's very interesting, though I have several questions:

Issue 1:

In your BIP you say: "CONFIRMED: The miner considers the transaction valid and commits to include it in the next block. "

How miners are forced to include such transaction? What happens if they don't ?

Issue 2:

What happens in this situation:

- A transaction has two receivers (outpoints) user1 and user2.
- Two transaction (a double-spend) are publishes t1 and t2 (both with very high fees)
- User1 asks the miners to sign the pre-confirmation or t1. All miners send confirmation of t1.
- User2 asks the miners to sign the pre-confirmation or t2. All miners send confirmation of t2, thus violating the commitment on t1.

Miners will always win, since they can choose t1 or t2, an always get a high fee, so they have no incentive to help either User1 or User2.

To avoid this situation, the protocol could me modified in this way:

- User B wants partial confirmations on transaction t1 (from A to B). The first output (B.output[0]) is the one that goes to himself.

- The user B creates a new transaction tn with a single input t1.outpoint[0] that pays a high fee and sends the change to a B back again (one input, two outputs).

- B sends this transaction to all miners directly by UDP. This transaction will ONLY be valid if t1 is published, since t1.outpoint[0] is only available in that scenario. Transaction tn cannot be send via the p2p network since it has an unconfirmed input.

Now miners do have an incentive to include t1. If they do so, they also receive the fees for transaction tn.

Was the explanation clear?

Issue 3:

In your BIP you say: "...The message shall contain the entire transaction to be partially confirmed, a return path (IP and UDP port) for the response, and proof that the requester is a party to the transaction. ".

But this way you could specify a IP/Port different than yours. It would be preferable to send the response to the same IP where the UDP packet has came.


Good work casascius and best regards,
 Sergio.

(emphasis mine)

Relaying nodes do not receive any fees for relaying.  And there are more than sufficient nodes on the network to prevent an attacker or miner from preventing a transaction from being relayed to others in 99% of the cases.

This appears to have scalability and security problems. From a scalability perspective unless mining is highly centralized you must communicate with many parties or process many signatures.  From a security perspective a miner signing saying they'll mine a transaction doesn't actually prove that they're even trying to do so or force them to continue trying (e.g. if a higher fee comes along).

Instead, I point out that P2Pool's sharechain approach already solves this.  Right now the included txn in p2pool shares can change freely, but in order to enable 10 second soft confirmations it would be perfectly possible for p2pool (or a similar system) to commit to some transactions (e.g. ones with sufficient fees) which can't be removed without making their shares get ignored.

This has the property that the proof of confirmation is actually also proof of really trying... and it doesn't have the same scale problem in the case of decenteralized miners where there are many possible ones. It could be done by existing pools for the pure confirmation purpose but there would be no incentive to participate other than providing faster confirmations and then defection is easy. When the shares are used for payout, however, there is a good incentive not to defect.

Although with finny attacks being cheap thanks to gpumax and getting cheaper, I don't know that any of this matters: One confirmation isn't enough for most things where zero isn't enough.

They're not, the same way nothing forces them to include transactions in blocks at all yet most do it anyway.  Practically, most miners aren't going to go out of their way to disrupt the integrity of the network.  By and large, there is no benefit to doing so.


Per the proposal, step 4 won't happen at the hands of the honest majority of miners.  They will not confirm T2 if they have already seen T1.  Most of them will send a REJECT message alerting the client to a likely double spend.

If transactions are sent at the same time, some will confirm t1 and others will confirm t2.  However, both will never simultaneously have a majority, and the flood of REJECT messages (which ought to be counted as "negative confirmations") will definitely make the transaction stand out.


Sure, of course - the same way I could order a magazine subscription, but put my neighbor's address as the delivery address, and then I will never get what I paid for.  But I have no rational incentive to do so.

Whether IP/Port should be included is up for discussion.  It may very well be that the most sensible solution is to reply to the source address and port contained in the datagram, so that the reply won't have any trouble traversing NAT etc.

+1

+1 to Sergio's points, too.  Casascius: I think you need to think more like an attacker; if they can cheaply mount an attack, then they will.

In each case, you must communicate with up to 2016 parties via a datagram, independent of the network size or transaction volume.  Datagrams are small and cheap.  You could blow out 2016 2kb datagrams at the same resource cost as blowing out a 4-megabyte jpeg to facebook.

Whenever there are far more than 2016 miners, you're still likely to get a statistically meaningful representative sample of the active miners out there.  More resolution offers little practical benefit (n/2016 is already accurate to 3 decimal places, what would somebody do with more?)

Indeed, one might need to process up to 2016 signatures to have full confidence in the results.  But if you're a retail POS terminal with a single user and an idle CPU 99% of the time, this shouldn't be a big problem.


Just so I understand, how does p2pool collectively commit to anything?  Include the commitment in a sharechain block?

What about traditional centralized mining pools?  I agree that having proof of trying is a desirable benefit.


Unrelated, a calling card scheme might allow the miners to detect Finney attacks and coordinate the rejection of the block containing it.

As an example, upon receiving a block that invalidates a confirmation, an IPC-participating miner could broadcast a message to the other (up to) 2016 miners saying "Hey! I don't like block X because it forces me to fail on a commitment, and I propose attacking it."  If the majority of miners send that message, they could follow it up with another message: "It looks to me like a majority of the mining power doesn't like block X, so I am attacking/ignoring it."

What happens if there are 8064 miners all with equal hashing power?  Even a partial confirmation from all 2016 of the last blocks' miners would only account for 25% of the network.

This might be a concern if Bitcoin were mined chiefly by solo miners.  The higher the difficulty gets, the less likely that will ever be the case.  Most mining is done by pools (traditional and P2Pool).

Let's consider traditional pools for a moment.  As long as they exist and have the majority of the hashing power, they will always be represented in the last 2016 blocks.

Now let's consider P2Pool.  Admittedly, I did not consider much about how P2Pool would interact until gmaxwell said something.  But P2Pool could collectively commit to a transaction simply by including that commitment in one of its sharechain blocks, as he seemed to suggest.  All other P2Pool workers would be required to honor the commitment if they honor the sharechain block.  If it worked that way, then all that needs to happen for all of P2Pool to collectively commit, would be for any P2Pool miner to solve a sharechain block after having heard about the transaction, which would result in it being shared across P2Pool's p2p entire network.

What if bitcoin grows to the point there are 8064 pools?  That's only 8 million miners with 1000 miners per pool.  Doesn't sound too unreasonable given that is only 0.11% of the worlds population.  Also the same problem exists with 4032 since you're only representing half.  In addition, many pools are smaller than 1000 users.

Sure, that's a distant possibility, but we shouldn't add scalability problems.  I suppose we could bump up the number of block later (and only the pools would need to upgrade), but we may run into a problem with transient miners.  It may not be possible to get confirmations from half if say mining is only done in the winter by most people due to the heat production involved.

I am not considering this as a concern, because I believe the number of traditional pools will tend more to zero, not infinity, as P2Pool evolves to satisfy the needs that currently drive people to traditional pools (a lot of which I believe is just that - "tradition" - they set themselves up to use some other pool at some point in the past and it works so why mess with it.  Or they consider setting up to mine on a traditional pool to be easier than setting up P2Pool - something that can change)

That's arguable since p2pool mining requires a blockchain and regular pool mining can be done on a computer with just a livecd.

Also, I consider it a concern because there are no rules in the system preventing it.  Sorry, but your guess as to what will happen just doesn't satisfy me.

Two problems with your proposal to punish rough miners:

1. You can ask miners not to follow certain longer block branch, but the have the opposite incentive.

2. You can't tell nodes or miners to invalidate transactions even if you have a proof of dishonest behavior, because that will give you a tool to invalidate blocks in the past. And that would give you a tool to revert millions of other (unrelated) transactions!

Now you have created a new type of double-spend attack by a rough miner that includes a (previously rejected) transaction on purpose.

That's how it is today, but that is almost certainly not how it will be the day 8064 discrete mining pools ever come into existence.


There are no rules preventing me from repetitiously slamming my own head on the sidewalk, but it can be safely said it is unlikely to happen because there is no incentive to do such a thing.  As difficulty tends to infinity, the likelihood of someone solving a block by themselves in their own lifetime approaches zero, and so it's a pretty safe bet it's not going to be very popular as time goes on.

Sorry, I promised to comment on your proposal in my thread: Collaboration between pools could make accepting 0-confirmation transaction safe (https://bitcointalk.org/index.php?topic=88442.msg985021#msg985021) , but then Meni Rosenfeld came up with his proposal: Trustless, instant, off-the-chain Bitcoin payments (https://bitcointalk.org/index.php?topic=91732.0), which seemed much better all around, so I stopped thinking about your post too.


When a miner commits to include a transaction into a block, essentially it means that he promises to mine on top of a shorter blockchain if necessary. The condition could be to mine on top of a blockchain that is no shorter then by one block to thwart Finney attack, two blocks to be immune to extended Finney attack with two premined blocks or even six to make the attack unrealistic. But a miner has to know that he is not alone in this, and that the shorter blockchain will eventually become the longest, otherwise he makes himself open to the attack where he would lose mining time.

In my proposal it was solved with multisig transaction, but that would bring more centralization to Bitcoin. In yours there has to be additional protocol for that.

This is where you briefly touched it.


I just thought about possibility of using Assurance contracts (https://en.bitcoin.it/wiki/Contracts#Example_3:_Assurance_contracts)


Create such transaction with high miner's fee, ask specific miners to chipin one satoshi to indicate their commitment, and then broadcast the transaction to let everyone know that there is indeed the majority of the network behind that transaction.

Which miners would have such an incentive?

They would only follow it if the majority of miners independently asserted that they don't want to follow it if a majority of other miners say the same thing.  And there is always an incentive, or at least no disincentive, in following the majority of miners.


It is not a message that says "Please invalidate arbitrary block X".  The only kind of block that can be invalidated is a brand new block containing a conflicting transaction never-before-heard by the majority of miners, only after the majority of miners has actively committed to some other transaction they in fact have already heard about, and only after the majority of miners have reconciled with one another to agree that that's what happened.  However, my suggestion is rather off-the-cuff and could be infeasible - please provide an example of how you figure it could be used in an attack.

How are you going to p2pool mine without a blockchain?  You would need supernodes or some other form of centralization.


But 4032 pools that solve one block a month each doesn't sound entirely unreasonable to me, but I'll concede it is not a pressing issue and one that could be solve fairly easily as long as transient miners don't become an issue.

In general, could Assurance contracts (https://en.bitcoin.it/wiki/Contracts#Example_3:_Assurance_contracts) serve as a voting system?

Who knows?  If I had an answer (I don't), it would probably be obsolete when the time came.  There are already discussions on how to use a meta-tree to allow a node to mine without the whole block chain.  A live CD (assuming CD's are not as dead as 8-tracks by then) could potentially pull all of that information off the network and into a ram drive and start mining with it.  USB flash drives can already hold the block chain and would certainly be able to handle a meta-tree solution.  By the time there's a possibility of 8000+ pools, a lot of evolution will have taken place and my guess is both the questions and the answers to them will probably have changed a lot.

Imagine a mining pool. You have shares— they're really all failed blocks, they still have hashes that connect down to the transactions so you can show that the shares were an attempt to mine a particular transaction.

Now, add an extra hash to the coinbase, like merged mining, except its the hash of a prior share (of at least some difficulty). Bam. Now you have a share chain.   You can use this for a byzantine consensus of who's putting how much hash power into the pool. This is what p2pool does— nodes share shares with the difficulty adjusted so that on average there is one per ten seconds. They use this to decide who gets paid and they impose some validity rules on the candidate blocks before they'll be considered valid shares, e.g. that they pay the right people relative to the share chain consensus.

There is no reason that the validity rules can't include something like "your block must include txn XXX" where XXX is some txn that previously made it into the share chain with enough fees and without yet being conflicted in the bitcoin chain.  Then the sharechain itself is proof of past, current, and future effort being put into mining a transaction, as leaving out that txn would prevent you from getting paid by the pool, and you can easily extract this proof and show others. No signature validations either, just a bunch of small headers and cheap hash operations.

A centralized pool could generate such a sharechain itself internally— although if the pool was the only participant in a particular share chain there wouldn't be an incentive to not drop the txn out prematurely, so it's only evidence of past effort.  To improve on that centralized pools could participate in sharechains among themselves (probably slower, e.g. 1 minute, for latency reasons), meta-pooling their payouts and providing more trustworthy evidence of future effort (and lowering their variance too, I suppose).

Sorry if this is being slightly off-topic. If I am right here, the following approach would help greatly to reduce chances of double-spend.

The initial transactions are relayed around the network in few seconds. It is the blocks which take about 10 minutes. I understand that nodes immediately throw away any transactions which they identify as double-spend attempts. But instead they should flag them "double-spend attempt!" and relay them. This way the network will know about the double-spend in few seconds. Then after few blocks everyone could forget them.
It is still possible that the news will not reach every node immediately, but still better than waiting for next block.
It still needs to be decided how to prevent any spamming of the network this way but this seems doable.

Not a new idea and the flooding problem has a solution too, e.g. http://sourceforge.net/mailarchive/message.php?msg_id=27901281

Ideas are cheap. Got code?  :)

Though this provides no protection against finny attacks.

I believe it has been touched upon somewhat already, but what about if - instead of having to trust miners to include a transaction into a block - the client is sent blocks that have difficulty of 1/600th of the Bitcoin block chain's difficulty? This would produce, on average, one block (with 1/600th the difficulty of the block chain) every one second (provided all the miners participate). The receiver can actually check that the miner is working on his transaction if the miner creates a hash tree of all the transactions in the block he's mining, and then sends the client the necessary leaf hashes to verify that. The miner would only have to send 2*log2(num_tx)-1 hashes from the hash tree to the client in order for the client to verify that his transaction is being mined on in a block. This is an implicit guarantee that the client's transaction is not a double spend, as the miner's block wouldn't get accepted if it contained a double spend.

So if we let the data blocks in this example be transactions, and the client's transaction be "Data block 000", the miner would only have to send "Hash 0-0-1", "Hash 0-0", "Hash 0-1", "Hash 0" and "Hash 1" in order for the client to verify that his transaction is being worked on (since "Top hash" is included in the block header and the client knows the hash of his own transaction ("Hash 0-0-0").

http://upload.wikimedia.org/wikipedia/en/3/3c/Hash_tree_02.png

Does anyone have any information on how much data a P2P network specializing in forwarding these types of messages would be able to handle? Only the block header would need to be sent out every 1 second (assuming all miners participate). When new transactions are sent into the network, that some client wishes to secure against a double spend, a hash of this transaction should be spread around in the network, so that clients can confirm that their transaction is included in the block. Perhaps the system should include some way for clients to advertise which leaf hashes they need in order to confirm that their own transaction is included in the block. Ie., if I'm concerned about the two transactions "Data block 003" and "Data block 006" being double spent, I wouldn't need to be sent "0-0-0", "0-0-1", "1-0-0" and "1-0-1" as they are not needed for me to verify that my transactions fit into the hash tree.

It's not a guarantee because the inclusion isn't fixed like it its when a transaction is actually mined, a miner could stop at any point.  Perhaps you could imagine some kind of system for discouraging that, but it would need a consensus mechanism... and would have to force all miners to mine the same txns (or at least no conflicts)

P2Pool now does this— miners exposing what they're working on in p2pool shares with no enforcement— however.

I see your point. If I'm standing at the store and my payment device sends a transaction to a miner, waits for 10 1-second blocks - which I show to the guy at the store receiving the payment - and then leave, I can just send out a new transaction when I'm out of the store that spends the same output but has a higher fee, and the miner will want to include this instead.

Would the idea then be to make a share chain that is invalid if it contains two transactions spending the same output? So that in order for the miner to include a double spend, he would have to discard the shares that include the original transaction? That could be a problem with 1-second blocks though...

Interesting. That solves the political problem with the idea that individual P2Pool miners would be forced into including certain transactions. Instead of being forced to include certain transactions, they just wouldn't be able to include one that conflicts with past blocks on the sharechain.

Are p2pool miners forced to include certain transactions as it is now? And if so, how come?

Not as far as I know. My post was in reference to the other idea in this thread where they would be forced to include transactions.

It doesn't really.

The expectation of solo mining is the same as pooled mining. If you'd like to split off and try to mine a conflicting transaction you can and you won't lose any coin on average— you'll even gain if the conflict has higher fees.

Well, yeah. None of this solves the underlying problem that zero-confirmation transactions shouldn't be used for anything valuable and/or irrevocable because of the Finney attack. The only problem this helps solve is the enforcement of ethics if you want to use a specific pool.

I also think that pools will become less prominent in future. If the ASIC transition really does happen then non-serious miners (the type who use live cds) will get kicked out and the only miners left will be those who treat it as an actual business. If you've invested heavily into specialized equipment then mining solo against your own bitcoind isn't such a big deal. If you represent 0.1% of the networks hash power then you'd get a block every 10 days or so - hardly eye-bleeding variance risk given the time and effort it took to set up your mining farm.

Also, as mining gets more and more competitive (today it isn't), fees levied by pool operators would become a bigger burden. In theory mining should be a close to marginal business given the relatively low barriers to entry. P2Pool does not charge fees, and it may well survive a lot longer, but again - there's a certain simplicity to just mining solo that may be appealing for large-ish miners, and I think eventually all miners will be somewhat large. I doubt we actually need more than 1000 distinct miners as long as they're distributed around the globe.

Currently P2pool is simpler to run than solo mining, though this is an artifact of ~no larger miners except Luke bothering to submit patches to  full node software for mining scalability.

Your opposition to long term real decentralization in Bitcoin is well established at this point.  I think as a community we need to start speaking up emphatically against these positions. I hope you will not take it personally when I do, because I have great respect for you no matter how much I disagree with you on this subject.

If Bitcoin were only to have 1000 distinct non-trivial mining entities then I believe Bitcoin would be worse than pointless.  With so few entities having a veto over the validity of transactions it would be substantially more centralized than any of the largely existing widely used currencies— as there are are far more bank like entities than that for any major currency, and unlike bitcoin other currencies have cash transactions which are more reversal resistant. The cost and complexity of bitcoin is not justified if it doesn't provide a solid advantage over highly trust centric (semi-)centralized systems like the USD.

From a technical perspective: If you were only to have 1000 entities the Bitcoin consensus algorithm is fundamentally wrong:  The stochastic POW chain consensus provides slow and unpredictable eventual consensus. A consensus of 1000 entities can be accomplished far more inexpensively, rapidly, and reliably by identify them and using a majority vote with digital signatures. There are places for systems with this kind of security property, and they are the sorts of things OpenTransactions seek to create (potentially ones with much better scalability than the broadcast based Bitcoin system).

It would certainly be nice if there existed a global, thoroughly distributed, cheaply validated, medium of exchange which could enable trade between distinct scalable and fast confirming federated systems... but it won't be so if Bitcoin tries to become everything to everyone with forcing users through services providers and limiting miners to those who can handle gigabits of bandwidth for multigigabyte blocks.

Fast provably strong confirmations are not something the Bitcoin consensus algorithm can do without sacrificing the things that make Bitcoin worth having and we shouldn't be afraid to admit this.

My motivation isn't to change the Bitcoin algorithm. I started out thinking on ways to extend it, with another - optional - layer on top. Proof-of-work might not be the right way forward for fast double spend prevention though.

I'm thinking that it might be possible to leverage the fact that Bitcoin takes care of the long term double spend prevention. Ie., after an hour or so, the block chain prevents double spends. Perhaps there's some clever protocol that can utilize this feature of Bitcoin, so that it can concentrate on only preventing (with a certain probability) double spends for an hour, or so.

I'm also thinking that it doesn't need to prevent double spends with absolute certainty (not even the Bitcoin protocol can do this). We only need to know the probability of a certain transaction being double spent, and using the value of this transaction, we can charge a fee that makes it economically disadvantageous to attempt a double spend.

But this is just brainstorming for me.

I really do think that the ideas of Bitcoin replacing VISA are misguided. We should be comparing the Bitcoin network to SWIFT (with its 1-day+ settlement time) and not VISA, with its ~10-second settlement time (notwithstanding chargebacks). I don't think 10,000 transactions per second in the Bitcoin network will ever happen, when the settlement time is ~1 hour.

I'm hardly opposed to decentralization, otherwise I'd just recommend everyone use blockchain.info as their mobile wallet instead of putting so much effort into an SPV client, right?

I think the disagreement here comes from two sources. One, prediction of the future is not casting an opinion on it. Right now there are only, what, 12 or 15 miners with most of the power? Hardly what Satoshi envisioned. Yet somehow Bitcoin functions and people are using it. When I say we may not need more than 1000 miners, I'm not saying that would be the best possible configuration, just that in practice we may not need more - Bitcoin would probably work OK.

Two, wildly differing perspectives on the cost of hardware. The cost of the equipment needed to run a node that keeps up with VISA (or beat it) has come down a lot with better calculations, optimizations to the software, etc. If in future you need a 24 core machine with 12 drives attached to it to run a full node, I don't see that as leading to centralization and therefore I don't see it as needing to be fixed, because in a world where Bitcoin was so widely used there'd be plenty of people and organizations willing to run such nodes and the cost of the hardware would have fallen a lot anyway.

BTW, one of the prime advantages of proof of work, as I see it, is there's no need for co-ordination. It may well be that 1000 nodes can achieve consensus much faster just by swapping signatures amongst themselves. However if you want to become the 1001st node (or stop being the first node) that's much harder in such a design. With PoW you just start calculating, you can join or leave the network at any time. That "robust simplicity" as Satoshi put it is a great thing.


I don't think you can say "notwithstanding chargebacks". If you don't care about chargebacks/double spends then Bitcoin settles in a few seconds, about the same speed as card payments today. And if you throw trusted hardware into the mix (like smart cards, or computers with TPM chips), you can trust you have the money instantly, as you have some confidence that the hardware holding the private keys won't allow the owner to make double spends.

Let's be clear, Bitcoin is a set of techniques to reduce the probability of people rolling back their spends and it does a very fine job of that. We can layer more techniques on top to try and push the envelope around value/speed, but those techniques don't have to be extensions of the core system. For instance you can do what the credit card system does and have deep risk analysis of customers. You can have double spend insurance. You can have double spend alerts. You can leverage secure hardware, like trusted computing does. You can experiment with networks of payment channels routers, like in Menis proposal.

Probably we'll end up with some combination of these ideas, which will mean that plenty of Bitcoin merchants accept payments instantly and in practice users don't need to wait for confirmation.

It'd be neat if somebody could find a way to converge on a global consensus much faster. The physics of message propagation throughout a large broadcast network suggest it won't be feasible for a while though.

I think the technical issues with this proposal are minor hiccups that could easily be worked around, I don't see any point. The Finney attack is the biggest threat to accepting 0-confirmation transactions and this does nothing to reduce that threat. So reducing the threat of a conflicting transaction by miners seems kind of pointless. It's like adding another chain across the window when the door is held shut with masking tape. If we had a fix for the Finney attack, then this might be worth doing as it would address the biggest problem with accepting 0-confirmation transactions, thus making it significantly safer to do so.

I think my point about not considering chargebacks as double spends is valid. I can't go out and spend the money on my VISA card twice. Chargebacks are an additional layer that VISA chooses to offer customers, because there's a demand for it. VISA doesn't have any problems with double spends. The fact that they offer chargebacks is a completely separate service from the actual transaction verification. We shouldn't conflate VISA-style chargebacks and a double spend vulnerability.

That being said I think the Bitcoin network works wonderfully considering its decentralized nature. I just think it would add a lot of value to have a decentralized 10-second payment system. Not that I think it's necessarily possible, but I like to play with the idea. Which is why I'm posting in this thread - to get a better understanding of what exactly is necessary for such a system to work.

I think we sometimes get stuck at designing a system that prevents unwanted activity, when it's only necessary to make unwanted activity unprofitable. Bitcoin is a great example of this. While all the hardcore cryptographers were trying to figure out a bullet-proof protocol for preventing double spends, Satoshi combined already available knowledge into a system that actually works.

Reminds me of this great Google Talk (http://www.youtube.com/watch?v=oCZMoY3q2uM) by Van Jacobson, where he describes how, back in the late 60's/early 70's, all researchers were spending their time trying to figure out how to quickly set up a physical connection between two points, for the use of electronic communication. While they were busy doing this, two guys developed the idea of a packet switched network. These ideas were ridiculed for not being "true to the cause" and a "hack".
The fact remains that a packet switched network is the basis of the Internet today. Researchers never figured out how to quickly set up a physical connection between two arbitrary points. I wouldn't be surprised if a "pure" cryptographic approach to solving the double spend problem suffers the same fate.

That's exactly what chargebacks let you do. If you obtain some goods then it is charged back, you get the money back but don't have to return the goods.

In theory this is not a problem because if you do it repeatedly you get kicked out of the system. In practice it's a huge problem because card fraud/theft is so common, so carders can obtain whatever they want and the people whose card details were stolen don't lose any money, effectively their money gets "double spent" (just the first spend was by somebody else).

You're right that VISA doesn't have a problem with double spends. The merchants who use VISA do though, which is why they invest so heavily into risk analysis and usually bump up the prices to cover card losses.

That's the nature of credit. Credit cards are credit. With credit, there's always a risk that the debtor won't pay the debt. It's not really a double spend because if you chargeback, you haven't spent in the first place. A purchase with a credit card is functionally more like a promise to pay than an actual payment.

If you chargeback a merchant wrongly, the merchant will sue you. They may decide to eat the cost if they thing you're not worth going after. It is important to understand that a chargeback doesn't in any way change how much money you owe and to whom. If the purchase wasn't legitimate, you never owed anyone for it, before or after the chargeback. If the purchase was legitimate, you owed for the transaction both before and after the chargeback. The credit card company is just an intermediary for your payment to the merchant. When a credit card company accepts a chargeback, they're simply removing themselves as an intermediary in the transaction between the cardholder and the merchant.

That's right. The 2.5% or so that merchants pay is only part of the cost of credit cards. The fraud they have to eat is part of that risk too. One of the big advantages of systems like Bitcoin over credit cards is that you don't have to expose the credentials needed to authorize additional spending just to do some spending now. Eventually, that could mean that crypto-currencies become significantly cheaper than credit cards, even more than just avoiding the transaction costs would suggest. (Even if features like chargebacks are added to them!)

Escrow, essentially, serves the same purpose as chargeback, so it's already implemented.

Mike's premise: Mining is going to get centralized anyways. There will be small numbers of miners. The economics and technology of mining all point that way.


Gmaxwell's premise: With small numbers of voters, majority voting via signatures is much cheaper, faster, and more secure ("reliable") than mining.

Combining these two premises yields a conclusion. -> Ditch Mining, Adopt Majority Voting via Signatures.

Now, instead of coming to a conclusion, they turn to a faith-based approach.

Axiom: Majority voting via Signatures is wrong.

Jointly, Gmaxwell's premise and Mike's premise imply that Majority voting via Signatures is right. This contradicts the axiom that majority voting is wrong. Therefore, either Mike's premise or Gmaxewll's premise is incorrect.


Not really. For example: https://bitcointalk.org/index.php?topic=127952.msg1360115#msg1360115 (https://bitcointalk.org/index.php?topic=127952.msg1360115#msg1360115)

You failed to understand the assumption in his hypothetical.  I've bolded it for you.

We are not looking for an n-entity system, no matter the value of n.  Even when Satoshi started out, and n was 1, we did not have and did not want a n-entity system.

What we want, and what we have, is a system where anyone can join.  It may not make economical sense for them to do so, so the system may, from time to time, have a small n value, but anyone can still join.

You've been straining to avoid understanding this simple point for about as long as you've been posting here.  How long can you keep it up?

http://en.wikipedia.org/wiki/Premise
Maybe that will help you expand your vocabulary? Or perhaps you are only capable of analyzing one premise at a time, as you did in the previous post.

Yes, your motivation is faith-based: "We are not looking for an n-entity system, no matter the value of n." I pointed that out in the previous post.

Apparently, quite a long time. Confronting faith with satire, logic, and empiricism is something I enjoy. I understand that it is usually ineffective.

Thanks for reminding me why I have you on ignore.  Not really sure why I clicked show on that post.  Probably curiosity.

Apparently, in your mind, it is "faith" when someone wants something other than what you want.  Bitcoin mining is decentralized in the sense that you don't need permission from anyone to become a miner yourself.  It may not make sense for you to do so, but no one can stop you.  Even if we end up in a world where there are only 10 miners, that system is still less centralized, in principle, than a system with 1000 miners in a cabal, or a million.

No one gives a shit what your "satire, logic and empiricism" confronts about something that we don't want.

I had assumed you were designing a product to help people make payments. Thus, the argument should be about how one can do this most effectively (low fees, secure, etc.)

As you say, you are pursuing personal objectives instead. Sorry for misunderstanding.

Bitcoin is an attempt to more closely approach the platonic ideal of money.

Part of that is payment processing, but there are other parts, such as store-of-value and unit-of-account.  If you only see one part in isolation, you might think that it is a "product to help people make payments" and start thinking that you need to wring every last bit of efficiency out of that one part.

I realize that this discussion ended in disaster, but the Pay-To-Instant-Confirmation idea is something I'm pretty interested in, and I just wanted to necro the topic to see if anyone has any new ideas.

The concept is that people pay an extra fee, and their funds arrive instantly in a way that they can trust that there will eventually be 6 confirmations. This was ostensibly done with ZipConf but all of those people vanished.

The partial confirmations concept seems useful to me.

The biggest issue is how to compensate miners for participating. Although I'm not sure this is absolutely necessary if we can make the solution sufficiently light weight (ie. light on bandwidth, CPU power and RAM).