Re: [Bitcoin-development] New BIP32 structure for P2SH multisig wallets

[Mike Hearn]

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?


On Sat, Apr 26, 2014 at 12:27 AM, Manuel Araoz  wrote:

> Hi, I'm part of the team building 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 ,
> 2 , 
> 3,
> 4 , 
> 5).
> Soon, we realized the assumptions in the discussions were not true for a
> multisig hd wallet, so we wanted to share our current approach to that, to
> get feedback and see if we can arrive to a new standard (and possibly a new
> BIP)
>
> These are our assumptions:
>  - N parties want to share an m-of-n wallet.
>  - Each party must generate their master private keys independently.
>  - Use multisig P2SH for all addresses.
>  - Use BIP32 to derive public keys, then create a multisig script, and use
> the P2SH address for that.
>  - The address generation process should not require communicating with
> other parties. (Thus, all parties must be able to generate all public keys)
>  - Transaction creation + signing requires communication between parties,
> of course.
>
> -
>
> Following BIP43, we're be using:
>
>
> m / purpose' / *
>
> where *purpose* is the hardened derivation scheme based on the new BIP
> number.
> We then define the following levels:
>
>
> m / purpose' / cosigner_index / change / address_index
>
> Each level has a special meaning detailed below:
>
> *cosigner_index* : the index of
> the party creating this address. The indices can be determined
> independently by lexicographically sorting the master public keys of each
> cosigner.
>
> *change*: 0 for change, 1 for receive address.
>
> *address_index*: Addresses are numbered from index 0 in sequentially
> increasing manner. We're currently syncing the max used index for each
> branch between all parties when they connect, but we're open to considering
> removing the index sync and doing the more elegant used-address discovery
> via a gap limit, as discussed in 
> BIP44.
> We feel 20 might be too low though.
>
> *Wallet high-level description:*
> Each party generates their own extended master keypair and shares the
> extended purpose' public key with the others, which is stored encrypted.
> Each party can generate any of the other's derived public keys, but only
> his own private keys.
>
> *General address generation procedure:*
> When generating an address, each party can independently generate the N
> needed public keys. They do this by deriving the public key in each of the
> different trees, but using the same path. They can then generate the
> multisig script and the corresponding p2sh address. In this way, each path
> corresponds to an address, but the public keys for that address come from
> different trees.
>
> *Receive address case:*
> Each cosigner generates addresses only on his own branch. One of the n
> cosigners wants to receive a payment, and the others are offline. He knows
> the last used index in his own branch, because only he generates addresses
> there. Thus, he can generate the public keys for all of the others using
> the next index, and calculate the needed script for the address.
>
> *Example: *Cosigner #2 wants to receive a payment to the shared wallet.
> His last used index on his own branch is 4. Then, the path for the next
> receive address is m/$purpose/2/1/5. He uses this same path in all of the
> cosigners trees to generate a public key for each one, and from that he
> gets the new p2sh address.
>
> *Change address case:*
> Again, each cosigner generates addresses only on his own branch. One of
> the n cosigners wants to create an outgoing payment, for which he'll need a
> change address. He generates a new address using the same procedure as
> above, but using a separate index to track the used change addresses.
>
> *Example: *Cosigner #5 wants to send a payment from the shared wallet,
> for which he'll need a change address. His last used change index on his
> own branch is 11. Then, the path for the next change address is
> m/$purpose/5/0/12. He uses this same path in all of the cosigners trees to
> generate a public key for each one, and from that he gets the new p2sh
> address.
>
>
> *Transaction creation and signing:*
> When creating

Re: [Bitcoin-development] New BIP32 structure for P2SH multisig wallets

[Thomas Voegtlin]

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, given that they all have unique root keys
> anyway?
> 
> 

I agree with that.

Perhaps the only thing that needs to be standardized is the order of
public keys in the redeem script: I think they should be sorted, so that
the p2sh address does not depend on the order of pubkeys.


--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP32 "wallet structure" in use? Remove it?

[Thomas Voegtlin]

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 their funds when they enter their seed in
another wallet. That is not acceptable, and should be avoided.




Le 25/04/2014 17:46, Gregory Maxwell a écrit :
> 
> I don't believe that wallet interoperability at this level is possible
> in general except as an explicit compatibility feature. I also don't
> believe that it is a huge loss that it is so.
> 
> The structure of the derivation defines and constrains functionality.
> You cannot be structure compatible unless you have the same features
> and behavior with respect to key management.  To that extent that
> wallets have the same features, I agree its better if they are
> compatible— but unless they are dead software they likely won't keep
> the same features for long.
> 
> Even if their key management were compatible there are many other
> things that go into making a wallet portable between systems; the
> handling of private keys is just one part:  a complete wallet will
> have other (again, functionality specific) metadata.
> 
> I agree that it would be it would be possible to support a
> compatibility mode where a wallet has just a subset of features which
> works when loaded into different systems, but I'm somewhat doubtful
> that it would be widely used. The decision to use that mode comes at
> the wrong time— when you start, not when you need the features you
> chose to disable or when you want to switch programs. But the obvious
> thing to do there is to just specify that a linear chain with no
> further branching is that mode: then that will be the same mode you
> use when someone gives you a master public key and asks you to use it
> for reoccurring changes— so at least the software will get used.
> 
> Compatibility for something like a recovery tool is another matter,
> and BIP32 probably defines enough there that with a bit of extra data
> about how the real wallet worked that recovery can be successful.
> 
> Calling it "vendor lock in" sounds overblown to me.  If someone wants
> to change wallets they can transfer the funds— manual handling of
> private keys is seldom advisable, and as is they're going to lose
> their metadata in any case.  No one expects to switch banks and to
> keep their account records at the new bank. And while less than
> perfect, the price of heavily constraining functionality in order to
> get another result is just too high.
> 
> --
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP32 "wallet structure" in use? Remove it?

[Tier Nolan]

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 could be anything.


On Sat, Apr 26, 2014 at 11:36 AM, Thomas Voegtlin  wrote:

> 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 their funds when they enter their seed in
> another wallet. That is not acceptable, and should be avoided.
>
>
>
>
> Le 25/04/2014 17:46, Gregory Maxwell a écrit :
> >
> > I don't believe that wallet interoperability at this level is possible
> > in general except as an explicit compatibility feature. I also don't
> > believe that it is a huge loss that it is so.
> >
> > The structure of the derivation defines and constrains functionality.
> > You cannot be structure compatible unless you have the same features
> > and behavior with respect to key management.  To that extent that
> > wallets have the same features, I agree its better if they are
> > compatible— but unless they are dead software they likely won't keep
> > the same features for long.
> >
> > Even if their key management were compatible there are many other
> > things that go into making a wallet portable between systems; the
> > handling of private keys is just one part:  a complete wallet will
> > have other (again, functionality specific) metadata.
> >
> > I agree that it would be it would be possible to support a
> > compatibility mode where a wallet has just a subset of features which
> > works when loaded into different systems, but I'm somewhat doubtful
> > that it would be widely used. The decision to use that mode comes at
> > the wrong time— when you start, not when you need the features you
> > chose to disable or when you want to switch programs. But the obvious
> > thing to do there is to just specify that a linear chain with no
> > further branching is that mode: then that will be the same mode you
> > use when someone gives you a master public key and asks you to use it
> > for reoccurring changes— so at least the software will get used.
> >
> > Compatibility for something like a recovery tool is another matter,
> > and BIP32 probably defines enough there that with a bit of extra data
> > about how the real wallet worked that recovery can be successful.
> >
> > Calling it "vendor lock in" sounds overblown to me.  If someone wants
> > to change wallets they can transfer the funds— manual handling of
> > private keys is seldom advisable, and as is they're going to lose
> > their metadata in any case.  No one expects to switch banks and to
> > keep their account records at the new bank. And while less than
> > perfect, the price of heavily constraining functionality in order to
> > get another result is just too high.
> >
> >
> --
> > Start Your Social Network Today - Download eXo Platform
> > Build your Enterprise Intranet with eXo Platform Software
> > Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> > Get Started Now And Turn Your Intranet Into A Collaboration Platform
> > http://p.sf.net/sfu/ExoPlatform
> > ___
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> --
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP32 "wallet structure" in use? Remove it?

