|
What do you mean by centralization? Let's taboo the word.
A centralized network protocol requires a specific network resource to be online and available in order for the protocol to work. Examples include a trusted timestamping, checkpointing, or routing server. This is the technical meaning that is prescribed to the opposite word "decentralized" as it applies to bitcoin - bitcoin is designed without any centralized network resource, and so among other things can continue to operate even in the face of powerful but not omniscient censorship. The same is true of Freicoin: so long as your blocks include the foundation outputs for the first three years, you will reach consensus with the Freicoin network.
Calling the budgetary requirements “centralization” is a twist of meaning. I wonder what you mean by that phrase? That is to say, if you taboo'd the word, what would you call it instead?
|
|
|
|
“Provably fair” was never a design requirement.
Peer-to-peer was, and unless you have equal rules for all participants it is not peer-to-peer. So yes, provably fair was never in the initial plans... it's just the only way to restore that plan. No aspect of the protocol is centralized. None. Zero. Zilch. This whole initial distribution thing happens outside of the freicoin/bitcoin protocol. |
|
|
|
I'm not sure what "perfectly" fair is either, but a provably fair system would be one in which all participants can prove that the 80% coins were handled according to strict rules without having to trust anyone. You're asking us to either trust you or independently verify that these recieving addresses belong to registered charities. That's a non-trivial cost that doesn't exist with "wasted" heat.
We have better things to do with our time than come up with a cryptographically secure distribution method that's only going to see use once. “Provably fair” was never a design requirement. |
|
|
|
|
The article describes how every other ETF in existence works. It describes the process by which an ETF must adhere to in order to get regulatory approval. It describes exactly the way in which everyone with knowledge about how ETFs work, expected a bitcoin ETF to operate. There is absolutely no new information here.
|
|
|
|
|
This is how all ETFs work.
|
|
|
|
|
Mike, I will make one comment that if you are going to trust the checkpoint (which you do currently - validation in Bitcoin-Qt isn't performed until after the last checkpoint, right?) and if the checkpoint included an authenticated UTXO index hash under the soft-fork scenario, then you could just download that UTXO set and start verification from there, with *exactly* the same security as you would otherwise would have had. This let's us keep the "one to two days" to perform IBD to a small value, and not continue to increase over time.
|
|
|
|
|
If any one of those is broken, your coins are worthless anyway.
|
|
|
|
Beat you to it  Domain Name:BOINCOIN.ORG
Created On:11-Aug-2011 04:46:21 UTC
We're going to be doing this within Freimarkets, and extension of Freicoin that allows user-issued assets and distributed p2p exchange. |
|
|
|
Implementing pruning would be a great leap forward in usability.
The problem isn't (yet) the size of the block chain on disk. 10GB isn't a lot of space. It's network bandwidth - downloading 10GB of data takes a while on any connection. Pruning would do nothing to fix that (you still have to download the blocks before selectively throwing portions away), and it may even make things worse since fewer peers will have the full blockchain to seed from. |
|
|
|
Actually, none of the fraud proofs/challenges I mentioned in that thread relied on utxo set commitments. Transactions with nonexistent txins would benefit from them, since then there could be concise proofs of nonexistent txins, but the way I described it, a peer would issue a challenge to find a valid Merkle branch to an allegedly nonexistent txin from some other peer. If at least one peer is honest and the network operator (which Bitcoin generally assumes anyway), then they will find the branch if the challenger turned out to be lying, and can ignore that him going forward.
Fixed that for you. Without nonexistance proofs, network operator attacks are trivial. |
|
|
|
What I meant is that I use Bitcoin as an end user pretty regularly and didn't yet encounter a P2SH address. They certainly have been used, but are they being used regularly? And if someone is using them regularly, would they continue after the payment protocol is available? These things aren't really clear.
We're wandering off-topic, but what does P2SH have to do with the payment protocol? |
|
|
|
|
Mike, you're putting up strawmen with your insistence on Alan's original rationale(s). Authenticated, committed UTXO index structures provide a variety of new capabilities some of which Alan et al may not have anticipated. You seem to think these new capabilities are not useful, or at least do not justify their cost, for unstated reasons that you think are obvious. I disagree.
For example, it does matter how long it takes to bootstrap when you're talking about initial user experience, or a user who would prefer to run a full node but not halt operations while syncing. There's a wide variety of reasons people run bitcoin nodes, and I see any reason to expect the associated security requirements to neatly fall into one or two different models.
As for a selective DoS on Bloom filtering, no I haven't observed such a thing, nor have I been looking either. But that's completely beside the point: in the security business it is our job to act preemptively and close attack vectors, ideally before the black-hat work is done to exploit them. As to querying multiple nodes, you are ignoring network operators who could filter or replace protocol message. The index structure, on the other hand, would allow authenticated negative responses as well, so the querying node won't be happy until it receives a proof or presence OR absence.
No one's arguing for UTXO indices over bloom filters. They each have their uses.
|
|
|
|
|
fBenchmark (-benchmark) doesn't measure ECDSA performance. Are you sure you're reading the output correctly?
|
|
|
|
You can't have full node security by bootstrapping off a miner-majority consensus, that's SPV level security by definition. To bootstrap a full node in a trust free manner you have to process the entire chain, or get a copy of the database from somewhere you "know" is correct (i.e. another one of your own nodes).
Right now the choices are SPV or full node. The misnamed “ultimate blockchain compression” proposal would enable a wide spectrum of security modes in-between the two. Initial synchronization requires SPV level of trust in the checkpointed UTXO set. However from that point forward full validation can be performed, and history can be incrementally validated as far back as required (to the last checkpoint, for example, or the full history). The ability to construct fraud proofs provides an additional layer of security as it provides a compact way to inform other peers of an attack-in-progress. These are valuable options that enable secure limited-trust operation on constrained devices, or a graduated level of security as synchronization is performed. The second claim that it helps lightweight clients also isn't really right. I've actually implemented lightweight mode (the one described by Satoshi at least) and UTXO commitments really change much, at least not fundamentally. You still need all the block headers to track the consensus, and at that point you may as well ask for transactions that match your keys at the same time using the existing merkle trees. A UTXO commitment in the coinbase might make things faster if you were to import a private key, at the cost of significantly increasing resource usage of every single node on the network. Given that private key import is (or should be) rare, this isn't a good tradeoff.
Mike, you seem content to trust that peers will send you transactions matching your bloom filter. I do not find that reasoning compelling. The UTXO index will give a short, verifiable proof that matching transactions are or are not reported. |
|
|
|
Again, the "ultimate blockchain compression" thing doesn't make any technical sense, that's why it's not happening.
I'd love to hear your technical arguments regarding that. |
|
|
|
|
Validation of a full block currently takes more than 1 second on most commodity hardware, and that's with the 1MB blocksize limit. There's a reason Satoshi choose 10 minute interblock times.
But it's a fair question to ask, and we should be concerned about performance. The number of hash operations required to update the UTXO index is approximately:
2 * (I + O) log (N)
I: # inputs in new block
O: # outputs in new block
N: # outputs in UTXO set
So it scales linearly with the size of the block, and logarithmically with the size of the UTXO set. The constant 2 is because there will be two indices maintained, not the 1 index currently used for block validation, although one should expect the constant factor to be different anyway.
Besides the constant-factor difference, the added cost is that log(N) factor. That's not a super-significant change to scalability, and in my own opinion is definitely a worthwhile cost for secure lightweight clients and quicker sync times.
However when it comes to performance and scalability, the elephant in the room is ECDSA, not hashing. A modern consumer PC can hash about 100 MB/s, but only do about 100 ECDSA signature verifications per second. The number of signature operations is related to the number of inputs, and therefore the size of the block. That's a speed difference of 3 to 5 orders of magnitude, depending on natural variation on the size of outputs and the number of signature operations per input.
EDIT: And thank you for your contribution!
|
|
|
|
|
Hi Arcturus, that address should work just fine for freicoin as well. Thanks! I'll see what the RSS problem is about .. it's a tumblr blog so I'm not sure what control I have over that, but I will try.
|
|
|
|
|
The unSYSTEM meeting is very different in scope and purpose from the business-oriented Bitcoin 2013 conference in San Jose. Hence this thread.
|
|
|
|
|
Well that's simple enough, just take the low-order bits. For your application you may or may not require a salt.
The idea works; whether it is a good idea or not depends on your application.
|
|
|
|
|
Show Posts
