I'm not sure I understand why you need any special structure for this at
all. The way I'd do it is just use regular HD wallets for everyone, of the
regular form, and then swap the watching keys. Why do people need to be
given a cosigner index at all, given that they all have unique root keys
Le 26/04/2014 11:43, Mike Hearn a écrit :
I'm not sure I understand why you need any special structure for this at
all. The way I'd do it is just use regular HD wallets for everyone, of the
regular form, and then swap the watching keys. Why do people need to be
given a cosigner index at all,
I totally agree with gmaxwell here. The cost of interoperability is too
high. It would force us to freeze all features, and to require a broad
consensus everytime we want to add something new.
In addition, some partial level of compatibility would probably lead to
users not able to recover all
Maybe the solution is to have a defined way to import an unknown wallet?
This means that the gap space and a search ordering needs to be defined.
Given a blockchain and a root seed, it should be possible to find all the
addresses for that root seed.
The hierarchy that the wallet actually uses
Yes, it is expensive but possible to discover any funds associated with a seed,
provided there are set limits to:
1. gap of address use (e.g. 20)
2. depth of hierarchy (e.g. 6)
3. gap in use of parallel branches (e.g. 0)
I would pick the limits in brackets above.
Regards,
Tamas Blummer
Actually gap in parallel branches already fails with BIP64 as it starts with
m/64'/…. without having m/63'
Regards,
Tamas Blummer
http://bitsofproof.com
On 26.04.2014, at 12:59, Tamas Blummer ta...@bitsofproof.com wrote:
Yes, it is expensive but possible to discover any funds associated with
Does it make sense to implement a generic Policy interface (abstract
class) which StandardPolicy extends?
Maybe you can then implement a WhitelistPolicy,
ReplacebyFeeStandardPolicy, ReplacebyFeeWhitelistPolicy...
This would make it simpler for miners to implement their own policies
in general.
In the majority of high-value transactions the fact that funds will be
sent is known prior to when they actually are. For instance, if Alice is
to meet Bob in person to buy a car or sell some Bitcoins, both parties
know the transaction will probably happen in the near future some time
before it
On Apr 26, 2014 6:43 AM, Mike Hearn m...@plan99.net wrote:
I'm not sure I understand why you need any special structure for this at
all. The way I'd do it is just use regular HD wallets for everyone, of the
regular form, and then swap the watching keys. Why do people need to be
given a cosigner
On 26/04/14 01:28, Mike Hearn wrote:
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 main area of concern is handling unexpected problems while sending
the Payment message, or receiving the corresponding PaymentACK message.
For example, in case of a transport layer failure or non-200 HTTP status
code while sending the Payment message, what should the wallet software
do
On 04/26/2014 12:48 PM, Tier Nolan wrote:
Maybe the solution is to have a defined way to import an unknown wallet?
That is nonsense. There is no way how to import the wallet if you don't
know its structure.
Given a blockchain and a root seed, it should be possible to find all the
addresses
On Sat, Apr 26, 2014 at 2:24 PM, Pavol Rusnak st...@gk2.sk wrote:
On 04/26/2014 12:48 PM, Tier Nolan wrote:
Maybe the solution is to have a defined way to import an unknown wallet?
That is nonsense. There is no way how to import the wallet if you don't
know its structure.
I agree. Especially
It is very young in bitcoin's life. We don't know what features will
work out best, or need to be radically changed after initial
deployment in the field.
Loose coordination is good. Good ideas will spread on their own.
Users will demand compatibility with certain features, and fail to
care
Dear Gavin, Andreas,
I'd see standardisation (or at least suggested standards) for error
handling as positive for consistency of user experience. I do see what
you mean about over-specification, however.
Thanks for the feedback, I've taken the main points and created two pull
requests:
I think you're misunderstanding the point. The way you get IsStandard
changed is that you make an application-oriented BIP detailing the use
of some new standard transaction type (say, generalized hash-locked
transactions for atomic swaps). We then discuss that proposal for its
technical merits
PaymentRequests are limited to 50,000 bytes. I can't think of a reason why
Payment messages would need to be any bigger than that. Submit a pull
request to the existing BIP.
In future it might be nice to have images and things in the payment
requests, to make UIs look prettier. But with the
I'd be very cautious of security implications of embedding files into
the payment request. Even file formats one would presume safe, such as
images, have had security issues (i.e.
https://technet.microsoft.com/library/security/ms11-006 )
Longer term I was wondering about embedding the
On 04/25/2014 04:27 PM, Wladimir wrote:
Kristov,
I've modified the gitian build so that it builds against Qt 4.6
instead of Qt 4.8 in this pull request:
https://github.com/bitcoin/bitcoin/pull/4094
A test build of master with that pulls gitian descriptor is available:
What stops the buyer just always waiting to get their money back?
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet -
Please be aware that your emails are being spamfoldered by Gmail. This is
because Yahoo has enabled DMARC enforcement for mail sent from Yahoo and
that renders it incompatible with Sourceforge mailing lists.
There are two fixes:
1) Don't use Yahoo.
2) The real fix which is, we should stop using
On Sat, Apr 26, 2014 at 08:07:58PM +0200, Mike Hearn wrote:
What stops the buyer just always waiting to get their money back?
The seller won't hand over the goods of course until they have a valid
transaction signed by the buyer sending them the escrowed funds. (and
the nLockTime deadline is
Note how the mechanism I'm proposing is basically just a Jeremy
Spilman-style micropayment channel(1) used for a single payment; I
should have made that clear in my original post.
Right, that does make more sense. Yes, it's a good idea. The question is
whether wallet UI's can support it
Dear all,
Still going through the payment protocol specifications... the MIME
types in BIP0071 aren't IANA registered, and honestly look unlikely to
be accepted if they were submitted as-is.
Latest RFC on media type registration is RFC 6838, which very strictly
restricts what can go in the
Bitcoin is not a vendor, so I doubt that would work.
I doubt we should spend any time on this. The chance of a string collision
is extremely low. The current mime types are fine.
On Sat, Apr 26, 2014 at 10:15 PM, Ross Nicoll j...@jrn.me.uk wrote:
Dear all,
Still going through the payment
Let's assume we use one shared branch for everyone. Then two cosigners
could need a new receiving address at the same time, and get the next
unused address on that branch.
This is the part I struggle to understand. There is no shared branch
because each user/cosigner has their own unique seed
There's no need to be confrontational. I don't think anyone here objects
to the basic concept of proof-of-stake. Some people, myself included,
have proposed protocols which involve some sort of proof of stake
mechanism, and the idea itself originated as a mechanism for eliminating
checkpoints,
On 04/26/2014 04:33 PM, Mike Hearn wrote:
Let's assume we use one shared branch for everyone. Then two
cosigners could need a new receiving address at the same time, and
get the next unused address on that branch.
This is the part I struggle to understand. There is no shared
Am 2014-04-26 22:17, schrieb Mike Hearn:
Bitcoin is not a vendor, so I doubt that would work.
By my interpretation of RFC 6838, the Bitcoin Foundation or even Gavin
himself could register a vendor tree for Bitcoin. In the case of the
foundation registering, getting the subtree named vdn.bitcoin
Ah, I see now. Thanks. And actually now I re-read it, Manuel's explanation
was clear, it just didn't sink in for some reason.
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with
What about using fraud proofs? Your coinbase only matures if nobody publishes
proof that you signed a competing block.
Then something is at least at stake. When it's your chance to sign a block,
attempting to sign and publish more than one at the same height reliably
punishes you (you
I read the post in this threads about Compact SPV proofs via block
header commitments (archived e-mail in
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04318.html).
I was working on the same problem almost at the same time, which is
something that's becoming very common
That makes double-spends trivially easy: sign two blocks, withholding
one. Then at a later point in time reveal the second signed block
(demonstrating your own fraud) and force a reorg.
On 04/26/2014 04:44 PM, Gareth Williams wrote:
What about using fraud proofs? Your coinbase only matures if
Sergio,
First of all, let's define what an SPV proof is: it is a succinct
sequence of bits which can be transmitted as part of a non-interactive
protocol that convincingly establishes for a client without access to
the block chain that for some block B, B has an ancestor A at some
specified
This seems like splitting hairs, no? A block isn't a guarantee (it can
get orphaned). And as a user of bitcoin (as opposed to a miner), this
change cannot affect any payment you ever receive.
Some of the interpretation is already different for coinbase UTXO's
(need a valid height, locked for 100
Who said anything about a re-org? The original block remains valid, your block
reward is just zero, upon maturity, in light of a valid fraud proof.
ie. the coinbase confiscation that I was just arguing against in another
thread :P but of course here based on cryptographic proof, not human
El 26/04/2014 10:43 p.m., Mark Friedenbach escribió:
Sergio,
First of all, let's define what an SPV proof is: it is a succinct
sequence of bits which can be transmitted as part of a non-interactive
protocol that convincingly establishes for a client without access to
the block chain that for
37 matches
Mail list logo
