Bitcoin Forum
December 09, 2016, 11:55:02 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 [4] 5 6 »  All
  Print  
Author Topic: Design notes for sharing work between multiple independent chains  (Read 13948 times)
BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
May 15, 2011, 06:07:50 PM
 #61

No, it's absolutely nothing like that at all. I suggest you read up some more on the function of the block chain, and the proposed alternate block chains, so you can get a sense of how much data might have to be stored by all Bitcoin nodes if people were to start storing arbitrary data in the main block chain.
1481284502
Hero Member
*
Offline Offline

Posts: 1481284502

View Profile Personal Message (Offline)

Ignore
1481284502
Reply with quote  #2

1481284502
Report to moderator
1481284502
Hero Member
*
Offline Offline

Posts: 1481284502

View Profile Personal Message (Offline)

Ignore
1481284502
Reply with quote  #2

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

Posts: 1481284502

View Profile Personal Message (Offline)

Ignore
1481284502
Reply with quote  #2

1481284502
Report to moderator
1481284502
Hero Member
*
Offline Offline

Posts: 1481284502

View Profile Personal Message (Offline)

Ignore
1481284502
Reply with quote  #2

1481284502
Report to moderator
unk
Member
**
Offline Offline

Activity: 84


View Profile
May 15, 2011, 07:24:53 PM
 #62

i have never seen a project that so readily assumes ignorance in newbies! (maybe the typical newbies are more ignorant here than elsewhere?)

you appear to have misunderstood my message. my analogy was not meant to compare the stakes, only the futility and arbitrariness of the exercise.

you cannot prevent people from 'storing arbitrary data in the main block chain', so at best the present attempt is to get a few people to coordinate their efforts to reduce the size of the block chain by not including things that the group of people doesn't want to include. as i already noted, 'even if you solve the design problem to your satisfaction, it resurfaces as a security problem'. at best you're seeking a gentleman's agreement, analogous to advisory locking in a filesystem.
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
May 15, 2011, 07:44:39 PM
 #63

I have never seen a project that so readily assumes ignorance in newbies!

I think that certain people have conclusions they like to jump to and they do so without properly reading the post they are replying to. It's also easy to infer criticism or an attack where none is meant.

Nobody is seriously suggesting anymore that one can prevent using the bitcoin chain to store data. People want to store data in the block chain to implement certain functionality and if we can facilitate the functionality by some other more convenient method then they will use that instead. Alt-chains attempts to do that.

[mike]'s proposal boils down to having miners who support alternative block chains incorporating a hash for one or more block chains in the coinbase transaction for the bitcoin blocks they're mining.

One drawback is that the people distributing the generic bitcoin client could pull the plug on all the alternative block chains by having their client reject blocks which have a non-standard coinbase. As alt-chain-compatible blocks would not be accepted and relayed by clients, the alt-chain supporting miners would essentially drop off the network. The bitcoin network would experience a drop in hashing power as these clients left but would otherwise continue unaffected.

I don't know whether the possibility of this kill-switch would be acceptable for the alt-chain users.

ByteCoin
BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
May 15, 2011, 08:01:15 PM
 #64

One drawback is that the people distributing the generic bitcoin client could pull the plug on all the alternative block chains by having their client reject blocks which have a non-standard coinbase. As alt-chain-compatible blocks would not be accepted and relayed by clients, the alt-chain supporting miners would essentially drop off the network. The bitcoin network would experience a drop in hashing power as these clients left but would otherwise continue unaffected.

Hmm... I'm not sure this would be an issue as long as large or lots of miners adopted this method. I imagine a pool that offered mining of all complementary block chains would be quite popular, and it would be in the best interest of everyone who wants to receive confirmations that they accept these types of blocks.
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
May 15, 2011, 09:13:19 PM
 #65

Why would anyone want to kill off alternative chains so badly?

And yeah I agree with ByteCoin. "Preventing" abuse is really hard, often impossible. Making it senseless or pointless is quite easy and how nearly all abuse control works. Bitcoin will never be a good way to store arbitrary data just because it wasn't meant for that. There's almost always a better tool for your problem.
xf2_org
Member
**
Offline Offline

Activity: 70


View Profile
May 15, 2011, 09:52:02 PM
 #66

