Topic: New paper: Accelerating Bitcoin's Trasaction Processing - page 3. (Read 36368 times)

Yes. There is things hiding in the dark... us shrills were actually the team of 'second gunmen' on the Grassy Knoll.

There its open. ha.

Thanks

Still, having this double spend alert would reduce the current threat, making the attack much more difficult to achieve.
What's the hold up in waiting to add this double spend alert?

Other than this paper that started this thread, what are the other possible that are being investigated to improve bitcoin's transaction speed?

Thanks very much for your reply.

The largest pools are about 30% of the network. That would give them a 1-in-3 chance of pulling it off, which is more than enough for some scenarios.

EDIT: The paper also assumes that once one transaction has been seen, a node will always reject a double-spending transaction. This is also false. Nothing prevents a self-serving operator from discarding the initial transaction and accepting the double-spend (because it has a higher fee, for example).

How important is that threat? I mean, how large is the largest pool and how much share of the HASH computing power does it have to sort of attempt to quantify the probability of this threat?

Ok, I see what you mean, only those large pool would know about the double spend.
So this large pool would need to be in bed with the double spender.

No. That paper makes the flawed assumption that double-spends must be propagated on the network. On the contrary, someone executing a double spend could own or have some relationship with one or more large mining pools and send the double-spend to them directly. No one would know about the double spend until it is already confirmed in the next block.

Have you seen this paper?

 http://eprint.iacr.org/2012/248.pdf

It sounds like, with what is depicted in section 5.3, that once this double spending alert is implemetned, just waiting for 15 seconds for receiving a payment without any conflict would be sufficient to be confident, isn't it?

There is no stable, secure way to manage interest rates that cannot be trivially gamed by participants, including that proposal you linked to. You're not the first to consider this problem. If you're of the opinion that some inflation/interest is desireable, you might be intersted in Freicoin. But this is wandering far afield from the topic.

I would also like to see some kind of community interest rate in the currency, similar to what was outlined here: https://docs.google.com/document/d/1302Fb5BpgTRS2P-snN4ys5JR3l8QU2QhpncldAYaXfM/edit?usp=sharing

No currency can have limited supply and stable prices.

Besides that, I think we are on to a winning formula, yes.

HA

As I understand it, you generate a verifiable 'trace signature' of a program run which bears a distinctive cryptographic relationship with the code itself; it can be considered to be 'signed' by the code used to create it.

But GIGO still applies.  Given the same starting point, the same code could run with different input, then you can give 'trace signatures' to two different people to verify, and have two people verify that the code ran correctly and those two people will still have different results. 

However, for some data structures, if you are given the starting point, the 'trace signature' AND the results, you can verify that the starting point was transformed into the results via the 'signed' run of the code, even if that valid run had unknown inputs.  This is possible with some structures and not others, but because of the cryptographic chain-of-evidence qualities, the Bitcoin Blockchain is one of the finest examples of a structure that it *DOES* work with.

But I think this is going rather far afield from the original intent of this thread, which was to make Bitcoin able to handle more transactions per second.

I thought it would be something like

inputs: prev_utxo_tree_hash, transaction set for current block
output: utxo_tree_hash

or

F(prev_utxo_tree_hash, transaction set for current block) = utxo_tree_hash


If this is correct then another node would just need prev_utxo_tree_hash, utxo_tree_hash and the signature of the execution of F to validate that the block was correctly processed. Doesn't even need the transactions.

Sorry again if I'm saying something stupid about snark, this is still like magic to me so it's hard to retain what can and cannot be done.

I suppose it's partially zero-knowledge as you wouldn't need all of the inputs to the program. I did read somewhere that the SNARK programs can have public inputs as well as arbitrary inputs which are unknown to verifiers. Is that right? Some details would be hidden to the verifier, such as the transactions.

Long output will blowup the complexity, the output can be boolean, where the hash the UTXO set is an input.


It's a great idea, but what does it got to do with zero-knowledge?


When an efficient SNARK implementation is available, there's a good chance that the Bitcoin devs will integrate this option.

Because nodes wouldn't need to store and validate the block-chain. It only needs to be validated once. The output of the validation could be the unspent outputs, so that all miners need is the last block alongside the unspent outputs. Then they can build upon that. Non-miners would simply verify the proofs in the blocks and take the unspent outputs relevant to them. Why is this not a good idea?

How would anyone actually start developing a crypto-currency that worked in such a way? It all seems very theoretical to me.

I think we just tend to confuse snark/scip with zero knowledge.

The answer is yes, but why do you guys keep resurrecting zero-knowledge back into this discussion?

Here's a talk from the 2013 Bitcoin conference by my PhD supervisor about it: http://www.youtube.com/watch?v=YRcPReUpkcU

You can think of it as some specified C or assembler source code having a similar role to that of ECDSA pubkey, and a succinct form of an execution of this source code as having a similar role to that of ECDSA signature. Given this "pubkey", everyone can verify that the "signature" indeed corresponds to a valid execution of that C/assembler program and that this execution terminated with the required output. The probability that an invalid "signature" will pass this verification algorithm is negligible. So in order to "compress" the blockchain, we specify the C/assembler code that checks the blocks from genesis until a certain checkpoint block, and compute a "signature" for an execution this computation, so that nodes can verify with zero-trust that this checkpoint is valid without downloading all the blocks since genesis, and without the need to fetch any blockchain data (to answer maaku's question). Saying that this "signature"/proof is zero-knowledge just means that it doesn't reveal any additional information besides the single bit that says whether in this execution all the blockchain blocks indeed passed validation (an example of additional info is, say, that this "signature"/proof leaks that Alice sent Bob 5 coins at some block). Why do you guys care about zero-knowledge in this regard?

I read part of the paper. In layman's terms, the "GHOST" parent selection of blocks takes into account the work of all the blocks that are children of a block which is a candidate to be made parent. Therefore it takes into full account the hash distribution of the network. In the current system, if the time between blocks was reduced significantly, then blocks which are propagated slowly will be placed on a side-chain as they will lose out in the propagation race, therefore, unlike the "GHOST" system, the current system cannot take the full hash-distribution into account.

Now if only that was explained in the abstract, it would have saved me so much time!

I was thinking about this myself. Could you use a zero-knowledge proof to validate the block-chain without needing the actual block-chain? I don't know very much about it at all.

Maybe. The proof needs to be verifiable without any blockchain data. Regular SNARKS can do this?