From: Dennison Bertram <dennison@dennisonbertram.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
Cc: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] is there a way to do bitcoin-staging?
Date: Sat, 15 Jun 2013 15:26:01 +0200 [thread overview]
Message-ID: <B19431AC-47B9-4BB2-9AA0-28C114556A01@dennisonbertram.com> (raw)
In-Reply-To: <CAKaEYhJfrszqC=7L9inkSH5+9nzUzRLx6Oq+C6bA+fDXXLfh8Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4746 bytes --]
Why use ripple and not just use the testnet?
The advantageous of allowing testnet to be used as an alt-coin are That Non standard transactions can be tested in a pseudo live environment where because the coins have some nominal value people are incentivized to try and steal and come up with clever ways of gamin the system. This sort of knowledge would be invaluable if non standard transactions are ever going to become a reality on main net.
It also allows developers a chance to develop in advance new technologies and services that currently won't run on bitcoin main net but might be enabled in the future at which point they can switch over to main net. Additionally without any development happening with non standard transactions as currently there is no economic incentive , there might be a strong argument to never bother enabling non standard transactions as the risk of doing so might not justify in many people's minds the benefits as if no one develops anything in advance most users might not find the theoretical possibilities worth the risk, thus permanently hobbling the full potential of satoshis idea. Rather if testnet were allowed to act as an alt coin something cool might be developed that the main net users might desire enough to overcome the inertia of the status quo.
Additionally it should be considered that the time in the future when non standard transactions might be enabled might be so far in the future when bitcoin has hit mass adoption and changing anything might require far more political negotiations between users and devs then currently. Meaning that perhaps much more proof of functionality and value as well as testing might e required.
Dennison
Sent from my iPhone
On Jun 15, 2013, at 1:18 PM, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>
>
>
> On 19 May 2013 15:23, Adam Back <adam@cypherspace.org> wrote:
>> Is there a way to experiment with new features - eg committed coins - that
>> doesnt involve an altcoin in the conventional sense, and also doesnt impose
>> a big testing burden on bitcoin main which is a security and testing risk?
>>
>> eg lets say some form of merged mine where an alt-coin lets call it
>> bitcoin-staging? where the coins are the same coins as on bitcoin, the
>> mining power goes to bitcoin main, so some aspect of merged mining, but no
>> native mining. and ability to use bitcoins by locking them on bitcoin to
>> move them to bitcoin-staging and vice versa (ie exchange them 1:1
>> cryptographically, no exchange).
>>
>> Did anyone figure anything like that out? Seems vaguely doable and
>> maybe productive. The only people with coins at risk of defects in a new
>> feature, or insufficiently well tested novel feature are people with coins
>> on bitcoin-staging.
>>
>> Yes I know about bitcoin-test this is not it. I mean a real live system,
>> with live value, but that is intentionally wanting to avoid forking bitcoins
>> parameters, nor value, nor mindshare dillution. In this way something
>> potentially interesting could move forward faster, and be les risky to the
>> main bitcoin network. eg particularly defenses against
>>
>> It might also be a more real world test test (after bitcoin-test) because
>> some parameters are different on test, and some issues may not manifest
>> without more real activity.
>>
>> Then also bitcoin could cherry pick interesting patches and merge them after
>> extensive real-world validation with real-money at stake (by early
>> adopters).
>
> Interesting idea. I wonder if ripple could be used to set up a transfer system between the 'main' and 'staging' systems ...
>
>>
>> Adam
>>
>> ------------------------------------------------------------------------------
>> AlienVault Unified Security Management (USM) platform delivers complete
>> security visibility with the essential security capabilities. Easily and
>> efficiently configure, manage, and operate all of your security controls
>> from a single console and one unified framework. Download a free trial.
>> http://p.sf.net/sfu/alienvault_d2d
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #2: Type: text/html, Size: 6315 bytes --]
next prev parent reply other threads:[~2013-06-15 13:26 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-19 13:23 [Bitcoin-development] is there a way to do bitcoin-staging? Adam Back
2013-05-19 15:08 ` Peter Vessenes
2013-05-20 6:34 ` Alan Reiner
2013-10-14 18:08 ` Adam Back
2013-10-14 18:21 ` Jeff Garzik
2013-11-21 20:22 ` coinscoins
2013-11-21 20:35 ` Melvin Carvalho
2013-11-21 21:11 ` [Bitcoin-development] bitcoin 1.x & 0.x in parallel (Re: is there a way to do bitcoin-staging?) Adam Back
2014-03-16 22:58 ` [Bitcoin-development] 2-way pegging " Adam Back
2014-03-16 23:22 ` Jorge Timón
2014-03-17 15:55 ` Gregory Maxwell
2013-10-14 18:43 ` [Bitcoin-development] is there a way to do bitcoin-staging? Michael Gronager
2013-10-14 20:20 ` Alan Reiner
2013-05-22 3:37 ` zooko
2013-05-22 4:12 ` Jeff Garzik
2013-05-20 7:12 ` Luke-Jr
2013-06-13 13:39 ` Adam Back
2013-06-14 19:20 ` Peter Todd
2013-06-14 20:50 ` Adam Back
2013-06-14 21:10 ` Luke-Jr
2013-06-14 21:25 ` Andreas Petersson
2013-06-15 0:09 ` Dennison Bertram
2013-06-15 1:57 ` Luke-Jr
2013-06-15 8:43 ` Dennison Bertram
2013-06-15 11:18 ` Melvin Carvalho
2013-06-15 13:26 ` Dennison Bertram [this message]
2013-06-16 15:46 ` Dennison Bertram
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=B19431AC-47B9-4BB2-9AA0-28C114556A01@dennisonbertram.com \
--to=dennison@dennisonbertram.com \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=melvincarvalho@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox