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
anyway
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 a
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 the
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 co
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
http:
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 wrote:
> Yes, it is expensive but possible to discover any funds associated with a
> seed, provided
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.
Th
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 act
On Sat, Apr 26, 2014 at 12:11 PM, Jorge Timón wrote:
> script IsStandard
> main IsStandardTx
> main AcceptToMemoryPool
>
Accept to memory pool could probably be replaced with an
IsStandard(scriptPubKey, scriptSig) method. The only "isStandard" part of
the process is the check inputs method (and
On Apr 26, 2014 6:43 AM, "Mike Hearn" 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 index at all
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 t
>
> 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
>
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 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 when m
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 inco
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:
BIP-0070:
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 and
>
> 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
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 PaymentReque
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:
>
> https://downlo
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 - Social
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 suf
>
> 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 w
On Sat, Apr 26, 2014 at 02:31:19PM -0400, Peter Todd wrote:
> 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 buy
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 defaul
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 wrote:
> Dear all,
>
> Still going through the payment protocol speci
>
> 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
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, some
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 share
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 eX
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 effectiv
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 no
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 height
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 b
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 judg
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 tha
I don't think there's an official definition of "SPV proof." I wasn't
trying to make a argument "from definition" (that would be fallacious!).
Rather I suspected that we had different concepts in mind and wanted to
check.
That said, I do think that the definition I gave matches how the term is
use
> Sample terminal output for latest Tails (0.23):
>
> amnesia@amnesia:~/linux-4765b8c-gitian-2d48b96/32$ ./bitcoin-qt
> Bus::open: Can not get ibus-daemon's address.
> IBusInputContext::createInputContext: no connection to ibus-daemon
> sendto: Operation not permitted
> Segmentation fault
> amnesia
41 matches
Mail list logo