[Tamas Blummer]

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://bitsofproof.com

On 26.04.2014, at 12:48, Tier Nolan  wrote:

> 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 could be anything.



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP32 "wallet structure" in use? Remove it?

[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  wrote:

> 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://bitsofproof.com
> 
> On 26.04.2014, at 12:48, Tier Nolan  wrote:
> 
>> 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 could be anything.
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP - Hash Locked Transaction

[Jorge Timón]

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.
The following functions (maybe more) could become methods of Policy:

script IsStandard
main IsStandardTx
main AcceptToMemoryPool

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Eliminating double-spends with two-party self-escrow for high value transactions

[Peter Todd]

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 actually does. Existing escrow solutions already take
advantage of this fact; for instance Localbitcoins provides sellers the
ability to escrow their funds with Localbitcoins prior to when the funds
are released to the buyer.

However with nLockTime a third-party escrow agent is *not* required.
Instead prior to Alice sending the funds to the escrow address, she has
Bob sign a refund transaction that unlocks at some time in the future.
Generally the transaction does go through, and Alice and Bob sign a
second transaction sending the funds to Bob. Sometimes it doesn't, and
Alice either gets Bob to sign a transaction sending the funds back to
her, or in the worst-case, just waits for the timeout to elapse.

Note that this technique can be used in addition to a third-party escrow
agent - the third-party then only plays a role in exceptional
circumstances.


Implementation sketch: Mycelium Local Trader


The Mycelium Local Trader(1) is functionality built into the Mycelium
Android wallet that helps users trade cash for bitcoins by finding
traders in their local area. To attempt to prevent double-spends it uses
"transaction confidence", a technique that attempts to determine how
many nodes on the network a given transaction has propagated too. Of
course this technique is fragile and vulnerable to many attacks.

Local Trader already has pre-meetup buyer to seller communication built
in. Within the application the buyers and sellers communicate and
negotiate the amount and price of the Bitcoins prior to arranging a
meeting place. We can extend this to self-escrow as follows:

1) Alice publishes her offer to sell Bitcoins for cash.

2) Bob replies to the offer with an unused pubkey, B.

3) Alice creates tx1 paying a CHECKMULTISIG scriptPubKey spendable by
   the co-operation of her pubkey, A, and Bob's pubkey, B. She signs tx1
   but does not publish it.

4) Alice creates tx_refund which is nLockTime'd until some point in the
   future and returns the output of tx1 to an address she controls. Note
   how tx_refund depends on the signed tx1.

5) Alice sends Bob the hash of tx_refund for him to sign. As Bob does
   not have the actual transaction Bob can't selectivly target tx1 for a
   transaction mutability attack. Bob is free to sign the hash as the
   pubkey has never been used before. Note that the tx_refund hash
   Bob signs should be calculated with SIGHASH_SINGLE|SIGHASH_ANYONECANPAY
   to allow Alice to, for instance, add fees.

6) Bob replies with the signature.

7) Alice checks the validity of the signature, and if satisfied,
   publishes tx1 to the network.

8) Alice and/or Bob travel to actually meet in person. If this takes
   time t the probability of a block being generated during that
   time is P=1-e^(1/10mins*t) For instance, with a travel time of 30
   minutes we get 95% success, 1 hour 99.75%, and 2 hours 99.999%
   success.

9a) If the cash is handed over successfully Alice signs a
SIGHASH_SINGLE|SIGHASH_ANYONECANPAY signature for the tx1 output
spending the funds to a scriptPubKey specified by Bob and gives that
signature to him.

10a) Bob creates a transaction spending the output, adds Alice's
 signature to it, and finally signs it himself. He broadcasts this
 transaction to the network, completing the transfer.

9b) If the cash is NOT handed over successfully Alice and Bob can either
co-operate to cancel the transaction immediately, sending the
escrowed funds back to Alice, or Alice can wait until the timeout to
use the signature she had Bob prepare in advance.


While the above is relatively complex, from the user's point of view the
process is quite similar to how Mycelium already works:

Alice: Publish offer -> Accept offer  -> Travel -> Release funds
Bob:   Browse ads-> Reserve funds -> Travel -> Accept

The chief difference being that the funds for the transaction have been
reserved, and if the transaction does not go through, will not be
unlocked without the co-operation of the other party, or the expiration
of the timeout.


Transaction Malleability


While the above is fairly secure if transactions aren't being mutated
en-mass, better protections would be desirable. First of all adding a
third-party escrow to the two-party escrow is a prudent last ditch
measure to ensure that if malleability is an issue the third-party can
release locked funds manually; note how SIGHASH_SINGLE is used as
opposed to SIGHASH_NONE to prevent that third-party from having access
to the funds. Secondly a future soft-fork such as Pieter Wuille's
BIP62(2) can eliminate malleability. In particular, a soft-fork that
en

Re: [Bitcoin-development] BIP - Hash Locked Transaction

[Tier Nolan]

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 AcceptToMemoryPool calls
IsStandardTx).

The standard script methods at the moment are also used for extracting
addresses for wallet management.

The standard script check could be made easier if it just checked for
pattern matches.

Is there any objections to this change, other than it doesn't go far enough?
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] New BIP32 structure for P2SH multisig wallets

[Manuel Araoz]

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, given that they all have unique root keys
anyway?

I tried to explain that here:

The reason for using separate branches for each cosigner is we don't want
two of them generating the same address and receiving simultaneous payments
to it. The ideal case is that each address receives at most one payment,
requested by the corresponding cosigner.

To clarify, the problem the cosigner_index is trying to solve is race
conditions when receiving payments. Remember that we can't assume all
cosigners to be online at all times. 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. They then each
pass the same address to their payers, and we can get two payments to the
same address. Monitoring balances is not enough in this case because a
cosigner can never know when the others are generating a new address.
Separating branches and having each cosigner only use one branch makes this
problem go away.
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

[Gareth Williams]

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 PoW alone gives me no confidence
> that the money is really mine, and we're left with a much less useful
> system. This should be more sacred than the 21m limit.
> 
> 
> Well, I think we should avoid the term "sacred" - nothing is sacred
> because we're not building a religion here, we're engineering a tool.

Are you sure there isn't room for just a touch of "religion"? :) As you
state below, all that protects my money from confiscation is strong
group consensus that it's mine - "a social rule, not a mathematical one."

Everything ultimately balances on that. People being a little bit
"religious" about following the protocol faithfully are the linchpin of
Bitcoin security, not PoW.


> Consider a world in which 1 satoshi is too valuable to represent some
> kinds of transactions, so those transactions stop happening even though
> we all agree they're useful. The obvious solution is to change the rules
> so there can be 210 million coins and 10x everyones UTXOs at some
> pre-agreed flag day. We probably wouldn't phrase it like that, it's
> easier for people to imagine what's happening if it's phrased as "adding
> more places after the decimal point" or something, but at the protocol
> level coins are represented using integers, so it'd have to be
> implemented as a multiply.

Agree.


> Would this be a violation of the social contract? A violation of all
> that is sacred? I don't think so, it'd just be sensible engineering and
> there'd be strong consensus for that exactly because 21 million /is/ so
> arbitrary. If all balances and prices multiply 100-fold overnight, no
> wealth is reallocated which would be the /actual/ violation of the
> social contract: we just get more resolution for setting prices.

Wholeheartedly agree. "21 million" is just shorthand for the
preservation of artificial scarcity. No rational person could argue that
what you described violates the social contract.

I do see what you're driving at - that there exists a situation where it
would be justified to change the interpretation of data in existing blocks.

But, please consider: if I controlled a single UTXO worth 1% of the
total money supply before your change, the network would still recognise
that I control a single UTXO worth 1% of the total money supply after
your change. So you haven't really changed the interpretation of
existing blocks at all there. It's just semantics :)

