Hmm, I'm sure you're right.  A $30 usb dongle attached to my Internet gateway that might bring me new business for less than credit cards and offers zero threat to my existing transaction infrastructure, or $300+ to install a whole new transaction payment system wired right into my POS system.  Those are totally comparable.

EDIT: Beyond that, nothing says that the device that provides such bitcoincards access to the bitcoin network has to be owned by the shop owner.  A couple owned by the mall property owner, or a random guy walking down the block over with one on his phone, or the bitcoin geek with his own in his apartment two floors up, and it all happens.

I have a pretty good idea, and a cell phone is unneccesary.

Then this proposal is already a fail.  Because what do you offer then?  Decentralization?  You might as well say 'the cloud' for all the relevance that would have to the end user.


Again, not materially different than a lightweight client or any normal full client willing to provide a pruned block upon request.


Not any data so consistant, which is why bitcoin requires the format that it presently does.  The blockchain structure is self-re-enfircing from amny directions; not just from a single merkle tree branch up to the block header.  It is possible, although unlikley, to create a transaction that falsely gives you an arbitrary amount of bitcoins from non-existant inputs and find a merkle tree branch that it can 'fit' in, but that would never last a millisecond of verfications from a full client.


But requires constant Internet, so offers zero advantage over the (full future) live network or an overlay network such as Stratum.  In fact, Startum does eactly what you seem to want to do both decentralized and without an alt-chain.

Again, a lightweight client can become up to a full client at will, as well as participate in Stratum where it might need to.  There is noting that prevents this kind of actions.



Then we're not talking about the same thing.  I'll make a graphic to depict this concept more clearly.  Until then, this conversation can't continue, because you will otherwise never believe that what I am proposing is possible.  I didn't believe it was possible, either... which is why I'm so excited about this idea because it actually does this
[/quote]

Okay.

I didn't say anything about bluetooth.

I'll buy them.

Both functions are provided for in the same way, a 'sensor' mesh network that permits such devices to talk to each other, as well as an access point wireless dongle that permits all of these type devices to talk to the Internet at large.

While this is true, it's far from a complete picture of the intergrated security model that full nodes have access to.  In order for a lightweight client to accept a payment transaction, it must either 1) have Internet and access to a supporting server or 2) accept the evidence that the sender's client provides.  Although a lightweight client sending to another should have no problem sending a copy of the input transactions, which the lightweight client can then verify that it fits into it's own claimed spot on the merkle tree connecting to it's own copy of the block header, this is still not quite the same as what options of verfications that a full client has.



I don't see that, sorry.


Of course, but this is holds no notable advantage over just a lightweight client once the running network can fully support them.  I can't really see what the use case is beyond what lightweight clients & pruning can't provide.




Of course a lightweight client can download the merkle tree and verifty that.  It jsut needs to be able to identify conditions that would prompt that action based upon some local risk model.  There is nothing that prevents a lightweight client from collecting the block headers, and downloading up to and including an entire block if a risky inbound transaction is received.




The block headers do contain accurate snampshot hashes.  That's why the merkle tree exists and why the merkle tree root(s) (current block & previous block) is in the block headers.

Yet, 1) those goals are the same as the pruning & lightweight client features of the protocol, not yet ready and 2) I don't agree that those goals can be met with a dependent & parallel chain any better (and probably less well) than #1.  You're still talking about a potentially huge block/file that would have to be downloaded every ten minutes.  What gain is there in that?  Might as well stick with the main network or an overlay such as Stratum.

And it's quite literally impossible for lightweigt clients to have the 'same confidence as" a full node.  The best that a lightweight client can have is some confidence.

It certainly doesn't hurt to talk about it, but I don't agree that such an idea has merit when compared to other methods od achieving similar goals already discussed.  And if I can't see it, I'f wager that there are many more who are going to be sceptical of it's value as well.  Without a minimum critical mass, nothing is going to matter.

Perhaps, but only if the benefit to the network is demonstratable as compared to alternatives.  While a p2p solution might be possible, it's not always necessary.  And if it's not necessary, it's not likely resource/economicly justifiable.  Bitcoin is p2p for sound reasons, but what reasons carry over to what amounts to a tracking service?  If the server that a particular client chooses should go down or be DDOS'ed, the result from the perspective of the user is the same as if he had left his service area; a temporary inconveince.  And in the case of header-only/lightweight clients, not necessarily even a dehibilitating one.  I'll admit, this idea has merit; but it seems to lack encentive.  I can admit I might be overlooking something here, but what gain does a miner have for participating and sharing his findings?  Both are important, because if his gains are personal, he then has limited incentive to share the results.

