Re: [Bitcoin-development] is there a way to do bitcoin-staging?
That is true, but someone is already running it as a service on the blockchain itself. See: https://www.proofofexistence.com/ You can imagine similar services cropping up for things like torrents, sending btc tweets, etc. While I am not saying these things are particularly refined ideas in and of themselves, people should have an opportunity to play with them, and better testnet. Sent from my iPhone On Jun 15, 2013, at 3:57 AM, Luke-Jr l...@dashjr.org wrote: Timestamping (proof of existence) doesn't need a coin at all. Just collect all the hashes you need timestamped into a PoE merkle tree and add that to the merged mining MT. It's pretty simple and straightforward, just needs someone to implement it. On Saturday, June 15, 2013 12:09:09 AM Dennison Bertram wrote: Have your seen 'proof of existence'? It's basically a bitcoin notary service that proves a document existed before it gets inserted into the blockchain. While a good idea- you could argue that it's blockchain spam as well- especially if one were to adapt it to high volumes in the future for notarizing permanently things like tweets (for example) or combining it with something like colored coins. These are great ideas, but maybe better suited to a proto bitcoin without needing to fashion a brand new coin. -- 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
Re: [Bitcoin-development] Bitcoin addresses -- opaque or not
On 11 June 2013 17:29, Luke-Jr l...@dashjr.org wrote: On Tuesday, June 11, 2013 1:11:33 PM Melvin Carvalho wrote: For the sake of argument let's say that opaque means that you can tell nothing about the address by examining the characters. This is true or false based on CONTEXT. Obviously, an implementation of transaction handling (eg, wallets) needs to be able to translate addresses to and from what they represent. On the other hand, things like URI handlers do not (and should not) try to interpret the address as anything other than an arbitrary word (\w+). I think this statement may need to be justified. My understanding was that they are NOT opaque, and that if that has changed, it will invalidate much at least some wiki page, for examples at least some of the following would now be false: The wiki goes into much detail on how addresses work, which is not the concern of most software in the Bitcoin ecosystem, but may be of interest to humans and developers working on the one component that operates the black box that addresses are. snip These aren't FALSE, they are true at the moment, but subject to revision by newer standards. Got it. I also here that there is a LIKELY change from the base58 encoding ... when was this established? I stated (on IRC) that it was likely Bitcoin would change from the base58 encoding for addresses ... at some unspecified time in the future, to some unspecified new encoding that addressed known limitations of base58. What those changes will be, or when, are not all established at this time. The only currently-planned change to addresses (very loosely defined) is inclusion of the Payment Protocol URIs. But the point is that software developers shouldn't assume that addresses will remain base58 forever. Does this mean that people should not be investing in vanity addresses? Luke -- 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
Re: [Bitcoin-development] is there a way to do bitcoin-staging?
On 19 May 2013 15:23, Adam Back a...@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
Re: [Bitcoin-development] is there a way to do bitcoin-staging?
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 melvincarva...@gmail.com wrote: On 19 May 2013 15:23, Adam Back a...@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 -- 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
Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Jun 10, 2013 at 5:43 PM, Peter Todd p...@petertodd.org wrote: On Mon, Jun 10, 2013 at 01:25:05PM -0400, Alan Reiner wrote: to sign votes. Not only that, but it would require them to reveal their public key, which while isn't technically so terrible, large amounts of money intended to be kept in storage for 10+ years will prefer to avoid any exposure at all, in the oft-chance that QCs come around a lot earlier than we expected. Sure, the actual risk should be pretty much non-existent, but some of the most paranoid folks are probably the same ones who have a lot of funds and want 100.00% of the security that is possible. They will see this as wildly inconvenient. Solving that problem is pretty easy actually: just add a voting only public key to your outputs. Specifically you would have an opcode called something like OP_VOTE and put a code-path in your script that only executes for that specific key. Rather than OP_VOTE all you really need is the spending tx matches a template functionality that has been proposed for many other things. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRvLIoAAoJEEWCsU4mNhiPdtoIAKOeEwtWXw6fNKbSN0miGmcQ rHxgoEh5EAPsbs0hkCRpsVF7OjvmAftOn0Z0K0X/a4UFVHI64bvvGUg0brmAMnh3 ha4Mu/o7UwxwVJmmd6vpUw4smjbQrKbRzheXXQKUsDG2HOmRzMabFjJG1F20mPdg RobwYG49fKLcjAfqqTjOwSQE5KBjrugAUo32OUJWHZyNR5E3JYUXRHseHCfQ+1Fd VOQ8rWA4OaqwiX7PXdrNMWXc7Ab1dK7j9U7n4FgzCGIJjAek2dGbYLdrjftGKI+z Vje7o/RCJFLkJW5cC/wDoB/58XyJuvsvGOBAjvz01UrengUiapkhLRjKQwbveEo= =P0Hm -END PGP SIGNATURE- -- 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
