> The subsidy to miners will finish and bitcoin miners will live only on fees.
> There's also other alts where the subsidy ends much faster.
> But even if transaction fees are a minimal part of miner's total
> reward, even a 1% annual return difference mean the difference between
> a profitable and an unprofitable operation.
I think most miners (even industrial) lose money, or at least go
through long periods when they are unprofitable and are holding out
for higher btc prices or better chips from the fab, infrastructure
improvements, or what have you. There's brief periods of insane
profitablility along with long periods of frustration. That makes
miners vulnerable. Eventually transactions will take over and asics
become a commodity built into every heater on the planet, and mining
is boring low profit and predictable (like web hosting), but this is
decades from now. Right now, miners are not going to be putting up the
fight against government meddling. They are too busy trying to
survive.
> If Bitcoin becomes the orwellian virtual currency that the people on
> top of the pyramid dream about, we will just switch to another alt
> that keeps being a p2p currency uncontrolled by anyone.
Same problems will crop up with any alt. Too private, and states will
kill it by 51% attack or other sneaky means, strangling it in the
cradle while it's still a baby. Too transparent, and you might as
well use credit cards. Privacy is not only an advantage, attackers can
take advantage of privacy too. There is always a tradeoff between
security and convenience. Crypto currencies fill a niche, and it's non
obvious what the optimal survival characteristics are.
>> I'll try to go a little more technical now. Picking up from my earlier
>> comment, there are (at least) two privacy attacks worth pondering
>>
>> 1) address registration
>> 2) prohibition of mixing
>>
>> These are distinct scenarios. In particular, you could have address
>> registration but tumbling permitted, so a state could form a picture of what
>> everyone has and tax wealth; but not necessarily form a picture of the
>> flows.
>
> They could also censor transactions coming out certain addresses. Any
> address owned by a dissident of the system, for example. This is
> intolerable. And the currency wouldn't be p2p anymore so it wouldn't
> make sense to keep using a costly p2p global consensus algorithm when
> there's no gain compared to running the system in a single centralized
> server.
You make a strong argument here. But I don't see it being one extreme
of the other. Example, the NSA logs everything, but a motivated
dissident can use Tor. But maybe the NSA has enough tor nodes to
compromise the network. Cat and mouse. Power squeezes the free parts
of the network, freedom squirrels away a little niche that it is
dangerous for power to touch. After all, power needs freedom to
maneuver sometimes too. So if we get a push for address registration
it won't be jackboots and a knock at the door, it will be sold as
convenience, comfort and safety, insured bitcoin without the fear of
getting everything stolen, and so on. And whitelists won't be
universal, but it will certainly be harder to hide. Everybody that
uses gmail and google docs rather than runs their own server know what
I'm talking about.
So my point if I have one is that darkwallet needs to appeal to
convenience too if it wants to win.
>> One could also imagine a scenario where addresses are not required to be
>> registered, but dark wallet style transaction tumbling is hounded into the
>> shadows to the point where it only exists on the fringes. This one seems
>> less likely to me, but not completely impossible. Such a scenario a state
>> attacker (or maybe even a motivated detective agency) could probably form a
>> picture of what addresses are linked using transaction flow analysis.
>> However, tumbling could at least deter casual block chain analysis, on the
>> level of casual clicking around in block chain.info
>>
>> The second scenario is quite inimical to dark wallet, and could result in
>> the project essentially drifting into irrelevancy if it is carried out on a
>> global scale.
>
> CoinSwap transactions just look like regular escrow transactions. How
> do you censor those?
If there are centralized coinswap servers to make it work faster and
more convenient, you shut those down.
If everything works really peer to peer, you find someone that made a
coinswap transaction where they sent bitcoin to a terrorist or a
pedophile (could be intentional entrapment by someone in exchange for
early release from prison), and you make an example out of him.
Money laundering is a crime but it's a gray area. Sometimes it is
tolerated, because it's too inconvenient to crack down, or because the
criminals have state ties. This is the reality that is being
navigated.
I think coinswap could become successful if is just too inconvenient
to do anything about. Of couse, some people will use it wrong and get
busted for whatever they are trying to do, just like some people use
tor wrong. To be clear, I am cautiously optimistic on coinswap.
>> The first scenario is more interesting to me. Carried to its logical
>> extreme, it would force states to tax wealth not income. And is this really
>> so bad?
>
> Yes, Orwellian money would be very bad and dangerous.
The funny thing is, Bitcoin already is almost orwellian money, unless
you take great pains. People think they are wearing a ski mask when it
is more like a fake mustache. That is why we have darkwallet effort in
the first place.
> Many people assume that bitcoin can make taxation unfeasible if it's
> not orwellian money like our bank deposits, but that doesn't make much
> sense.
> Orwellian money is relatively new and states have taxed anonymous gold
> without problem.
> There's indirect taxes, tax on land rents (Henry George's proposed
> "single tax"), circulation taxes and a myriad of other taxation forms
> that can't be easily avoided.
> Probably the US army cannot be maintained without ever growing debt,
> but the current situation is unsustainable with or without bitcoin.
> But money that respects their users privacy won't kill states.
>
>> In particular, I wonder if it behooves dark wallet to adopt a position of
>> agnosticism towards address registration, and focus its argument and
>> lobbying rather on hindering flow analysis.
>>
>> Address registration is going to be a fight in 2014, wherever there are
>> governments and bitcoin. But does it need to be dark wallet's fight?
>
> As said I think is intolerable and is everybody's fight.
> If our enemies have success, Bitcoin will no longer be a p2p currency:
> it would become orwellian money, which is simply incompatible with
> p2p.
>
> Probably we should start another thread if we want to keep talking
> about address white-listing...
I will continue on another thread if you start one. That is, if there
is anything left to say. I don't want to necessarily beat this into
the ground either.
Maybe whitelisting won't even happen. But if you are preparing for it
to happen, and you want to fight it, you need to think hard how you're
going to do it. It won't be easy or straightforward.
Darkwallet seems to me not to make much difference one way or the
other when it comes to the whitelist.
>
>> On Dec 27, 2013, at 12:36 PM, Jorge Timón wrote:
>>
>>> I don't think this kind of legal attack is very realistic.
>>> While there's miners that don't censor txs with "unregistered
>>> addresses", all those transactions can go trough them.
>>> Say the US tries to enforce white lists through US-based pools.
>>> There will be other pools in other countries or even in tor.
>>> Are they going house by house looking for ASIC buyers? Mining the
>>> transactions with the highest fees instead of only the "white ones"
>>> will always be more profitable, so they're really only pushing mining
>>> out of the country and making the local miners who try lose money on
>>> their investments because they can't compete with foreign miners.
>>> Which country will copy those regulations next? After seeing that
>>> produce undesirable economic results and at the same time don't impede
>>> transactions with addresses outside of their white-listing centralized
>>> server?
>>> The idea of a centralized white-list server for a p2p currency is so
>>> stupid that failure is the only possible outcome I contemplate.
>>> But even if this ever became a real problem, we could always switch to
>>> a less efficient system that guarantees anonymity ala zerocoin or
>>> other similar proposals.
>>>
>>> So, Daniel, I completely disagree with your analysis, but I'm curious
>>> as to what's your proposed replacement for PoW. I guess you want
>>> something like proof of stake or ripple.com's consensus?
>>> Both have much bigger problems than PoW.
>>>
>>>
>>> On 12/23/13, Metatron YHVH <metatrongone@???> wrote:
>>>> So if the powers that be can set up god tier mining pools, then how is
>>>> this
>>>> even fair?
>>>>
>>>> The fiat currency of today is still governing who has how much and that
>>>> doesn't give me much hope for crypto currencies as a whole.
>>>>
>>>> Moreover, I don't like politics however, as soon as those bastards on
>>>> C-Span made bitcoin apart of the conversation, bitcoin became a political
>>>> topic.
>>>>
>>>> The Dark Wallet is a good idea, but it doesn't matter what technology you
>>>> have, as long as people influence (or govern) the USERS, you might as
>>>> well
>>>> sign up a coinbase account.
>>>>
>>>> - Metatron
>>>>
>>>>
>>>> On Mon, Dec 23, 2013 at 11:16 AM, Daniel Larimer <
>>>> dlarimer@???> wrote:
>>>>
>>>>> The solution is to move away from Proof-of-Work based coins.
>>>>>
>>>>>
>>>>> On Dec 23, 2013, at 1:59 PM, Thomas Hartman <thomas@???>
>>>>> wrote:
>>>>>
>>>>>> Mining is moving to an industrial model, giant shipping containers
>>>>>> full of gear that costs millions of dollars. Regulation by the state
>>>>>> seems almost inevitable to me.
>>>>>>
>>>>>> So I think if the state and regulators can capture miners and force
>>>>>> them to only clear transactions to registered addresses, what can a
>>>>>> technology such as darkwallet do?
>>>>>>
>>>>>> This is a political fight, isn't it?
>>>>>>
>>>>>> The freedom to have an unregistered address (financial privacy) is
>>>>>> either a basic human right, recognized by governments and citizens
>>>>>> across the globe (and >51% of miners), or it isn't.
>>>>>>
>>>>>> If there is regulatory capture of the miners, my understanding is dark
>>>>>> wallet could still provide obfuscation of FLOWS, even though balances
>>>>>> would be transparent. So, the government could tax your bitcoin but
>>>>>> they might not know where it came from. It's still more freedom than
>>>>>> every flow being known and datamined.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Dec 23, 2013 at 9:58 AM, Amir Taaki <genjix@???> wrote:
>>>>>>> Freezing BitCoin addresses by regulating miners, April 2011
>>>>>>> https://bitcointalk.org/index.php?topic=5979.0
>>>>>>>
>>>>>>> "Whilst I think it's inevitable, this sort of legal framework would
>>>>>>> ultimately be self regulating and so should not be feared. BitCoin is
>>>>>>> a
>>>>>>> system for agreeing on a global consensus around the ordering of
>>>>>>> transactions. If that consensus is truly a consensus then there will
>>>>>>> no
>>>>>>> be real controversy over the freeze orders and few (or no) miners will
>>>>>>> ignore them. Consider temporarily freezing the assets of Gadaffi or
>>>>>>> Mubarak as examples."
>>>>>>>
>>>>>>> pushing blacklists from way back when.
>>>>>>>
>>>>>>> On 23/12/13 16:22, Thomas Hartman wrote:
>>>>>>>> Short answer no, long answer barely.
>>>>>>>>
>>>>>>>> Node distribution of miners has some impact on centralization of
>>>>>>>> power,
>>>>>>>> which has implications for state and regulatory capture of bitcoin.
>>>>>>>> And
>>>>>>>> in the long run DW may want to lobby the miners to prioritize certain
>>>>>>>> types of transactions.
>>>>>>>>
>>>>>>>> In the short run I think we don't need to think about mining.
>>>>>>>>
>>>>>>>> On Dec 22, 2013 10:02 PM, "Metatron YHVH" <metatrongone@???
>>>>>>>> <mailto:metatrongone@gmail.com>> wrote:
>>>>>>>>
>>>>>>>> Is mining relevant here?
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Dec 22, 2013 at 9:36 AM, Thomas Hartman
>>>>>>>> <thomas@??? <mailto:thomas@standardcrypto.com>>
>>>>> wrote:
>>>>>>>>
>>>>>>>> Well, at least you posted some budget and a spec.
>>>>>>>>
>>>>>>>> You still hijacked the thread (3 threads) though. If you would
>>>>> at
>>>>>>>> least start a new thread, it would be somewhat more socially
>>>>>>>> acceptable.
>>>>>>>>
>>>>>>>> On Sun, Dec 22, 2013 at 8:49 AM, Metatron YHVH
>>>>>>>> <metatrongone@??? <mailto:metatrongone@gmail.com>>
>>>>>>>> wrote:
>>>>>>>>> Bitcoins and RFID currency. I've got 7,692 USD to anyone who
>>>>>>>> prove they are
>>>>>>>>> different.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sun, Dec 22, 2013 at 7:47 AM, caedes <caedes@???
>>>>>>>> <mailto:caedes@sindominio.net>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi!
>>>>>>>>>>
>>>>>>>>>> On 19/12/13 18:23, Mike Belshe wrote:
>>>>>>>>>>> Hey Peter -
>>>>>>>>>>>
>>>>>>>>>>> I think this is a super list. A couple of thoughts:
>>>>>>>>>>>
>>>>>>>>>>> a) In the section on multi-sig and multi-factor, I think we
>>>>>>>> can split
>>>>>>>>>>> these apart. Multi-factor user authentication is very
>>>>>>>> valuable and not
>>>>>>>>>>> the same as multi-factor signing, which is a second level of
>>>>>>>>>>> complexity. The multi-factor auth can be off-blockchain, e.g.
>>>>>>>>>>> authenticating with SMS message to your phone or Google
>>>>>>>> Authenticator
>>>>>>>>>>> challenge. Given the state of malware today, I personally
>>>>>>>> would
>>>>>>>>>>> propose two requirements:
>>>>>>>>>>> 1) wallets SHOULD use multi-factor authentication before
>>>>>>>>>>> authorizing access to a wallet (e.g. view balances, addresses,
>>>>>>>>>>> transactions, etc)
>>>>>>>>>>> 2) wallets MUST use multi-factor auth before signing a
>>>>>>>>>>> transaction. [note: I recognize that MUST might be too
>>>>>>>> aggressive
>>>>>>>>>>> right now, but I wouldn't use a wallet without it. this
>>>>>>>> can also be
>>>>>>>>>>> impractical for server-side wallets]
>>>>>>>>>>
>>>>>>>>>> Using multi-sig for multi-factor so the wallet needs to get some
>>>>>>>>>> additional signatures (or even the keys can be somewhere
>>>>>>>> else) can make
>>>>>>>>>> 2factor more orthogonal to the whole thing specially since we
>>>>>>>> need to
>>>>>>>>>> support multisig spending, and other partial transaction
>>>>>>>> fullfilling.
>>>>>>>>>>
>>>>>>>>>> We can still account for other 2fa schemes, but i'm thinking
>>>>>>>> more of
>>>>>>>>>> exploiting key signing itself and maybe bip32 wallet structure.
>>>>>>>>>>
>>>>>>>>>> I agee on uour requirements, but also think they might be too
>>>>>>>> harsh for
>>>>>>>>>> some uses I would require them myself so I could feel safe
>>>>>>>> with my wallet.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> b) Multi-factor signing (e.g. P2SH) may be too early to
>>>>>>>> really define.
>>>>>>>>>>> But here are some issues which have come up from my own
>>>>>>>> personal
>>>>>>>>>>> development experience:
>>>>>>>>>>> - Wallets SHOULD NOT create two keys on a single host
>>>>>>>> or device
>>>>>>>>>>> - Wallets SHOULD provide a way to import external
>>>>>>>> public keys
>>>>>>>>>>> which can be used as part of a P2SH address
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Agree on these ones. Public keys could be imported through
>>>>>>>> extended
>>>>>>>>>> public keys too if we agree to using those.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Slightly off topic: For P2SH, address creation requires
>>>>>>>> the public
>>>>>>>>>>> key, not the public hash of an address. For me, this has
>>>>>>>> made it
>>>>>>>>>>> difficult to import keys created through out-of-band
>>>>>>>> sources. Most
>>>>>>>>>>> wallets/key generators/etc only provide the address and not
>>>>>>>> the public
>>>>>>>>>>> key, and this is a hinderance to easy P2SH creation off
>>>>>>>> host. It
>>>>>>>>>>> would be great if there were a way to address this, but I
>>>>>>>> don't know
>>>>>>>>>>> how.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> We have to work on solutions... our aim is settle down on a
>>>>>>>> way to
>>>>>>>>>> negotiate addresses and other parameters among identities,
>>>>>>>> also key
>>>>>>>>>> importing can be supported to make these easier.
>>>>>>>>>>
>>>>>>>>>> cheers!
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> unSYSTEM mailing list: http://unsystem.net
>>>>>>>>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> ॐMetatronॐ
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> unSYSTEM mailing list: http://unsystem.net
>>>>>>>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> unSYSTEM mailing list: http://unsystem.net
>>>>>>>>
>>>>>>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>>
>>>>>>>> ॐMetatronॐ
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> unSYSTEM mailing list: http://unsystem.net
>>>>>>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> unSYSTEM mailing list: http://unsystem.net
>>>>>>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> unSYSTEM mailing list: http://unsystem.net
>>>>>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>>>>>>>
>>>>>> _______________________________________________
>>>>>> unSYSTEM mailing list: http://unsystem.net
>>>>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>>>>>
>>>>> _______________________________________________
>>>>> unSYSTEM mailing list: http://unsystem.net
>>>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> ॐMetatronॐ
>>>>
>>>
>>>
>>> --
>>> Jorge Timón
>>>
>>> http://freico.in/
>>> _______________________________________________
>>> unSYSTEM mailing list: http://unsystem.net
>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>>
>> _______________________________________________
>> unSYSTEM mailing list: http://unsystem.net
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>>
>
>
> --
> Jorge Timón
>
> http://freico.in/
> _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
::
Re: [unSYSTEM] [Bitcoin-development…
