A bit longer for me.

I don't know why not.  Thus far the headers total about 16megs.


It can, it's just not a requirement.  It's unlikely that most gateways are going to be nodes.  More likley a couple hundred gateways port forwarding or ssh tunneling to one node.


No, you cannot.  The followuup transactions are not 'valid' for a block until the transaction prior to it is in a block.  I don't even think that they can propogate past the first full node until the first one is in a block.

An offline device can create and sign a transaction, it cannot validate it.  However, (in theory, don't know about this device yet) any disconnected device with local copies of it's inputs could also keep the merkle trees that show where those input transactions fit into the blockchain.  This is about as close to an offline validation as it likely possible.


First the 'gateway' is just another mesh radio connected to the Internet, there is no reason to expect that the gateway itself would be a bitcoin node.  A counter-party to a change based transaction needs to be able to see that the previous transaction fits into a block, otherwise the next transaction is indistingishable from a double spend attempt.  This would be possible if the counter-party were a connected full node & the prior transaction made it back to the internet by another path,but such an event cannot be assumed.

I suspect that I know the tech being presented here, and if I'm correct, the video is likely understating the practical ranges.  I know that I'm guilty of speculation, but I suspect that the mesh tech alluded to is dash7.

http://en.wikipedia.org/wiki/DASH7

Note that Dash7 devices are inherently location aware, in a relative sense; i.e. they know where there are relative to other dash7 devices.  The customer location tracking features mentioned in the video are one of the encentives for vendors to adopt a set of 'dongles', which would (presumedly) be aware of their own positions in an absolute sense (GPS).

Also note that Dash7 devices can have theortical ranges up to 2km, which practially means about 1km; and that it's max data rate is 200kbps.  However, it cannot do both max range and max speed at the same time, so the video's downgrading of the noted ranges might be due to a concern of overpromising or it might be due to the intent of the card designers fixing the data rate at the max and otherwise living with whatever range remains.

Dash7 isn't good for data that streams or large files, but for mesh propogation of bitcoin data it's practially ideal.  Also the ISM band that DAsh7 uses (433Mhz) is a 32nd harmonic of that which NFC uses as a standard, so both techs can coexist on the same tranceiver and share much silicon, making such features cheaper to produce.

There would be a practical limit, but it's one that's hard to predict.  It depends upon the input transactions that the device has in local storage, because it can only make transactions based upon the unspent inputs that it has since last connect.  It's not practically possible for a disconnected device (light or otherwise) to be able to use the change from a previous transaction as an input in a new transaction because all other devices should require that the change transaction have 6 confirms or at least a copy of the block's merkle tree as evidence that it's a valid transaction and not a double spend.  Since the device is disconnected, there is no way for it to have that evidence even if some other device has already forwarded the transaction to the network on it's behalf.  In practice, such a device is going to have to keep a set of seperate transaction inputs of varied sizes in order to make multiple payments between online sessions.

http://en.wikipedia.org/wiki/Moravec's_paradox

Creating an AI capable of exceeding human limits of intelligence is almost trivial, particularly when confined to particular definitions of intelligence such as aptitude at the game of Chess.  But until we understand ourselves, we can't hope to teach a computer to do things that come naturally to an infant.

http://cvdazzle.com/

Therefore, the architect is as doomed by smart computer systems as the Disney animator, but the skilled laborer is irreplacable.

REally?  How old are these ties?  Because I'm pretty sure that railroad ties have used toxic chemicals to prevent bugs from eating the support out from under the rails for over 100 years, and at no point would I have wanted such things anywhere near my vegetable garden.

I'm curious.  What does one use old railroad ties for?

So many things.  Basicly anything that you can normally get online, and many things that you cannot, I have bought with bitcoin.  I've even bought rock'n'roll; but no sex, drugs or guns; though. 

At least the ATM will have a camera to film the event.

You understand correctly.  A favored address can both be an input and an output in a transaction, however there are other downsides to doing things this way than just making it obvious which output is the change.  They are obscure enough to ignore for the average Joe and it's uncertain that they actually present a risk, so for the vast majority of users it's unlikely to be an issue, but it's a poor habit to get started.

Set one up and you will have one.

I'll be waiting with baited breath!

Of course.  There are a number of different ways to do that.  Unblock only bitcoin ports & whitelist bitcoin related websites, and simply open wide after payment.  A lot of people would pay just to unblock facebook & twitter, so you could just block those sites until paid.

http://www.plata.com.mx/mplata/articulos/articlesFilt.asp?fiidarticulo=185

Not at all related to bitcoin, but interesting nontheless.

I don't think that I'm expressing myself well here.  I not 'scoffing' at the idea that some clients need live Interent access in order to function.  I'm saying that more than one method to support lightweight clients that require live Internet already exist, and none of them actually require the resource overhead of an alt-chain.  Make no mistake, the distributed security of bitcoin is an awesome thing, but it's also expensive in many ways.  Murged mining helps in that regard to a limited degree, but it's a crude kind of hack.  Not at all the smooth, elegant & interwoven solution that bitcoin itself is.

What I want is a lightweight client, that can run on my Android phone, and if the cell network is down (snowstorm, Katrina, zombie outbreak, whatever) or I'm deliberately out of my service zone (camping, safari, fishing trip, whatever) my light android client can still transact to some degree sans live Internet.  The light client as described in Satoshi's white paper, that holds the block headers & copies of it's own input transactions; can spend bitcoins because it can create & sign a proper transaction.  It can also receive a transaction.  What it can't do, without live Internet, is check the validity of a transaction; beyond checking to see if the provided input transactions fit into the Merkle tree.  Even with live Interent, an independent light client can't do that nor discover new transactions for itself without scanning whole blocks itself.  That's teh role that both Stratum & this proposal seem to fill.  If this proposal requires live internet at the time of transaction,then it offers no practical advantages over Stratum.  Stratum is, itself, a distributed p2p netowrk protocol.  It may not look like bitcoin, but it doesn't need to either.


No, not must.  A client with the block headers, copies of the transactions used to send money to it's own addresses (it's input transactions) and a local wallet.dat can create & sign transctions locally, and it can thus use any of a number of ways to communicate that transction over to the vendor; who then may or may not be able to verify it and may or may not be able to forward that transaction to the Internet immediately.  These are not requirements.  However, a client that holds only a wallet.dat would need the live support of a Stratum server to construct it's own transaction, so that kind of (ultralight?) client would require live internet.