Contrast this with invalidating a coinbase before maturity, which
clearly has a very real impact. At the point the vote passes, you're ***
sidestepping the PoW mechanism and rewriting the meaning of an existing,
validated block ***.


> So. The thing that protects your money from confiscation is not proof of
> work. PoW is just a database synchronisation mechanism. The thing that
> protects your money from confiscation is a strong group consensus that
> theft is bad. But that's a social rule, not a mathematical rule.

Agree. That's my whole point :)

I recognise my security is in the hands of the users (the economic
majority.) Tomorrow they could all decide to patch their nodes to
reallocate my UTXOs, and there's not a damn thing I could do about it,
PoW and private keys notwithstanding. I must simply trust that they will
not do this.

So we can have:
1. "Neutral Bitcoin", where everyone is committed to prevention of theft
by following a simple set of mathematical rules which treat all
validated blocks as equal.
Or:
2. "Political Bitcoin", where everyone is committed to prevention of
theft based on human judgements, and the contents of some validated
blocks are more equal than others.

I recognise that the latter allows for a lot of flexibility in combating
fraud, but with (substantial) due respect, it isn't Bitcoin.

-Gareth



signature.asc
Description: OpenPGP digital signature
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072)

[Gavin Andresen]

>
> 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 next? Is it safe to re-send the Payment message? I'd propose that for
> any transport failure or 500 status code, the client retries after a
> delay (suggested at 30-60 seconds). For 400 status codes, the request
> should not be repeated, and as such the user should be alerted and a
> copy of the Payment message saved to be resent later.
>

Why does error handling have to be standardized?

I generally think that wallet software should be free to do whatever gives
the user the best experience, so I'm in favor of restricting BIPs to things
that must be standardized so that different implementations inter-operate.


> For 300 (redirect and similar) status codes, is it considered safe to
> follow redirects? I think we have to, but good to make it clear in the
> specification.
>

Referencing whatever RFCs defines how to fetch URLs would be the best way
to do this. Submit a pull request.


>
> On the merchant's side; I think it would be useful for there to be
> guidance for handling of errors processing Payment messages. I'd suggest
> that Payment messages should have a fixed maximum size to avoid merchant
> systems theoretically having to accept files of any size; 10MB would
> seem far larger than in any way practical, and therefore a good maximum
> size?


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.


> A defined maximum time to wait (to avoid DDoS via connection
> holding) might be useful too, although I'd need to do measurements to
> find what values are tolerable.
>

Implementation detail that doesn't belong in the spec, in my humble opinion.


> I would like to have the protocol state that merchant systems should
> handle repeatedly receiving the same Payment message, and return an
> equivalent (if not identical) PaymentACK to each. This is important in
> case of a network failure while the client is sending the Payment
> message, as outlined above.
>

I think this should be left to implementations to work out.


> Lastly, I'm wondering about potential timing issues with transactions;
> if a merchant system wants to see confirmation of a transaction before
> sending a PaymentACK...


 not a good idea. The user should get feedback right away. Poking a
"pay now" button and then waiting more than a second or three to get "your
payment has been received and is being processed" is terrible UI.


-- 
--
Gavin Andresen
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP32 "wallet structure" in use? Remove it?

[Pavol Rusnak]

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 for that root seed.

Unless the keyspace is almost infinite because:

> The hierarchy that the wallet actually uses could be anything.

-- 
Best Regards / S pozdravom,

Pavol Rusnak 

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP32 "wallet structure" in use? Remove it?

[Pieter Wuille]

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 multiple chains are combined (multisig) for
P2SH usage, defining things like a gap limit becomes impossible
without knowing some metadata.

However, perhaps it is possible to define something like "BIP44
import-compatible", meaning that the application doesn't actually
support all of BIP44 features, but does guarantee not losing any funds
when imported? Similar things could be done for other purpose types.

-- 
Pieter

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP32 "wallet structure" in use? Remove it?

[Jeff Garzik]

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 incompatibilities in other features.

Tight interoperability at this stage is too confining.




On Fri, Apr 25, 2014 at 11:46 AM, Gregory Maxwell  wrote:
> On Fri, Apr 25, 2014 at 7:53 AM, Jim  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 wallets. I don't want them to suffer from vendor lockin.
>>
>> Can we not agree on a lowest common denominator that we agree to support ?
>> An "HD Basic" if you like.
>> For entry level users we can keep things simple and any "HD Basic" bitcoin 
>> will be fully interoperable.
>>
>> Sure, if you use anything fancy you'll be locked in to a particular wallet 
>> but a lot of users just want somewhere safe to put their bitcoin, spend it 
>> and receive it.
>>
>> I appreciate standising everything is very difficult (if not impossible) but 
>> if we don't have a minimum of interoperability I think we'll do our users a 
>> disservice.
>
> I don't believe that wallet interoperability at this level is possible
> in general except as an explicit compatibility feature. I also don't
> believe that it is a huge loss that it is so.
>
> The structure of the derivation defines and constrains functionality.
> You cannot be structure compatible unless you have the same features
> and behavior with respect to key management.  To that extent that
> wallets have the same features, I agree its better if they are
> compatible-- but unless they are dead software they likely won't keep
> the same features for long.
>
> Even if their key management were compatible there are many other
> things that go into making a wallet portable between systems; the
> handling of private keys is just one part:  a complete wallet will
> have other (again, functionality specific) metadata.
>
> I agree that it would be it would be possible to support a
> compatibility mode where a wallet has just a subset of features which
> works when loaded into different systems, but I'm somewhat doubtful
> that it would be widely used. The decision to use that mode comes at
> the wrong time-- when you start, not when you need the features you
> chose to disable or when you want to switch programs. But the obvious
> thing to do there is to just specify that a linear chain with no
> further branching is that mode: then that will be the same mode you
> use when someone gives you a master public key and asks you to use it
> for reoccurring changes-- so at least the software will get used.
>
> Compatibility for something like a recovery tool is another matter,
> and BIP32 probably defines enough there that with a bit of extra data
> about how the real wallet worked that recovery can be successful.
>
> Calling it "vendor lock in" sounds overblown to me.  If someone wants
> to change wallets they can transfer the funds-- manual handling of
> private keys is seldom advisable, and as is they're going to lose
> their metadata in any case.  No one expects to switch banks and to
> keep their account records at the new bank. And while less than
> perfect, the price of heavily constraining functionality in order to
> get another result is just too high.
>
> --
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072)

[Ross Nicoll]

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: https://github.com/bitcoin/bips/pull/54/
BIP-0072: https://github.com/bitcoin/bips/pull/55/

Please tell me if these need any further work.

Ross

On 26/04/14 14:23, Gavin Andresen wrote:
>> 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 next? Is it safe to re-send the Payment message? I'd propose that for
>> any transport failure or 500 status code, the client retries after a
>> delay (suggested at 30-60 seconds). For 400 status codes, the request
>> should not be repeated, and as such the user should be alerted and a
>> copy of the Payment message saved to be resent later.
>>
> Why does error handling have to be standardized?
>
> I generally think that wallet software should be free to do whatever gives
> the user the best experience, so I'm in favor of restricting BIPs to things
> that must be standardized so that different implementations inter-operate.
>
>
>> For 300 (redirect and similar) status codes, is it considered safe to
>> follow redirects? I think we have to, but good to make it clear in the
>> specification.
>>
> Referencing whatever RFCs defines how to fetch URLs would be the best way
> to do this. Submit a pull request.
>
>
>> On the merchant's side; I think it would be useful for there to be
>> guidance for handling of errors processing Payment messages. I'd suggest
>> that Payment messages should have a fixed maximum size to avoid merchant
>> systems theoretically having to accept files of any size; 10MB would
>> seem far larger than in any way practical, and therefore a good maximum
>> size?
>
> 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.
>
>
>> A defined maximum time to wait (to avoid DDoS via connection
>> holding) might be useful too, although I'd need to do measurements to
>> find what values are tolerable.
>>
> Implementation detail that doesn't belong in the spec, in my humble opinion.
>
>
>> I would like to have the protocol state that merchant systems should
>> handle repeatedly receiving the same Payment message, and return an
>> equivalent (if not identical) PaymentACK to each. This is important in
>> case of a network failure while the client is sending the Payment
>> message, as outlined above.
>>
> I think this should be left to implementations to work out.
>
>
>> Lastly, I'm wondering about potential timing issues with transactions;
>> if a merchant system wants to see confirmation of a transaction before
>> sending a PaymentACK...
>
>  not a good idea. The user should get feedback right away. Poking a
> "pay now" button and then waiting more than a second or three to get "your
> payment has been received and is being processed" is terrible UI.
>
>


