Do it. Someone will scream harm. The loudest voices screaming how it would
be harmful are doing the most harm.
The only way to know is build it, and test it. If the network breaks, then
it is better we find out sooner rather than later.
My only suggestion is call it 'bitstake' or something to
Proving that you can convince the economic majority that the
interpretation of existing blocks is in any way up for grabs would set a
dangerous precedent, and shake some people's faith in Bitcoin's overall
robustness and security (well, mine anyway.)
Hmm, then I think your faith needs to be
You don't get any money back, but you do get an angry shopkeeper chasing
you down the street / calling the police / blacklisting you from the
store.
If they could do that they'd just take the stolen property back and you
would have failed to spend your money twice. So this is by definition,
Does anyone use or plan to use the wallet structure part of the BIP32
document?
I suggest removing it from the document and maybe instead point at
BIP43. That new specification proposal just defines a purpose and
leaves everything else to the inventor of that purpose. The idea it that
over time a
My understanding is that sidechains require merged mining support and that
sidechains create no coinbase transactions themselves. When Bitcoin Core
supports the two-way peg then I would update my source code branch to
incorporate that or any other change that is released. Ideally, when
On 25/04/14 20:17, Mike Hearn wrote:
Proving that you can convince the economic majority that the
interpretation of existing blocks is in any way up for grabs would set a
dangerous precedent, and shake some people's faith in Bitcoin's overall
robustness and security (well,
On 25/04/14 20:19, Mike Hearn wrote:
You don't get any money back, but you do get an angry shopkeeper chasing
you down the street / calling the police / blacklisting you from the
store.
If they could do that they'd just take the stolen property back and you
would have failed
Oh dear.
For reasons that are perfectly reasonable we are close to losing any chance of
intra-client HD compatibility for BIP32 wallets.
In the next 12 months there will probably be collectively millions of users of
our new wallets. I don't want them to suffer from vendor lockin.
Can we not
When you have a *bitcoin* TXn buried under 100 blocks you can be damn
sure that money is yours - but only because the rules for interpreting
data in the blockchain are publicly documented and (hopefully)
immutable. If they're mutable then the PoW alone gives me no confidence
that the money
On Fri, Apr 25, 2014 at 7:53 AM, Jim jim...@fastmail.co.uk wrote:
Oh dear.
For reasons that are perfectly reasonable we are close to losing any chance
of intra-client HD compatibility for BIP32 wallets.
In the next 12 months there will probably be collectively millions of users
of our new
I generally agree, but I wonder how popular cloning wallets between devices
will be in future. Right now if someone wants to have a wallet shared
between Hive, blockchain.info and Bitcoin Wallet for Android, we just tell
them they're out of luck and they need to pick one, or split their funds up
This is a BIP to allow the spender to choose one of multiple standard
scripts to use for spending the output.
https://github.com/TierNolan/bips/blob/bip4x/bip-0045.mediawiki
This is required as part of the atomic cross chain transfer protocol. It
is required so that outputs can be retrieved, if
This one looks entirely useless (it cannot be made secure), and the assertion
that it is necessary for atomic cross-chain transfers seems unfounded and
probably wrong...
Luke
On Friday, April 25, 2014 6:49:37 PM Tier Nolan wrote:
As part of the atomic cross chain system, outputs need to be
I believe you meant to link here instead?
https://github.com/TierNolan/bips/blob/bip4x/bip-0046.mediawiki
This looks reasonable from a brief skim over, but does not define any use
cases (it mentions necessary for atomic cross chain transfers, but does not
explain how it is useful for that -
On Fri, Apr 25, 2014 at 8:18 PM, Luke-Jr l...@dashjr.org wrote:
This one looks entirely useless (it cannot be made secure)
The hash locking isn't to prevent someone else stealing your coin. Once a
user broadcasts a transaction with x in it, then everyone has access to x.
It is to release the
Dear Gavin, all,
Going over the payment protocol specifications, I've noticed that
there's appears to be a lack of specificity on handling of error states.
In most cases there are reasonably obvious solutions, however it would
seem positive to formalise processes to ensure consistency. I'm
On Fri, Apr 25, 2014 at 07:17:48PM +, Luke-Jr wrote:
I believe you meant to link here instead?
https://github.com/TierNolan/bips/blob/bip4x/bip-0046.mediawiki
This looks reasonable from a brief skim over, but does not define any use
cases (it mentions necessary for atomic cross
On Fri, Apr 25, 2014 at 8:17 PM, Luke-Jr l...@dashjr.org wrote:
I believe you meant to link here instead?
https://github.com/TierNolan/bips/blob/bip4x/bip-0046.mediawiki
Yeah, sorry.
This looks reasonable from a brief skim over, but does not define any use
cases (it mentions necessary
On Fri, Apr 25, 2014 at 8:58 PM, Peter Todd p...@petertodd.org wrote:
Keep in mind that P2SH redeemScripts are limited to just 520 bytes;
there's going to be many cases where more complex transactions just
can't be encoded in P2SH at all.
True. Having said that, this is just a change to
It is also useful for betting: an oracle will associate a hash with each
possible outcome, and when outcome is know, it will reveal a corresponding
preimage which will unlock the transaction.
This approach has several advantages over approach with multi-sig script:
1. oracle doesn't need to be
On Fri, Apr 25, 2014 at 1:02 PM, Tier Nolan tier.no...@gmail.com wrote:
This looks reasonable from a brief skim over, but does not define any use
cases (it mentions necessary for atomic cross chain transfers, but does
not
explain how it is useful for that - perhaps that belongs in another BIP
On Fri, Apr 25, 2014 at 11:06:37PM +0300, Alex Mizrahi wrote:
It is also useful for betting: an oracle will associate a hash with each
possible outcome, and when outcome is know, it will reveal a corresponding
preimage which will unlock the transaction.
This approach has several advantages
On Fri, Apr 25, 2014 at 1:14 PM, Peter Todd p...@petertodd.org wrote:
Actually I did some work looking at this problem a few months ago and
other than somewhat larger transactions it looks like implementing
oracles by having the oracle reveal ECC secret keys works better in
every case. Notably
On Friday, April 25, 2014 8:02:41 PM Tier Nolan wrote:
I don't think the cross chain system needs a BIP (except to justify this
one).
If cross chain transfer become popular, then it would be useful to ensure
that clients are interoperable, but first things first. If the
transactions aren't
Kristov,
On Wed, Apr 23, 2014 at 10:05 PM, Kristov Atlas kristovat...@gmail.com wrote:
On 04/22/2014 09:30 AM, Warren Togami Jr. wrote:
I see that the latest nightly build (thanks for that, Warren) is still not
compatible with Tails/Debian Squeeze. Is there still an intention to address
this
Yes. Tails 1.1, based on Wheezy, will be out on June 10:
https://tails.boum.org/contribute/calendar/
-Kristov Atlas
On 04/24/2014 08:18 AM, Wladimir wrote:
On Thu, Apr 24, 2014 at 10:25 AM, Wladimir laa...@gmail.com wrote:
On Thu, Apr 24, 2014 at 10:15 AM, Warren Togami Jr. wtog...@gmail.com
On Fri, Apr 25, 2014 at 10:09 PM, Kristov Atlas
aut...@anonymousbitcoinbook.com wrote:
Yes. Tails 1.1, based on Wheezy, will be out on June 10:
https://tails.boum.org/contribute/calendar/
Thanks!
Wladimir
--
Start
On Fri, Apr 25, 2014 at 9:26 PM, Luke-Jr l...@dashjr.org wrote:
They define standard for interoperability between
software. So, if you want nodes to relay these transactions, you need to
convince them, not merely write a BIP for the transaction format.
I agree with you in theory, each miner
On Fri, Apr 25, 2014 at 01:19:48PM -0700, Gregory Maxwell wrote:
On Fri, Apr 25, 2014 at 1:14 PM, Peter Todd p...@petertodd.org wrote:
Actually I did some work looking at this problem a few months ago and
other than somewhat larger transactions it looks like implementing
oracles by having
On Fri, Apr 25, 2014 at 10:14 PM, Peter Todd p...@petertodd.org wrote:
Along those lines, rather than doing up yet another format specific type
as Tier Nolan is doing with his BIP, why not write a BIP looking at how
the IsStandard() rules could be removed?
Removal of isStandard() would be
On github I commented on the BIP43 pull request about adding a
purpose of 0' which would correspond to the BIP32 recommended tree
structure for a single account wallet. (m/0'/chain) This will allow
for backwards compatibility and interoperability at least for existing
single account BIP32
Hi, I'm part of the team building copay https://github.com/bitpay/copay,
a multisignature P2SH HD wallet. We've been following the discussion
regarding standardizing the structure for branches both on this list and on
github (1 https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki,
2
I will just chime in that I've been working on a similar spec for Armory
to implement P2SH multisig and I came up with basically an identical
scheme. I think you covered most of what is needed. The one thing I
did differently was try to match the BIP 32 structure, by keeping the
original 3
33 matches
Mail list logo
