On Wed, Sep 06, 2017 at 09:59:54PM -0400, Russell O'Connor via bitcoin-dev
wrote:
> The fast hash for internal nodes needs to use an IV that is not the
> standard SHA-256 IV. Instead needs to use some other fixed value, which
> should itself be the SHA-256 hash of some fixed string (e.g. the strin
After reading
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012194.html
I see that Adam is correct. Unfortunately this SF would make Felix's
confidential transactions
more complicated. The blinding and unblinding transactions would have to
be created with
minimal output value
This design purposefully does not distinguish leaf nodes from internal nodes.
That way it chained invocations can be used to validate paths longer than 32
branches. Do you see a vulnerability due to this lack of distinction?
> On Sep 6, 2017, at 6:59 PM, Russell O'Connor wrote:
>
> The fast ha
Thanks for the proposal. Aside from potential privacy implications of
revealing the derivation path for non BIP-44, 45, 49 HD nodes, this scheme
is superior to the alternate {x,y,z}pub idea. Since coin_type is part of
the path, the 'xpub' prefix may be shared across all coins if they so
choose. Thi
On 07.09.2017 00:29, Pavol Rusnak via bitcoin-dev wrote:
> The discussion about changing bip32 version bytes for SegWit got me
> thinking and I ended up with what I think is the best proposal:
>
> https://github.com/satoshilabs/slips/blob/master/slip-0032.md
>
> (It is hosted in SL repo for now
The fast hash for internal nodes needs to use an IV that is not the
standard SHA-256 IV. Instead needs to use some other fixed value, which
should itself be the SHA-256 hash of some fixed string (e.g. the string
"BIP ???" or "Fash SHA-256").
As it stands, I believe someone can claim a leaf node as
The pattern used by Felix Weiss' BIP for Confidential Transactions
depends on or is tidier with 0-value outputs.
Adam
On 7 September 2017 at 00:54, CryptAxe via bitcoin-dev
wrote:
> As long as an unspendable outputs (OP_RETURN outputs for example) with
> amount=0 are still allowed I don't see i
As long as an unspendable outputs (OP_RETURN outputs for example) with
amount=0 are still allowed I don't see it being an issue for anything.
On Sep 5, 2017 2:52 PM, "Jorge Timón via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> This is not a priority, not very important either.
I would like to propose two new script features to be added to the
bitcoin protocol by means of soft-fork activation. These features are
a new opcode, MERKLE-BRANCH-VERIFY (MBV) and tail-call execution
semantics.
In brief summary, MERKLE-BRANCH-VERIFY allows script authors to force
redemption to u
The discussion about changing bip32 version bytes for SegWit got me
thinking and I ended up with what I think is the best proposal:
https://github.com/satoshilabs/slips/blob/master/slip-0032.md
(It is hosted in SL repo for now, but if there is will, I would love to
have this added to BIP repo as
On Tue, Sep 5, 2017 at 10:51 PM, Jorge Timón via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Is there any reason or use case to keep allowing spendable outputs
> with null amounts in them?
>
Someone could have created a timelocked transaction that depends on a zero
value output.
Hi Luke,
thanks for your feedback.
I can try to coordinate with the OpenAssets group, but the base
requirements are completely different. For example, they are very far
from any form of plausible deniability.
Please tell me which problems are not solved technically, so that I can
try to fix
I think you could check out and coordinate with the OpenAssets proposal.
Your current draft also claims to solve a lot of problems that it doesn't
actually solve technically...
Luke
On Wednesday 06 September 2017 11:44:47 Luca Venturini via bitcoin-dev wrote:
> Hi everyone,
>
> I would like t
Hi Dan,
thank you for your feedback. Let me clarify that the plausible
deniability is a property of the protocol. If this will become a BIP,
and will be approved, there will be wallets that will manage tokens. In
the meantime, and in the future, it is important that a person with a
legacy bit
On 05/09/17 19:03, Luke Dashjr via bitcoin-dev wrote:
> I think it makes more sense to use a child number field for this purpose.
> It seems desirable to use the same seed for all different script formats...
If I were designing the serialization format today, I would drop the
fingerprint and expan
Hi everyone,
I would like to propose a standard protocol to manage tokens on top of
the Bitcoin blockchain.
The full text is enclosed and can be found here:
https://github.com/token21/token-protocol-specification
Any feedback will be appreciated.
Luca Venturini
---
Abstract
This
> In addition, consensus might be more difficult to reach on that
Let's move forward with the simplest solution that solves the problem and
achieves consensus! Version bytes {x,y,z} fits the bill.
On Wed, Sep 6, 2017 at 4:26 AM, Thomas Voegtlin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.
On 08/30/2017 12:24 AM, shiva sitamraju via bitcoin-dev wrote:
> What would happen if you recover a wallet using seed words ?
> 1. Since there is no difference in seed words between segwit/non
> segwit, the wallet would discover both m/44' and m/49' accounts
> 2. Note that we cannot ask the u
On 05.09.2017 21:00, Kabuto Samourai wrote:
>
> The Electrum approach is nice but may not go far enough, as xpub and zpub
> both list "P2PKH or P2SH." Why not expand the number of version prefixes to
> eliminate the ambiguity?
>
I agree that this would make sense if we had done it from the sta
19 matches
Mail list logo
