Re: [Bitcoin-development] SmartSPV – A better Simplified Payment Verification for Smartphones

2014-04-24 Thread Gregory Maxwell
On Thu, Apr 24, 2014 at 9:52 PM, Sergio Lerner
 wrote:
> In a previous e-mail Mike Hearn asked me how I was going to handle 17K block
> headers a day in my NimbleCoin currency in a the SPV mode.
> I designed a variation of the standard headers-only SPV mode I called
> SmartSPV. This mode could also be implemented by BitcoinJ for Bitcoin.

If you are freely specifying things, and you control the headers than
you can can already make SPV evaluations of work have log(n) scaling.

See: 
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04318.html


(wrt headers in reverse, perhaps you might also want to mine
https://en.bitcoin.it/wiki/User:Gmaxwell/Reverse_header-fetching_sync
for ideas).

--
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] SmartSPV – A better Simplified Payment Verification for Smartphones

2014-04-24 Thread Sergio Lerner
In a previous e-mail Mike Hearn asked me how I was going to handle 17K
block headers a day in my NimbleCoin currency in a the SPV mode.
I designed a variation of the standard headers-only SPV mode I called
SmartSPV. This mode could also be implemented by BitcoinJ for Bitcoin.

The method is explained here:
http://bitslog.wordpress.com/2014/04/25/smartspv-a-better-simplified-payment-verification-for-smartphones/

But I copy the whole blog post in this e-mail so you don't need to click
on it.


SmartSPV – A better Simplified Payment Verification for Smartphones

NimbleCoin  is a new cryptocurrency I’ll be
hopefully launching soon. One of its nice features is that it uses the
FastBlock5
 protocol
(a 5 seconds block interval) to achieve near instant payments. Because
NimbleCoin also implements merged mining
, each
block header can be as large as 700 bytes (including Merkle branch and
coinbase transaction). Yesterday Mike Hearn asked my a difficult
question: how would NimbleCoin SPV nodes (such as the ones running on
smartphones) process tons of headers if the bandwidth is limited or the
clients are disconnected from the Internet for long periods?

The answer is Smart-SPV, a variation of the standard SPV headers-only
 mode that allows a
smartphone to keep a fairly accurate state of the wallet balance without
downloading all the missing headers and without sacrificing battery life
and time.

Headers-only SPV clients

downloads a complete copy of the headers for all blocks in the entire
blockchain but not all the transactions. In order to update the user
wallet, SPV clients ask their peers to filter those blocks that contains
transactions that the SPV is interested in, such as those that have
payments to their own bitcoin addresses. This is done using bloom
filters .

In Smart-SPV mode, when a client is missing block headers two things
happen simultaneously:

1. The client starts downloading block headers from the last one solved
backwards.

2. The client starts downloading the blocks headers from the first
missing header, forward.

While the client catches up with all the missing blocks, the wallet
balance may not be fully reliable. Nevertheless if a new payment is
received and confirmed, or a new payment is made, the wallet will
increased the balance and show it. This is what the user expects.

*How it works*

A live block is a block which is the last block of the block-chain and
it’s received on time (it has a time-stamp near the current time). Each
time a live block is received, it is flagged as LIVE and this flag is
stored permanently with the block.  A live transaction is a transaction
that is included in a live block. When a live transaction is confirmed
by 6 blocks flagged as LIVE the transaction is considered mature. A
mature transaction may be included in a block that is still orphan. All
mature transactions are scanned and used to compute the balance of the
wallet. Also all transactions that are included in blocks rooted at the
last checkpoint and finishing in the last live block are also considered
mature (this is the standard condition). Since the wallet always
modifies the balance according to mature transactions, an payment is
received and acknowledged even if the branch where it is included is
still orphaned. If the SPV client clock is correctly synchronized, the
Smart-SPV protocol does not pose any additional security risk different
from the known SPV limitations.






--
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] 0 confirmation txs using replace-by-fee and game theory

2014-04-24 Thread Gareth Williams
On 24/04/14 22:07, Chris Pacia wrote:
> It would work but it's an ugly hack IMO. What do people do if they don't
> have extra to pay when making a purchase? I have 200 mbtc and want to
> buy a 200 mbtc phone but I can't because I need 400 mbtc. Sucks for me.

I don't see why it couldn't work with just 200mBTC.
* you sign a 200mBTC TX to me, walk out of my shop with the phone
* you immediately sign & broadcast a double-spend TX with higher fee
* my POS computer (or BitPay's) sees the double spend, immediately
spends the initial TX to fees, and sounds the shoplifting alarm.

You don't get any money back, but you do get an angry shopkeeper chasing
you down the street / calling the police / blacklisting you from the
store. Assuming my POS computer's behaviour was completely automated and
widespread - and therefore predictable on your part - why would you ever
try this?

The number of people irrational enough to try this /knowing it never
works/ is likely to be way lower than the number who just stuff the
phone in their pocket and shoplift the old fashioned way. So I'd be
comfortable without the extra 200mBTC collateral :-)







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] Coinbase reallocation to discourage Finney attacks

2014-04-24 Thread Gareth Williams
On 25/04/14 00:28, Mike Hearn wrote:
> Why are we here? We are here because we were brought together by shared
> goals.
> 
> What are those goals? They were defined at the start of the project by
> the creator of the project.
> 
> Why do we issue 21 million coins and not 42? Because 21 million is the
> goal everyone signed up for.

Mike: the blockchain is a public document, with a very public and well
defined interpretation, which we've all signed up for too.

What's the point of piling PoW on top of some data to make it difficult
to modify if the interpretation itself is open to modification?

There is an important distinction to draw between a hard fork via a
change in block validation rules, and a hard fork via a change in the
/interpretation of the blockchain itself/.

Bitcoin validates data /before/ it makes it into a block; we can all be
confident that, short of a reorg, /if it's in a block, it's the law/. As
much as the 21m cap is the law anyway.

Proving that you can convince the economic majority that the
interpretation of existing blocks is in any way up for grabs would set a
dangerous precedent, and shake some people's faith in Bitcoin's overall
robustness and security (well, mine anyway.)

My 2 bits.

-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] Translators Needed for Bitcoin Core

2014-04-24 Thread Odinn Cyberguerrilla
Thanks for this reminder, I will bring this up with some others who I
think may be able to help in this area and dedicate some time.  I may be
able to free up some time with a little language work as well.

> You do not need to be a developer to help in the improvement of Bitcoin.
>
> http://sourceforge.net/p/bitcoin/mailman/message/32255092/
> Bitcoin Core 0.9.2 feature freeze is May 13th, 2014.  Now is the time for
> native non-English speakers to join Transifex to clean up the translations
> in all languages.  This is important for more than just Bitcoin because
> Litecoin will use these same translations.
>
> *What should volunteer translators do?*
> https://bitcointalk.org/index.php?topic=571414
> Try the nightly builds of Bitcoin Core as it heads toward 0.9.2.  Not
> recommended for your production wallet.
>
> https://www.transifex.com/projects/p/bitcoin/
> Join Transifex as a translator and add your account to your language.
>
> https://groups.google.com/forum/#!forum/bitcoin-translators
> Join the Translator mailing list to receive announcements when
> translations
> are needed for Bitcoin.  You will also receive notifications if other
> Bitcoin Project things in Transifex need translations (likely
> bitcoin.org).
> --
> 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


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

2014-04-24 Thread Stephen Reed
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.

-Steve

Stephen L. Reed

Austin, Texas, USA
512.791.7860 

--
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] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption

2014-04-24 Thread William Yager
Gmaxwell pointed out that we could safely front-load all the key
pre-stretching. The spec has been updated to take advantage of this.

The user's password is now protected by 10,000 rounds of salted
PBKDF2-HMAC-SHA512, as well as the main KDF (which ranges from scrypt
2^14/8/8 to scrypt 2^18/16/16 and PBKDF2-HMAC-SHA512 2^16 to 2^21).

Will

On Mon, Apr 21, 2014 at 7:05 PM, William Yager  wrote:

>
> The idea is that more powerful devices (mobile phones, laptops, etc.) can
> do all the key-stretching on their own, whereas weaker devices with access
> to another device with more computing power (like Trezors) do a fair amount
> of key-stretching on their own, but can safely export the rest of the
> key-stretching to the other device.
>
--
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] 0 confirmation txs using replace-by-fee and game theory

2014-04-24 Thread Jannis Froese
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 24.04.2014 14:15, Mike Hearn wrote:
> Beyond needing to double balances, what if the shop is selling me a
> phone on contract? So the actual cost of the phone is lower than
> the real price on the assumption of future revenue. Alice double
> spends (aka steals) the phone, paying double the artifically lower
> cost but still making a good saving. Bob does not end up with
> "nothing", he ends up in the red.

Nearly every payment system in existence has this problem: you have to
be able to enforce the contract out-of-band. The scenario you describe
is no worse than a payment network with instant, secure confirmations
because Alice could just as well refuse to make the second payment.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTWUYdAAoJEBrvn3PsoRcmT28QAJNbxjLRPYvkIfizeHoAFRH2
pNfd9458/AECJ6muGAs+tYeDw9uhYMVPnbMLZOwzgPl8HE5NN9XbGjCpwpNzsEK4
a8zb5CsonBh+xBNgbx1CIjCNYYQLd2qmgxMVaH4R7VWS+DgVBjfKq5MnM0vdSNcw
SSzb9dMEjgl1cOZa07CG4GuPwEUIFiCVygjYSrGP2E8qCepKvH+0webIXk7COqZK
SyhTdhS+dsdgGW5Mm8cA8zIVPaWYXMo88kOq2S4fIs5HiWtnVXQ9ljJ4r2Py1SEO
H3u4lMWc7Hu0PUW6b6K+uDQfyJtRNi0diJSswseA37v6BeQW4zYMNfL40AsnG+Fv
MusJFtBqHzXKhAeE/zpwi5QWs/qHvRYlETifIMKMrQldssDJo15ed/M8wNCZRobv
Q7K3XKOt228nUUP2FrZl1I4wGWwkBMpzP89t8HMrTZYV2EFWqE+lu9oXcEjz9k12
64UXiWXU0jRAhMiCAvQUL7fKaOb9TXfGPy+3+bZOAtKM5M582+0d94EObA67SBsm
O4H5vLTwS041x1cndW0NDxDbtM+IAuu2Jorzqzcie3ld7cqsKAyDbSk3i1C7zQzG
hvI6FxIy0n6GA9ciw8RM44Q4zPVxYQ4e/MMby9ko7otmL5HLlOCnOUmJ/JHn+QJG
Z7MDRkKAslLUUEqzgQWb
=HNO6
-END PGP 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] Coinbase reallocation to discourage Finney attacks

