Topic: [white paper] Purely P2P Crypto-Currency With Finite Mini-Blockchain - page 6. (Read 24217 times)

Ok, I have a better idea now of what it is you are suggesting, you could hard-code the more commonly needed functionality. However, I will say that scripts are more flexible, and furthermore that we should move away from having to approve each script individually.

You don't need scripts to do multi-sig accounts. You can just define such account type. And defining account types in code is more powerful than scripts because you have access to full blockchain state. You can example make accounts with withdraw limits per day. And please do not say anything about scripts flexibility because in reality every use case of script needs to be enabled by developers and accepted by miners. They could as well just write code handling new account type.

Close to 0%, but currently securing bitcoins is very hard and the system isn't very scalable. You need multisig and more sophisticated scripts to keep bitcoins secure, you need payment channels to allow trustless off-chain payments, etc.

And, yes, I currently enjoy very little utility from Bitcoin in its intended purpose. It will be more useful when it is more widespread, but that will happen only if it's scalable and easy to secure.

Any specifics? How many percent of current bitcoin transactions are something OTHER than simple pay to address? Is bitcoin useless because of it?

The paper says each bitcoin is 10M satoshis, the correct number is 100M.

Cryptocurrencies are almost useless without scripts.

This idea will obviously need to make use of P2SH; the account addresses will be hashes of scripts rather than public keys, and the defining script will be given in the spending transaction.

Thanks. I am now following that thread as well.

I am not a coder myself, but am the software Product Manager at the company where I work. So, I might be able to help coordinate. And I am willing to contribute at least some to the funding. But, that still leaves a pressing need for some strong coders to help move this forward. I will be talking to a couple of programmers I know, who may not be strong in crypto (yet), but who may be interested. That's the best I can do at the moment.

Good idea, I will do that now. I meant to send you a message with a link to that thread but I must have forgotten about it. At least you know now.

Post this link in this thread first post. I'd like to contribute but didn't even know new thread was started.

Project implementation thread can be found at link below. As of yet no developers have come forward to help so if you can help in any way or know anyone who can, that would be helpful.

https://bitcointalksearch.org/topic/building-the-next-generation-of-crypto-currency-developers-required-215936

Yes, basically, that is the answer. It is quite similar in many ways but because we're not trying to apply a change on top of an existing blockchain scheme we can leave out many unnecessary features and make it more efficient, and much easier to build.

I am very interested in this mini-blockchain idea, and the other ideas in the thread. This could be a very major step forward for crypto-currency.

What steps are being taken to put this into code? What help or resources are needed? Is there any other thread I should be following to keep abreast of this?

great idea! realize it if you can

Another approach to secure laundry using Eltase's ideas.

First let's define Mixing Set.
Mixing Set consists of header and list of inputs to mix. Header includes:
- mixing denomination (1 coin, 100 coin, etc)
- mixing size (how many inputs)
- mixing public key
- time available for ticket redeeming
- input coins used as collateral

Mixing parameters should be standardized so it would be easier to find matching inputs.

Users sends to network intentions to mix which include
- sufficient amount of coins (denomination + fee)
- requested denomination
- requested minimum mixing size
- requested ticket redeeming window
- blinded mixing ticket = blind(random string + payout address). We need random string so every ticket is unique.

Miners monitor received mixing intentions and if miner find set which can be used for creating Mixing Set he can create one.
Miner generates new key pair just for single Mixing Set and includes this key in header. With this key he make blind signatures of all mixing tickets and include such transaction in block.
When Mixing Set is included coins are taken from all participants but are not deposited anywhere.

All mixing participants can now see that their mixing intentions were included in blockchain. They unblind their tickets and with it create output transactions against Mixing Set (their tickets are signed with blocks private key).
Redeem transactions can be included in any next block until redeeming time is up.
When redeeming is over we can have 3 outcomes
- there was less redeemed tickets than input. In this case outputs are credited normally and creator of Mixing Set gets free money.
- all tickets was redeemed. Outputs are credited normally.
- there was more redeemed tickets than inputs. This mean creator of Mixing Set cheated so he looses his collateral (miner who mined block containing first extra ticket gets it) and money is returned to senders. Users can't ever loose their money.

I think it is similar, but is better because it drops unnecessary UXTO concept.

Could you maybe summarize how your proposal is different from "Ultimate Blockchain Compression" (https://bitcointalksearch.org/topic/ultimate-blockchain-compression-w-trust-free-lite-nodes-88208. Ref [4] in your paper.)?

As far as I can see, the Account-Tree is more or less equivalent to the UTXO-Set and the Proof-Chain is equivalent to the merge-mined block-header.

Yes, I thought it over and your solution can work indeed and has many advantages over mine.

Blind signature schemes have existed prior to the advent of the internet, and they solve the problem. And in my solution's case (though it has some minor caveats), there is no danger of ever losing your money or having to reveal where you intended to send money if the mixer does something bad. Yours requires that the operator has collateral to cover all transactions, where mine does not. There is also the problem that if not enough transactions are being processed through a mixing account but it is forced to release your transaction, there may be few transactions inbetween that provide reduced linkability. And if the mixer does not release the transaction, your solution completely deanonymizes the transaction if they want to get their money. These are all very significant caveats. And the result is no better than sending your coins to a gambling site or whatever and cashing them out to another account. You could argue the gambling site is more likely to keep records, but coin mixer accounts as part of the protocol is ripe for the honeypotting.

Someone need to know how to pair inputs to outputs so he can update account ledger. I don't see a way to avoid that.

re: coin laundry, the system I described here could be safely used for any amount of money. If the SH attempts to be devious, all money will simply be returned and he will lose his deposit. And no correlation can be made between the from and the to accounts (other than it is one of the initiators, so 1/x). It seems as if you have given the laundry this information, so you have not protected anyone from the laundry keeping records. This is the same privacy offered by sending your coins to any site that will keep a balance for you and then cash out at a later time.

However, I did not bring up that it could be used for any amount of money in that thread. I am on the fence about including an all-you-can-use coin mixer as part of the protocol. But it can be very versatile. As part of the transaction, you have the amount required and the number of initiators you require. Say you want to clean 50 coins, and you want 99 other people to clean 50 coins with you, then you initiate it and wait. If you are paranoid that someone will send 99 txes to oust you, you only need to send a tx that fits the criteria of another group and join that one's pool.

Awesome features with account ledger continues:

Secure coin laundry
We create new account type for coin laundry operators. Account include required fee and amount of coin deposited as collateral. Collateral is needed to make sure operator is honest. Coins in collateral can only be withdrawed with delay, so operator cannot disappear with users funds.

Algorithm of operation is:
1. Users sends transaction to laundry. To transaction a message is attached which describe amounts and addresses where laundry should send coins. Message encrypted with mixer public key, so only he can read it's contents.
2. Operator must execute specified transactions in N next blocks.
3. I mixer fails to execute transactions user reveals unencrypted message. Anyone can check if it matches encrypted version . User has N blocks to do it and if mixer indeed failed to execute instructions then sent coins are returned to sender from operator collateral (maybe with penalty).

Laundry operator gathers user inputs and when he receive enough of different inputs he starts to execute received instructions. He gets fee for that and he does not have incentive to be dishonest because he risks loosing collateral.

With careful calculation of good values for N and making sure there is never more outstanding user transactions than collateral this system can be made totally safe.