<unnamed>

Public Key

npub15n7zls4lcps7wksmdctal39neyact74jljgsq86ylkzfn4njk95sv8vrz4

Profile Code

nprofile1qqs2flp0c2luqc08tgdku97lcjeujwu9l2e0eygqraz0mpye6eetz6gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsyncjcs

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-07 18:23:39 UTC

- reply

📅 Original date posted:2020-03-27
📝 Original message:Big picture, it seems to me this idea is workable and very interesting. I see
three likely enhancements that will be necessary or desirable:
1. Atomic swap of multiple UTXOs, and binary decomposition of value in lots
2. Key exchange ("addresses") to facilitate a secure comms path from
sender -> receiver
3. (Optional) single-use seals to close old state
(1) It's unlikely that a party sending a UTXO to another party will have a UTXO
of exactly the right size that's needed, already locked into the statechain. If
he has to create the UTXO first and then lock it into the statechain, the
statechain solution is no better than an on-chain send. And once the receiver
has the UTXO, it's unlikely that he will want to send exactly that same amount
to another receiver later. This isn't a problem in Lightning where amounts can
be arbitrarily updated. As a consequence, I think Lightning is more valuable for
small-value payments, and statechains will be more valuable for larger values.
The natural solution is to decompose your outputs in a binary decomposition,
having e.g. UTXOs with 1048576 satoshis, another with 2097152 satoshis, and so
on. Then when I want to send, I select the appropriate UTXOs as a binary
decomposition of the value I want to send, with a "lot size" of 1048576
satoshis, or the dust limit. The notion of "lots" like this is common in
traditional markets...many stocks are bought and sold in lots of 100, and forex
is traded in lots of $100,000. Users of a statechain therefore need log(V)
available UTXOs locked into the statechain, where V is their value in BTC.
Having fixed lot sizes like this also makes coinjoin-type uses more viable. The
statechain could also assist in dividing a UTXO into two utxos of the next lot
size down, so that I have the right UTXOs to hit the value I want to send.
This means that the statechain now has to *atomically* swap multiple UTXOs. In
principle, it should be possible for a statechain to circumvent the
Pagnia-Gärtner theorem[1] as it is a trusted third party, but guaranteed output
delivery will still be a problem. If a statechain can do this, it is also
capable of performing such swaps across two blockchains, creating the
execution/clearing element (but not order book) for a DEX. This same mechanism
can also be used to pay the SE for its service through a different UTXO than the
one being transferred.
Second (2), the steps in Tom's protocol presuppose a secure communications path
from the sender's wallet to the receiver's. This is probably not practical for a
myriad of reasons, but this data can be relayed through the SE if it is
encrypted for the target. This implies a new kind of "address" or "payment
request" that identifies the IP of the SE in use, pubkey of the
sender/recipient, and amount. If sender and receiver have each other's pubkeys
through another channel, as addresses/lightning payment requests are used today,
they can perform a Diffie-Hellman round mediated by the SE to establish a secure
communications path for the rounds of the protocol. Piggybacking on the
Lightning p2p network might be another option.
Third (3), a logical enhancement would be to use some kind of single-use seal,
which is "opened" when the UTXO is created or transferred, and "closed" when it
is transferred again. Thus a receiver can ensure that the sender is the holder
of current state and not some old state. It's a good idea from Peter Todd, and
Tom's Mainstay[2] may be a way to do it. The SE itself can maintain a rolling
single-use seal Merkle root, periodically timestamped into Bitcoin for faster
time resolution than Bitcoin, if you trust the SE but not your counterparty
(which is the trust assumption present in the first place). Getting Bitcoin
itself to reject backout transactions from closed seals is another problem...but
having a single-use seal implementation involved is a start.
.. [1] https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.44.7863
.. [2] https://mainstay.xyz
Tom Trevethan via bitcoin-dev [bitcoin-dev at lists.linuxfoundation.org] wrote:
> Hi all,
>
> We are starting to work on an implementation of the statechains concept (https:
> //medium.com/@RubenSomsen/
> statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39), with
> particular interest in using the protocol enable the change of ownership
> (novation) of an individual position in an active discreet log contract (DLC)
> without an on-chain transaction, and without needing the cooperation of the
> counterparty. The protocol as outlined by Ruben requires features not currently
> available in Bitcoin (like SIGHASH_NOINPUT), and it is uncertain when (or even
> if) this will be added. So we are looking at variants that would work with
> current Bitcoin functionality, and it would be good to get some feedback on
> them.
>
> There are two main modifications we are looking at:
> 1. Instead of an eltoo-based backup/refund transaction (enabling the current
> owner to claim the UTXO in case the statechain entity disappears) we propose
> using a decrementing nLocktime for backup transactions as the output changes
> hands. Here, the first owner gets a backup transaction with an nLocktime at
> some future height (h0), then the next owner gets a backup transaction with
> nLocktime (h0-c) where c is a confirmation window. This approach has the
> downside of limiting the lifetime of the UTXO, but it also doesn't require the
> current owner to be always online.
>
> 2. Replacing the 2-of-2 multisig output (paying to statechain entity SE key and
> transitory key) with a single P2(W)PKH output where the public key shared
> between the SE and the current owner. The SE and the current owner can then
> sign with a 2-of-2 ECDSA MPC. This enables each owner to generate their own
> private key share, and the SE changes their key share at each change of
> ownership (with the shared public key remaining the same). This works as
> follows (.G is EC point multiplication, * is scalar multiplication):
>
> KeyGen:
>
> a. Owner 1 generates private key share o1 then calculates the corresponding
> public key of the share O1 and sends it to the SE: O1 = o1.G
> b. The SE then generates a private key: s1 (the SE private key share),
> calculates the corresponding public key and sends it to Owner 1: S1 = s1.G
> c. Both SE and Owner 1 then multiply the public keys they receive by their own
> private key shares to obtain the same shared public key P (which corresponds to
> a shared private key of p = o1*s1): P = o1.(s1.G) = s1.(o1.G)
> d. Owner 1 creates a funding transaction (Tx0) to pay an amount A to the
> address corresponding to P (but doesn't sign it).
> e. Once Owner 1 and SE cooperatively sign the first backup transaction, Owner 1
> then signs and broadcasts the deposit transaction Tx0.
>
> Transfer from Owner 1 to Owner 2:
>
> a. Owner 2 generates two private keys: o2 (the new owner UTXO private key
> share) and b2 (the new owner refund private key).
> b. The SE generates a temporary blinding nonce x and calculates the value x*s1
> and sends this securely to Owner 2.
> c. Owner 2 then multiplies this received value by the modular inverse of o2
> (o2_inv) and then sends this value (x*s1*o2_inv), to Owner 1.
> d. Owner 1 then multiplies this received value by the key share o1 and sends
> the resulting value (x*s1*o2_inv*o1) to the SE.
> e. The SE then multiplies this received value by the modular inverse of the
> temporary nonce (x_inv) to obtain x*s1*o2_inv*o1*x_inv. This cancels the
> blinding nonce x to give s1*o2_inv*o1. This value, when multiplied by the new
> owner key share o2 equals the original shared private key s1*o1.
> f. The SE then sets this value equal to s2 = s1*o2_inv*o1 and deletes s1. s2
> and o2 are now the key shares of `P` and can be used to colaboritively sign
> (with 2P ECDSA). So long as the SE delets s1, the old owner key share (o1) is
> of no use in deriving or co-signing with the full shared private key, and is
> invalidated.
> g. The shared public key P remains unchanged, but the corresponding private key
> (which no individual party ever has knowledge of or can derive) can only be
> determined from the key shares of the SE and Owner 2 (i.e. P = s2*o2.G).
> h. Owner 2 then calculates their backup public key (B2 = b2.G) and sends it to
> the SE.
> i. The SE creates a backup transaction (Tx2) that pays the output of Tx0 to the
> address corresponding to B2 , with `nLockTime` set to a block height h0 - c0,
> where c0, is a confirmation time sufficient to guarantee that Tx2 can be
> confirmed in the blockchain before Tx1 (therefore making Tx1 invalid).
> j. Owner 2 and the SE then cooperate to sign Tx2 with shared key (P) using the
> 2P ECDSA protocol, which Owner 2 then saves.
>
> The principle of the logic of the key transfer is that the two separate key
> shares are updated, but the full shared private key (which no-one knows)
> remains the same. The new owner chooses a new secret value for their private
> key share, and this (along with the private key share of the previous owner) is
> utilized by the SE to update their share. The use of the nonce (x) prevents any
> of the participants from determining any information about each others secret
> keys. In this way Owner 2 cannot determine s1 from x*s1, Owner 1 cannot
> determine s1 or o2 from x*s1*o2_inv and the SE cannot determine o1 or o2 from
> x*s1*o2_inv*o1.
>
> This transfer protocol can be repeated to transfer the ownership to new owners.
> Each time the SE key share sX is updated, the previous key shares become
> invalid and are of no use even if the current key share is subsequently
> revealed. The SE still needs to be trusted to delete the old key share, but
> this protocol removes the risk the the SE can be hacked by a previous owner to
> steal the funds.
>
> Any comments on the above would be greatly appreciated.
>
> Tom
> !DSPAM:5e7b7203210751402398759!
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> !DSPAM:5e7b7203210751402398759!
--
Cheers, Bob McElrath
"For every complex problem, there is a solution that is simple, neat, and wrong."
-- H. L. Mencken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200327/72079e39/attachment-0001.sig>

2023-06-07 18:23:38 UTC

- reply

📅 Original date posted:2020-03-26
📝 Original message:Very good point, but I think this is easy to fix.
It's not actually necessary that the quantity in (b) involve the SE's secret key
s1. It can be purely the blinding factor. This quantity gets relayed through the
SE anyway, after a round trip through owner 2, where the SE removes the blinding
nonce. The SE needs to determine the ratio of the two private keys o1*o2_inv.
There's no reason for the SE to send anything about s1 other than the public
keys S1=s1.G and S2=s2.G, keeping the secret keys s1 and s2 hidden behind ECDLP
and not sharing quantities involving them in Z_p.
Thus:
b. (SE) x -> (2)
c. (2) o2_inv*x -> (1)
d. (1) o1*(o2_inv*x) -> (SE)
e. (SE) s2 = x_inv*(o1*o2_inv*x)*s1 = o1*o2_inv*s1
s2.G -> (2)
f. (2) o2.s2.G = o1.s1.G = P
Now we could have had a different problem, in step (e) if the SE sends owner 2
the quantity o1*o2_inv*s1, a self-sending owner can determine a similar quantity
to what you described (x1+x2)*s1: (o1*o2_inv + o2*o3_inv)*s1 and we're back to
an Irwin-Hall distribution.
It's not necessary to send a quantity involving s1 in steps (b-e). Owner 2
already has his private key o2 and the SE has his new private key
s2=o1*o2_inv*s1. Since P=o1.s1.G=o2.s2.G we're set up for o2 to transfer the
funds, but it's necessary to prove to (2) that his o2 does in fact control the
UTXO. This can be done by sending (2) the public key S2=s2.G which he can
multiply by o2 to get P=o2.s2.G and verify that the SE does have the correct
private key corresponding to his o2 for the public key P recorded on-chain.
Thus in the self-send situation, the owner no longer has any algebraic relations
he can use as you describe.
Algebraic relations remain in step (d) that a self-sending owner could use, but
they all involve his own private keys, which he knows anyway. He has only one
relation from the previous owner and all subsequent relations do not involve
that owner. However if a pair of entities send funds back and forth, each owner
could collect a sum as you describe, if the counterparty (2) re-uses keys:
o2_inv*(x1 + x2)
The SE has similar relations in step (e) if there's key reuse. Therefore it's
important that on each transfer, you generate a new key and do not re-use keys.
A responsible SE could detect a key-reuse situation by e.g. recording old
pubkeys P1, P2 even though he deleted s1 and s2, and inform the user of the
key-reuse error and abort.
Do you think that works?
P.S. SGX is not "trust minimization", it's "trust transfer" -- specifically to
the keys managing the SGX. If we thought processor manufacturers were better at
key management than the rest of us, we should just hand them the task. I don't
think that's the case, and I don't think anyone else does either. An SGX
attestation as an optional add-on I think is a worthwhile enhancement, as long
as it's not on the critical path of the protocol.
Albert via bitcoin-dev [bitcoin-dev at lists.linuxfoundation.org] wrote:
> Hi,
>
> Great to see some work in this direction, here's some thoughts on your keygen
> scheme:
>
> In the scenario where Owner1=Owner2, that is, one of the owners sends some
> coins to itself, that owner would get to know both x1*s1 and x2*s2=
> x2*s1*o2_inv*o1, and, because he already knows o1 and o2, that implies
> knowledge of both x1*s1 and x2*s1 where x1 and x2 are random numbers sampled
> from an uniform distribution. Once the owner has these two numbers, he can just
> sum these together to obtain s1*(x1+x2).
> Now, because of the central limit theorem, the distribution of x1+x2 should
> approximate a normal one, concretely an Irwin–Hall distribution, with that
> approximation getting better when more numbers are collected through iterations
> of the protocol. Once you've collected enough numbers to approximate a normal
> well enough (looking at Irwin Hall distribution graphs^[1] you can observe that
> with less than 10 samples the distribution is already pretty similar to a
> normal one), it should be possible to drastically reduce the search space and
> apply brute force to guess the value of \sum x and, consequently, s1.
>
> Practically, it's possible that the search space is still too large for
> brute-force to be fruitful, so this attack might not work, but it shows that
> there is information leakage in every protocol iteration.
>
> On another note, if you are not already aware of, something which might be
> worth looking into is the possibility of further trust-minimising the SE role
> by forcing it's code to be run inside an AWS oracle or a hardware isolated
> processor such as SGX.
>
> Albert
>
> [1] https://en.wikipedia.org/wiki/Irwin%E2%80%93Hall_distribution
>
> On Wed, Mar 25, 2020, at 9:52 PM, Tom Trevethan via bitcoin-dev wrote:
>
> Hi all,
>
> We are starting to work on an implementation of the statechains concept (
> https://medium.com/@RubenSomsen/
> statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39), with
> particular interest in using the protocol enable the change of ownership
> (novation) of an individual position in an active discreet log contract
> (DLC) without an on-chain transaction, and without needing the cooperation
> of the counterparty. The protocol as outlined by Ruben requires features
> not currently available in Bitcoin (like SIGHASH_NOINPUT), and it is
> uncertain when (or even if) this will be added. So we are looking at
> variants that would work with current Bitcoin functionality, and it would
> be good to get some feedback on them.
>
> There are two main modifications we are looking at:
> 1. Instead of an eltoo-based backup/refund transaction (enabling the
> current owner to claim the UTXO in case the statechain entity disappears)
> we propose using a decrementing nLocktime for backup transactions as the
> output changes hands. Here, the first owner gets a backup transaction with
> an nLocktime at some future height (h0), then the next owner gets a backup
> transaction with nLocktime (h0-c) where c is a confirmation window. This
> approach has the downside of limiting the lifetime of the UTXO, but it also
> doesn't require the current owner to be always online.
>
> 2. Replacing the 2-of-2 multisig output (paying to statechain entity SE key
> and transitory key) with a single P2(W)PKH output where the public key
> shared between the SE and the current owner. The SE and the current owner
> can then sign with a 2-of-2 ECDSA MPC. This enables each owner to generate
> their own private key share, and the SE changes their key share at each
> change of ownership (with the shared public key remaining the same). This
> works as follows (.G is EC point multiplication, * is scalar
> multiplication):
>
> KeyGen:
>
> a. Owner 1 generates private key share o1 then calculates the corresponding
> public key of the share O1 and sends it to the SE: O1 = o1.G
> b. The SE then generates a private key: s1 (the SE private key share),
> calculates the corresponding public key and sends it to Owner 1: S1 = s1.G
> c. Both SE and Owner 1 then multiply the public keys they receive by their
> own private key shares to obtain the same shared public key P (which
> corresponds to a shared private key of p = o1*s1): P = o1.(s1.G) = s1.
> (o1.G)
> d. Owner 1 creates a funding transaction (Tx0) to pay an amount A to the
> address corresponding to P (but doesn't sign it).
> e. Once Owner 1 and SE cooperatively sign the first backup transaction,
> Owner 1 then signs and broadcasts the deposit transaction Tx0.
>
> Transfer from Owner 1 to Owner 2:
>
> a. Owner 2 generates two private keys: o2 (the new owner UTXO private key
> share) and b2 (the new owner refund private key).
> b. The SE generates a temporary blinding nonce x and calculates the value
> x*s1 and sends this securely to Owner 2.
> c. Owner 2 then multiplies this received value by the modular inverse of o2
> (o2_inv) and then sends this value (x*s1*o2_inv), to Owner 1.
> d. Owner 1 then multiplies this received value by the key share o1 and
> sends the resulting value (x*s1*o2_inv*o1) to the SE.
> e. The SE then multiplies this received value by the modular inverse of the
> temporary nonce (x_inv) to obtain x*s1*o2_inv*o1*x_inv. This cancels the
> blinding nonce x to give s1*o2_inv*o1. This value, when multiplied by the
> new owner key share o2 equals the original shared private key s1*o1.
> f. The SE then sets this value equal to s2 = s1*o2_inv*o1 and deletes s1.
> s2 and o2 are now the key shares of `P` and can be used to colaboritively
> sign (with 2P ECDSA). So long as the SE delets s1, the old owner key share
> (o1) is of no use in deriving or co-signing with the full shared private
> key, and is invalidated.
> g. The shared public key P remains unchanged, but the corresponding private
> key (which no individual party ever has knowledge of or can derive) can
> only be determined from the key shares of the SE and Owner 2 (i.e. P =
> s2*o2.G).
> h. Owner 2 then calculates their backup public key (B2 = b2.G) and sends it
> to the SE.
> i. The SE creates a backup transaction (Tx2) that pays the output of Tx0 to
> the address corresponding to B2 , with `nLockTime` set to a block height h0
> - c0, where c0, is a confirmation time sufficient to guarantee that Tx2 can
> be confirmed in the blockchain before Tx1 (therefore making Tx1 invalid).
> j. Owner 2 and the SE then cooperate to sign Tx2 with shared key (P) using
> the 2P ECDSA protocol, which Owner 2 then saves.
>
> The principle of the logic of the key transfer is that the two separate key
> shares are updated, but the full shared private key (which no-one knows)
> remains the same. The new owner chooses a new secret value for their
> private key share, and this (along with the private key share of the
> previous owner) is utilized by the SE to update their share. The use of the
> nonce (x) prevents any of the participants from determining any information
> about each others secret keys. In this way Owner 2 cannot determine s1 from
> x*s1, Owner 1 cannot determine s1 or o2 from x*s1*o2_inv and the SE cannot
> determine o1 or o2 from x*s1*o2_inv*o1.
>
> This transfer protocol can be repeated to transfer the ownership to new
> owners. Each time the SE key share sX is updated, the previous key shares
> become invalid and are of no use even if the current key share is
> subsequently revealed. The SE still needs to be trusted to delete the old
> key share, but this protocol removes the risk the the SE can be hacked by a
> previous owner to steal the funds.
>
> Any comments on the above would be greatly appreciated.
>
> Tom
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> !DSPAM:5e7c2da240641930319229!
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> !DSPAM:5e7c2da240641930319229!
--
Cheers, Bob McElrath
"For every complex problem, there is a solution that is simple, neat, and wrong."
-- H. L. Mencken

2023-06-07 17:49:33 UTC

- reply

📅 Original date posted:2016-03-09
📝 Original message:Dave Hudson [dave at hashingit.com] wrote:
> A damping-based design would seem like the obvious choice (I can think of a
> few variations on a theme here, but most are found in the realms of control
> theory somewhere). The problem, though, is working working out a timeframe
> over which to run the derivative calculations.
>From a measurement theory perspective this is straightforward. Each block is a
measurement, and error propagation can be performed to derive an error on the
derivatives.
The statistical theory of Bitcoin's block timing is known as a Poisson Point
Process: https://en.wikipedia.org/wiki/Poisson_point_process or temporal point
process. If you google those plus "estimation" you'll find a metric shit-ton of
literature on how to handle this.
> The problem is the measurement of the hashrate, which is pretty inaccurate at
> best because even 2016 events isn't really enough (with a completely constant
> hash rate running indefinitely we'd see difficulty swings of up to +/- 5% even
> with the current algorithm). In order to meaningfully react to a major loss
> of hashing we'd still need to be considering a window of probably 2 weeks.
You don't want to assume it's constant in order to get a better measurement.
The assumption is clearly false. But, errors can be calculated, and retargeting
can take errors into account, because no matter what we'll always be dealing
with a finite sample.
Personally I don't think difficulty target variations are such a big deal, if
the algorithm targets that over any long time interval, the average block time
is 10 min. Bitcoin's current algorithm fails here, with increasing hashrate (as
we have), it issues coins faster than its assumed schedule.
--
Cheers, Bob McElrath
"For every complex problem, there is a solution that is simple, neat, and wrong."
-- H. L. Mencken