--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP - Selector Script

[Mark Friedenbach]

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 reach consensus about the best way to do, for
example, cross-chain atomic swaps. It is then implemented.

So please, focus on some BIP(s) detailing applications of hash-locked
transactions, and we will engage more constructively -- I promise that I
will as cross-chain atomic swaps scratch my itch as well.

On 04/25/2014 01:48 PM, Tier Nolan wrote:
> On Fri, Apr 25, 2014 at 9:26 PM, Luke-Jr  > 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 could decide their inclusion
> rules for themselves.
> 
> In practice, if the reference client is updated, then most miners will
> accept those transactions.  In addition, it would eventually propagate
> to alt-coins (or at least the supported ones).
> 
> I could simply submit the changes as a pull request for the reference
> client, but I was hoping that by doing it this way, it would increase
> the odds of it being accepted.
>  
> 
> Defining a BIP for cross-chain trading would be one way to do that.
> 
> 
> I don't think it quite requires the same coordination in the short
> term.  I could write up the sequence as an info BIP.
> 
> The malleability "issue" has been known for years.
> I wouldn't expect any special effort made to fix it...
> 
> 
> It is possible to tweak the protocol so that it still works.  However,
> it means that 3rd parties are required (that could go in the BIP too).
>  
> 
> There is some ongoing discussion of a softfork to basically redo the
> Script
> language entirely, but it will take quite a bit of time and
> development before
> we'll see it in the wild.
> 
> 
> Implementing multi-P2SH gets a lot of the benefits of MAST, in terms of
> efficiency.
>  
> 
> 
> Luke
> 
> P.S. Did the BIP editor assign these numbers? If not, best to keep them
> numberless until assigned, to avoid confusion when people Google the
> real BIP
> 44 and 45...
> 
> 
> Not yet, but that is just my personal repo.  I did email gmaxwell, but
> he said that they can't be assigned until some discussion has happened.
>  
> I take your point that the name appears in the link though, so could
> cause issues with searching.
> 
> 
> 
> --
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 
> 
> --
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> 
> 
> 
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072)

[Mike Hearn]

>
> 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 current version 50kb
should be plenty indeed.
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072)

[Ross Nicoll]

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 PaymentRequest into web
pages directly via the  tag, which could eliminate need for
BIP0072 and potentially improve user interface integration that way.
Obviously this would require browser plugins, however.

Ross

On 26/04/14 18:36, Mike Hearn wrote:
>> 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 current version 50kb
> should be plenty indeed.
>


--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Compatibility Bitcoin-Qt with Tails

[Kristov Atlas]

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://download.visucore.com/bitcoin/linux-4765b8c-gitian-2d48b96.tar.gz
> https://download.visucore.com/bitcoin/linux-4765b8c-gitian-2d48b96.tar.gz.sig
>
> These bitcoin-qt executables *should* work on Debian Squeeze / Tails
> Linux. Let me know if it is the case.
>
>
Hey Wladimir,

Thanks for building this binary. The initial problem with Qt was 
resolved, and I was able to load the GUI that chooses my datadir. After 
choosing the default datadir, however, it segfaulted.

The segfault came after the usual message that I get when running 
Bitcoin Core in Tails, which is the "sendto: Operation not permitted" 
message since Core will not be able to connect to the internet without 
going through Tails' Tor SOCKS proxy. When I specify the SOCKS proxy 
through the command-line, I get a brief flash of the GUI before it 
segfaults again.

The "Bus::open" and "IBusInputContext::createInputContext" messages are 
atypical and might be related to the segfault.

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@amnesia:~/linux-4765b8c-gitian-2d48b96/32$ ./bitcoin-qt
Segmentation fault
amnesia@amnesia:~/linux-4765b8c-gitian-2d48b96/32$ ./bitcoin-qt 
-proxy=127.0.0.1:9050
Segmentation fault


-Kristov

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Eliminating double-spends with two-party self-escrow for high value transactions

[Mike Hearn]

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, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proof-of-Stake branch?

[Mike Hearn]

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 Sourceforge mailing list
software

Fundamentally all Yahoo is saying with their policy is that rewriting of
mails sent from their service is not allowed. This is a highly reasonable
policy, akin to forbidding SSL MITM attacks, but for email.

There are several ways to be compatible with this policy: unfortunately
sf.net doesn't do any of them.




On Fri, Apr 25, 2014 at 12:35 PM, Stephen Reed wrote:

> 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
> sidechains can work with PoW Bitcoin, then those same sidechains should
> work without any changes with PoS Bitcoin running in my testnet.
>
> I will be examining PPC, NXT and whitepapers for ideas that I can
> implement in such a way as the result can be called Bitcoin. The only
> difference would be the absence of wasteful Proof-of-Work, and the presence
> of mining rewards distributed to full nodes in proportion to the amount of
> bitcoin each is willing to expose to the network. Coin age is a good
> starting point. A reference peer-to-peer pool developed by me would be
> responsible for fairly distributing the mining rewards as daily dividend
> payments to PoS full node pool members.
>
> In a few days, I plan to establish a Proof-of-Stake Bitcoin project thread
> in the Project Development sub-forum of Bitcointalk. We can continue the
> technical discussion there, starting with a list of principles.
>
>
> Stephen L. Reed
> Austin, Texas, USA
> 512.791.7860
>
> On Friday, April 25, 2014 4:42 AM, Jeffrey Paul  wrote:
>
> Are proof of stake blockchains compatible with the sidechain/two-way peg
> system invented by Greg (and maybe others - reports unclear)?
> >
> >http://letstalkbitcoin.com/blockchain-2-0-let-a-thousand-chains-blossom/
> >
> >It's my limited understanding that any sidechains in such a model are
> somewhat cryptographically tied to the PoW system that bitcoin's chain
> uses. I am seriously curious if alternate decentralized consensus
> algorithms (proof of execution, proof of stake, et c) are compatible with
> the sidechain universe as envisioned.
> >
> >Perhaps someone with a deeper technical understanding could explain how,
> if so, or if my incomplete hunch (that alternate consensus algorithms
> cannot retain compatibility with Bitcoin in a two way peg model) is correct.
> >
> >These sorts of "alternate universe" altcoin experiments with different
> proof models take on a different cost/benefit ratio if they can't ever
> interoperate as sidechains, which is why I'm curious.
> >
> >Best,
> >-jp
> >
> >--
> >Jeffrey Paul   +1 (312) 361-0355
> >5539 AD00 DE4C 42F3 AFE1 1575 0524 43F4 DF2A 55C2
> >
> >
> >> On 25.04.2014, at 00:33, Troy Benjegerdes  wrote:
> >>
> >> This also might be an interesting application of the side
> >> chains concept Peter Todd has discussed.
> >
> >
>
>
> --
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Eliminating double-spends with two-party self-escrow for high value transactions

[Peter Todd]

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 sufficiently far away that the probability of
not being able to get the transaction mined in time is low)

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.

1) 
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg02028.html

-- 
'peter'[:-1]@petertodd.org
69ea3b64f8b627bc81c8981ce80e95edf81cd356ad04e1a0