2014-04-24 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/24/2014 03:37 PM, Jorge Timón wrote:


The 21 million bitcoin limit is not important because of its exact
value, nor is it important because Satoshi picked it.

The 21 million limit is important because users hold bitcoin based on
the promise that the block reward will never be adjusted ex post
facto. The behavior users are relying on is "The bitcoins you hold are
forever a calculable fraction of all the bitcoins that will ever be
issued."

That's what bitcoin holders agreed to, and that's what can never be
changed.

The fact that the number is arbitrary is not relevant. We can agree to
meet for lunch at some arbitrarily chosen time, and the fact that the
time was chosen arbitrary in no way means that one party arbitrarily
choosing not to show up doesn't break the agreement.

- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTWUTWAAoJECoisBQbQ4v0JiwIALQtf4GrNaIdEidJr+f3z8G3
smDgU5xXhN4+1Eo5xU/ZmQy03tU5E00/PRiMTHz1RNXeO+w/iu4PlAJN7pk5oy75
QzDtaCzDjKMCN+1PCQ5VNCL04ws8JifU6QLxSgXgsShBnv19FlxiejgvjNWg+Lzc
uHxyP0PlvfF5BWTiEV68KYcfQPbamOH7Vb8v4tQ4/j/ioA7mYso+Q0jX0Y4ae1FN
XNs4KnTsIFTsXWzBIYFlFPwQ5d+mdG84W7FpmwwcXaRWQxMwdJq8QjlUuFng439B
6OgQqtq4wmvwoPjKS5nOesfdrdH9Scx2zg6uwhaY0zKMtPW/CEzzLFUfq+cZ6q0=
=r+t0
-END PGP SIGNATURE-


0x1B438BF4.asc
Description: application/pgp-keys
--
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

2014-04-24 Thread Mike Hearn
>
> Casting that vote does them no harm.
> Every time another pool joins the blacklist, there's no harm to them to
> doing so.  At some point they will reach a majority


These statements do not follow from each other.
--
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

2014-04-24 Thread Christophe Biocca
> Casting that vote does them no harm.
> Every time another pool joins the blacklist, there's no harm to them to doing 
> so.

I actually agree that this is a problem, but that's actually not
inherent in the proposed enforcement mechanism (just the current
voting rules).

Here's an alternate:

- To start a vote, you set aside a part of your coinbase with amount X
<= their entire coinbase amount.
- Then you need 51 blocks with a "yes" vote before the coinbase
maturity of the target for the vote to be considered a success.
- Success means target coinbase has X coins reallocated/burned.
- Failure means vote-initiating coinbase has X coins reallocated/burned.

The incentives for voting miners are to vote yes if and only if they
dislike the targeted miner more than the initiator (all other monetary
effects are identical). That isn't a bulletproof way to force miners
to only punish double spenders (rather than anything they dislike in
general), but it removes the risk free nature of trying to take away
another miner's coinbase.

It means that you'll need a high level of confidence other miners are
on your side before taking a risk, but, because you've got a much
longer time frame than 10 minutes, you can get manual confirmation
from other miners.

On Thu, Apr 24, 2014 at 11:03 AM, Peter Todd  wrote:
> On Thu, Apr 24, 2014 at 10:47:35AM -0400, Christophe Biocca wrote:
>> Actually Peter, coinbase confiscations are a much worse mechanism for
>> enforcement of widespread censorship rules than simple orphaning. They
>> lose their power when the transaction miners are punished for can
>> build up over time without losing their usefulness:
> 
>> Of course, in such a dystopian future, orphaning would be the
>> enforcement mechanism. It would be stupid to rely on coinbase
>> reallocation/burning to do this task when the existing tools work so
>> much better.
>
> I don't disagree with you at an end stage, but the thing with coinbase
> blacklists/confiscation is because it's a voting mechanism the initial
> stages of enforcing widespread censorship rules with it are much easier.
> For instance, if a 10% pool that has been forced/wants to blacklist
> certain transactions can do so, and then vote to blacklist blocks that
> do not abide by that blacklist. Casting that vote does them no harm.
> Every time another pool joins the blacklist, there's no harm to them to
> doing so.  At some point they will reach a majority, which causes the
> blacklist to actually apply. The whole process happens smoothly, letting
> the blacklist be applied safely and easily.  With orphaning/reorging on
> the other hand you just can't be sure that the other miners will
> actually adopt it, making adoption risky.
>
> Of course, that's above and beyond the fact that you can't prove a
> Finney attack happened to a third-party, making it easy to attack
> smaller miners with Sybil attacks, get them creating blocks with
> double-spends in them, and using that as an excuse to punish them.
>
>> What's interesting is that this mechanism is especially tailored to
>> blocking time sensitive transactions (that need to be confirmed
>> now/soon, or are worthless), such that their total out-of-band fees
>> can't build up over time. Double spending is one such category. I'm at
>> a loss to come up with something else, but maybe someone has a good
>> example?
>
> Decentralized markets are a great example: the bids and orders they
> depend on are time-senstive and become much less valuable if they get
> delayed greatly.
>
> --
> 'peter'[:-1]@petertodd.org
> 091ae589c034bc0466e2feca51dc018bb2c3303e8ab8648b

--
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] 0 confirmation txs using replace-by-fee and game theory

2014-04-24 Thread Mike Hearn
>
> Of course if we're not comparing this with Bitcoin today and we're
> comparing it to some theoretical mechanism for instant p2p
> serialization without requiring proof of work then, yes, this concept
> is not very interesting.
>

Bitcoin's competition is not some theoretical perfect p2p system but
rather, bank notes and credit cards.
--
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

2014-04-24 Thread Jorge Timón
On 4/24/14, Mike Hearn  wrote:
> You can't disentangle the two. Proof of work just makes a block chain hard
> to tamper with. What it contains is arbitrary. Honest miners build a block
> chain that's intended to stop double spending. Dishonest miners don't.
> They're both engaging in proof of work, to different ends.

Yes, you can disentangle replace-by-fee policies from "rewriting
history" attacks.
That's exactly what I'm saying.
Proof of work is the most important thing that makes the blockchain
hard to tamper with.

>> Whatever, let's keep calling stupid miners "honest miners"
>>
>
> No, let's not. Your definition of "smart miner" is one I'd called "stupid
> miner" (or possibly "short bitcoin miner"). They are miners who would
> reduce the value of their coins, by making their own system less useful.
> That's not smart, that's simply short termism taken to an extreme, sort of
> like a business owner who puts so much pressure on his employees they all
> quit. He might have gained a bit more profit in the short term, but only at
> the cost of destroying his business that would have given lower but
> sustainable returns over the long term.

Whatever, pick the terms yourself but let's just stick to the same ones, please.
I've read this argument before, but I simply don't buy it because I
disagree with the premise that replace-by-fee reduces the value of the
coins (not to mention we shouldn't assume miners stock coins for
long).
I think replace-by-fee policies are actually an improvement over
first-saw-first-included policies.

>> This persistent argument from authority is annoying.
>>
>
> Peter always says this too, but it's again an incorrect position. This is
> not an argument from authority.

I don't know about other occasions with other people but what you just
used with me was an argument from authority fallacy. Now you're using
a false analogy to try to convince us you didn't.

If I was saying "we should change the maximum from 21 M to 100 M
because mining subsidies could continue for longer".
"Mining subsidies aren't necessarily a good thing" or
"That's no justification for a hardfork" or
"That could destroy people's confidence in the currency"
would be logical arguments.

"No, because Satoshi picked 21 M" would be an argument from authority fallacy.

>> That's not what I'm saying. Miners that don't mine on top of the
>> longest chain are dishonest by my own definition as well.
>>
>
> Right, but I don't accept this definition of honesty. That's not a
> definition any man on the street would use:

Whatever let's use whatever definitions you want, if I don't like your
definition of honesty I will just invent a new term to define my own.

> "If you pay for something with forged bank notes and walk out
> immediately, you are honest. But if you pay for something with forged bank
> notes and hang around for longer than 10 minutes, you are dishonest"

Sorry, I don't see the analogy.

> That would sound silly to anyone because what's so special about 10
> minutes? It's the act of passing counterfeit money and stealing from the
> merchant that's the dishonest act, how long it takes is irrelevant.

10 minutes is what Satoshi picked. Just kidding...

> In Bitcoin, the dishonest act by the user is signing for the same output
> twice (ignoring special protocols here), and the dishonest act by the miner
> is deviating from normal behaviour for a fee to try and trick the recipient
> into believing they have been paid. The exact details are something
> computer scientists care about, but the average Bitcoin user would not.

People need to understand that Bitcoin transactions are not instant.
For instants transactions you need to rely somehow on trust, use some
trust-less offchain mechanism or use a payment protocol that would
make double-spending irrational (like the one described in the other
thread that uses replace-by-fee).
So I think miner's default behavior should be replace-by-fee. But that
doesn't imply that I want miners to rewrite pow-validated history.

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

2014-04-24 Thread Mike Hearn
Thanks Sergio!

On Thu, Apr 24, 2014 at 5:13 PM, Sergio Lerner wrote:

> For more information you can check my post:
> http://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/
> Also NimbleCoin is a new alt-coin that uses 5-sec block intervals, allows
> 100 tps and  it's based on BitcoinJ (NimbleCoinJ now). So not only it
> is possible, but it was coded by Mike itself.
>

Fascinating! I think that's the first time I heard of an alt coin entirely
based on bitcoinj as its core implementation. Looking forward to your
release.