2023-06-07 17:49:32 UTC

- reply

📅 Original date posted:2016-03-08
📝 Original message:Dave Hudson via bitcoin-dev [bitcoin-dev at lists.linuxfoundation.org] wrote:
> I think the biggest question here would be how would the difficulty
> retargeting be changed? Without seeing the algorithm proposal it's difficult
> to assess the impact that it would have, but my intuition is that this is
> likely to be problematic.
I have no comment on whether this will be *needed* but there's a simple
algorithm that I haven't seen any coin adopt, that I think needs to be: the
critically damped harmonic oscillator:
http://mathworld.wolfram.com/CriticallyDampedSimpleHarmonicMotion.html
In dynamical systems one does a derivative expansion. Here we want to find the
first and second derivatives (in time) of the hashrate. These can be determined
by a method of finite differences, or fancier algorithms which use a quadratic
or quartic polynomial approximation. Two derivatives are generally all that is
needed, and the resulting dynamical system is a damped harmonic oscillator.
A damped harmonic oscillator is basically how your car's shock absorbers work.
The relevant differential equation has two parameters: the oscillation frequency
and damping factor. The maximum oscillation frequency is the block rate. Any
oscillation faster than the block rate cannot be measured by block times. The
damping rate is an exponential decay and for critical damping is twice the
oscillation frequency.
So, this is a zero parameter, optimal damping solution for a varying hashrate.
This is inherently a numeric approximation solution to a differential equation,
so questions of approximations for the hashrate enter, but that's all. Weak
block proposals will be able to get better approximations to the hashrate.
If solving this problem is deemed desirable, I can put some time into this, or
direct others as to how to go about it.
--
Cheers, Bob McElrath
"For every complex problem, there is a solution that is simple, neat, and wrong."
-- H. L. Mencken