signature.asc
Description: Digital signature
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Eliminating double-spends with two-party self-escrow for high value transactions

[Mike Hearn]

>
> 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 without being overly complex. We'd be
asking users to take extra steps to work around unintuitive limitations of
the protocol. Products that do that too much tend to get left for something
that "just works". But there may be a slick way to present it.
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Eliminating double-spends with two-party self-escrow for high value transactions

[Peter Todd]

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 buyer sending them the escrowed funds. (and
> the nLockTime deadline is sufficiently far away that the probability of
> not being able to get the transaction mined in time is low)
> 
> 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.
> 
> 1) 
> http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg02028.html

I swear, I'm getting alzheimers or something. This and stealth addresses
is now the second time I've totally forgotten I had just read an idea a
week prior:

Reddit user RubenSomsen, ten days ago:

"I would really like it if Mycelium allowed me to temporarily lock my
bitcoins in a 2-of-2 transaction with a potential buyer (of course with
nlocktime back to myself) so the network can start confirming the
transaction before we even meet."
-http://www.reddit.com/r/Bitcoin/comments/236k5d/mycelium_local_trader_is_now_available/cgtxede

Better explanation than mine too for someone wanting a quick intro.

-- 
'peter'[:-1]@petertodd.org
38a12e1b8bc9562cddc5cfa24ba7c418f4b945f6b1677e41


signature.asc
Description: Digital signature
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] BIP0071 media type registration with IANA

[Ross Nicoll]

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 default "application/" namespace.
Essentially they'd want it to be an ISO standard or similar. There are
vendor namespaces, which look much more feasible (this is how Powerpoint
2007 ended up as
"application/vnd.openxmlformats-officedocument.presentationml.presentation"),
but would be quite a dramatic change to BIP0071.

What's the general feeling on this? Personally I'm in favour of
following the registration process, so register a Bitcoin vendor
namespace with IANA, then allocate MIME types such as:

application/vnd.bitcoin.payment.request
application/vnd.bitcoin.payment.payment
application/vnd.bitcoin.payment.ack

Thoughts?

Ross

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP0071 media type registration with IANA

[Mike Hearn]

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 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 default "application/" namespace.
> Essentially they'd want it to be an ISO standard or similar. There are
> vendor namespaces, which look much more feasible (this is how Powerpoint
> 2007 ended up as
>
> "application/vnd.openxmlformats-officedocument.presentationml.presentation"),
> but would be quite a dramatic change to BIP0071.
>
> What's the general feeling on this? Personally I'm in favour of
> following the registration process, so register a Bitcoin vendor
> namespace with IANA, then allocate MIME types such as:
>
> application/vnd.bitcoin.payment.request
> application/vnd.bitcoin.payment.payment
> application/vnd.bitcoin.payment.ack
>
> Thoughts?
>
> Ross
>
>
> --
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] New BIP32 structure for P2SH multisig wallets

[Mike Hearn]

>
> 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 and thus unique key
hierarchy, right? What you described above could be an issue if all
co-signers shared the same seed but then the scheme wouldn't work.
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proof-of-Stake branch?

[Mark Friedenbach]

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, something which is very much on topic and of concern to
many here.

The problems come when one tries to *replace* proof-of-work mining with
proof-of-stake "mining." You encounter problems related to the fact that
with proof-of-stake nothing is actually at stake. You are free to sign
as many different forks as you wish, and worse have incentive to do so,
because whatever fork does win, you want it to be yours. In the worst
case this results in double-spends at will, and in the best case with
any of the various proposed protections deployed, it merely reduces to
proof-of-work as miners grind blocks until they find one that names them
or one of their sock puppets as the signer of the next block.

I sincerely doubt you will find a solution to this, as it appears to be
a fundamental issue with proof-of-stake, in that it must leverage an
existing mechanism for enforced scarcity (e.g. proof-of-work) in order
to work in a consensus algorithm. Is there some solution that you have
in mind for this?

Mark

On 04/25/2014 12:33 AM, Troy Benjegerdes wrote:
> 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 clearly differentiate
> it from Bitcoin. This also might be an interesting application of the side
> chains concept Peter Todd has discussed.
> 
> On Thu, Apr 24, 2014 at 04:32:15PM -0700, Stephen Reed wrote:
>> Hello all.
>>
>> I understand that Proof-of-Stake as a replacement for Proof-of-Work is a 
>> prohibited yet disputed change to Bitcoin Core. I would like to create a 
>> Bitcoin branch that provides a sandboxed testbed for researching the best 
>> PoS implementations. In the years to come, perhaps circumstances might 
>> arise, such as shifting of user opinion as to whether PoS should be moved 
>> from the prohibited list to the hard-fork list.
>> -
>>
>> A poll I conducted today on bitcointalk, 
>> https://bitcointalk.org/index.php?topic=581635.0 with an attention-grabbing 
>> title suggests some minority support for Bitcoin Proof-of-Stake. I invite 
>> any of you to critically comment on that thread.
>>
>> "Annual 10% bitcoin dividends can be ours if  Proof-of-Stake full nodes 
>> outnumber existing Proof-of-Work full nodes by three-to-one. What is your 
>> choice?"
>>
>> "I do not care or do not know enough." - 5 (16.1%) 
>> "I would download and run the existing Proof-of-Work program to fight the 
>> change." - 14 (45.2%) 
>> "I would download and run the new Proof-of-Stake program to favor the 
>> change. " - 12 (38.7%) 
>> Total Voters: 31 
>> -
>>
>> Before I branch the source code and learn the proper way of doing things in 
>> this community, I ask you simply if creating the branch is harmful? My goal 
>> is to develop, test and document PoS, while exploring its vulnerabilities 
>> and fixing them in a transparent fashion.
>>
>> Thanks for taking a bit of your time to read this message.
> 
> 
> 
> 

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] New BIP32 structure for P2SH multisig wallets

[Alan Reiner]

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 branch
> because each user/cosigner has their own unique seed and thus unique
> key hierarchy, right? What you described above could be an issue if
> all co-signers shared the same seed but then the scheme wouldn't work.
>
Consider two people with phones, using 2-of-2,  using private seeds k1
and k2.  Every address generated by either party is:

2-of-2(K1/a'/b/c, K2/a'/b/c) 

So for any a, b and c you end up with a 2-of-2 address.  The
seeds/branches will not be used for single-sig receiving... it's always
a multisig 2-of-2.  In fact it behaves much like a regular wallet, you
give an a, b, and c value, and you get an address -- it's just that this
wallet always gives you a P2SH multisig address.

The problem is that if you follow BIP32 in the the most obvious way,
both devices will generate receiving addresses along the last index, 
i.e.   K/a'/b/0, K/a'/b/1, K/a'/b/2,...  If I am at one store and my
wife at another, we might both give out 2-of-2(K1/a'/b/382, K2/a'/b/382)
at the same time not realizing the other one has distributed that
address.  There's not a good way to coordinate the devices well enough
to avoid it.  But we don't have to.

The solution is to use two separate branches -- both phones will
follow/watch both branches, but each only only distributes payment
addresses from one such branch.

The original proposal here suggested adding a level to the tree using
the "cosigner index" as a branch point for doing this...  I recommended
simply having 2*N values for "b", so that each participant has a
receiving line and change line, that won't conflict with other devices. 
However, all devices will still watch all 2*N branches to know the total
balance of the wallet, and will use UTXOs from those branches when
constructing spending transactions/proposals.
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP0071 media type registration with IANA

[Jannis Froese]

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 should be 
no problem.

> I doubt we should spend any time on this. The chance of a string 
> collision is extremely low. The current mime types are fine.
It's mostly about the good feeling of having followed the rules and 
proper procedures, I doubt that there is a difference in practice

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] New BIP32 structure for P2SH multisig wallets

[Mike Hearn]

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 eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proof-of-Stake branch?

[Gareth Williams]

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 effectively waste your chance and receive no reward.)

I can't remember who I saw discussing this idea. Might have been Vitalik 
Buterin?