A co-dependent blockchain with the same period as bitcoin itself seems like it's just adding noise.
However, a daily digest of (postive) balances might be useful in a number of ways; with (perhaps) an hourly update produced of recent (but 6 confirms deep) changes to that digest.  I can see such a bitstream being used as a secondary verification of authenticity for major retail chains that didn't want to track the blockchain at every location, but wanted to also protect against some form of local hack/fraud/yet-unknown-attack-vector.  I could also see small, independent vendors on the edge of the network (read not enough bandwidth to commit) to maintain a realitively trustworthy local database of address balances so that he could accept bitcoin transactions from walk-in customers without getting hosed by every script-kiddie in his neighborhood.

It's quite impossible for bitcoin to exceed, or likely even approach, a condition that would result in transaction fees exceeding those of credit card companys; for no other reason than bitcoin users would switch back and forth as it suits them, and the more it costs the fewer people it suits.

That said, higher numbers of transactions per block also spreads the burdens.  The more (paying) transactions that a block includes, the more miners are going to stay after the block reward decreases.  No miners are required to include free transactions, so if there are more paying transactions in the queue than could fit within a single block, free transactions are simply going to have to wait till the rush passes.  That's fine for donations, or transactions between trusting parties, but higher transaction values & those with limited mutual trust are simply going to have to pay the market transaction costs to get things done faster.  If it's cheaper in transaction costs to buy your new car on credit, people will do it.  If it's cheaper to pay the bitcoin transaction fee and wait an hour, people will do that.  It's futile to try to guess how such contrived scenarios would work out, because the market would never let things get that far.

Although this is an interesting idea, I don't think that it's viable.  How do you encentivise miners to secure this alt-chain?  However, a running balance table server isn't a bad idea as a pay-for service for light clients to use as a means to check their own addresses to make sure that they havn't missed something.  For example, one (or serveral) balance servers could exist that individual lightweight clients could contact out-of-bitcoin-band as a quick check upon startup, or a secondary check.  If the balance returned does not match, the lightweight client may have to try again, but if the balance returned matches what it thinks that it should have upon startup, the client can happily assume that it has all the relevant transactions to continue.

The service could be paid for in an anonymous, monthly fee.  Once every 30 days or so, the client tries to send the chosen balance server a small tip, and the server collects the addresses presented in that transaction (since lightweight clients tend to use fewer new addresses, or a more sophisticated lightweight client for the desktop could simply create a special transaction that uses as many input address as may be important, or simply uses the monthy transaction to consolidate addresses into a new operating address producing the server's monthly fee in the process).  When the client is restarted in the middle of the month according to the datetime available to the client, it first checks to see what it thinks that it's balance is, and then sends off the appropriate requests to the subscribed balance server.  If the server responds with the matching balance, the client happliy can quick boot and be ready for action (like bitcoinspinner).  If the balance returned is differnet, the client then should tell the user that it needs to update itself before spending, and proceed to do so in the background.  If the server feels it's not been properly paid, it returns an error code; or of the address is unknown in the blockchain; which would likely be the same as a zero balance to a running balance server.  Lightweight clients (that hold block headers) could still manage local transactions sans live Internet access, but with a warning to the user that Internet was not present and this could present a risk.  This setup would allow android clients to get into a working condition as fast as BitcoinSpinner most of the time, while also permitting delayed transactions/offline transactions to occur, which BitcoinSpinner & BitcoinJ most certainly cannot do.

Nominally, yes.  Practically, no.

It might yet.  It's still part of the protocol, feel free to dive in and code it into a client fork; and we shall see where that takes us.

Print me a Makerbot Cupcake and I'd be interested.

That won't work.  The algo is smarter than that.

You're the party treasurer, I take it?

Couple hundred a month.

You are easily amazed.


I guess bitcoin doesn't quite 'feel' right to you, so you 'sense' that you can come up with something better, but simply don't know how.

Concerning that "don't know how" part, have you ever stopped to consider the possibility that what you are considering actually isn't possible, even if you can imagine it is?


Legitimate, perhaps.  But you've been harping about what you vaguely perceive as flaws in bitcoin, but can't articulate those concerns, including the one that started this thread.  Yet you are just as vague about solutions.  Don't tell me that an airship is better travel than a cruise ship, when you've never been on an airship and only walked on a cruise ship while docked.  Either give me details and credible reasons (i.e. ones that I can't shoot down in the first round, at least) or stop wasting my time.

How do you propose to enforce your vision?


Network effects be damned, eh?
And implementation details are what I'm trying to get from you.  

I sense that you didn't understand that question either, but pretty good dodge there.

It's the price of electricity and the weather, for the little end user/miner who needs a little spot heat in a cold climate.