2023-06-07 17:46:55 UTC

- reply

📅 Original date posted:2015-12-19
📝 Original message:Peter Todd via bitcoin-dev [bitcoin-dev at lists.linuxfoundation.org] wrote:
> One of the issues raised by the pools present was block withholding
> attacks, which they said are a real issue for them. In particular, pools
> are receiving legitimate threats by bad actors threatening to use block
> withholding attacks against them.
The only possible other bad actors are other miners. So who are the "bad actor"
miners? It's a short list of candidates.
> P2Pool is often brought up as a replacement for pools, but it itself is still
> relatively vulnerable to block withholding, and in any case has many other
> vulnerabilities and technical issues that has prevented widespread adoption of
> P2Pool.
I've been trying to understand this source of "vulnerabilities and technical
issues" with p2pool and have received a lot of contradictory information. Can
someone in the know summarize what the problems with p2pool are?
The economic situation where miners can be deprived of profit due to the lack of
synchronicity in block updates is a physics problem due to the size of the Earth
and will never be removed. This is a design flaw in Bitcoin. Therefore a
different, more comprehensive solution is called for.
My solution to this is somewhat longer term and needs more simulation but
fundamentally removes the source of contention and fixes the design flaw, while
remaining as close "in spirit" to bitcoin as possible:
https://scalingbitcoin.org/hongkong2015/presentations/DAY2/2_breaking_the_chain_1_mcelrath.pdf
Not only does block withholding simply not work to deny other miners income due
to the absence of orphans, but I explicitly added a dis-incentive against
withholding blocks in terms of the "cohort difficulty". Other graph-theoretic
quantities are in general possible in the reward function to better align the
incentives of miners with the correct operation of the system. Also by lowering
the target difficulty and increasing the block (bead) rate, one lowers the
variance of miner income.
Part of the reason I ask is that there has been some interest in testing my
ideas in p2pool itself (or a new similar share pool), but I'm failing to
understand the source of all the complaints about p2pool.
--
Cheers, Bob McElrath
"For every complex problem, there is a solution that is simple, neat, and wrong."
-- H. L. Mencken