On 27 April 2014 6:39:28 AM AEST, Mark Friedenbach  wrote:
>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, something which is very much on topic and of concern to
>many here.
>
>The problems come when one tries to *replace* proof-of-work mining with
>proof-of-stake "mining." You encounter problems related to the fact
>that
>with proof-of-stake nothing is actually at stake. You are free to sign
>as many different forks as you wish, and worse have incentive to do so,
>because whatever fork does win, you want it to be yours. In the worst
>case this results in double-spends at will, and in the best case with
>any of the various proposed protections deployed, it merely reduces to
>proof-of-work as miners grind blocks until they find one that names
>them
>or one of their sock puppets as the signer of the next block.
>
>I sincerely doubt you will find a solution to this, as it appears to be
>a fundamental issue with proof-of-stake, in that it must leverage an
>existing mechanism for enforced scarcity (e.g. proof-of-work) in order
>to work in a consensus algorithm. Is there some solution that you have
>in mind for this?
>
>Mark
>
>On 04/25/2014 12:33 AM, Troy Benjegerdes wrote:
>> 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 clearly
>differentiate
>> it from Bitcoin. This also might be an interesting application of the
>side
>> chains concept Peter Todd has discussed.
>> 
>> On Thu, Apr 24, 2014 at 04:32:15PM -0700, Stephen Reed wrote:
>>> Hello all.
>>>
>>> I understand that Proof-of-Stake as a replacement for Proof-of-Work
>is a prohibited yet disputed change to Bitcoin Core. I would like to
>create a Bitcoin branch that provides a sandboxed testbed for
>researching the best PoS implementations. In the years to come, perhaps
>circumstances might arise, such as shifting of user opinion as to
>whether PoS should be moved from the prohibited list to the hard-fork
>list.
>>> -
>>>
>>> A poll I conducted today on bitcointalk,
>https://bitcointalk.org/index.php?topic=581635.0 with an
>attention-grabbing title suggests some minority support for Bitcoin
>Proof-of-Stake. I invite any of you to critically comment on that
>thread.
>>>
>>> "Annual 10% bitcoin dividends can be ours if  Proof-of-Stake full
>nodes outnumber existing Proof-of-Work full nodes by three-to-one. What
>is your choice?"
>>>
>>> "I do not care or do not know enough." - 5 (16.1%) 
>>> "I would download and run the existing Proof-of-Work program to
>fight the change." - 14 (45.2%) 
>>> "I would download and run the new Proof-of-Stake program to favor
>the change. " - 12 (38.7%) 
>>> Total Voters: 31 
>>> -
>>>
>>> Before I branch the source code and learn the proper way of doing
>things in this community, I ask you simply if creating the branch is
>harmful? My goal is to develop, test and document PoS, while exploring
>its vulnerabilities and fixing them in a transparent fashion.
>>>
>>> Thanks for taking a bit of your time to read this message.
>> 
>> 
>> 
>> 
>
>--
>Start Your Social Network Today - Download eXo Platform
>Build your Enterprise Intranet with eXo Platform Software
>Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>Get Started Now And Turn Your Intranet Into A Collaboration Platform
>http://p.sf.net/sfu/ExoPlatform
>___
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development maili

[Bitcoin-development] About Compact SPV proofs via block header commitments

[Sergio Lerner]

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 nowadays..

The proposal starts with the following claim:

"In simple payment verification (SPV) proofs it is currently necessary
that every intervening block header be provided between two blocks in
order to establish both connectivity and proof of work."

I think this is false. Let's first assume that at the time of an attack
we're connected only to the attacker (no honest nodes). An
non-interactive SPV proof needs to prove that a transaction belongs to
the best chain because creating a counterfeit proof cost more than the
amount of money involved in the proof. Suppose that the proof consist at
least of a block header and a merkle branch to the claimed transaction.

Do the proof need connectivity with the last checkpoint known by the
verifier? (here checkpoint is any block known for sure to be in the best
chain)

Not much, because connectivity only proves that the proof was not
pre-computed before the checkpoint. Only if the checkpoint is very near
(say 10 blocks back) it brings some practical evidence that the attacker
did not have much time to prepare an attack.
 
Do the proof need to know the interleaving proof-of-work?

Not much. If the distance between blocks is less than 2016 blocks, then
the difficulty may have change only by a factor of 4. Currently
difficult adjustments are much lower (I suppose that about 1.1 or so).
Then one can assume that the proof block target difficulty is almost the
same as the last known difficulty if the block distance is less than
2016. If the distance is more, we just load all the interleaving
re-target blocks to detect the actual difficulty.

Do the proof need to have a certain number of  confirmations?

Yes and no, because this is the only evidence that the prover has either
spend money in creating the fake block or took a genuine block.
The cost of creating a fake block can be approximated as the minimum of:
- The current reward of the block (since currently fees are much lower
than the reward)
- The average block fees (when the reward goes to zero)
- The minimum electricity cost of mining the block.

As time passes one could assume that the electricity cost of mining will
approach the other two. 

But there is the problem of parallel synchronized attacks: if an
attacker can reuse the same fake SPV proof to attack several victims,
then the reward for cheating increases proportionally but the cost stays
the same.
For instance, if 6 confirmations are required, and each block can hold
2000 transactions, the attacker can find 2000 victims and re-use the
same 6 block chain to "prove" payments to 2000 victims. Also the cost of
mining 6 blocks can be amortized by mining 7, and attacking in the first
two 4000 victims, etc...

Any scheme than relies on non-interactive SPV proofs will fail if
Bitcoin will scale up-to a point where victims can be easily found and
synchronized.
So I think one should assume that at least one peer is honest...

But if we assume than during the attack least one peer is honest, then
we could directly ask every peer to give us the blocks of their
best-chains at the same heights of the presented proof.  No back-links
are necessary.  If any peer shows a different block, then we should
carefully detect which of the two nodes is the one attacking us and ban
it, by downloading the best-chain headers from the last checkpoint to
the block of the proof.  This would be rare so I don't see when the
back-links can help.

The use case should be:

==Use cases==

For SPV client that has just come online asks peers what is the last block 
height/time. 
If a peer replies with an old block, then that peer is still downloading the 
block-chain and it's ignored.
For the remaining peers, the client starts asking for parents blocks until all 
parents agree (this is the last common parent). 
If (U)TxO hash-tree commitments are available, then the wallet is updated using 
this data from the common parent block. 

At the same time the client retrieves compact non-interactive 
proofs-of-inclusion (possibly orphan) for its transactions 
without having to download every intervening block header.

Is there something wrong with this?
 
Best regards,
Sergio.

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin

Re: [Bitcoin-development] Proof-of-Stake branch?

[Mark Friedenbach]

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 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 effectively waste your chance and receive no reward.)
> 
> I can't remember who I saw discussing this idea. Might have been Vitalik 
> Buterin?
> 
> On 27 April 2014 6:39:28 AM AEST, Mark Friedenbach  wrote:
>> 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, something which is very much on topic and of concern to
>> many here.
>>
>> The problems come when one tries to *replace* proof-of-work mining with
>> proof-of-stake "mining." You encounter problems related to the fact
>> that
>> with proof-of-stake nothing is actually at stake. You are free to sign
>> as many different forks as you wish, and worse have incentive to do so,
>> because whatever fork does win, you want it to be yours. In the worst
>> case this results in double-spends at will, and in the best case with
>> any of the various proposed protections deployed, it merely reduces to
>> proof-of-work as miners grind blocks until they find one that names
>> them
>> or one of their sock puppets as the signer of the next block.
>>
>> I sincerely doubt you will find a solution to this, as it appears to be
>> a fundamental issue with proof-of-stake, in that it must leverage an
>> existing mechanism for enforced scarcity (e.g. proof-of-work) in order
>> to work in a consensus algorithm. Is there some solution that you have
>> in mind for this?
>>
>> Mark
>>
>> On 04/25/2014 12:33 AM, Troy Benjegerdes wrote:
>>> 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 clearly
>> differentiate
>>> it from Bitcoin. This also might be an interesting application of the
>> side
>>> chains concept Peter Todd has discussed.
>>>
>>> On Thu, Apr 24, 2014 at 04:32:15PM -0700, Stephen Reed wrote:
 Hello all.

 I understand that Proof-of-Stake as a replacement for Proof-of-Work