My understanding is that dogecoin suffers somewhat from having so many
headers. SPV clients have to download them all in sequence so the more
blocks you have, the more data they must download and thus the slower they
sync. Sync times for SPV wallets today are fast enough that unless you
spend six months in the jungle with your phone switched off, you probably
won't notice. With 5 second block times unless there's some other solution
you'd have much worse UX.

BTW, Pieter experimented with relaying blocks as hash lists (actually
merkleblocks) and I believe he found that it could often fail and be slower
if the mempools were not quite synced. At any rate, it was apparently more
complicated than it looked. That may be a side effect of trying to reuse
the Bloom filtering code however.


> Another solution to achieve <5 secs block intervals is this:
> http://bitslog.wordpress.com/2014/03/20/mincen-a-new-protocol-to-achieve-instant-payments/
>

MinCen looks like a rather interesting idea. I will read the paper.
--
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

2014-04-24 Thread Sergio Lerner

On 23/04/2014 05:51 p.m., Mike Hearn wrote:
> On Wed, Apr 23, 2014 at 10:44 PM, Adam Ritter  > wrote:
>
> Isn't a faster blockchain for transactions (maybe as a sidechain)
> solving the problem? If there would be a safe way for
> 0-confirmation transactions, the Bitcoin blockchain wouldn't even
> be needed.
>
>
> The 10 minute average comes from a desire to balance wasted work due
> to natural chain splits with latency. With a very fast block interval
> you end up with lots of forks and things take longer to converge,
> also, it can make attacks easier because an attacker is building on
> his own blocks so he doesn't suffer propagation delays and the
> attendant splits.
>
> It's not clear you can just make a faster block chain. 10 minutes is
> somewhat arbitrary, it could be 5 minutes and the system would still
> work, but it probably can't be 5 seconds.
5 seconds block interval is possible. I've simulate it with great
success and I encourage anyone to repeat or check my simulations.

There are a very few protocol modifications that are required to allow 5
seconds block, and most of them have already been discussed in the forums.
For more information you can check my post:
http://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/
Also NimbleCoin is a new alt-coin that uses 5-sec block intervals,
allows 100 tps and  it's based on BitcoinJ (NimbleCoinJ now). So not
only it is possible, but it was coded by Mike itself.
Important note: the 5-sec block interval method probably requires a
block reward forever. It doesn't work well if there is no block reward
at all.

>
> Unfortunately for best physical-world usability you really need very
> fast payments. A few seconds is competitive with modern credit cards.
Another solution to achieve <5 secs block intervals is this:
http://bitslog.wordpress.com/2014/03/20/mincen-a-new-protocol-to-achieve-instant-payments/

So the problem with 0-confirmations is solely of Bitcoin and other
alt-coins, new alt-coins may achieve instant transactions and no not
have to rely on 0-confirmations.

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-development


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

2014-04-24 Thread Peter Todd
On Thu, Apr 24, 2014 at 10:47:35AM -0400, Christophe Biocca wrote:
> Actually Peter, coinbase confiscations are a much worse mechanism for
> enforcement of widespread censorship rules than simple orphaning. They
> lose their power when the transaction miners are punished for can
> build up over time without losing their usefulness:

> Of course, in such a dystopian future, orphaning would be the
> enforcement mechanism. It would be stupid to rely on coinbase
> reallocation/burning to do this task when the existing tools work so
> much better.

I don't disagree with you at an end stage, but the thing with coinbase
blacklists/confiscation is because it's a voting mechanism the initial
stages of enforcing widespread censorship rules with it are much easier.
For instance, if a 10% pool that has been forced/wants to blacklist
certain transactions can do so, and then vote to blacklist blocks that
do not abide by that blacklist. Casting that vote does them no harm.
Every time another pool joins the blacklist, there's no harm to them to
doing so.  At some point they will reach a majority, which causes the
blacklist to actually apply. The whole process happens smoothly, letting
the blacklist be applied safely and easily.  With orphaning/reorging on
the other hand you just can't be sure that the other miners will
actually adopt it, making adoption risky.

Of course, that's above and beyond the fact that you can't prove a
Finney attack happened to a third-party, making it easy to attack
smaller miners with Sybil attacks, get them creating blocks with
double-spends in them, and using that as an excuse to punish them.

> What's interesting is that this mechanism is especially tailored to
> blocking time sensitive transactions (that need to be confirmed
> now/soon, or are worthless), such that their total out-of-band fees
> can't build up over time. Double spending is one such category. I'm at
> a loss to come up with something else, but maybe someone has a good
> example?

Decentralized markets are a great example: the bids and orders they
depend on are time-senstive and become much less valuable if they get
delayed greatly.

-- 
'peter'[:-1]@petertodd.org
091ae589c034bc0466e2feca51dc018bb2c3303e8ab8648b


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] Fwd: Coinbase reallocation to discourage Finney attacks

2014-04-24 Thread Adam Ritter
I wouldn't mind having $5 of my money held at
Apple/Google/VISA/Mastercard/BitPay (and I wouldn't be sad of losing $5 if
any of these companies go bankrupt).
Actually I had in mind creating a centralized version of Bitcoin for
ultra-fast payments. With keeping all addresses on SSDs, asking for 1 cent
/ address month, 1 cent / transaction should be possible to reach even with
6x replication. Companies could compete in price as long as the API is
standardized. Automatic top-up should be simple as well.


On Wed, Apr 23, 2014 at 10:53 PM, Gregory Maxwell wrote:

> On Wed, Apr 23, 2014 at 1:44 PM, Adam Ritter  wrote:
> > Isn't a faster blockchain for transactions (maybe as a sidechain) solving
> > the problem? If there would be a safe way for 0-confirmation
> transactions,
> > the Bitcoin blockchain wouldn't even be needed.
>
> Large scale consensus can't generally provide instantly irreversible
> transactions directly: Increasing the block speed can't help past the
> point where the time starts getting close to the network diameter...
> you simply can't tell what a consensus of a group of nodes is until
> several times the light cone that includes all of them.  And if you
> start getting close to the limit you dilute the power working on the
> consensus and potentially make life easier for a large attacker.
>
> Maybe other chains with different parameters could achieve a different
> tradeoff which was better suited to low value retail transactions
> (e.g. where you want a soft confirmation fast). A choice of tradeoffs
> could be very useful, and maybe you can practically get close enough
> (e.g. would knowing you lost a zero-conf double spend within 30
> seconds 90% of the time be good enough?)... but I'm not aware of any
> silver bullet there which gives you something identical to what a
> centralized service can give you without invoking at least a little
> bit of centralization.
>
--
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] 0 confirmation txs using replace-by-fee and game theory

2014-04-24 Thread Jorge Timón
On 4/24/14, Mike Hearn  wrote:
>>
>> This scheme would discourage people from attempting a Finney attack
>> because they would end up worse off if they did.
>>
> Phrased another way, it simply makes every block a Finney attack that
> charges the maximum double spending fee possible. This doesn't solve the
> problem.

This solves regular double-spends, not Finney attacks, but finney
attacks (which are not really the easiest attacks in the world) don't
get any worse.

On 4/24/14, Chris Pacia  wrote:
> It would work but it's an ugly hack IMO. What do people do if they don't
> have extra to pay when making a purchase? I have 200 mbtc and want to buy a
> 200 mbtc phone but I can't because I need 400 mbtc. Sucks for me.
>
> I would much prefer the hassle of a green address notary than always having
> to make sure I have double what I need to make a purchase.

This scheme wouldn't be mandatory. You can still wait for
confirmations or rely somehow on existing trust instead if that's
better for you on that situation.

> Beyond needing to double balances, what if the shop is selling me a phone
> on contract? So the actual cost of the phone is lower than the real price
> on the assumption of future revenue. Alice double spends (aka steals) the
> phone, paying double the artifically lower cost but still making a good
> saving. Bob does not end up with "nothing", he ends up in the red.

Sybil attacks aside, Alice can't save anything, period. If she tries
she will end up losing it all.
I don't see how signing a longer term contract protects her in any way.

> But there's a much simpler way to dispose with this idea. Jorge, go down to
> your local bars and cafes, and ask them if they'd be willing to accept a
> form of payment that allows anyone to steal from them by simply paying
> double the purchase price to some other random guy. They *will* look at you
> as if you're crazy. Why would they ever do that?

They would do that to avoid having to wait for a confirmation or two
(I think one is good enough for most small purchases) when being paid
by people they don't trust just before they leave.
Maybe they prefer to just make people wait if they think that will
make them pay up-front.
This is completely optional and only an improvement on the current situation.

Of course if we're not comparing this with Bitcoin today and we're
comparing it to some theoretical mechanism for instant p2p
serialization without requiring proof of work then, yes, this concept
is not very interesting.

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

2014-04-24 Thread Christophe Biocca
Actually Peter, coinbase confiscations are a much worse mechanism for
enforcement of widespread censorship rules than simple orphaning. They
lose their power when the transaction miners are punished for can
build up over time without losing their usefulness:

Assume a world where 75% of the hashpower is coerced into
stealing/burning the coinbases of miners who allow transactions to and
from a particular set of addresses (the actual rule isn't that
important). Then the following would be a rational behaviour from the
remaining 25%:

- Mine according to the enforced rules most of the time.
- Accept banned transactions paying you with an output (no real
miners' fees) and keep them in an ever-accumulating pool.
- When there's so much of those to make it worth your while, mine a
block filled with them.

If miners don't orphan your block, you made money. They can't
retaliate further, because you can publish the block anonymously, not
tying it to your previous identity. Hell, some of the 75% might be
able to do the same right under the authorities' noses (it would be
really hard to spot by an external observer).

Note that I, banned user, can submit to all these non-enforcing miners
at once (with a different fee txout for each). I get a severe
degradation of service, especially if I'm part of an extremely small
minority, but ultimately as long as a single miner can accumulate
enough transactions with enough fees, I'll eventually get through.

Of course, in such a dystopian future, orphaning would be the
enforcement mechanism. It would be stupid to rely on coinbase
reallocation/burning to do this task when the existing tools work so
much better.