isn't this discussion like the developers of a bittorrent client saying 'how should we design the client so that it lets people share only action movies, rather than comedies'? as theymos and others have implied, you can't stop it, and the principle upon which you'd favour 'finance' isn't clear anyhow.

what is 'nonfinancial' about a dns transaction but 'financial' about a generic multi-party contract? even if you solve the design problem to your satisfaction, it resurfaces as a security problem, for what could ever restrict the block chain to 'financial' information anyway? designing the 'action-movie only' bittorrent client would be a fool's errand.

If you try to stuff data through the existing system, it's like TCP-over-DNS:  possible, but so not designed for that purpose that it is slow, inefficient, limited and problematic.

It also impacts existing currency users, who probably don't want their currency use to be slowed or impacted by DNS data.  That will potentially slow or damage bitcoin-the-currency, which is what most people here are interested in.

JohnDoe
Sr. Member
****
Offline Offline

Activity: 392



View Profile
May 27, 2011, 07:33:53 PM
 #67

I'm not proficient with low-level bitcoin stuff yet, but... is such a transaction possible then?

in: 0.01 from a valid bitcoin address
out: 0.00 to arbitrary data / public key
(induced fee: 0.01 to the miner)

Yes -- that's how it would be done. 0-value outputs are valid.

OK, some people might hate me for this:...

If it's OK to store a hash that way... It should also be OK to store a small simple NS record, right? :->

I think so. Take a look at the DNS proposal that nanotube an I made, which stores records in that area:
http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal

Sorry, I'm not a very technical person. Are you saying that a DNS system can be implemented on top of Bitcoin without needing to make any changes to the protocol or ask for permission from anyone? If so then doesn't that make Namecoin worthless or is a new block chain with new transaction types still technically superior than this method?
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2506


View Profile
May 28, 2011, 06:41:55 AM
 #68

Are you saying that a DNS system can be implemented on top of Bitcoin without needing to make any changes to the protocol or ask for permission from anyone?

Yes.

Quote
If so then doesn't that make Namecoin worthless or is a new block chain with new transaction types still technically superior than this method?

Some people think that a separate system is better. I think combining DNS into Bitcoin's block chain (not into the Bitcoin software) is better because the incentive problem is already solved, it's easier to do, and it would give some intrinsic value to bitcoins.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
JohnDoe
Sr. Member
****
Offline Offline

Activity: 392



View Profile
May 28, 2011, 01:33:08 PM
 #69

Some people think that a separate system is better. I think combining DNS into Bitcoin's block chain (not into the Bitcoin software) is better because the incentive problem is already solved, it's easier to do, and it would give some intrinsic value to bitcoins.

Yeah, I know the opposing views on the subject. I'm asking purely from a technical standpoint if your system has any limitation that Namecoin doesn't have, thus making the existence of Namecoin still worthwhile even if bitDNS is implemented. I ask because I was planning on investing in Namecoin but I'm afraid that if it becomes a threat to Bitcoin (which I think it will if Bitcoin remains purely for financial transactions forever) then your system will be widely supported and implement, thus crashing the value of namecoins.
BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
May 28, 2011, 03:06:33 PM
 #70

How would Namecoin become a threat to Bitcoin?
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2506


View Profile
May 28, 2011, 04:59:49 PM
 #71

Yeah, I know the opposing views on the subject. I'm asking purely from a technical standpoint if your system has any limitation that Namecoin doesn't have, thus making the existence of Namecoin still worthwhile even if bitDNS is implemented.

BitDNS can't use Bitcoin's lightweight client mode, so in the future it will always be rare for people to run their own BitDNS resolvers. I don't know if Namecoin is set up to use client mode, either, though. BitDNS probably requires more resources, too, since servers need to scan all non-DNS transactions.

I think Namecoin is broken for other reasons, though:
https://forum.bitcoin.org/index.php?topic=7244.msg106438#msg106438

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
May 29, 2011, 06:34:43 PM
 #72

As most miners will forget old transactions, you would have to renew the transactions from time to time with BitDNS.
Am I right, theymos?
Maybe BitDNS clients could act like archivers.

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2506


View Profile
May 29, 2011, 07:50:55 PM
 #73

As most miners will forget old transactions, you would have to renew the transactions from time to time with BitDNS.
Am I right, theymos?

