Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

[Gregory Maxwell]

On Thu, Apr 10, 2014 at 10:30 AM, Tier Nolan  wrote:
> Error correction is an interesting suggestion.

Though I mentioned it, it was in jest— I think right now it would be
an over-design at least for the basic protocol.  Also, storing
'random' blocks has some locality problems, when verifying blocks you
need to obtain them contiguously, and so we can take advantage of the
locality of reference.  For the non-error-coded case I believe nodes
with random spans of blocks works out asymptotically to the same
failure rates as random.

One thing that I like to point out is that there is absolutely no need
for the entire network to use the same p2p protocol. Diversity here
would be very good.  I think it would be really good for someone to
have an alternative p2p protocol using these techniques even though I
think they aren't yet compelling enough to be table stakes in the
basic protocol.

There are some very helpful things you can do with forward error
correction for faster and more efficient block relaying too:
https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding

(The conversation Peter Todd was referring to was one where I was
pointing out that with suitable error coding you also get an
anti-censorship effect where its very difficult to provide part of the
data without potentially providing all of it)

> If there was 1 nodes and each stored 0.1% of the blocks, at random, then
> the odds of a block not being stored is 45 in a million.

I think in the network we have today and for the foreseeable future we
can reasonably count on there being a reasonable number of nodes that
store all the blocks... quite likely not enough to satisfy the
historical block demand from the network alone, but easily enough to
supply blocks that have otherwise gone missing.

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Feedback request: colored coins protocol

[Flavien Charlon]

I have updated the
spec
.

> This is an interesting approach, but OP_RETURN size limitations can be a
significant problem for some kinds of applications.

This is correct, the number of colored outputs you can have per transaction
is limited by OP_RETURN's 40 bytes. We use a compact format
(LEB128)
for the asset quantity of each output to mitigate that. Assuming you're
transferring small amounts of colored coins, you could have up to about 30
colored ouputs.

It should work for a decentralized exchange (you only really need 2 or 3
colored outputs). Applications like sending dividends in colored coins
however may require splitting into several smaller transactions, but I
believe that's an acceptable limitation.


On Thu, Apr 10, 2014 at 6:24 PM, Alex Mizrahi wrote:

>
>
>>  At this point, I don't think what you are doing is even colored coins
>> anymore. You might want to look into Counterparty or Mastercoin.
>>
>
> Nope, it's still colored coins. The difference between colored coin model
> and Mastercoin model is that colored coins are linked to transaction
> outputs, while Mastercoin has a notion of address balances.
>
> The implications of this is that in colored coin model explicit
> dependencies allow us to rely on SPV. (Assuming that one can fetch the
> dependency graph to link txout in question to genesis.)
> While it is not the case with Mastercoin.
>
> While it's pretty far from the original colored coins model, what Flavien
> have described is identical to it in majority of aspects.
>
> This is an interesting approach, but OP_RETURN size limitations can be a
> significant problem for some kinds of applications.
>
>
> --
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development