What's interesting is that this mechanism is especially tailored to
blocking time sensitive transactions (that need to be confirmed
now/soon, or are worthless), such that their total out-of-band fees
can't build up over time. Double spending is one such category. I'm at
a loss to come up with something else, but maybe someone has a good
example?

On Thu, Apr 24, 2014 at 10:09 AM, Mike Hearn  wrote:
>> Like I said before, that leads to the obvious next step of
>> deleting/stealing their coinbases if they don't identify themselves.
>
>
> And as I said before, that's a huge leap. A majority of miners deciding
> double spending needs tougher enforcement doesn't imply they also think all
> miners should identify themselves. Those are unrelated things.
>
> This kind of totally unsupported "obvious next step" argument can be applied
> to any proposal in any walk of life. We developed SPV clients? The obvious
> next step is that miners have to stop being anonymous. We developed floating
> fees? The obvious next step is that miners have to stop being anonymous. The
> prior arguments sound absurd exactly because they're not obvious or even
> logical - same as this.
>
>
>
> --
> 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] Coinbase reallocation to discourage Finney attacks

2014-04-24 Thread Mike Hearn
>
> And that's achieved through proof of work, not through "miner's honesty".
>

You can't disentangle the two. Proof of work just makes a block chain hard
to tamper with. What it contains is arbitrary. Honest miners build a block
chain that's intended to stop double spending. Dishonest miners don't.
They're both engaging in proof of work, to different ends.


> Whatever, let's keep calling stupid miners "honest miners"
>

No, let's not. Your definition of "smart miner" is one I'd called "stupid
miner" (or possibly "short bitcoin miner"). They are miners who would
reduce the value of their coins, by making their own system less useful.
That's not smart, that's simply short termism taken to an extreme, sort of
like a business owner who puts so much pressure on his employees they all
quit. He might have gained a bit more profit in the short term, but only at
the cost of destroying his business that would have given lower but
sustainable returns over the long term.


> This persistent argument from authority is annoying.
>

Peter always says this too, but it's again an incorrect position. This is
not an argument from authority.

Why are we here? We are here because we were brought together by shared
goals.

What are those goals? They were defined at the start of the project by the
creator of the project.

Why do we issue 21 million coins and not 42? Because 21 million is the goal
everyone signed up for.

Why did everyone sign up for 21 million coins? Because that's what Satoshi
picked.


If someone asked us to change from 21 to 42 million coins, we'd probably
say no and the justification would be that this is the number we started
with. That's not "argument from authority", it's just recognition that the
parameters of a shared project has to be defined somehow, and for Bitcoin
it was defined at the start.

Now the argument Gregory makes is that changing the block chain algorithm
in this way would be a violation of the social contract. This is a generic
outcome to be legitimately worried about - we don't want to change what
Bitcoin is in ways that would dismay its users. That just leads to a fork.

I argue that this isn't such a change because it makes nothing possible
that was previously impossible, it just makes it less disruptive, and the
*actual* shared goal of Bitcoin is not "preserve the block chain algorithm
exactly as found in v0.1" but rather "stop double spending".

You are arguing elsewhere that Bitcoin should allow double spending for a
fee. That *would* be a clear violation of the social contract!


> That's not what I'm saying. Miners that don't mine on top of the
> longest chain are dishonest by my own definition as well.
>

Right, but I don't accept this definition of honesty. That's not a
definition any man on the street would use:

"If you pay for something with forged bank notes and walk out
immediately, you are honest. But if you pay for something with forged bank
notes and hang around for longer than 10 minutes, you are dishonest"

That would sound silly to anyone because what's so special about 10
minutes? It's the act of passing counterfeit money and stealing from the
merchant that's the dishonest act, how long it takes is irrelevant.

In Bitcoin, the dishonest act by the user is signing for the same output
twice (ignoring special protocols here), and the dishonest act by the miner
is deviating from normal behaviour for a fee to try and trick the recipient
into believing they have been paid. The exact details are something
computer scientists care about, but the average Bitcoin user would not.


> And I also disagree that all the people who think this way are
> "hopelessly confused". We may be confused, but I think there's always
> hope for removing confusions provided that there's will to learn,
> which I think it is at least my case.
>

Indeed and that's why we have these threads! These are fundamental issues
that simply must be debated.
--
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] 0 confirmation txs using replace-by-fee and game theory

2014-04-24 Thread Jorge Timón
On 4/24/14, Peter Todd  wrote:
> ...
> With replace-by-fee scorched-earth the success rate of such
> double-spends would be significantly reduced as the attacker would need
> to get lucky with bad propagation not just once, but twice in a row.

Interesting.

>> Replace-by-fee and child-pays-for parent cannot be prohibited by a
>> protocol rule.
>> I believe all miners will eventually implement these policies because
>> it is the more rational way for them to prioritize transactions.
>> Finally I hope they do because it would make 0-confirmation
>> transactions possible as described in this post.
>> So I can't find any reasoning against replace-by-fee unless my example
>> is terribly flawed.
>> Am I missing something?
>
> A few things:
>
> 1) Replace-by-fee doesn't protect against sybil attacks; only

No worse than the current situation.

> 2) Replace-by-fee scorched earth does require you to keep private keys
> online to sign the replacements. Not a big deal, but it's yet another
> reason why you wouldn't want to use it for high-value stuff.

High-value transactions should wait for several confirmations.

> 3) It doesn't directly solve finney attacks(1) where the miner mines the
> transaction in private. However finney attacks are only relevant if
> there is high centralization of hashing power, and all other proposed
> mechanisms, e.g. coinbase reallocation, themselves do a lot of harm to
> decentralization. (just look at how coinbase reallocation lets large
> pools bully smaller miners out of business by blacklisting their blocks)

Again, no worse than the current situation. And regular double-spends
attacks are much simpler than finney attacks.

> One interesting thing with regard to finney attacks and replace-by-fee
> though is that enforcing hasher visibility of the blocks they are mining
> - what getblocktemplate was meant to do voluntarily - lets any hasher
> detect a finney attack double-spend and broadcast it. They have a weak
> incentive to do so - the scorched earth reply is a high-fee transaction
> of course and pre-broadcasting transactions makes blocks propagate
> faster - at which point you're back to a public double-spend.  Enforcing
> visibility of block contents to hashers is definitely a good thing for
> decentralization.

Where can I read more about "enforcing hashing visibility of block contents"?
Sounds somewhat similar to p2pool to me but I'm not sure I understand 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] Coinbase reallocation to discourage Finney attacks

2014-04-24 Thread Mike Hearn
>
> Like I said before, that leads to the obvious next step of
> deleting/stealing their coinbases if they don't identify themselves.
>

And as I said before, that's a huge leap. A majority of miners deciding
double spending needs tougher enforcement doesn't imply they also think all
miners should identify themselves. Those are unrelated things.

This kind of totally unsupported "obvious next step" argument can be
applied to any proposal in any walk of life. We developed SPV clients? The
obvious next step is that miners have to stop being anonymous. We developed
floating fees? The obvious next step is that miners have to stop being
anonymous. The prior arguments sound absurd exactly because they're not
obvious or even logical - same as this.
--
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

2014-04-24 Thread Jorge Timón
On 4/24/14, Mike Hearn  wrote:
> No! This is a misunderstanding. The mechanism they use to prevent double
> spends is to *ignore double spends*. The blocks they created indicate the
> ordering of transactions they saw and proof of work is used to arrive at a
> shared consensus ordering given the possibility that transactions arrived
> at different times.
>
> I'm continually amazed at how many people seem to see the current algorithm
> as the goal in and of itself, instead of an imperfect but workable means of
> achieving the actual goal.

I'm not saying proof of work is the goal, the goal is still p2p
transaction serialization.
And that's achieved through proof of work, not through "miner's honesty".

> This definition of honesty is not my own, the one Bitcoin has always used.

Whatever, let's keep calling stupid miners "honest miners", smart
miners "dishonest-by-replace-by fee miners" and miners that do replace
by fee and also hash on top of old blocks "utterly dishonest miners".

> Obviously if Satoshi had wanted transactions to be double spendable by fee
> in the mempool he would have made Bitcoin work that way, instead of coming
> up with the nSequence based replacement scheme instead.

Maybe Satoshi hadn't thought in depth about replace-by-fee when he
wrote the code.
Why should we care?
If nSequence was a design mistake Satoshi did, should we maintain it
to somehow honor him?
Maybe the payment protocol shouldn't have been developed because he
had some weird ideas about paying to ips? Maybe we shouldn't write any
tests because he didn't do so?
This persistent argument from authority is annoying.

> First-seen *is* a protocol rule, as much as Set-Cookie storing data in a
> browser is an HTTP protocol rule. The fact that auditing compliance with it
> is harder to do than some others does not make it less of a rule.

It is not a protocol rule that validators can use to discriminate the
longest valid chain and therefore is not enforceable. Not even through
a softfork because miners can't know which transactions other miners
saw first.
So if it is a protocol rule, I think it shouldn't be.

> Again you are hopelessly confused. Miners that are trying to double spend
> are *by definition* not making transactions irreversible, they are trying
> to make transactions reversible.

Miners that mine on top of the longest valid chain are helping in
making transactions irreversible whether they implement a first-saw or
a replace-by-fee policy.

> Look at it this way. There is no inherent reason BitUndo has to undo only
> Finney attacks. If it gets sufficient hash power it could offer undoing of
> 1-confirm transactions too, right? Sure it'll mostly fail but that's
> already a part of its business model. Sometimes it'll get two blocks in a
> row and succeed. It's a very minor tweak to what they're doing. Would you
> argue these miners are still useful? After all, it's impossible to be
> certain after the fact that miners built on top of the "wrong" block
> because forks occur naturally.

That's not what I'm saying. Miners that don't mine on top of the
longest chain are dishonest by my own definition as well.
You want to equate replace-by-fee "dishonesty" with
trying-to-rewrite-history dishonesty by saying that the transactions
that "have been seen" in the network are already history and that's
where we disagree. I think only what's in the chain is history and I
also think that's the whole point of proof of work.
And I also disagree that all the people who think this way are
"hopelessly confused". We may be confused, but I think there's always
hope for removing confusions provided that there's will to learn,
which I think it is at least my case.