Yes. Our spec handles this by requiring DNS renewals. There are ways to handle it more elegantly, though (using multiple 0-value outputs, for example). The spec was written a while ago.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
May 29, 2011, 10:35:20 PM
 #74

There are ways to handle it more elegantly, though (using multiple 0-value outputs, for example).
Can you explain (or give a link on) the "multiple 0-value output" solution?

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2506


View Profile
May 30, 2011, 12:45:07 AM
 #75

An output with 0 value is valid, and these outputs can't be forgotten by the network until they are spent (which is also valid). So you can stuff all of the DNS data into several of those outputs.

When the bitDNS spec was written, having more than two outputs was not considered standard; therefore, it was difficult to get those transactions into blocks. Now they are standard.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
May 30, 2011, 06:41:12 AM
 #76

An output with 0 value is valid, and these outputs can't be forgotten by the network until they are spent (which is also valid). So you can stuff all of the DNS data into several of those outputs.

When the bitDNS spec was written, having more than two outputs was not considered standard; therefore, it was difficult to get those transactions into blocks. Now they are standard.

So people would put the DNS info in one output and would send bitcoins to the other to lock the transaction.
But in the demurrage fees thread has been said that miners can forget transactions even if they're not spent.

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2506


View Profile
May 30, 2011, 06:51:00 AM
 #77

But in the demurrage fees thread has been said that miners can forget transactions even if they're not spent.

That's only if >50% of the mining power agrees to do that. I doubt it will ever happen.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
May 30, 2011, 06:58:12 AM
 #78

But in the demurrage fees thread has been said that miners can forget transactions even if they're not spent.

That's only if >50% of the mining power agrees to do that. I doubt it will ever happen.

No.
The demurrage fee will be charged only if the network agrees, but miners can forget transactions without asking permission. This was an argument against the need of demurrage fees. Most miners will forget old transactions, and only "archivers" (specialized miners) will get the fees for transactions that contain an "old account" as input.

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2506


View Profile
May 30, 2011, 07:00:12 AM
 #79

No.
The demurrage fee will be charged only if the network agrees, but miners can forget transactions without asking permission. This was an argument against the need of demurrage fees. Most miners will forget old transactions, and only "archivers" (specialized miners) will get the fees for transactions that contain an "old account" as input.


I argued against that notion in the thread:

If miners with your rules don't have >50% of the network, you can't safely forget unspent transactions. If you are unable to find the transaction when it is needed for verification, you have only two bad choices:
- You can accept the transaction without checking it after it gets in a block. Every time one of these blocks ends up getting rejected by the majority of the network due to its invalid transaction, you will lose all of your hashing work since the last block. (This is even worse if you wait a few blocks before accepting it.)
- You can reject the transaction. Some important part of the network might accept the transaction, and you will be isolated from them unless you have more than 50% of the network.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
May 31, 2011, 11:51:26 AM
 #80

No.
The demurrage fee will be charged only if the network agrees, but miners can forget transactions without asking permission. This was an argument against the need of demurrage fees. Most miners will forget old transactions, and only "archivers" (specialized miners) will get the fees for transactions that contain an "old account" as input.


I argued against that notion in the thread:

If miners with your rules don't have >50% of the network, you can't safely forget unspent transactions. If you are unable to find the transaction when it is needed for verification, you have only two bad choices:
- You can accept the transaction without checking it after it gets in a block. Every time one of these blocks ends up getting rejected by the majority of the network due to its invalid transaction, you will lose all of your hashing work since the last block. (This is even worse if you wait a few blocks before accepting it.)
- You can reject the transaction. Some important part of the network might accept the transaction, and you will be isolated from them unless you have more than 50% of the network.

So you don't think miners will forget DNS transactions.
I think bitDNS could be good for bitcoin if there's a way to prevent DNS transactions to last forever. If bitDNS prevents miners from forgeting the DNS data by parking (or worse, burning) bitcoins in one of the two outputs (the other contains the DNS map), bitDNS service is taking a service from the bitcoin chain for "free" (everlasting storing). I don't think that's fair for the bitcoin network.
With demurrage, bitDNS would need to renew DNS transactions from time to time and would pay miners for the service (through demurrage or transaction fees).
Although I see the problems Namecoin can have, I think it would be interesting to develop the work sharing software for it, since it's the only other block chain in place right now.

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
Pages: « 1 2 3 [4] 5 6 »  All
  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!