2023-06-07 17:43:29 UTC

- reply

📅 Original date posted:2015-10-14
📝 Original message:So it seems to me that all I need to do is figure out who the current leader is,
and DDoS him off the network to shut Bitcoin-NG down.
This is a significant advantage to bitcoin's ex-post-facto blocks: no one knows
where the next one will come from. The only way to shut the network down is to
shut all nodes down.
Emin Gün Sirer via bitcoin-dev [bitcoin-dev at lists.linuxfoundation.org] wrote:
> Hi everyone,
>
> We just released the whitepaper describing Bitcoin-NG, a new technique for
> addressing some of the scalability challenges faced by Bitcoin. Surprisingly,
> Bitcoin-NG can simultaneously increase throughput while reducing latency, and
> do so without impacting Bitcoin's open architecture or changing its trust
> model. This post illustrates the core technique:
> http://hackingdistributed.com/2015/10/14/bitcoin-ng/
> while the whitepaper has all the nitty gritty details:
> http://arxiv.org/abs/1510.02037
>
> Fitting NG on top of the current Bitcoin blockchain is future work that we
> think is quite possible. NG is compatible with both Bitcoin as is, as well as
> Blockstream-like sidechains, and we currently are not planning to compete
> commercially with either technology -- we see NG as being complementary to both
> efforts. This is pure science, published and shared with the community to
> advance the state of blockchains and to help them reach throughputs and
> latencies required of cutting edge fintech applications. Perhaps it can be
> adopted, or perhaps it can provide the spark of inspiration for someone else to
> come up with even better solutions.
>
> We would be delighted to hear your feedback.
> - Ittay Eyal and E. Gün Sirer.
>
> !DSPAM:561e98cd301391127216946!
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> !DSPAM:561e98cd301391127216946!
--
Cheers, Bob McElrath
"For every complex problem, there is a solution that is simple, neat, and wrong."
-- H. L. Mencken