Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

On Tue, Jan 23, 2018 at 12:30:06AM +, Gregory Maxwell via bitcoin-dev wrote: > One point that comes up while talking about merkelized scripts is can > we go about making fancier contract use cases as indistinguishable as > possible from the most common and boring payments. > Now we tweak C to

Re: [bitcoin-dev] Blockchain Voluntary Fork (Split) Proposal (Chaofan Li)

The human perception of difference will be eliminated. Will your bank tell you whether your balance means coins or paper money? If wallets and exchanges only show the total amount of btc rather than btc.0 and btc.1, there is no human perception difference. Also note that one valid address is

Re: [bitcoin-dev] Blockchain Voluntary Fork (Split) Proposal (Chaofan Li)

On 01/22/2018 04:38 PM, Chaofan Li via bitcoin-dev wrote: > Miners are most likely to be  equally distributed between the two almost > same chains. This is irrelevant as miners don't determine the utility of a money, they anticipate it. However you don't have to accept this to recognize the error

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

This sounds like a useful idea for improving the privacy of coinswap. Traditionally coinswap mixing had an anonymity set related to the number of multisig transactions being used on the blockchain. With the new tech of Schnorr, MAST and now this Taproot, with sufficient adoption coinswap's

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

On Mon, Jan 22, 2018 at 7:21 PM, Russell O'Connor wrote: > At this point, is it better just to use GF(2^256+n)? Is GF(2^256+n) going > to be that much slower than GF(2^8) that we care to make things this > complicated? (I honestly don't know the answer.) I expect it

Re: [bitcoin-dev] Blockchain Voluntary Fork (Split) Proposal (Chaofan Li)

Miners are most likely to be equally distributed between the two almost same chains. If one chain is faster, according to the difficulty adjustment scheme, it will become more difficult to mine. The two chain should have similar chain generation rates with similar difficulty and similar length.

Re: [bitcoin-dev] Blockchain Voluntary Fork (Split) Proposal (Chaofan Li)

This is true but confuses people because obviously miners must commit capital to mining before any block space can exist to have value. The reason for the misunderstanding is that miners don’t simply respond, they anticipate. All production, and therefore capital investment, is the result of

Re: [bitcoin-dev] Blockchain Voluntary Fork (Split) Proposal

All other things being equal, the money with the larger network is more useful due to the cost of exchange between them, which can only be eliminated by one absorbing the network of the other. According the Thiers’ law (i.e. in the absence of currency controls), the more useful money will get

Re: [bitcoin-dev] Blockchain Voluntary Fork (Split) Proposal

Without enforcement liquidity will diverge. On Mon, Jan 22, 2018 at 1:46 PM, Chaofan Li via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi ZmnSCPxj > > I dont think they need to be ENFORCED to be worth the same. > If the two chains’ algorithms are the same , except some

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

On Thu, Jan 18, 2018 at 1:58 PM, Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Thu, Jan 18, 2018 at 4:59 PM, Ondřej Vejpustek > wrote: > >> If being secure against partial share leakage is really part of your > >> threat

Re: [bitcoin-dev] Blockchain Voluntary Fork (Split) Proposal (Chaofan Li)

> On Jan 22, 2018, at 11:01 AM, Ilan Oh via bitcoin-dev > wrote: > > The chain with the most mining power will tend to have more value. I believe you have the causality on that backwards. The tokens which are worth more value will attract more mining

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

> Most transactions don't have change?! Under what circumstance? For most > use-cases the reverse is true: almost all all transactions have change, > because > it's rare for the inputs to exactly math the requested payment. It's actually a common misconception. With good coin selection, I am

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

On Mon, Jan 22, 2018 at 12:40:31PM -0500, Rhavar via bitcoin-dev wrote: > So my half-baked idea is very simple: > > Allow users to merge multiple unconfirmed transactions, stripping extraneous > inputs and change as they go. > > This is currently not possible because of the bip125 rule: > "The

Re: [bitcoin-dev] Blockchain Voluntary Fork (Split) Proposal (Chaofan Li)

How do you handle the mining on each chain ? The chain with the most mining power will tend to have more value. Also blocks are not mined equally and 1 chain will be longer than the other thus faster thus more valuable. It seems to be a sidechain proposal with the exact same protocol.

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

> Perhaps they could even replace old tx with economically equivalent summary > transactions? I imagine with schnorr signatures, the incentives will emerge for that to make sense. But right now if I want to merge my transaction with an untrusted party in general we're only really going to be

Re: [bitcoin-dev] Blockchain Voluntary Fork (Split) Proposal

Hi ZmnSCPxj I dont think they need to be ENFORCED to be worth the same. If the two chains’ algorithms are the same , except some identifiers (eg. btc.0 btc.1）, they have no reason to have different value. If so, the market will adjust the value. Also, the total supply can be the same. The amount

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

Along the same lines, I wonder if unrelated people with tx that are not confirming could cooperate to merge their disparate tx into a CoinJoin tx with a higher fee rate? Perhaps they could even replace old tx with economically equivalent summary transactions? The mempool seems like nature's

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

> So now I still owe John 1 BTC, however it's not immediately clear if it's safe to send to him If you spent your change from transaction A, that would be safe. There'd be no way you John could end up with 2 BTC from you then. On Mon, Jan 22, 2018 at 1:40 PM, Rhavar via bitcoin-dev <

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

> If you spent your change from transaction A, that would be safe. There'd be > no way you John could end up with 2 BTC from you then. Yes, that's what the following paragraph says -- along with it's limitations =) -Ryan Original Message On January 22, 2018 1:16 PM, Alan

[bitcoin-dev] Transaction Merging (bip125 relaxation)

So my half-baked idea is very simple: Allow users to merge multiple unconfirmed transactions, stripping extraneous inputs and change as they go. This is currently not possible because of the bip125 rule: "The replacement transaction pays an absolute fee of at least the sum paid by the original

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

> > My post provided a concrete example. I'd be happy to answer any > questions about it, but otherwise I'm not sure how to make it more > clear. My apologies, I didn't read it carefully. You are absolutely right. Our scheme doesn't protect against the scenario. > Quite the opposite-- a large

Re: [bitcoin-dev] Blockchain Voluntary Fork (Split) Proposal

Good morning Chaofan Li, What enforces that bitcoin A is worth the same as bitcoin B? Or are they allowed to eventually diverge in price? If they diverge in price, how is that different from the current situation with Bitcoin, BCash, Bitcoin Gold, Bitcoin Hardfork-of-the-week, and so on?