> What I said is, if you believe all miners are willing to double spend for a
> fee then this resolves the experiment as a failure. This is also obvious -
> if you can pay miners to go back and rewrite the chain at will, Bitcoin
> doesn't work.

This is in fact quite polemic and thus obviously not obvious.
Bitcoin works because rewriting the chain gets exponentially more
expensive as time passes.

> Because all miners follow this ridiculous policy, they should be willing to
> fork the chain at any point to claim the higher fee on the new tx. After
> ...
>
> Do you see now why your definition of honesty is completely broken?

I see now that I may have not properly expressed myself in the earlier
post since you clearly misunderstood what I meant by "smart miners".
By that I mean miners implementing replace-by-fee and
child-pays-for-parent policies Not miners trying to rewrite history,
which I agree is about as smart as mining on top of orphan blocks.

--
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:/

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

2014-04-24 Thread Peter Todd
On Thu, Apr 24, 2014 at 11:56:23AM +0200, Mike Hearn wrote:
> > ... proposing the mechanism be used to claw back mining income from a
> > hardware vendor accused of violating its agreements on the amount of
> > self mining / mining on customers hardware.
> >
> 
> I think this would not be doable in practice, unless there was a way to
> identify that a block was mined with pre-sold equipment. Peter points out
> that the pool in question is marking their blocks by reusing addresses -
> ditto for the double spending against dice sites - but that's a trivial
> thing for them to fix. Then it'd be difficult (impossible?) for miners to
> identify KnC blocks even if there was a strong majority consensus to delete
> their coinbases.

Like I said before, that leads to the obvious next step of
deleting/stealing their coinbases if they don't identify themselves.

Another likely outcome would be for coinbase blacklisting to be used as
a way to force a minority of miners to adopt a transaction blacklist
that the majority of miners had adopted. Any block containing
transactions spending coins on the txout blacklist would itself be
punished by having the block reward either blacklisted or taken.

> The reason I think this particular change is doable is that it should be
> possible to quite reliably identify blocks that are Finney attacking for
> profit. That doesn't generalise to any policy though.

It's not possible to produce a cryptographic proof that a given block
engaged in a Finney attack. You're proposed coinbase blacklisting/reallocation
mechanism is simply a way of voting on what coinbases to either
blacklist or reallocation, nothing more.

-- 
'peter'[:-1]@petertodd.org
3d5f2a2a68690093cd99f8af1bc8395061251017019cc30a


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] 0 confirmation txs using replace-by-fee and game theory

2014-04-24 Thread Peter Todd
On Thu, Apr 24, 2014 at 12:48:54PM +0200, Jorge Timón wrote:
> Here is a solution to the problem of having 0 confirmation
> transactions

FWIW I'm running an experiment right now to detect how easy it is to
doublespend 0-conf transactions I need to collect more data, but initial
results indicate that transaction propagation is sufficiently unreliable
that double-spending frequently works without miners using
replace-by-fee even when both transactions pay high fees, there is a 60
second delay between first and second, and there's only about four
replace-by-fee nodes on the network.

With replace-by-fee scorched-earth the success rate of such
double-spends would be significantly reduced as the attacker would need
to get lucky with bad propagation not just once, but twice in a row.

> that relies on game
> theory and most miners implementing replace-by-fee and child-pays-for-parent.
> 
> This has been proposed before
> http://sourceforge.net/p/bitcoin/mailman/message/30876033/
> I'm just going to describe the general idea in more detail.

Just to be clear, while that post is mine, original credit for the idea
actually goes to John Dillon as far as I know; I first heard about it
from him in private discussion.

> Replace-by-fee and child-pays-for parent cannot be prohibited by a
> protocol rule.
> I believe all miners will eventually implement these policies because
> it is the more rational way for them to prioritize transactions.
> Finally I hope they do because it would make 0-confirmation
> transactions possible as described in this post.
> So I can't find any reasoning against replace-by-fee unless my example
> is terribly flawed.
> Am I missing something?

A few things:

1) Replace-by-fee doesn't protect against sybil attacks; only
confirmations are solid evidence that a transaction has actually reached
the mining power and your communication channel to that mining power
isn't being blocked. Keep in mind that Bitcoin depends on the existence
of a jam-free network, and very importantly, lets you detect when that
network has failed and you are being jammed. No unconfirmed transaction
scheme can solve this problem in a decentralized network.

2) Replace-by-fee scorched earth does require you to keep private keys
online to sign the replacements. Not a big deal, but it's yet another
reason why you wouldn't want to use it for high-value stuff.

3) It doesn't directly solve finney attacks(1) where the miner mines the
transaction in private. However finney attacks are only relevant if
there is high centralization of hashing power, and all other proposed
mechanisms, e.g. coinbase reallocation, themselves do a lot of harm to
decentralization. (just look at how coinbase reallocation lets large
pools bully smaller miners out of business by blacklisting their blocks)

One interesting thing with regard to finney attacks and replace-by-fee
though is that enforcing hasher visibility of the blocks they are mining
- what getblocktemplate was meant to do voluntarily - lets any hasher
detect a finney attack double-spend and broadcast it. They have a weak
incentive to do so - the scorched earth reply is a high-fee transaction
of course and pre-broadcasting transactions makes blocks propagate
faster - at which point you're back to a public double-spend.  Enforcing
visibility of block contents to hashers is definitely a good thing for
decentralization.

1) https://bitcointalk.org/index.php?topic=3441.msg48384#msg48384

-- 
'peter'[:-1]@petertodd.org
93d8af23978adc9e201a1f2e2dc52844f9013a1da3621572


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] Development Roadmap of Bitcoin Core 0.9.2

2014-04-24 Thread Wladimir
On Thu, Apr 24, 2014 at 10:25 AM, Wladimir  wrote:
> On Thu, Apr 24, 2014 at 10:15 AM, Warren Togami Jr.  wrote:
>
> But indeed we need to decide on a cut-off point. I'd have preferred
> 4.7 or 4.8. Qt 4.6 is *ancient* - it was released in februari 2010.
> Apart from tails it doesn't seem like anyone is using those old stable
> distributions on the desktop.

Does anyone know of the timeframe in which tails will switch to a
newer version of Qt?

As it's debian based: will switch to a Wheezy/7.4. Wheezy has Qt 4.8
so is decidedly unproblematic.

I see they're working on migration at least:

- https://tails.boum.org/blueprint/Wheezy/
- https://git-tails.immerda.ch/tails/log/?h=feature/wheezy

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


Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory

2014-04-24 Thread Mike Hearn
>
> This scheme would discourage people from attempting a Finney attack
> because they would end up worse off if they did.
>
Phrased another way, it simply makes every block a Finney attack that
charges the maximum double spending fee possible. This doesn't solve the
problem.

Beyond needing to double balances, what if the shop is selling me a phone
on contract? So the actual cost of the phone is lower than the real price
on the assumption of future revenue. Alice double spends (aka steals) the
phone, paying double the artifically lower cost but still making a good
saving. Bob does not end up with "nothing", he ends up in the red.

But there's a much simpler way to dispose with this idea. Jorge, go down to
your local bars and cafes, and ask them if they'd be willing to accept a
form of payment that allows anyone to steal from them by simply paying
double the purchase price to some other random guy. They *will* look at you
as if you're crazy. Why would they ever do that?
--
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] 0 confirmation txs using replace-by-fee and game theory

2014-04-24 Thread Chris Pacia
This scheme would discourage people from attempting a Finney attack because
they would end up worse off if they did.

It would work but it's an ugly hack IMO. What do people do if they don't
have extra to pay when making a purchase? I have 200 mbtc and want to buy a
200 mbtc phone but I can't because I need 400 mbtc. Sucks for me.

I would much prefer the hassle of a green address notary than always having
to make sure I have double what I need to make a purchase.
On Apr 24, 2014 7:55 AM, "Mike Hearn"  wrote:

> Am I missing something?
>
>
> The scheme you described does nothing about Finney attacks, which is the
> issue presently faced.
>
>
> --
> 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] 0 confirmation txs using replace-by-fee and game theory

2014-04-24 Thread Mike Hearn
>
> Am I missing something?


The scheme you described does nothing about Finney attacks, which is the
issue presently faced.
--
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] 0 confirmation txs using replace-by-fee and game theory

2014-04-24 Thread Jorge Timón
Here is a solution to the problem of having 0 confirmation
transactions that relies on game
theory and most miners implementing replace-by-fee and child-pays-for-parent.

This has been proposed before
http://sourceforge.net/p/bitcoin/mailman/message/30876033/
I'm just going to describe the general idea in more detail.

Here's a small draft on how this could work:

Alice goes to Bob's store and wants to buy something cheaper than a
car, say a smartphone.
So Bob says, "it's 200 usd in btc, please pay me 400 usd in btc"
So Alice signs a tx with 400 and no fee with her old phone and she
just sends it to Bob rather than the network.
Bob creates a child transaction keeping 200 and giving 199.9 (0.1 usd
fee) back to Alice.

But you know, Alice wants to double spend.
She double spends 399.8 to herself (0.2 fee)
Bob thinks "last chance", he double-spends the child: 200 to Bob, back
199 to Alice (1 usd fee).
Alice is stubborn: 398 to Alice (2 usd fee).
Bob is really pissed off, double spends the child: 400 in fees.

So, ok, Bob lost the phone and got nothing but Alice has paid twice as
she needed for the phone.
Nobody's happy thus everybody's happy.

This is similar to the general game theory "stag hunt" case.
The payoff matrix could be something like this:

Bob returns change   Bob burns in fees
 -++---
  Alice behaves + 1 , + 1- 1, + 1
 -++---
  Alice double-spends   + 3, - 1 - 1, - 1

The game has two Nash equilibria, but cooperation is Pareto efficient.

Replace-by-fee and child-pays-for parent cannot be prohibited by a
protocol rule.
I believe all miners will eventually implement these policies because
it is the more rational way for them to prioritize transactions.
Finally I hope they do because it would make 0-confirmation
transactions possible as described in this post.
So I can't find any reasoning against replace-by-fee unless my example
is terribly flawed.
Am I missing something?