>> is a prohibited yet disputed change to Bitcoin Core. I would like to
>> create a Bitcoin branch that provides a sandboxed testbed for
>> researching the best PoS implementations. In the years to come, perhaps
>> circumstances might arise, such as shifting of user opinion as to
>> whether PoS should be moved from the prohibited list to the hard-fork
>> list.
 -

 A poll I conducted today on bitcointalk,
>> https://bitcointalk.org/index.php?topic=581635.0 with an
>> attention-grabbing title suggests some minority support for Bitcoin
>> Proof-of-Stake. I invite any of you to critically comment on that
>> thread.

 "Annual 10% bitcoin dividends can be ours if  Proof-of-Stake full
>> nodes outnumber existing Proof-of-Work full nodes by three-to-one. What
>> is your choice?"

 "I do not care or do not know enough." - 5 (16.1%) 
 "I would download and run the existing Proof-of-Work program to
>> fight the change." - 14 (45.2%) 
 "I would download and run the new Proof-of-Stake program to favor
>> the change. " - 12 (38.7%) 
 Total Voters: 31 
 -

 Before I branch the source code and learn the proper way of doing
>> things in this community, I ask you simply if creating the branch is
>> harmful? My goal is to develop, test and document PoS, while exploring
>> its vulnerabilities and fixing them in a transparent fashion.

 Thanks for taking a bit of your time to read this message.
>>>
>>>
>>>
>>>
>>
>> --
>> Start Your Social Network Today - Download eXo Platform
>> Build your Enterprise Intranet with eXo Platform Software
>> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> Get Started Now And Turn Your Intranet Into A Collaboration Platform
>> http://p.sf.net/sfu/ExoPlatform
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
Start Your Social Networ

Re: [Bitcoin-development] About Compact SPV proofs via block header commitments

[Mark Friedenbach]

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 and work distance back, and the cost of creating a
false proof is at least as much work as it claims to represent.

The previous email you quote demonstrates how with additional backlink
commitments this can be done in logarithmic space: using an average of
log(N) headers to construct an SPV proof from block A to block B where N
is the height differential. It can be verified without access to the
block chain or other peers. Note that with back links the cost of
creating a fraudulent SPV proof is the same as 51% attacking bitcoin
itself. The protocol you outlined does not have this property.

Other than that, honestly I'm not really sure what you are trying to
accomplish. An interactive proof is does not meet the above requirements
and is not usable for the driving application of two-way pegs. Maybe you
had some other application in mind? I've looked at your SmartSPV
proposal, but fail to see how it doesn't reduce to simply blind trust in
your view of the network from your peers. SPV proofs on the other hand
put an economic cost to fraud.

On 04/26/2014 06:08 PM, Sergio Lerner wrote:
> 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 nowadays..
> 
> The proposal starts with the following claim:
> 
> "In simple payment verification (SPV) proofs it is currently necessary
> that every intervening block header be provided between two blocks in
> order to establish both connectivity and proof of work."
> 
> I think this is false. Let's first assume that at the time of an attack
> we're connected only to the attacker (no honest nodes). An
> non-interactive SPV proof needs to prove that a transaction belongs to
> the best chain because creating a counterfeit proof cost more than the
> amount of money involved in the proof. Suppose that the proof consist at
> least of a block header and a merkle branch to the claimed transaction.
> 
> Do the proof need connectivity with the last checkpoint known by the
> verifier? (here checkpoint is any block known for sure to be in the best
> chain)
> 
> Not much, because connectivity only proves that the proof was not
> pre-computed before the checkpoint. Only if the checkpoint is very near
> (say 10 blocks back) it brings some practical evidence that the attacker
> did not have much time to prepare an attack.
>  
> Do the proof need to know the interleaving proof-of-work?
> 
> Not much. If the distance between blocks is less than 2016 blocks, then
> the difficulty may have change only by a factor of 4. Currently
> difficult adjustments are much lower (I suppose that about 1.1 or so).
> Then one can assume that the proof block target difficulty is almost the
> same as the last known difficulty if the block distance is less than
> 2016. If the distance is more, we just load all the interleaving
> re-target blocks to detect the actual difficulty.
> 
> Do the proof need to have a certain number of  confirmations?
> 
> Yes and no, because this is the only evidence that the prover has either
> spend money in creating the fake block or took a genuine block.
> The cost of creating a fake block can be approximated as the minimum of:
> - The current reward of the block (since currently fees are much lower
> than the reward)
> - The average block fees (when the reward goes to zero)
> - The minimum electricity cost of mining the block.
> 
> As time passes one could assume that the electricity cost of mining will
> approach the other two. 
> 
> But there is the problem of parallel synchronized attacks: if an
> attacker can reuse the same fake SPV proof to attack several victims,
> then the reward for cheating increases proportionally but the cost stays
> the same.
> For instance, if 6 confirmations are required, and each block can hold
> 2000 transactions, the attacker can find 2000 victims and re-use the
> same 6 block chain to "prove" payments to 2000 victims. Also the cost of
> mining 6 blocks can be amortized by mining 7, and attacking in the first
> two 4000 victims, etc...
> 
> Any scheme than relies on non-interactive SPV proofs will fail if
> Bitcoin will scale up-to a point where victims can be easily found and
> synchronized.
> So I think one should assume that at least one peer is honest...
> 
> But if we assume than during the attack least one peer is honest, then
> we could directly ask every peer to give us the blocks of their
> best-chains at the same heights of the presented proof.  No back-links
> are necessary.  If any peer s

Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

