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
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 autom
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
Thanks Greg!
I'd be hesitant to deploy a MAST proposal without this clever application of
pay-to-contract-hash now! Looks like the overhead over a more-naive MAST
construction is rather trivial, too!
Matt
On January 23, 2018 12:30:06 AM UTC, Gregory Maxwell via bitcoin-dev
wrote:
>Interest i
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 anonymit
Interest in merkelized scriptPubKeys (e.g. MAST) is driven by two main
areas: efficiency and privacy. Efficiency because unexecuted forks of
a script can avoid ever hitting the chain, and privacy because hiding
unexecuted code leaves scripts indistinguishable to the extent that
their only differenc
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 would be especially since op
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.
or
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 ant
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 us
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 identifi
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 model the current proposal is gratuit
> 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 hash rate. Miners respond to cash-out
val
> 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 able
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 r
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.
__
> 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 sa
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
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 accum
> 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 <
bitcoin-dev@
> 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 Evans
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
>
> 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 bl
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?
Reg
24 matches
Mail list logo