-- 
Jorge Timón

http://freico.in/

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

2014-04-24 Thread Mike Hearn
On Thu, Apr 24, 2014 at 1:22 PM, Jorge Timón  wrote:

> > I'm using it in the same sense Satoshi used it. Honest miners work to
> > prevent double spends. That's the entire justification for their
> existence.
>
> I thought the mechanism they used to prevent double-spends was proof of
> work.
> Therefore dishonest miners where only those who mine on top of a block
> which is not the longest valid chain they've seen.
>

No! This is a misunderstanding. The mechanism they use to prevent double
spends is to *ignore double spends*. The blocks they created indicate the
ordering of transactions they saw and proof of work is used to arrive at a
shared consensus ordering given the possibility that transactions arrived
at different times.

I'm continually amazed at how many people seem to see the current algorithm
as the goal in and of itself, instead of an imperfect but workable means of
achieving the actual goal.

To distinguish this definition from your own "honest miners are those
> who decide on double-spends by mining the transaction they saw first"
>

This definition of honesty is not my own, the one Bitcoin has always used.
Obviously if Satoshi had wanted transactions to be double spendable by fee
in the mempool he would have made Bitcoin work that way, instead of coming
up with the nSequence based replacement scheme instead.

First-seen *is* a protocol rule, as much as Set-Cookie storing data in a
browser is an HTTP protocol rule. The fact that auditing compliance with it
is harder to do than some others does not make it less of a rule.

I completely disagree.
> Miner's proof of work makes transactions irreversible.


Again you are hopelessly confused. Miners that are trying to double spend
are *by definition* not making transactions irreversible, they are trying
to make transactions reversible.

Look at it this way. There is no inherent reason BitUndo has to undo only
Finney attacks. If it gets sufficient hash power it could offer undoing of
1-confirm transactions too, right? Sure it'll mostly fail but that's
already a part of its business model. Sometimes it'll get two blocks in a
row and succeed. It's a very minor tweak to what they're doing. Would you
argue these miners are still useful? After all, it's impossible to be
certain after the fact that miners built on top of the "wrong" block
because forks occur naturally.


> Even if you always had to wait for transactions to be confirmed with
> some irreversible proof of work (as described in Satoshi's
> whitepaper), it doesn't follow that "automatically resolves the
> Bitcoin experiment as a failure". I don't understand how can you
> conclude that.
>

What I said is, if you believe all miners are willing to double spend for a
fee then this resolves the experiment as a failure. This is also obvious -
if you can pay miners to go back and rewrite the chain at will, Bitcoin
doesn't work.

Consider the incentives. Let's say all miners are "smart" in your
estimation and are willing to double spend transactions for higher fees.
Because all miners follow this ridiculous policy, they should be willing to
fork the chain at any point to claim the higher fee on the new tx. After
all, although they will throw away the work they did on the previous chain,
if the fee on the new tx is high enough to balance this then it can be
profitable for them to do it.

Because a double spender can afford to give nearly all of his new tx away
in fees, this means even txns well buried in the chain can be profitably
double spent: even if the double spender gets back only 10% of the
transferred amount, if it was a big transfer for some expensive object,
they still win! They got object + 10%

Do you see now why your definition of honesty is completely broken?
--
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

2014-04-24 Thread Jorge Timón
On 4/23/14, Mike Hearn  wrote:
>> I guess word "honest" might have different meanings, that can be a source
>> of confusing.
>> 1. Honest -- not trying to destroy bitcoin
>> 2. Honest -- following rules which are not required by the protocol
>>
>
> I'm using it in the same sense Satoshi used it. Honest miners work to
> prevent double spends. That's the entire justification for their existence.

I thought the mechanism they used to prevent double-spends was proof of work.
Therefore dishonest miners where only those who mine on top of a block
which is not the longest valid chain they've seen.
To distinguish this definition from your own "honest miners are those
who decide on double-spends by mining the transaction they saw first"
definition I propose to give another new name to the later, instead of
changing the definition of the former.
So inside the group of honest miners we have some that decide on
transactions based on reception times and others that simply maximize
their revenue while respecting the protocol rules.
I suggest "stupid miners" and "smart miners" respectively as more
clear terms for what we're talking about here.

> Miners that are deliberately trying to double spend are worse than useless.

I completely disagree.
Miner's proof of work makes transactions irreversible. Even if zero
confirmation transactions weren't possible in a replace-by-fee
environment, that's very useful.
Even if you always had to wait for transactions to be confirmed with
some irreversible proof of work (as described in Satoshi's
whitepaper), it doesn't follow that "automatically resolves the
Bitcoin experiment as a failure". I don't understand how can you
conclude that.

But in fact 0 conf txs are possible *precisely* using replace-by-fee,
as described in the "
0 confirmation txs using replace-by-fee and game theory" thread. So
that conclusion is definitely wrong.

On your concrete proposal, it seems to me that you're trying to
prevent double-spending without relying on proof of work, which I
think it impossible in the context of a truly p2p system.
I don't think your current proposal is secure and I fear that at best
you will end up with an "invite only" transaction processing network
like Ripple.com has with their consensus algorithm and Unique Node
Lists: that's not really p2p.

-- 
Jorge Timón

http://freico.in/

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

2014-04-24 Thread Mike Hearn
>
> Yes, you can reorg out the blocks and actually remove them, but I
>
understood that you were _not_ proposing that quite specifically. But
> instead proposed without reorging taking txouts that were previously
> assigned to one party and simply assigning them to others.
>

Well, my original thought was just to delete the coinbases. But then some
people don't like the idea of destroying money (equivalently, reducing the
system's resolution) so I proposed reallocating it instead. I'm not sure
which is better though. Deletion is closer to what the existing system
allows, for sure.

Would you feel differently if the consequence was UTXO deletion rather than
reallocation? I think the difference makes no impact to the goal of
discouraging double spending.


> ... proposing the mechanism be used to claw back mining income from a
> hardware vendor accused of violating its agreements on the amount of
> self mining / mining on customers hardware.
>

I think this would not be doable in practice, unless there was a way to
identify that a block was mined with pre-sold equipment. Peter points out
that the pool in question is marking their blocks by reusing addresses -
ditto for the double spending against dice sites - but that's a trivial
thing for them to fix. Then it'd be difficult (impossible?) for miners to
identify KnC blocks even if there was a strong majority consensus to delete
their coinbases.

The reason I think this particular change is doable is that it should be
possible to quite reliably identify blocks that are Finney attacking for
profit. That doesn't generalise to any policy though. Blocks are intended
to be structurally identical to each other if best practices are followed
and even with the dire pool situation a big chunk of mining hash power
today is effectively anonymous.
--
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

2014-04-24 Thread Gregory Maxwell
On Thu, Apr 24, 2014 at 1:39 AM, Mike Hearn  wrote:
> It absolutely is!
> https://bitcointalk.org/index.php?topic=60937.0

May I direct your attention to the third post in that thread?

Luke attempting to ret-con the enforcement flag into a vote didn't
make it one, and certantly wouldn't make it a fair, just, or sane
method of one. And so much for the effectiveness— you didn't implement
it for years even after it was deployed.

And yes, you can take any decision system and draw comparisons to
voting and call it a vote but that doesn't mean is serves the same
role or was intended for that purpose.

> No, coinbases are deletable. If some miners fork the chain and build a
> longer one, the others will all switch to it and the coinbases blocks they

Yes, you can reorg out the blocks and actually remove them, but I
understood that you were _not_ proposing that quite specifically. But
instead proposed without reorging taking txouts that were previously
assigned to one party and simply assigning them to others.

> I think the root of this disagreement is whether the block chain algorithm
> left by Satoshi is somehow immutable and itself the end, or whether it's (as
> I see it) just a means to an end and therefore an algorithm that can be
> tweaked and improved, to get us closer to the goal.

I don't think thats the root of the the disagreement at all. I think
all sorts of changes are interesting, especially ones that increase
flexibility or fix bugs but less so ones that would impose significant
changes on parties without their consent especially things that look
like taking someone's coins and assigning them to someone else.

I think the root is that you believe that the miners are, should be,
or even could be trustworthy in ways that I do not,  and as a result
you expect to be able to extract the performance of a trusted
centralized system out of them that I do not. Bitcoin is a system
where the incentives are well enough aligned that you appear to only
need a small amount of altruism to make it reliable. ... and even
summoning that altruism is a challenge— as miners hand over control of
their hash-power to centralized pools (some known to have behaved
poorly in the past), etc.

I would like that performance if it came at no cost: But proposals
that miners conspiring to blacklist transactions/blocks produced by
other people is something with a risk of a worse violation of the
system's promises than some disagreement of the ordering of
unconfirmed transactions.  Pretty much immediately after your post
Peter Todd— in his trouble making manner— went and posted on reddit
proposing the mechanism be used to claw back mining income from a
hardware vendor accused of violating its agreements on the amount of
self mining / mining on customers hardware.  While Peter's suggestion
was no doubt intentionally trouble making— I'm not clear on where the
line is here: Harm from reordering pretty much non-existent currently
and is highly speculative, while the harm to miners by hardware
vendors who've promised to not compete with their own customers or use
their equipment is not at all speculative and very salient to miners.

This especially in light of the fact that the system already has an
equitable method to decide what order transactions should be in... but
instead you propose an additional complex heuristic system where based
on some unspecified collusion some majority of miners take a
minorities coins and assign them to themselves.

Unlike reorginization this form of wealth transferal has no collateral
damage meaning that a majority cabal can use it to deprive a minority
outsider of some or all income without risking disrupting the network,
it would also lay the groundwork for additional forms of censorship
which I believe would be at odds with the purpose and architecture of
the system... and, as I noted above, it wouldn't actually prevent
theft, it would just mean that no single block could make its theft
services available to all comers (or even any of the public at all).
The simple mechenism of allowing only only a small number of paid
reordering transactions per block would prevent forming a quorum on
the decision to revoke the coinbase, and you'd even get additional
income from the probe transactions without even helping any real
double spends at all. The incentives seem very hard to analyze.

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