It's not slightly more to download.  It's at least as much with potentially several orders of magnitude more to download, store & verify.  There is also the multiplicity issue with blockchains.  Bitcoin requires that multiplicity of redundent data, but the light clients do not.  That is one of the driving forces for overlay networks such as Stratum, to limit the multiplicity.  just because you might not be seeing that across your own data plan, doesn't mean that someone doesn't need to pay for that extra duplication of effort as well.  One way or another, the end users are going to be paying for the network. 

I can see that, what I can't see is what gain is there in downloading a regualr digest of a pruned blockchain, when you could just help finish the touches on pruning and do the exact same thing within the bitcoin netowrk, no murged mining hack nor additional network resources required.  What you guys  are trying to acomplish is already possible within the protocol.  Without additional advantages, why bother?

And this is another thing, that is one huge assumption.  We didn't know that bitcoin itself would work two years ago.  How do you know that murged mining works as described?  I sure don't.


While dicks will always be dicks, those dicks can't really steal anything of significance, and the high costs of doing what you are talking about is a huge deterrent.

Stratum uses a different model.  I'm not one of the developers, so I only understand what the intent is; but each stratum server is a full bitcoin client first, and also participates in the secondary network.  The stratum servers don't depend upon each other to do anything outside of what the bitcoin network already does.  The stratum protocol functions as a controlled spigot to the bitcoin network firehose.  A stratum capable client can query a single stratum server that the user trusts (because he has a service paid for, or because he personally set up that particular server) and privately query the stratum server for data about particular addresses or transactions.  The client, should it not trust any particular server, can reach out to several stratum servers in a semi-random way (either biased towards servers that it has contacted before and not be told falsehoods, or by some other method) and query multiple servers and check responses against each other.  It provides a standard method for a single full bitcoin node to function as the blockchain to hundreds or thousands of light clients, that may or may not actually maintain either block headers or transaction inputs.  Like a distributed version of a split wallet service, like BitcoinSpinner without the vendor lock-in.


That a remote possibility, but again most of the light clients that we expect to see in the future will be desktop apps that don't mine but are still capable of switching to full node mode at will or by user direction.  If the stratum network is being DDOSed, or is otherwise unreachable, most (probably not all) such clients would simply jump directly onto the main bitcoin network to acheive their ends.  This is likely to cause problems in it's own right, but the option always remains open.


I'm skeptical of that, myself.  I will reserver my final judgement based upon what you can show me later.


First, it can compare to local blockheaders, it's just not limited to that.

Second, see above about checking several servers against each other, or simply running your own stratum server at home for use on your android.


You make that sound like that's easy to do, or cheap.  Yes, such an attack vector is possible under thin conditions.  Still, it's potential gain is limited to what the spoofed client is willing to send or what he believes that he has received, not all he has.  I can't see all that kind of effort just to steal my lunch money.  If you're buying a new car with bitcoin, you're going to be taking some more deliberate steps anyway.  The general trend is that security & convience are at odds to each other, and these light clients are intended for convience with relative security, not the full absolute security that a hardened full client could provide while also running it on a cell phone.  This also doesn't consider the use of risk assessment algos.  For example, if your client tries to reach out to the stratum network to check a transaction sent to itself, but can't connect to your personal stratum server, so it falls back to polling 8 random servers & eight servers from within it's own 'good' history.  It gets back all the right responses, but the version number of the nodes it knew about all have different checksums than last time.  Could be that you haven't used this app in a while and everyone really has upgraded, or it could be that you've been corralled into a honey-pot network.  The client notifies you of it's risk assesment, you can either take the transaction on faith or reject it and refuse to hand over the product.


True.  You also need the same from an alt-chain just to be able to have one.  That only shifts the problem across time, it does not change teh problem logically.


Once the block has been created, true.  Not true while the block is being settled upon.  This is why bitcoin, itslef, requires 6 confirmations before the standar client will resend the coins.


My understanding of merged mining is limited, but my understanding of regular proof-of-work is not.  That said, as I undertstand it, merged mining permits the alt chain to leverage bitcoin's securlty to shore up it's own; generally by inerweaving specially identified transactions into the bitcoin blocks, while interweaving all or part of the last bitcoin block's header into the alt-chains's header; thus proving a time sequence in lockstep with bitcoin's own.  While this little hack would permit a mnor alt-chain to benefit from the securty of the bitcoin blockchain, it does nothing that I know of to actually improve teh trustworthyness of the miners that created the alt-chain block to begin with.  Does namecoin do this?

Probably, under certain conditions. 

And you know this, how?

That's worse than getting rickrolled.  What the hell was the point of that one?