On bitcoin, and BitDNS

[da2ce7]

I am in the process of writing quite significant change about how BitDNS and extensions of Bitcoin.

Talk about my recommendations in this thread.  I will be adding more posts as I complete more of the design (that is in my head atm).

http://domainchain.org/wiki/doku.php?id=bitname  Now using a wiki. 

[1714922686]

1714922686

[1714922686]

1714922686

[da2ce7]

This is the summary of recommendations that modify the bitcoin protocol.  Please discuss:

Proposal One: Templates, Transaction groups, and Burning Transactions

Templates:
Already included in the bitcoin client, described changes make it more powerful and useful to base groups upon

1.   A template must contains three parameters:
   a.   Unique ID
   b.   Human Readable Name
   c.   Codified verification that can rigorously check if a transaction is valid or not for that particular template.
2.   Optionally, a template may include a codified way of modifying the transactions.  (Discussion?) - Not a good Idea
3.   Every transaction must still comply with the existing enforced network rules. Such as no, double spending.
4.   Every non-standard transaction shall claim what sort of transaction it is by including the template ID that it belongs to, and then is verified to comply with the template it claims to belong.
5.   Transaction without a template ID will be assumed to comply only with the 'standard transaction' template.
6.   No transaction shall claim to belong to more than one template.

Transaction Groups:
A group that contains all the transactions that are validated by the same template.

1.   Verified transactions should be placed within a grouped together in each block.
2.   Summary of every transaction accepted into the block should be included as a special group.  The summary must contain information about witch group each transaction belongs.
3.   Every group must be hashed separately.
4.   The hash of every group should be included in the block’s merkle tree.
5.   The p2p network should allow clients to download either the entire block, or just the block and summary group.
6.   Generators must check the entire block for errors before accepting the block.

Burning Transactions:
New sort of transaction that sends the coins contained to null, and contains the rate that the coins are released back into circulation.  This transaction is an extension of the transaction fees.

1.   A Burning Transaction must contain an extra special ‘out’ that specifies:
   a.   The Rate (per block) of release of coins back into circulation.
   b.   Total amount of coins to be released.
c.   A special address that is defined as ‘null’
2.   This transaction can contain normal transaction fees like any other transaction.
3.   The first block after the block that contains this transaction may claim the first part of coins released.
4.   The coins released may be claimed at any point after or on the block that they are released on.
5.   When claiming the coins, the generator must quote the block that contains burning transaction in its block. - Not needed

[ribuck]

2.   Optionally, a template may include a codified way of modifying the transactions.  (Discussion?)

No template-based transaction rewriting please. It would hugely widen the attack surface for exploits.

[ByteCoin]

No template-based transaction rewriting please. It would hugely widen the attack surface for exploits.

Minimising the attack surface for exploits is vital.

What is the new functionality that you wish to introduce which cannot be implemented using a suitable non-lobotomised script?

ByteCoin

[Hal]

"1.c.   Codified verification that can rigorously check if a transaction is valid or not for that particular template."

Would this be codified by an extended scripting language, or by hard-coded logic in the client? I think it has to be a scripting language, otherwise it will be too hard to get agreement to add new templates. We would need to create scripting extensions to allow a wide range of new applications. For BitDNS we would need the ability to look back in the block chain and check if a given name has been registered before.

"3.   Every transaction must still comply with the existing enforced network rules. Such as no, double spending."

With the kinds of scripting extensions I anticipate, we could actually replace all these implicit, hard-coded Bitcoin rules with explicit scripted tests. The same kind of script that could test that a new BitDNS name had not been registered before, could be used to test that a Bitcoin transaction wasn't a double-spend.

There might be some  template applications where the double-spending rules don't make sense. Some of the BitDNS proposals don't do true Bitcoin transactions at all, they piggyback extra data on top of a dummy Bitcoin transaction where you just pay yourself. It would be nice to remove this unnecessary part.

In this view, the core logic of Bitcoin would check that blocks had the required difficulty, were properly formatted, and that their scripts all return true. Everything else would be done by application-specific layers.

[da2ce7]

2.   Optionally, a template may include a codified way of modifying the transactions.  (Discussion?)

No template-based transaction rewriting please. It would hugely widen the attack surface for exploits.

Sounds reasonable, I was looking for some extra flexibility, however attack surface area is more important to minimize.

[da2ce7]

"1.c.   Codified verification that can rigorously check if a transaction is valid or not for that particular template."

Would this be codified by an extended scripting language, or by hard-coded logic in the client? I think it has to be a scripting language, otherwise it will be too hard to get agreement to add new templates. We would need to create scripting extensions to allow a wide range of new applications. For BitDNS we would need the ability to look back in the block chain and check if a given name has been registered before.

I think that a scripting language would be adequate, however it would have to be fully unit-tested.

"3.   Every transaction must still comply with the existing enforced network rules. Such as no, double spending."

In this view, the core logic of Bitcoin would check that blocks had the required difficulty, were properly formatted, and that their scripts all return true. Everything else would be done by application-specific layers.

Every Transaction still needs transaction fess, double spending is important to check at a foundational level.

[da2ce7]

http://domainchain.org/wiki/doku.php?id=bitname

I have finally written out the basic ideas.  It needs lots of fleshing out.