2014-04-24 Thread Andy Parkins
On Wednesday 23 April 2014 15:31:38 Mike Hearn wrote:
> > There _are_ consequences though: 95% of the time, you end up buying
> > something and paying for it.
> 
> Yeah, I was imagining a situation in which people who use Bitcoin regularly
> do buy things they actually want, but wouldn't say no to occasionally
> getting them for free (think coffees at starbucks etc). So if their double
> spend fails, no big deal, they're no worse off than if they didn't try.

Again true enough; but then we're back to evenly distributed dishonesty, and 
so you still don't get the potential 5% scam being used at 100% capacity.


Andy

-- 
Dr Andy Parkins
andypark...@gmail.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] Coinbase reallocation to discourage Finney attacks

2014-04-24 Thread Mike Hearn
On Thu, Apr 24, 2014 at 10:19 AM, Gregory Maxwell wrote:

> This is not voting.
>

It absolutely is! It was widely discussed as such at the time, here is a
thread where people ask how to vote and the operator of Eclipse said he was
removing his vote for P2SH:

https://bitcointalk.org/index.php?topic=60937.0

You might not feel it's a particularly fair or representative vote, but
it's still miners saying "I support enforcement of this new rule" or "I do
not support this" where the majority of cast votes wins. Some miners have
more votes than others, but it's still a vote.


> Yes, making really distributed systems that work in a complex world is
> hard. It certantly would be /easier/ to just declare miners "trusted
> parties"
>

Miners *are* trusted parties, they are just not all trusted simultaneously.
Bitcoin can tolerate a small number of dishonest miners whilst producing a
degraded service. It cannot work if all miners are dishonest or decide to
deviate from their intended operation, like if they all produce empty
blocks. The white paper made this clear from the start, and it's also
common sense.

Allowing the majority of honest miners to keep the dishonest ones in check
is what Bitcoin is all about. I don't understand this view that a very
small change to the existing protocol is somehow terrible or impossible,
but expecting everyone to simply build an entirely new system from scratch
is easy and inevitable. I'd much prefer to just keep the existing system
working as well as it has so far, and I think that is true of most users
too.


> Temporarily censoring transactions by orphaning otherwise valid blocks
> that contain them for as long as you retain a majority is possible


No, coinbases are deletable. If some miners fork the chain and build a
longer one, the others will all switch to it and the coinbases blocks they
previously mined will never become spendable (effectively they were
"deleted" before maturity). Only if the other miners also blacklist the
majorities fork and never join it, then the majority for some reason gives
up and rejoins the minority, is what you described correct. But why would
they do that? If they're the majority then all the other nodes will follow
them. They have no incentive to throw away their fork and rejoin the
minority chain ever again.

I think the root of this disagreement is whether the block chain algorithm
left by Satoshi is somehow immutable and itself the end, or whether it's
(as I see it) just a means to an end and therefore an algorithm that can be
tweaked and improved, to get us closer to the goal.

If the end is a useful payments system, as decentralised as possible, that
prevents double spending, then this proposal is a simple enhancement of the
current system that ensures corrupt miners don't get paid by honest users
for services they didn't provide, thus discouraging a particular kind of
attack.
--
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] Development Roadmap of Bitcoin Core 0.9.2

2014-04-24 Thread Wladimir
On Thu, Apr 24, 2014 at 10:15 AM, Warren Togami Jr.  wrote:

> I now see how it worked with Bitcoin 0.8.6.  Lucid has qt-4.6.2.
>
> It is more than one symbol.  It does not seem to be a wise thing to replace
> functions beyond the trivial in glibc and libstdc++.

Qt is not part of the compiler/build environment. Thus we don't need
to resort to those kind of tricks.

As I said: we can easily build against Qt 4.6 instead. As said, that
wouldn't even need building Qt on linux, just unpacking and exporting
the headers.

But indeed we need to decide on a cut-off point. I'd have preferred
4.7 or 4.8. Qt 4.6 is *ancient* - it was released in februari 2010.
Apart from tails it doesn't seem like anyone is using those old stable
distributions on the desktop.

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


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

2014-04-24 Thread Gregory Maxwell
On Thu, Apr 24, 2014 at 12:58 AM, Mike Hearn  wrote:
> The complexity overhead is trivial - we already used coinbase scriptSigs for
> voting on P2SH, I'm sure it'll be used for voting on other things in future
> too.

We use coinbase sigs to gauge the safety of enforcing a soft fork
several times and not just for P2SH, to determine when enforcement of
it will be decisive and not result in risking a partition in the
network that might permit transaction reversals. This is not voting.
As a feature decision mechanism his is a rather coercive thing because
it gives the highest hash-power bidders control even when their
interests may be rather thoroughly unaligned with population that owns
and uses bitcoin in general, but as a plain indicator of when its safe
to enforce a new rule (same mechanism, different motivation— though a
point is that safe usage means using much more than 50% as the
threshold) it works pretty well.

>  that's hugely complex and messy.

Yes, making really distributed systems that work in a complex world is
hard. It certantly would be /easier/ to just declare miners "trusted
parties" and require them to always collude to produce a single
consensus view of the world that is always honest and never
contradictory, except that it doesn't work. Because they aren't
individually trusted or even trustworthy.

> Why? Remember deleting coinbases with nothing more than a simple majority is
> already possible in the existing protocol and always has been.

Temporarily censoring transactions by orphaning otherwise valid blocks
that contain them for as long as you retain a majority is possible and
impossible to prevent in this architecture. This isn't the same as
deleting.  Deleting suggests the common misconception that a majority
of miners can do anything they want.

--
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] Development Roadmap of Bitcoin Core 0.9.2

2014-04-24 Thread Warren Togami Jr.
On Wed, Apr 23, 2014 at 10:02 PM, Wladimir  wrote:

> On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell 
> wrote:
> > On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. 
> wrote:
> >> If you are
> >> a rare user who needs Bitcoin-Qt on an incompatible system you can at
> least
> >> build it from source.
> >
> > Tails users usually can't really build it from source— talks is a live
> > boot mostly stateless linux distribution for privacy applications.
> > It's really good in general.
>
> Aside: But is Bitcoin Core a well-suited application for those uses? I
> cannot imagine someone running a full node on a stateless system.
>
> Anyhow: As this is only one symbol, we can probably get rid of it (as
> we didn't use it in 0.8.6?), or put it behind some #ifdef
> COMPATIBILITY_BUILD...
>
> Another option: Instead of statically building it'd be easy enough to
> build against the 4.6 Qt headers instead without even swapping the
> library. Qt is, after all, forward-compatible - between the 4.x
> versions. This will lose some GUI features but if compatibility is
> more important here that's a choice that can be made.
>
> Wladimir
>

I now see how it worked with Bitcoin 0.8.6.  Lucid has qt-4.6.2.

It is more than one symbol.  It does not seem to be a wise thing to replace
functions beyond the trivial in glibc and libstdc++.

I personally think we need to decide upon a cut-off point beyond which it
makes no sense to add the risk of increased complexity.  RHEL6 had qt-4.6.2
as well and I don't think I've heard a single complaint about bitcoin-qt
being broken there given almost nobody uses it as a desktop.

Warren
--
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

2014-04-24 Thread Thomas Voegtlin


Le 24/04/2014 09:21, Gregory Maxwell a écrit :
> 
> It doesn't appear to me that reoccurring payments, receive accounts,
> multisig addresses, etc can be used with this proposal, but instead
> you must use a different purpose code and another BIP and are not
> compatible with the draft here.
> 
> Am I misunderstanding it?   Will Electrum be limiting itself in this
> way?  I'd consider it a unfortunate loss of functionality if wallets
> couldn't implement reoccurring payment chains without making users
> generate entirely different wallets (which they couldn't share funds
> across) since addresses for recurring payments was one of the main
> motivations in BIP32.
> 
> 

No, Electrum will not be limiting itself in this way. I believe that we
are only at the beginning of exploring the different possibilities
opened by HD wallets. It will probably take years until we have clear
ideas on what users need, what choices they make, and how to organize
everything. Therefore it is too early to take decisions that might limit
future functionality.

I can see that it is very difficult today to find a consensus on wallet
structure between wallet developers. In addition, I changed my mind
several times on these questions, so I guess I will probably need to
change things again in the future.

This is why I decided to include a version number in Electrum seeds. The
version number will be updated everytime the wallet structure changes. I
know many developers do not follow me on this, but that is something I
am quite sure Electrum needs, despite all the other things I am not sure
about :)

I think it is too early to aim for inter-wallet compatibility today. I
guess we should postpone this goal, and move on with software releases.
As Andreas pointed out, we should just make sure that we do not import
an incompatible seed in another wallet, because not recovering all your
bitcoins would be a terrible user experience; the version number built
in the seed will ensure that for Electrum.

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

2014-04-24 Thread Mike Hearn
Right. So part of this is my fault, I'm afraid, because I do not intend to
implement any kind of subwallet/account support in bitcoinj. My reasons are:

   1. The bitcoinj API already lets you create and use multiple wallets.
   What's more, because of the desire to do key rotation (think rotating a
   previously unencrypted wallet to an encrypted one that is stored on SSD's
   that cannot reliably erase data), a bitcoinj wallet can actually contain
   multiple BIP32 seeds and hierarchies at once, although only the last one
   will be used for vending addresses. So adding subwallet support onto this
   makes it even more complicated.

   2. If there was a much better user experience to be enabled by this, it
   may be worth it, but I believe many people will find subwallets rather
   confusing. They don't match the analogy of bank accounts in several ways.
   For instance, transferring money across them leaks private data and costs
   miners fees, neither of which are true with banks.

   Also it differs in a more important way. People have different bank
   accounts because those accounts implement different policies. Current
   accounts may pay a lower interest rate than savings accounts, but have
   different features, and accounts can be used as security boundaries i.e. no
   card withdrawals from savings. But "subwallets" are not like this. The only
   justification for their existence is to avoid outputs being merged together
   to make payments - a subtle technical detail of the protocol that users are
   ill equipped to understand. If someone asked me "why should I create a
   second account" I would be unable to give them a satisfying answer without
   first teaching them about how the Bitcoin protocol works and the privacy
   implications of that, which is practically a lecture sized topic.

   3. MultiBit did support multiple wallets for a long time (just by
   creating multiple wallet files and using the support in bitcoinj for
   running them in parallel), but they decided to remove this feature in
   MultiBit HD because it caused support headaches. People would stash money
   in one wallet or the other, close the wallet and then forget and think they
   had lost it, etc. It may be that TREZOR type subwallets don't suffer this
   confusion because they can't be moved around or "closed" in the same way a
   file can be, but still, this is a data point against multiple simultaneous
   wallets. At least for products targeting entry level consumers.