[Christophe Biocca]

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 blocks). Anyone expecting them to
behave like any other UTXO will get bitten by one of those subtleties
(MtGox's withdrawals had issues with exactly this, IIRC).

On Sat, Apr 26, 2014 at 8:15 AM, Gareth Williams  wrote:
> 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 PoW alone gives me no confidence
>> that the money is really mine, and we're left with a much less useful
>> system. This should be more sacred than the 21m limit.
>>
>>
>> Well, I think we should avoid the term "sacred" - nothing is sacred
>> because we're not building a religion here, we're engineering a tool.
>
> Are you sure there isn't room for just a touch of "religion"? :) As you
> state below, all that protects my money from confiscation is strong
> group consensus that it's mine - "a social rule, not a mathematical one."
>
> Everything ultimately balances on that. People being a little bit
> "religious" about following the protocol faithfully are the linchpin of
> Bitcoin security, not PoW.
>
>
>> Consider a world in which 1 satoshi is too valuable to represent some
>> kinds of transactions, so those transactions stop happening even though
>> we all agree they're useful. The obvious solution is to change the rules
>> so there can be 210 million coins and 10x everyones UTXOs at some
>> pre-agreed flag day. We probably wouldn't phrase it like that, it's
>> easier for people to imagine what's happening if it's phrased as "adding
>> more places after the decimal point" or something, but at the protocol
>> level coins are represented using integers, so it'd have to be
>> implemented as a multiply.
>
> Agree.
>
>
>> Would this be a violation of the social contract? A violation of all
>> that is sacred? I don't think so, it'd just be sensible engineering and
>> there'd be strong consensus for that exactly because 21 million /is/ so
>> arbitrary. If all balances and prices multiply 100-fold overnight, no
>> wealth is reallocated which would be the /actual/ violation of the
>> social contract: we just get more resolution for setting prices.
>
> Wholeheartedly agree. "21 million" is just shorthand for the
> preservation of artificial scarcity. No rational person could argue that
> what you described violates the social contract.
>
> I do see what you're driving at - that there exists a situation where it
> would be justified to change the interpretation of data in existing blocks.
>
> But, please consider: if I controlled a single UTXO worth 1% of the
> total money supply before your change, the network would still recognise
> that I control a single UTXO worth 1% of the total money supply after
> your change. So you haven't really changed the interpretation of
> existing blocks at all there. It's just semantics :)
>
> Contrast this with invalidating a coinbase before maturity, which
> clearly has a very real impact. At the point the vote passes, you're ***
> sidestepping the PoW mechanism and rewriting the meaning of an existing,
> validated block ***.
>
>
>> So. The thing that protects your money from confiscation is not proof of
>> work. PoW is just a database synchronisation mechanism. The thing that
>> protects your money from confiscation is a strong group consensus that
>> theft is bad. But that's a social rule, not a mathematical rule.
>
> Agree. That's my whole point :)
>
> I recognise my security is in the hands of the users (the economic
> majority.) Tomorrow they could all decide to patch their nodes to
> reallocate my UTXOs, and there's not a damn thing I could do about it,
> PoW and private keys notwithstanding. I must simply trust that they will
> not do this.
>
> So we can have:
> 1. "Neutral Bitcoin", where everyone is committed to prevention of theft
> by following a simple set of mathematical rules which treat all
> validated blocks as equal.
> Or:
> 2. "Political Bitcoin", where everyone is committed to prevention of
> theft based on human judgements, and the contents of some validated
> blocks are more equal than others.
>
> I recognise that the latter allows for a lot of flexibility in combating
> fraud, but with (substantial) due respect, it isn't Bitcoin.
>
> -Gareth
>
>
> --
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Y

Re: [Bitcoin-development] Proof-of-Stake branch?

[Gareth Williams]

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 judgement.

On 27 April 2014 11:22:07 AM AEST, Mark Friedenbach  wrote:
>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 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 effectively waste your chance and receive no
>reward.)
>> 
>> I can't remember who I saw discussing this idea. Might have been
>Vitalik Buterin?
>> 
>> On 27 April 2014 6:39:28 AM AEST, Mark Friedenbach 
>wrote:
>>> 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, something which is very much on topic and of concern to
>>> many here.
>>>
>>> The problems come when one tries to *replace* proof-of-work mining
>with
>>> proof-of-stake "mining." You encounter problems related to the fact
>>> that
>>> with proof-of-stake nothing is actually at stake. You are free to
>sign
>>> as many different forks as you wish, and worse have incentive to do
>so,
>>> because whatever fork does win, you want it to be yours. In the
>worst
>>> case this results in double-spends at will, and in the best case
>with
>>> any of the various proposed protections deployed, it merely reduces
>to
>>> proof-of-work as miners grind blocks until they find one that names
>>> them
>>> or one of their sock puppets as the signer of the next block.
>>>
>>> I sincerely doubt you will find a solution to this, as it appears to
>be
>>> a fundamental issue with proof-of-stake, in that it must leverage an
>>> existing mechanism for enforced scarcity (e.g. proof-of-work) in
>order
>>> to work in a consensus algorithm. Is there some solution that you
>have
>>> in mind for this?
>>>
>>> Mark
>>>
>>> On 04/25/2014 12:33 AM, Troy Benjegerdes wrote:
 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 clearly
>>> differentiate
 it from Bitcoin. This also might be an interesting application of
>the
>>> side
 chains concept Peter Todd has discussed.

 On Thu, Apr 24, 2014 at 04:32:15PM -0700, Stephen Reed wrote:
> Hello all.
>
> I understand that Proof-of-Stake as a replacement for
>Proof-of-Work
>>> is a prohibited yet disputed change to Bitcoin Core. I would like to
>>> create a Bitcoin branch that provides a sandboxed testbed for
>>> researching the best PoS implementations. In the years to come,
>perhaps
>>> circumstances might arise, such as shifting of user opinion as to
>>> whether PoS should be moved from the prohibited list to the
>hard-fork
>>> list.
> -
>
> A poll I conducted today on bitcointalk,
>>> https://bitcointalk.org/index.php?topic=581635.0 with an
>>> attention-grabbing title suggests some minority support for Bitcoin
>>> Proof-of-Stake. I invite any of you to critically comment on that
>>> thread.
>
> "Annual 10% bitcoin dividends can be ours if  Proof-of-Stake full
>>> nodes outnumber existing Proof-of-Work full nodes by three-to-one.
>What
>>> is your choice?"
>
> "I do not care or do not know enough." - 5 (16.1%) 
> "I would download and run the existing Proof-of-Work program to
>>> fight the change." - 14 (45.2%) 
> "I would download and run the new Proof-of-Stake program to favor
>>> the change. " - 12 (38.7%) 
> Total Voters: 31 
> -
>
> Before I branch the source code and learn the proper way of doing
>>> things in this community, I ask you simply if creating the branch is
>>> harmful? My goal is to develop, test and document PoS, while
>exploring
>>> its vulnerabilities and fixing them in a transparent fashion.
>
> Thanks for taking a bit of your time to read this message.




>>>
>>>
>--
>>> Start Your Social Network Today - Download eXo Platform
>>> Build your Enterprise Intranet with eXo Platform Software
>>>

Re: [Bitcoin-development] About Compact SPV proofs via block header commitments

[Sergio Lerner]

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 some block B, B has an ancestor A at some
> specified height and work distance back, and the cost of creating a
> false proof is at least as much work as it claims to represent.
Ok. I was thinking with another definition SPV proof.

For me a SPV proof is a 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 a block B is part of the
best-chain.

I understand that SPV nodes require SPV proofs as defined in my
definition, but I can't realize how to prove that SPV nodes require SPV
proofs under your definition. So your definition sounds to me like one
possible solution, but not the need.
 
Is your definition something well-established in the community?




--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] About Compact SPV proofs via block header commitments

[Mark Friedenbach]

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
used in the Satoshi whitepaper, and the way in which SPV clients like
BitcoinJ work. "Best chain" is typically taken to mean the most-work,
*valid* chain. Without invoking moon math or assumptions of honest peers
and jamming-free networks, the only way to know a chain is valid is to
witness the each and every block. SPV nodes on the other hand, simply
trust that the most-work chain is a valid chain, based on economic
arguments about the opportunity cost of mining invalid blocks. These SPV
nodes use block headers as proofs to determine the most-work block
connected to the genesis block or most recent checkpoint. So yes,
operationally at least this is what the community seems to mean by "SPV
proof".

Now regarding your use case:

> For the remaining peers, the client starts asking for parents blocks 
> until all parents agree (this is the last common parent).

This linear scan of block headers is what I would prefer to avoid. By
using back-links you make it have log(N) space usage.

On 04/26/2014 07:39 PM, Sergio Lerner wrote:
> 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 some block B, B
>> has an ancestor A at some specified height and work distance back,
>> and the cost of creating a false proof is at least as much work as
>> it claims to represent.
> Ok. I was thinking with another definition SPV proof.
> 
> For me a SPV proof is a 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 a block B is part
> of the best-chain.
> 
> I understand that SPV nodes require SPV proofs as defined in my 
> definition, but I can't realize how to prove that SPV nodes require 
> SPV proofs under your definition. So your definition sounds to me 
> like one possible solution, but not the need.
> 
> Is your definition something well-established in the community?
> 
> 
> 
> 
> --
>
>
> 
Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software Java Based 
> Open Source Intranet - Social, Extensible, Cloud Ready Get Started 
> Now And Turn Your Intranet Into A Collaboration Platform 
> http://p.sf.net/sfu/ExoPlatform 
> ___ Bitcoin-development 
> mailing list Bitcoin-development@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Compatibility Bitcoin-Qt with Tails

[Wladimir]

> 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@amnesia:~/linux-4765b8c-gitian-2d48b96/32$ ./bitcoin-qt
> Segmentation fault
> amnesia@amnesia:~/linux-4765b8c-gitian-2d48b96/32$ ./bitcoin-qt 
> -proxy=127.0.0.1:9050
> Segmentation fault

Can you get a traceback?

Wladimir

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development