Topic: Gold collapsing. Bitcoin UP. - page 577. (Read 2032291 times)

Sorry, I was not clear.  The three items I listed are not alternative views of "sidechains", but three independent interaction mechanisms that would together comprise the "sidechains proposal".  (Or perhaps only 1+2, or 1+3 if 2 is superfluous once one has 3).

My understanding is that interactions of type 1 and 2 do not require a change in protocol or in the mining software, and in fact the bitcoin network cannot prevent them.  I suppose that interactions of type 3 (merged mining) would require restructuring of the BCN but no change in the BCP, and each miner would be free to choose which "sidechains" it wants to merge-mine.

Looks like you've been reduced to utter babble as best I can tell.  You must have had a peek at my question and it fused your couple dozen neurons together.

I'm sorry but these are not sidechains. In this scenario there exist only one blockchain, Bitcoin's, where the units are stored/assigned to wallets and not a secondary blockchain.

Exchanges for example have multiple wallets storing their clients' fund and an internal ledger of ownership that determines how much bitcoins every clients are storing.

You do not understand tech. :-)
 - 1 timestamp is equal to 100% MM
 - SC can use POS or login to central server ... I really do not need to share my blockchain with 7B unknown people. (I work together with only few people, and do shopping in less than 100 local shops )

Please let me try again to spread my ignorance about sidechains.  

Perhaps the sidechains project could be renamed "ways in which the bitcoin network (BCN) can interact with other internet services, and how the bitcoin protocol (BCP) would have to be modified to allow them".  These "other services" being the "sidechains".

Different people have different ideas of what sort of services would qualify for "sidechains", but let's not focus on that, focus instead on the interactions.  In order to exclude those variable assumptions, I will use the term "bitcoin-dependent service" (BDS) instead of "sidechain".

I gather that there are at least three kinds of interactions that are being discussed:

1. Bitcoins may be somehow be "moved"  from the BTC blockchain to the BDS, who would handle them in some way, and eventually "return" them to the BTC blockchain.  

   This kind of interaction does not seem to require any change in the BCP
   or the BCN, and in fact is routinely used by exchanges
   and other similar services.   It would suffice to move the coins
   to BTC addresses whose private keys are known and
   managed by the BDS. To "return" the coins, the BDS
   would have only to sign transactions out of those
   addresses.
  
   The BDS is free to manage the private keys of its
   addresses any way it sees fit. The BDS may allow its
   users to generate those addresses and keep the keys, or
   it may keep the keys in its central servers, or it may
   use the standard bitcoin multisig mechanism, etc.
  
   Thus the bitcoin network does not even need to know that
   the BDS exists; and this use of the BCN by the BDS is
   "fair use" by tradition and design.

2. The BDS may exploit the power of the BCN to secure its data structures against tampering or rewind

   This interaction too does not seem to require any
   additional mechanism in the BCN or the BCP. The BDS
   computes a SHA hash of the data it wants to secure, and
   sends to the BCN a transaction request containing that
   hash, possibly disguised.  Once the transaction is
   included in the bitcoin blockchain, anyone can detect if
   the original data is posted by the BDS and has
   not been tampered with.
  
   The BDS could do this operation at a rate higher than the
   bitcoin block rate, in which case each bitcoin block will
   contain several of those hashes. However, BDS users wishing
   to verify the hashes would still have to wait for the
   next bitcoin block, and possibly several blocks. These
   BDS hashes may be Merkle-chained and combined with any
   Byzantine generals mechanism by the BDS to achieve other
   kinds of security.  The BCN does not need to know that.
  
   One thing "morally wrong" with this solution is that it
   is "parasitic": the BDS would enjoy, almost for free,
   the same level of  security against tampering that would
   otherwise require a separate network with the same power
   of the BCN. The BDS would have to pay a transaction fee
   to the BCN for each stamp, but the fees currently are
   negligible compared to  the cost of the BCN. That is an
   unfortunate consequence of the BCP, that offloads
   the cost of the BCN to the the buyers of new bitcoins.
  