Whilst I can well believe there are TREZOR users who are asking for this
feature today, currently the costs feel a bit higher than the benefits.

It would be rather nice to be able to type in a mnemonic code that myTREZOR
was initialised with and duplicate that wallet into a bitcoinj based wallet
app. But if I have to implement subwallets and expose this in the API, and
if all wallet authors that want to be able to share a wallet with myTREZOR
have to expose subwallets in their GUIs too, even though the concept may
prove confusing and hard to explain, then it might be more tempting to just
tell users that want to switch wallet apps to send the money via the block
chain instead.




On Thu, Apr 24, 2014 at 9:10 AM, Pieter Wuille wrote:

> On Thu, Apr 24, 2014 at 8:54 AM, Thomas Voegtlin  wrote:
> >> Why do clients need to use the features in BIP 64? If Electrum doesn't
> want to
> >> use accounts, [...]
> >
> > To clarify:
> > Electrum plans to have bip32 accounts; Multibit will not, afaik.
>
> To clarify:
> BIP64 has a much stricter definition for accounts than BIP32.
>
> In BIP32, it is not well specified what accounts are used for. They
> can be used for "subwallets", "receive accounts" (as in bitcoind's
> account feature), "recurring payments", part of a chain used as
> multisig addresses, ... determined individually for each index.
>
> In BIP64, they are strictly used for subwallets, and can't be used by
> anything else.
>
> --
> 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
>
--
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-developm

Re: [Bitcoin-development] Development Roadmap of Bitcoin Core 0.9.2

2014-04-24 Thread Wladimir
On Thu, Apr 24, 2014 at 10:02 AM, Wladimir  wrote:
> On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell  wrote:
>> On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr.  wrote:
>>> If you are
> > Another option: Instead of statically building it'd be easy enough to
> build against the 4.6 Qt headers instead without even swapping the
> library. Qt is, after all, forward-compatible - between the 4.x
> versions. This will lose some GUI features but if compatibility is
> more important here that's a choice that can be made.

Are you sure this is Qt 4.6 at all? Not Qt 4.7?

I'd expect *much* more symbols if this was a Qt 4.8 versus 4.6
conflict. Qt 4.7 introduced a lot of new things (see all the
occurences of  #if QT_VERSION >= 0x040700 - things like
setPlaceHolderText would be expected to pop up too), but 4.8 did not.

Can you check?

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


Re: [Bitcoin-development] Development Roadmap of Bitcoin Core 0.9.2

2014-04-24 Thread Wladimir
On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell  wrote:
> On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr.  wrote:
>> If you are
>> a rare user who needs Bitcoin-Qt on an incompatible system you can at least
>> build it from source.
>
> Tails users usually can't really build it from source— talks is a live
> boot mostly stateless linux distribution for privacy applications.
> It's really good in general.

Aside: But is Bitcoin Core a well-suited application for those uses? I
cannot imagine someone running a full node on a stateless system.

Anyhow: As this is only one symbol, we can probably get rid of it (as
we didn't use it in 0.8.6?), or put it behind some #ifdef
COMPATIBILITY_BUILD...

Another option: Instead of statically building it'd be easy enough to
build against the 4.6 Qt headers instead without even swapping the
library. Qt is, after all, forward-compatible - between the 4.x
versions. This will lose some GUI features but if compatibility is
more important here that's a choice that can be made.

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


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

2014-04-24 Thread Mike Hearn
On Thu, Apr 24, 2014 at 12:06 AM, Alex Mizrahi wrote:
>
> Different approaches have different trade-offs, and thus different areas
> of applicability.
>
> Proof-of-work's inherent disadvantage is that it takes some time until
> transaction becomes practically irreversible. On the other hand, it has
> advantages like neutrality, censorship-resistance, high degree of security,
> etc.
>

Sure, they have different tradeoffs. My assertion is this:  the costs and
disadvantages that come with building what is in effect an entirely
parallel and separate system for stopping double spends, are much much
worse than making simple tweaks to strengthen the mechanism we already have.

Put another way, the cost/benefit ratio of this proposal seems much better
to me than the alternatives.


> In this case you get benefits of both approaches.
>

You also get the costs of both approaches, which are extremely significant.

 Censorship-resistance is irrelevant when one buys a cup of coffee with his
> pocket money, isn't it?


That's like saying banks can't censor you because you can always withdraw
all your money in cash. But in practice:

   1. That's a huge pain in the ass so nobody does it
   2. Many merchants will refuse non-trivial payments in cash and demand
   bank money because it's simpler for them

Analogously, having to wait some large expiry period to extract your money
from the "double spending prevention service" (a.k.a. bitbank) is a pain in
the ass, and many merchants would refuse to take your newly double
spendable money even if theoretically they could, because it keeps their
operations much simpler if they can just assume a sale is final and can't
be reversed.

So I think such a scheme would rapidly return to the a world that looks
much like the one we have now.


> For some reason, instead of considering these hybrid solutions (which can
> also address scalability problems), you want to make PoW-based system more
> complex to be applicable for real-time transaction too.
>

The complexity overhead is trivial - we already used coinbase scriptSigs
for voting on P2SH, I'm sure it'll be used for voting on other things in
future too. So that's already in place. Counting up votes and editing the
UTXO set is the sort of patch one guy can create, it's not very big. And
it's conceptually just the same as what miners can do today by re-orging
out blocks, but with much less impact on end users and less implementation
complexity (no giant reorgs that might themselves have to split recursively
whilst they're being built).

On the other hand, building an entirely separate system, with separate
trusted companies that have trusted brand names, adding support to all the
wallets, getting all sellers on board, making everything use an extended
BIP 70 (as that's the only real way to implement it), trying to explain to
users why they're now expected to pay extra fees when they previously
didn't and then discovering that you got a choice of only a handful of
double-spend-preventers everyone could agree on with little potential for
more  that's hugely complex and messy.


> This will, likely, weaken advantages provided by PoW
>

Why? Remember deleting coinbases with nothing more than a simple majority
is already possible in the existing protocol and always has been.
--
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

2014-04-24 Thread Thomas Voegtlin


Le 24/04/2014 09:10, Pieter Wuille a écrit :
> To clarify:
> BIP64 has a much stricter definition for accounts than BIP32.
> 
> In BIP32, it is not well specified what accounts are used for. They
> can be used for "subwallets", "receive accounts" (as in bitcoind's
> account feature), "recurring payments", part of a chain used as
> multisig addresses, ... determined individually for each index.
> 
> In BIP64, they are strictly used for subwallets, and can't be used by
> anything else.
> 

yes, I saw that.

In particular, bip64 stipulates that the wallet "never mixes coins
across different accounts". This is not what Electrum does currently.
The UI allows you to chose between two modes: activate a single account
(and the wallet will only use UTXOs from that acccount), or activate all
accounts (and spend from all of them simultaneously).

Concerning multisig addresses, I have changed my mind: Electrum will use
parallel BIP32 trees. A wallet will not mix standard and multisig
accounts. I think that is better in terms of UX.

I agree with Mike Hearn's view that wallets with multiple accounts are
probably too difficult to deal with for most users. If a user feels the
need to have different "accounting identities", they will probably
create different wallet files, instead of creating bip32 subwallets.

However, since multiple subwallets have been asked by many users,
Electrum will propose them. But this should not be the default. More
important, multiple accounts should never be required (in my previous
implementation, they were required for multisig, because the wallet was
creating multisig addresses in dedicated multisig accounts)

Thomas

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

2014-04-24 Thread Gregory Maxwell
On Thu, Apr 24, 2014 at 12:10 AM, Pieter Wuille  wrote:
> On Thu, Apr 24, 2014 at 8:54 AM, Thomas Voegtlin  wrote:
>>> Why do clients need to use the features in BIP 64? If Electrum doesn't want 
>>> to
>>> use accounts, [...]
>>
>> To clarify:
>> Electrum plans to have bip32 accounts; Multibit will not, afaik.
>
> To clarify:
> BIP64 has a much stricter definition for accounts than BIP32.
>
> In BIP32, it is not well specified what accounts are used for. They
> can be used for "subwallets", "receive accounts" (as in bitcoind's
> account feature), "recurring payments", part of a chain used as
> multisig addresses, ... determined individually for each index.
>
> In BIP64, they are strictly used for subwallets, and can't be used by
> anything else.

It doesn't appear to me that reoccurring payments, receive accounts,
multisig addresses, etc can be used with this proposal, but instead
you must use a different purpose code and another BIP and are not
compatible with the draft here.

Am I misunderstanding it?   Will Electrum be limiting itself in this
way?  I'd consider it a unfortunate loss of functionality if wallets
couldn't implement reoccurring payment chains without making users
generate entirely different wallets (which they couldn't share funds
across) since addresses for recurring payments was one of the main
motivations in BIP32.

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

2014-04-24 Thread Pieter Wuille
On Thu, Apr 24, 2014 at 8:54 AM, Thomas Voegtlin  wrote:
>> Why do clients need to use the features in BIP 64? If Electrum doesn't want 
>> to
>> use accounts, [...]
>
> To clarify:
> Electrum plans to have bip32 accounts; Multibit will not, afaik.

To clarify:
BIP64 has a much stricter definition for accounts than BIP32.

In BIP32, it is not well specified what accounts are used for. They
can be used for "subwallets", "receive accounts" (as in bitcoind's
account feature), "recurring payments", part of a chain used as
multisig addresses, ... determined individually for each index.

In BIP64, they are strictly used for subwallets, and can't be used by
anything else.

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