Bitcoin Forum
December 05, 2016, 02:38:02 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: On bitcoin, and BitDNS  (Read 1458 times)
da2ce7
Legendary
*
Offline Offline

Activity: 1218


Live and Let Live


View Profile
December 14, 2010, 02:21:37 PM
 #1

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.  Grin

One off NP-Hard.
1480948682
Hero Member
*
Offline Offline

Posts: 1480948682

View Profile Personal Message (Offline)

Ignore
1480948682
Reply with quote  #2

1480948682
Report to moderator
1480948682
Hero Member
*
Offline Offline

Posts: 1480948682

View Profile Personal Message (Offline)

Ignore
1480948682
Reply with quote  #2

1480948682
Report to moderator
1480948682
Hero Member
*
Offline Offline

Posts: 1480948682

View Profile Personal Message (Offline)

Ignore
1480948682
Reply with quote  #2

1480948682
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
da2ce7
Legendary
*
Offline Offline

Activity: 1218


Live and Let Live


View Profile
December 14, 2010, 02:22:42 PM
 #2

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

One off NP-Hard.
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 14, 2010, 02:43:11 PM
 #3

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
Sr. Member
****
Offline Offline

Activity: 416


View Profile
December 14, 2010, 03:34:42 PM
 #4

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
VIP
Sr. Member
*
Offline Offline

Activity: 314



View Profile
December 14, 2010, 08:20:49 PM
 #5

"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.

Hal Finney
da2ce7
Legendary
*
Offline Offline

Activity: 1218


Live and Let Live


View Profile
December 14, 2010, 11:14:09 PM
 #6

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.

One off NP-Hard.
da2ce7
Legendary
*
Offline Offline

Activity: 1218


Live and Let Live


View Profile
December 14, 2010, 11:16:46 PM
 #7

"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.

One off NP-Hard.
da2ce7
Legendary
*
Offline Offline

Activity: 1218


Live and Let Live


View Profile
December 15, 2010, 02:08:14 AM
 #8

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

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

One off NP-Hard.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!