3. The BDS could use the full power of the BCN to implement its own PoW mechanisms by merged mining

   I don't understand enough of the discussion to tell
   whether this kind of interaction would provide more
   utility to the BDS than item 2 above, but let's suppose
   it does.  On the other hand, it would provide more
   incentives to the BCN, though which may be important
   if the rewards and fees derived from bitcoin mining
   were to dwindle.
  
   If I understood correctly, in the simplest scheme each
   node in the BCN would collect work requests from the
   affiliated BDSes. Each request would contain a hash of some
   arbitrary data that the BDS wants to secure. The node
   assembles a bitcoin block containing some bitcoin
   transactions and those BDS hashes, and then tries to solve
   the PoW puzzle for that block, as in the current
   protocol.

   Each work request would also specify an
   associated difficulty level and a reward value, either in
   bitcoins or in some tokens defined by the BDS. The bitcoin block
   itself would be one of those requests. As the node keeps
   working, its best solution will satisfy an increasing
   subset of the work requests. At any moment the node may
   decide to stop, collect the rewards it has won, and start
   all over, or continue trying to find a better solution.
   To claim the rewards the node sends the whole bitcoin
   block, with the best nonce, to each BDS in that subset.
  
   Is this a vaguely correct description of merged mining?
  
   If so, I suppose that some nontrivial mechanism/protocol
   would be needed to ensure that the affiliated BDSes pay
   the promised rewards, either in BTC or in their own
   tokens.  Would this require a change in the BCP?
  
   Merged mining would proveide an incentive for miners to service
   all BDSes that pay enough rewards.  The BDSes, in turn, would again
   get the power of the full BCN for a fraction of the cost.
   Indeed, merge mining would support a larger network than
   could be supported by bitcoin alone.  

   A BDS could get faster turnaround than bitcoin's (say 1 request
   every 10 seconds) by specifying a lower difficulty and
   proportionally lower reward.
  
   A possible "danger" that I see in this idea is that
   bitcoin itself would be just a BDS like any other
   (except that it dictates the format of the solved block,
   which the other BDSs would have to accept). Thus the
   miners may eventually abandon bitcoin if it is not
   profitable enough compared with the other BDSes.
  
Does this make any sense?

if that's how you view SC's then we don't need them.

actually i think you are incredibly confused since you're trying to secure all these supposed federated server SC's you claim are running with minimal MM'ing.  you should let me know where these are located so i can go perform a 51% and destroy them  

It doesn't change any of the conclusions I've made. We've talked about this many times and you've never bothered to clarify the concept so I doubt you understand any better than the rest of us. Your noise to signal ratio is so high.

Looks like you know how to improve MC so we can do 100k TPS. Please explain.
Do not respond with "Increase blocksize to 16 GB."

Yeah right. I think you are based on what you've said. Why did you confirm what JStolfi said and that is the concept we've gone over many times.

Id also like to see evidence of just who is MM'ing your federated servers that you claim are running.  

I though you meant one particular method of doing 100k tps was insecure, not the mere fact of achieving that rate.

Can you explain what about higher transaction rates inherently makes the blockchain less secure?

Yes, I can do math.

So 100k TPS means 2.25 TB / day of transaction data.

What's your point?

Because I started buying gold Jan 2014

Gold 1985 to date -

Wait, but why are you looking only at the last 4 year? If you look at, say, the last 40 years, the picture is quite different.

Wait, but why are you looking only at the last year?  If you look at, say, the last 4 years, the picture is quite different.
If that is the way we should look at the bitcoin price... 

In all honesty, that's not a particular challenge, but you'll be able to do it more efficiently than your competition if you have some of these scattered around the world:



but you probably won't be allowed to operate it for long without hooking up to one of these:



Actually, the real meat of the problem is related to network stuff which is harder to explain pictorially.