<unnamed>

Public Key

npub17qxssk9sj2r7jswvh3y32e7vwz7mcckhz33gk9nurdmw0lhsfkgswupwet

Profile Code

nprofile1qqs0qrggtzcf9plfg8xtcjg4vlx8p0duvtt3gc5tze7pkah8lmcymygpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsecramd

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:37:52 UTC

- reply

📅 Original date posted:2015-08-28
📝 Original message:But that's not what this proposal does. They have to pay the difficulty penalty merely for a *chance* at later being able to mine larger blocks.
Maybe this could be fixed by allowing miners to produce a larger-than-limit block *immediately* by paying a difficulty penalty. Then we can simply take the 80th-percentile block size in each 2016-block period as the nominal block-size limit in the next period.
On Friday, 28 August 2015, at 4:38 pm, Mark Friedenbach via bitcoin-dev wrote:
> It is in their individual interests when the larger block that is allowed
> for them grants them more fees.
>
> On Aug 28, 2015 4:35 PM, "Chris Pacia via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > When discussing this with Matt Whitlock earlier we basically concluded the
> > block size will never increase under this proposal do to a collective
> > action problem. If a miner votes for an increase and nobody else does, the
> > blocksize will not increase yet he will still have to pay the difficulty
> > penalty.
> >
> > It may be in everyone's collective interest to raise the block size but
> > not their individual interest.
> > On Aug 28, 2015 6:24 PM, "Gavin via bitcoin-dev" <
> > bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> >> With this proposal, how much would it cost a miner to include an 'extra'
> >> 500-byte transaction if the average block size is 900K and it costs the
> >> miner 20BTC in electricity/capital/etc to mine a block?
> >>
> >> If my understanding of the proposal is correct, it is:
> >>
> >> 500/900000 * 20 = 0.11111 BTC
> >>
> >> ... Or $2.50 at today's exchange rate.
> >>
> >> That seems excessive.
> >>
> >> --
> >> Gavin Andresen
> >>
> >>
> >> > On Aug 28, 2015, at 5:15 PM, Matt Whitlock via bitcoin-dev <
> >> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> >
> >> > This is the best proposal I've seen yet. Allow me to summarize:
> >> >
> >> > • It addresses the problem, in Jeff Garzik's BIP 100, of miners selling
> >> their block-size votes.
> >> > • It addresses the problem, in Gavin Andresen's BIP 101, of blindly
> >> trying to predict future market needs versus future technological
> >> capacities.
> >> > • It avoids a large step discontinuity in the block-size limit by
> >> starting with a 1-MB limit.
> >> > • It throttles changes to ±10% every 2016 blocks.
> >> > • It imposes a tangible cost (higher difficulty) on miners who vote to
> >> raise the block-size limit.
> >> > • It avoids incentivizing miners to vote to lower the block-size limit.
> >> >
> >> > However, this proposal currently fails to answer a very important
> >> question:
> >> >
> >> > • What is the mechanism for activation of the new consensus rule? It is
> >> when a certain percentage of the blocks mined in a 2016-block retargeting
> >> period contain valid block-size votes?
> >> >
> >> >
> >> > https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki
> >> >
> >> >
> >> >> On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev wrote:
> >> >> Pull request: https://github.com/bitcoin/bips/pull/187
> >> > _______________________________________________
> >> > bitcoin-dev mailing list
> >> > bitcoin-dev at lists.linuxfoundation.org
> >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >

2023-06-07 17:37:50 UTC

- reply

📅 Original date posted:2015-08-28
📝 Original message:This is the best proposal I've seen yet. Allow me to summarize:
• It addresses the problem, in Jeff Garzik's BIP 100, of miners selling their block-size votes.
• It addresses the problem, in Gavin Andresen's BIP 101, of blindly trying to predict future market needs versus future technological capacities.
• It avoids a large step discontinuity in the block-size limit by starting with a 1-MB limit.
• It throttles changes to ±10% every 2016 blocks.
• It imposes a tangible cost (higher difficulty) on miners who vote to raise the block-size limit.
• It avoids incentivizing miners to vote to lower the block-size limit.
However, this proposal currently fails to answer a very important question:
• What is the mechanism for activation of the new consensus rule? It is when a certain percentage of the blocks mined in a 2016-block retargeting period contain valid block-size votes?
https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki
On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev wrote:
> Pull request: https://github.com/bitcoin/bips/pull/187

2023-06-07 15:49:31 UTC

- reply

📅 Original date posted:2015-08-25
📝 Original message:On Tuesday, 25 August 2015, at 1:16 pm, Peter Todd via bitcoin-dev wrote:
> What would you think of an approach like John Dillon's proposal to
> explicitly give the economic majority of coin holders a vote for the max
> blocksize? Miners could still vote BIP100 style for what max they were
> willing to use, limited in turn by the vote of the economic majority.
What fraction of coin holders do you suppose will vote? And, of those, what fraction have the technical knowledge to make an informed vote? It would be like polling Toyota truck owners to see whether the 2017 Tacoma should increase its engine's cylinder displacement by 10%. Ordinary users just aren't going to be able to vote meaningfully, and most won't respond to the poll at all.

2023-06-07 15:49:31 UTC

- reply

📅 Original date posted:2015-08-25
📝 Original message:On Tuesday, 25 August 2015, at 1:37 pm, Peter Todd wrote:
> On Tue, Aug 25, 2015 at 04:26:23PM -0400, Matt Whitlock wrote:
> > On Tuesday, 25 August 2015, at 1:16 pm, Peter Todd via bitcoin-dev wrote:
> > > What would you think of an approach like John Dillon's proposal to
> > > explicitly give the economic majority of coin holders a vote for the max
> > > blocksize? Miners could still vote BIP100 style for what max they were
> > > willing to use, limited in turn by the vote of the economic majority.
> >
> > What fraction of coin holders do you suppose will vote? And, of those, what fraction have the technical knowledge to make an informed vote? It would be like polling Toyota truck owners to see whether the 2017 Tacoma should increase its engine's cylinder displacement by 10%. Ordinary users just aren't going to be able to vote meaningfully, and most won't respond to the poll at all.
>
> Note that you can make the % of voters required adapt dyanmically to voter
> interest. Also, your example is rather misleading, as car buyers *do*
> make those kinds of decisions though various market mechanisms.
Yes, car buyers do make those kinds of decisions through market mechanisms. An equivalent process for Bitcoin would be that the max block-size limit (and other fundamental economic parameters) would be determined via a process of forking off altcoins (such as Bitcoin XT will do) and allowing the market to decide which coin is most valuable. This is the "default" mechanism for change (because it's what naturally happens when there is a lack of internal consensus), but it's not the least painful mechanism.
My point still stands that — just as in democracy in general — the voters are really in no position to cast informed votes, nor should they be (cf. "rational ignorance" [1]). I do not oppose opening up the determination of the max block-size limit to a popular "check" via stakeholder vote — actually, I think this is an important check on miners' power — but I do argue that the vote is likely to have drastically little participation and very low-quality results.
[1] Rational Ignorance: «Ignorance about an issue is said to be "rational" when the cost of educating oneself about the issue sufficiently to make an informed decision can outweigh any potential benefit one could reasonably expect to gain from that decision, and so it would be irrational to waste time doing so.» <https://en.wikipedia.org/wiki/Rational_ignorance>

2023-06-07 15:49:16 UTC

- reply

2023-06-07 15:49:15 UTC

- reply

2023-06-07 15:41:49 UTC

- reply

📅 Original date posted:2015-07-09
📝 Original message:On Thursday, 9 July 2015, at 6:57 pm, Tom Harding wrote:
> Replace-by-anything can only work if conflicts are relayed, so the
> solution is not to act against the peer.
>
> Alex Morcos offered a suggestion on IRC -- track recently-rejected
> txid's and don't getdata them. The idea sounds good to me.
While that's probably a good idea, it wouldn't do much to reduce the load. I am not seeing many repeated transaction hashes among the "rejected replacement" messages in my log.

2023-06-07 15:41:48 UTC

- reply

📅 Original date posted:2015-07-09
📝 Original message:I'm presently running my full node with Peter Todd's full replace-by-fee patch set [1]. I am seeing a LOT of messages in the log about replacement transactions being rejected due to their paying less in fees than the transactions they would replace. I understand that this could happen legitimately from time to time, due to my node's receiving a replacing transaction prior to receiving the replaced transaction; however, due to the ongoing spam attack, I am seeing a steady stream of these rejection messages, dozens per second at times. I am wondering if each replacement rejection ought to penalize the peer who relayed the offending transaction, and if the penalty builds up enough, then the peer could be temporarily banned, similar to how other "misbehaving" peers are treated.
[1] https://github.com/petertodd/bitcoin/commits/replace-by-fee-v0.10.2

2023-06-07 15:41:33 UTC

- reply

📅 Original date posted:2015-07-02
📝 Original message:PR#1647 only addresses miner policy, though, right? I believe the BIP is addressing the user-facing side of this functionality. CPFP mining policy does very little good if wallets don't offer any way for users to goose up incoming transactions.
On Wednesday, 1 July 2015, at 9:52 pm, Mark Friedenbach wrote:
> This is called child pays for parent and there is a three year old pull
> request implementing it:
>
> https://github.com/bitcoin/bitcoin/pull/1647
>
> The points regarding sweep transaction UI is out of scope for a BIP I'm
> afraid. I suggest talking with wallet authors, and if agreement can be
> found writing a pull request.
> On Jul 1, 2015 9:44 PM, "Dan Bryant" <dkbryant at gmail.com> wrote:
>
> > This is a process BIP request to add functionality to the Bitcoin-Core
> > reference implementation. If accepted, this could also add
> > flexibility into any future fee schedules.
> >
> > https://github.com/d4n13/bips/blob/master/bip-00nn.mediawiki

2023-06-07 15:39:08 UTC

- reply

📅 Original date posted:2015-06-19
📝 Original message:Even if you could prove "intent to pay," this would be almost useless. I can sincerely intend to do a lot of things, but this doesn't mean I'll ever actually do them.
I am in favor of more zero-confirmation transactions being reversed / double-spent. Bitcoin users largely still believe that accepting zero-conf transactions is safe, and evidently it's going to take some harsh lessons in reality to correct this belief.
On Friday, 19 June 2015, at 9:42 am, Eric Lombrozo wrote:
> If we want a non-repudiation mechanism in the protocol, we should explicitly define one rather than relying on “prima facie” assumptions. Otherwise, I would recommend not relying on the existence of a signed transaction as proof of intent to pay…
>
>
> > On Jun 19, 2015, at 9:36 AM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> >
> > On Friday, 19 June 2015, at 3:53 pm, justusranvier at riseup.net wrote:
> >> I'd also like to note that "prima facie" doesn't mean "always", it means
> >> that "the default assumption, unless proven otherwise."
> >
> > Why would you automatically assume fraud by default? Shouldn't the null hypothesis be the default? Without any information one way or another, you ought to make *no assumption* about the fraudulence or non-fraudulence of any given double-spend.
>

2023-06-07 15:39:08 UTC

- reply

📅 Original date posted:2015-06-19
📝 Original message:On Friday, 19 June 2015, at 3:53 pm, justusranvier at riseup.net wrote:
> I'd also like to note that "prima facie" doesn't mean "always", it means
> that "the default assumption, unless proven otherwise."
Why would you automatically assume fraud by default? Shouldn't the null hypothesis be the default? Without any information one way or another, you ought to make *no assumption* about the fraudulence or non-fraudulence of any given double-spend.

2023-06-07 15:38:58 UTC

- reply

📅 Original date posted:2015-06-19
📝 Original message:On Friday, 19 June 2015, at 9:18 am, Adrian Macneil wrote:
> If full-RBF sees any significant adoption by miners, then it will actively
> harm bitcoin adoption by reducing or removing the ability for online or POS
> merchants to accept bitcoin payments at all.
Retail POS merchants probably should not be accepting vanilla Bitcoin payments, as Bitcoin alone does not (and cannot) guarantee the irreversibility of a transaction until it has been buried several blocks deep in the chain. Retail merchants should be requiring a co-signature from a mutually trusted co-signer that vows never to sign a double-spend. The reason we don't yet see such technology permeating the ecosystem is because, to date, zero-conf transactions have been irreversible "enough," but this has only been a happy accident; it was never promised, and it should not be relied upon.

2023-06-07 15:38:34 UTC

- reply

📅 Original date posted:2015-06-18
📝 Original message:On Thursday, 18 June 2015, at 8:31 pm, Ross Nicoll wrote:
> I may disagree with Mike & Gavin on timescale, but I do believe there's
> a likelihood inaction will kill Bitcoin
An honest question: who is proposing inaction? I haven't seen anyone in this whole, agonizing debate arguing that 1MB blocks are adequate. The debate has been about *how* to increase the block-size limit and whether to take action ASAP (at the risk of fracturing Bitcoin) or to delay action for further debate (at the risk of overloading Bitcoin). Even those who are arguing for further debate are not arguing for *inaction*.

2023-06-07 15:37:30 UTC

- reply

📅 Original date posted:2015-06-12
📝 Original message:On Friday, 12 June 2015, at 7:44 pm, Peter Todd wrote:
> On Fri, Jun 12, 2015 at 02:36:31PM -0400, Matt Whitlock wrote:
> > On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
> > > On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
> > > > Why should miners only be able to vote for "double the limit" or "halve" the limit? If you're going to use bits, I think you need to use two bits:
> > > >
> > > > 0 0 = no preference ("wildcard" vote)
> > > > 0 1 = vote for the limit to remain the same
> > > > 1 0 = vote for the limit to be halved
> > > > 1 1 = vote for the limit to be doubled
> > > >
> > > > User transactions would follow the same usage. In particular, a user vote of "0 0" (no preference) could be included in a block casting any vote, but a block voting "0 0" (no preference) could only contain transactions voting "0 0" as well.
> > >
> > > Sounds like a good encoding to me. Taking the median of the three
> > > options, and throwing away "don't care" votes entirely, makes sense.
> >
> > I hope you mean the *plurality* of the three options after throwing away the "don't cares," not the *median*.
>
> Median ensures that voting "no change" is meaningful. If "double" + "no
> change" = 66%-1, you'd expect the result to be "no change", not "halve""
> With a plurality vote you'd end up with a halving that was supported by
> a minority.
Never mind. I think I've figured out what you're getting at, and you're right. We wouldn't want "halve" to win on a plurality just because the remaining majority of the vote was split between double and remain-the-same. Good catch. :)

2023-06-07 15:37:29 UTC

- reply

📅 Original date posted:2015-06-12
📝 Original message:On Friday, 12 June 2015, at 7:44 pm, Peter Todd wrote:
> On Fri, Jun 12, 2015 at 02:36:31PM -0400, Matt Whitlock wrote:
> > On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
> > > On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
> > > > Why should miners only be able to vote for "double the limit" or "halve" the limit? If you're going to use bits, I think you need to use two bits:
> > > >
> > > > 0 0 = no preference ("wildcard" vote)
> > > > 0 1 = vote for the limit to remain the same
> > > > 1 0 = vote for the limit to be halved
> > > > 1 1 = vote for the limit to be doubled
> > > >
> > > > User transactions would follow the same usage. In particular, a user vote of "0 0" (no preference) could be included in a block casting any vote, but a block voting "0 0" (no preference) could only contain transactions voting "0 0" as well.
> > >
> > > Sounds like a good encoding to me. Taking the median of the three
> > > options, and throwing away "don't care" votes entirely, makes sense.
> >
> > I hope you mean the *plurality* of the three options after throwing away the "don't cares," not the *median*.
>
> Median ensures that voting "no change" is meaningful. If "double" + "no
> change" = 66%-1, you'd expect the result to be "no change", not "halve""
> With a plurality vote you'd end up with a halving that was supported by
> a minority.
I'm very confused.
Let's say, out of the 12,000 blocks in a voting period:
• 1000 blocks express no preference,
• 2000 blocks vote to halve the limit,
• 3500 blocks vote to double the limit, and
• 5500 blocks vote to keep the limit the same.
The plurality vote is to keep the limit the same. The median vote is… well, I'm not sure, since there are four choices, and an average of the two "middle" choices doesn't seem to make sense.

2023-06-07 15:37:28 UTC

- reply

📅 Original date posted:2015-06-12
📝 Original message:Why should miners only be able to vote for "double the limit" or "halve" the limit? If you're going to use bits, I think you need to use two bits:
0 0 = no preference ("wildcard" vote)
0 1 = vote for the limit to remain the same
1 0 = vote for the limit to be halved
1 1 = vote for the limit to be doubled
User transactions would follow the same usage. In particular, a user vote of "0 0" (no preference) could be included in a block casting any vote, but a block voting "0 0" (no preference) could only contain transactions voting "0 0" as well.
Incidentally, I love this idea, as it addresses a concern I immediately had with Jeff's proposal, which is that it hands control exclusively to the miners. And your proposal here fixes that shortcoming in a economically powerful way: miners lose out on fees if they don't represent the wishes of the users.
On Friday, 12 June 2015, at 2:11 pm, Peter Todd wrote:
> Jeff Garzik recently proposed that the upper blocksize limit be removed
> entirely, with a "soft" limit being enforced via miner vote, recorded by
> hashing power.
>
> This mechanism within the protocol for users to have any influence over
> the miner vote. We can add that back by providing a way for transactions
> themselves to set a flag determining whether or not they can be included
> in a block casting a specific vote.
>
> We can simplify Garzik's vote to say that one of the nVersion bits
> either votes for the blocksize to be increased, or decreased, by some
> fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
> nVersion bit in transactions themselves, also voting for an increase or
> decrease. Transactions may only be included in blocks with an
> indentical vote, thus providing miners with a monetary incentive via
> fees to vote according to user wishes.
>
> Of course, to cast a "don't care" vote we can either define an
> additional bit, or sign the transaction with both versions. Equally we
> can even have different versions with different fees, broadcast via a
> mechanism such as replace-by-fee.
>
>
> See also John Dillon's proposal for proof-of-stake blocksize voting:
>
> https://www.mail-archive.com/[email protected]/msg02323.html
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778

2023-06-07 15:37:28 UTC

- reply

📅 Original date posted:2015-06-12
📝 Original message:On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
> On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
> > Why should miners only be able to vote for "double the limit" or "halve" the limit? If you're going to use bits, I think you need to use two bits:
> >
> > 0 0 = no preference ("wildcard" vote)
> > 0 1 = vote for the limit to remain the same
> > 1 0 = vote for the limit to be halved
> > 1 1 = vote for the limit to be doubled
> >
> > User transactions would follow the same usage. In particular, a user vote of "0 0" (no preference) could be included in a block casting any vote, but a block voting "0 0" (no preference) could only contain transactions voting "0 0" as well.
>
> Sounds like a good encoding to me. Taking the median of the three
> options, and throwing away "don't care" votes entirely, makes sense.
I hope you mean the *plurality* of the three options after throwing away the "don't cares," not the *median*.

2023-06-07 15:37:27 UTC

- reply

📅 Original date posted:2015-06-12
📝 Original message:On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:
> Peter it's not clear to me that your described protocol is free of miner
> influence over the vote, by artificially generating transactions which they
> claim in their own blocks
Miners could fill their blocks with garbage transactions that agree with their vote, but this wouldn't bring them any real income, as they'd be paying their own money as fees to themselves. To get real income, miners would have to vote in accordance with real users.

2023-06-07 15:35:37 UTC

- reply

📅 Original date posted:2015-05-26
📝 Original message:On Tuesday, 26 May 2015, at 1:15 am, Peter Todd wrote:
> On Tue, May 26, 2015 at 12:52:07AM -0400, Matt Whitlock wrote:
> > On Monday, 25 May 2015, at 11:48 pm, Jim Phillips wrote:
> > > Do any wallets actually do this yet?
> >
> > Not that I know of, but they do seed their address database via DNS, which you can poison if you control the LAN's DNS resolver. I did this for a Bitcoin-only Wi-Fi network I operated at a remote festival. We had well over a hundred lightweight wallets, all trying to connect to the Bitcoin P2P network over a very bandwidth-constrained Internet link, so I poisoned the DNS and rejected all outbound connection attempts on port 8333, to force all the wallets to connect to a single local full node, which had connectivity to a single remote node over the Internet. Thus, all the lightweight wallets at the festival had Bitcoin network connectivity, but we only needed to backhaul the Bitcoin network's transaction traffic once.
>
> Interesting!
>
> What festival was this?
The Porcupine Freedom Festival ("PorcFest") in New Hampshire last summer. I strongly suspect that it's the largest gathering of Bitcoin users at any event that is not specifically Bitcoin-themed. There's a lot of overlap between the Bitcoin and liberty communities. PorcFest draws somewhere around 1000-2000 attendees, a solid quarter of whom have Bitcoin wallets on their mobile devices.
The backhaul was a 3G cellular Internet connection, and the local Bitcoin node and network router were hosted on a Raspberry Pi with some Netfilter tricks to restrict connectivity. The net result was that all Bitcoin nodes (lightweight and heavyweight) on the local Wi-Fi network were unable to connect to any Bitcoin nodes except for the local node, which they discovered via DNS. I also had provisions in place to allow outbound connectivity to the API servers for Mycelium, Blockchain, and Coinbase wallets, by feeding the DNS resolver's results in real-time into a whitelisting Netfilter rule utilizing IP Sets.
For your amusement, here's the graphic for the banner that I had made to advertise the network at the festival (*chuckle*): http://www.mattwhitlock.com/bitcoin_wifi.png

2023-06-07 15:35:36 UTC

- reply

📅 Original date posted:2015-05-26
📝 Original message:On Monday, 25 May 2015, at 11:48 pm, Jim Phillips wrote:
> Do any wallets actually do this yet?
Not that I know of, but they do seed their address database via DNS, which you can poison if you control the LAN's DNS resolver. I did this for a Bitcoin-only Wi-Fi network I operated at a remote festival. We had well over a hundred lightweight wallets, all trying to connect to the Bitcoin P2P network over a very bandwidth-constrained Internet link, so I poisoned the DNS and rejected all outbound connection attempts on port 8333, to force all the wallets to connect to a single local full node, which had connectivity to a single remote node over the Internet. Thus, all the lightweight wallets at the festival had Bitcoin network connectivity, but we only needed to backhaul the Bitcoin network's transaction traffic once.
> On May 25, 2015 11:37 PM, "Matt Whitlock" <bip at mattwhitlock.name> wrote:
>
> > This is very simple to do. Just ping the "all nodes" address (ff02::1) and
> > try connecting to TCP port 8333 of each node that responds. Shouldn't take
> > but more than a few milliseconds on any but the most densely populated LANs.
> >
> >
> > On Monday, 25 May 2015, at 11:06 pm, Jim Phillips wrote:
> > > Is there any work being done on using some kind of zero-conf service
> > > discovery protocol so that lightweight clients can find a full node on
> > the
> > > same LAN to peer with rather than having to tie up WAN bandwidth?
> > >
> > > I envision a future where lightweight devices within a home use SPV over
> > > WiFi to connect with a home server which in turn relays the transactions
> > > they create out to the larger and faster relays on the Internet.
> > >
> > > In a situation where there are hundreds or thousands of small SPV devices
> > > in a single home (if 21, Inc. is successful) monitoring the blockchain,
> > > this could result in lower traffic across the slow WAN connection. And
> > > yes, I realize it could potentially take a LOT of these devices before
> > the
> > > total bandwidth is greater than downloading a full copy of the
> > blockchain,
> > > but there's other reasons to host your own full node -- trust being one.
> > >
> > > --
> > > *James G. Phillips IV*
> > > <https://plus.google.com/u/0/113107039501292625391/posts>
> > > <http://www.linkedin.com/in/ergophobe>
> > >
> > > *"Don't bunt. Aim out of the ball park. Aim for the company of
> > immortals."
> > > -- David Ogilvy*
> > >
> > > *This message was created with 100% recycled electrons. Please think
> > twice
> > > before printing.*
> >

2023-06-07 15:35:35 UTC

- reply

📅 Original date posted:2015-05-26
📝 Original message:Who would be performing a Sybil attack against themselves? We're talking about a LAN here. All the nodes would be under the control of the same entity. In that case, you actually want them all connecting solely to a central hub node on the LAN, and the hub node should connect to "diverse and unpredictable" other nodes on the Bitcoin network.
On Monday, 25 May 2015, at 9:46 pm, Kevin Greene wrote:
> This is something you actually don't want. In order to make it as difficult
> as possible for an attacker to perform a sybil attack, you want to choose a
> set of peers that is as diverse, and unpredictable as possible.
>
>
> On Mon, May 25, 2015 at 9:37 PM, Matt Whitlock <bip at mattwhitlock.name>
> wrote:
>
> > This is very simple to do. Just ping the "all nodes" address (ff02::1) and
> > try connecting to TCP port 8333 of each node that responds. Shouldn't take
> > but more than a few milliseconds on any but the most densely populated LANs.
> >
> >
> > On Monday, 25 May 2015, at 11:06 pm, Jim Phillips wrote:
> > > Is there any work being done on using some kind of zero-conf service
> > > discovery protocol so that lightweight clients can find a full node on
> > the
> > > same LAN to peer with rather than having to tie up WAN bandwidth?
> > >
> > > I envision a future where lightweight devices within a home use SPV over
> > > WiFi to connect with a home server which in turn relays the transactions
> > > they create out to the larger and faster relays on the Internet.
> > >
> > > In a situation where there are hundreds or thousands of small SPV devices
> > > in a single home (if 21, Inc. is successful) monitoring the blockchain,
> > > this could result in lower traffic across the slow WAN connection. And
> > > yes, I realize it could potentially take a LOT of these devices before
> > the
> > > total bandwidth is greater than downloading a full copy of the
> > blockchain,
> > > but there's other reasons to host your own full node -- trust being one.
> > >
> > > --
> > > *James G. Phillips IV*
> > > <https://plus.google.com/u/0/113107039501292625391/posts>
> > > <http://www.linkedin.com/in/ergophobe>
> > >
> > > *"Don't bunt. Aim out of the ball park. Aim for the company of
> > immortals."
> > > -- David Ogilvy*
> > >
> > > *This message was created with 100% recycled electrons. Please think
> > twice
> > > before printing.*
> >
> >
> > ------------------------------------------------------------------------------
> > One dashboard for servers and applications across Physical-Virtual-Cloud
> > Widest out-of-the-box monitoring support with 50+ applications
> > Performance metrics, stats and reports that give you Actionable Insights
> > Deep dive visibility with transaction tracing using APM Insight.
> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >

2023-06-07 15:35:34 UTC

- reply

📅 Original date posted:2015-05-26
📝 Original message:This is very simple to do. Just ping the "all nodes" address (ff02::1) and try connecting to TCP port 8333 of each node that responds. Shouldn't take but more than a few milliseconds on any but the most densely populated LANs.
On Monday, 25 May 2015, at 11:06 pm, Jim Phillips wrote:
> Is there any work being done on using some kind of zero-conf service
> discovery protocol so that lightweight clients can find a full node on the
> same LAN to peer with rather than having to tie up WAN bandwidth?
>
> I envision a future where lightweight devices within a home use SPV over
> WiFi to connect with a home server which in turn relays the transactions
> they create out to the larger and faster relays on the Internet.
>
> In a situation where there are hundreds or thousands of small SPV devices
> in a single home (if 21, Inc. is successful) monitoring the blockchain,
> this could result in lower traffic across the slow WAN connection. And
> yes, I realize it could potentially take a LOT of these devices before the
> total bandwidth is greater than downloading a full copy of the blockchain,
> but there's other reasons to host your own full node -- trust being one.
>
> --
> *James G. Phillips IV*
> <https://plus.google.com/u/0/113107039501292625391/posts>
> <http://www.linkedin.com/in/ergophobe>
>
> *"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
> -- David Ogilvy*
>
> *This message was created with 100% recycled electrons. Please think twice
> before printing.*

2023-06-07 15:34:33 UTC

- reply

📅 Original date posted:2015-05-26
📝 Original message:On Tuesday, 26 May 2015, at 11:22 am, Danny Thorpe wrote:
> What prevents RBF from being used for fraudulent payment reversals?
>
> Pay 1BTC to Alice for hard goods, then after you receive the goods
> broadcast a double spend of that transaction to pay Alice nothing? Your
> only cost is the higher network fee of the 2nd tx.
The "First-Seen-Safe" replace-by-fee presently being discussed on this list disallows fraudulent payment reversals, as it disallows a replacing transaction that pays less to any output script than the replaced transaction paid.

2023-06-07 15:33:55 UTC

- reply

📅 Original date posted:2015-05-08
📝 Original message:On Friday, 8 May 2015, at 3:32 pm, Joel Joonatan Kaartinen wrote:
> It seems you missed my suggestion about basing the maximum block size on
> the bitcoin days destroyed in transactions that are included in the block.
> I think it has potential for both scaling as well as keeping up a constant
> fee pressure. If tuned properly, it should both stop spamming and increase
> block size maximum when there are a lot of real transactions waiting for
> inclusion.
I saw it. I apologize for not including it in my list. I should have, for sake of discussion, even though I have a problem with it.
My problem with it is that "bitcoin days destroyed" is not a measure of demand for space in the block chain. In the distant future, when Bitcoin is the predominant global currency, bitcoins will have such high velocity that the number of bitcoin days destroyed in each block will be much lower than at present. Does this mean that the block size limit should be lower in the future than it is now? Clearly this would be incorrect.
Perhaps I am misunderstanding your proposal. Could you describe it more explicitly?

2023-06-07 15:33:55 UTC

- reply

📅 Original date posted:2015-05-08
📝 Original message:On Friday, 8 May 2015, at 8:48 am, Matt Whitlock wrote:
> On Friday, 8 May 2015, at 3:32 pm, Joel Joonatan Kaartinen wrote:
> > It seems you missed my suggestion about basing the maximum block size on
> > the bitcoin days destroyed in transactions that are included in the block.
> > I think it has potential for both scaling as well as keeping up a constant
> > fee pressure. If tuned properly, it should both stop spamming and increase
> > block size maximum when there are a lot of real transactions waiting for
> > inclusion.
>
> My problem with it is that "bitcoin days destroyed" is not a measure of demand for space in the block chain. In the distant future, when Bitcoin is the predominant global currency, bitcoins will have such high velocity that the number of bitcoin days destroyed in each block will be much lower than at present. Does this mean that the block size limit should be lower in the future than it is now? Clearly this would be incorrect.
I feel a need to point out something that may be obvious to some but not to others: the cumulative total number of "bitcoin days destroyed" since the genesis block is bounded by the cumulative total number of "bitcoin days created" since the genesis block. (You can't destroy something that hasn't yet been created.) After all coins have been mined, bitcoin days will be created at a rate of 21M bitcoin days per day. In the long run, bitcoin days will be destroyed at a rate not exceeding 21M bitcoin days per day. This is so because bitcoin days cannot be destroyed at a rate faster than they are created for an indefinitely long time. This upper limit on the rate of bitcoin days destruction is irrespective of bitcoin adoption and the growth in demand for space in the block chain.
Even ignoring the fact that "bitcoin days destroyed" is bounded whereas demand for block-chain space is not, we'd still have to answer the question of whether the rate of bitcoin days destroyed is a good estimator of demand for block-chain space. Why would it be? Suppose some day Satoshi moves his 1M coins to a new address. Would this huge destruction of bitcoin days imply anything about future demand for space in the block chain? No.

2023-06-07 15:33:54 UTC

- reply

📅 Original date posted:2015-05-08
📝 Original message:Between all the flames on this list, several ideas were raised that did not get much attention. I hereby resubmit these ideas for consideration and discussion.
- Perhaps the hard block size limit should be a function of the actual block sizes over some trailing sampling period. For example, take the median block size among the most recent 2016 blocks and multiply it by 1.5. This allows Bitcoin to scale up gradually and organically, rather than having human beings guessing at what is an appropriate limit.
- Perhaps the hard block size limit should be determined by a vote of the miners. Each miner could embed a desired block size limit in the coinbase transactions of the blocks it publishes. The effective hard block size limit would be that size having the greatest number of votes within a sliding window of most recent blocks.
- Perhaps the hard block size limit should be a function of block-chain length, so that it can scale up smoothly rather than jumping immediately to 20 MB. This function could be linear (anticipating a breakdown of Moore's Law) or quadratic.
I would be in support of any of the above, but I do not support Mike Hearn's proposed jump to 20 MB. Hearn's proposal kicks the can down the road without actually solving the problem, and it does so in a controversial (step function) way.

2023-06-07 15:33:02 UTC

- reply

📅 Original date posted:2015-05-06
📝 Original message:I'm not so much opposed to a block size increase as I am opposed to a hard fork. My problem with a hard fork is that everyone and their brother wants to seize the opportunity of a hard fork to insert their own pet feature, and such a mad rush of lightly considered, obscure feature additions would be extremely risky for Bitcoin. If it could be guaranteed that raising the block size limit would be the only incompatible change introduced in the hard fork, then I would support it, but I strongly fear that the hard fork itself will become an excuse to change other aspects of the system in ways that will have unintended and possibly disastrous consequences.

2023-06-07 15:32:12 UTC

- reply

📅 Original date posted:2015-03-25
📝 Original message:On Tuesday, 24 March 2015, at 6:57 pm, Tom Harding wrote:
> It appears that a limited-lifetime address, such as the fanciful
>
> address = 4HB5ld0FzFVj8ALj6mfBsbifRoD4miY36v_349366
>
> where 349366 is the last valid block for a transaction paying this
> address, could be made reuse-proof with bounded resource requirements,
The core devs seem not to like ideas such as this because a transaction that was once valid can become invalid due to a chain reorganization.

2023-06-07 15:28:48 UTC

- reply

📅 Original date posted:2015-01-20
📝 Original message:On Tuesday, 20 January 2015, at 6:44 pm, Tamas Blummer wrote:
> Knowing the private key and owning the linked coins is not necessarily the same in front of a court.
>
> At least in german law there is a difference between ‘Eigentum' means ownership and ‘Besitz’ means ability to deal with it.
> Being able to deal with an asset does not make you the owner.
So what we're telling the newbies in /r/bitcoin is plain wrong. Bitcoins *do* have an owner independent from the parties who have access to the private keys that control their disposition. That's pretty difficult to reconcile from a technological perspective.

2023-06-07 15:28:47 UTC

- reply

📅 Original date posted:2015-01-20
📝 Original message:On Tuesday, 20 January 2015, at 10:46 am, Peter Todd wrote:
> I was talking to a lawyer with a background in finance law the other day
> and we came to a somewhat worrying conclusion: authors of Bitcoin wallet
> software probably have a custodial relationship with their users,
> especially if they use auto-update mechanisms. Unfortunately this has
> potential legal implications as custodial relationships tend to be
> pretty highly regulated.
>
> Why is this? Well, in most jurisdictions financial laws a custodial
> relationship is defined as having the ability, but not the right, to
> dispose of an asset. If you have the private keys for your users'
> bitcoins - e.g. an exchange or "online" wallet - you clearly have the
> ability to spend those bitcoins, thus you have a custodial relationship.
If you have the private keys for your users' bitcoins, then you are every bit as much the owner of those bitcoins as your users are. There is no custodial relationship, as you have both the ability and the right to spend those bitcoins. Possession of a private key is equivalent to ownership of the bitcoins controlled by that private key.

2023-06-07 15:28:47 UTC

- reply

📅 Original date posted:2015-01-20
📝 Original message:On Tuesday, 20 January 2015, at 12:40 pm, Peter Todd wrote:
> On Tue, Jan 20, 2015 at 12:23:14PM -0500, Matt Whitlock wrote:
> > If you have the private keys for your users' bitcoins, then you are every bit as much the owner of those bitcoins as your users are. There is no custodial relationship, as you have both the ability and the right to spend those bitcoins. Possession of a private key is equivalent to ownership of the bitcoins controlled by that private key.
>
> Posessing a private key certainly does not give you an automatic legal
> right to anything. As an example I could sign an agreement with you that
> promised I would manage some BTC on your behalf. That agreement without
> any doubt takes away any legal right I had to your BTC, enough though I
> may have have the technical ability to spend them. This is the very
> reason why the law has the notion of a custodial relationship in the
> first place.
I never signed any kind of agreement with Andreas Schildbach. I keep my bitcoins in his wallet with the full knowledge that an auto-update could clean me out. (I only hold "walking around" amounts of money in my mobile wallet for exactly this reason.) I would love it if Andreas offered me an agreement not to spend my bitcoins without my consent, but I doubt he'd legally be allowed to offer such an agreement, as that would indeed set up a custodial relationship, which would put him into all sorts of regulatory headache.

2023-06-07 15:28:43 UTC

- reply

📅 Original date posted:2015-01-28
📝 Original message:On Wednesday, 28 January 2015, at 5:19 pm, Giuseppe Mazzotta wrote:
> On 28-01-15 16:42, Mike Hearn wrote:
> > Just as a reminder, there is no obligation to use the OS root
> > store. You can (and quite possibly should) take a snapshot of the
> > Mozilla/Apple/MSFT etc stores and load it in your app. We do this
> > in bitcoinj by default to avoid cases where BIP70 requests work on
> > some platforms and not others, although the developer can easily
> > override this and use the OS root store instead.
> >
> Except that Mozilla/Apple/MSFT will update these certificate stores -
> second their policies - and your snapshot/collection might get
> outdated at a different pace than the OS-provided certificates,
> depending on how you (or the package maintainer) are rolling out updates.
I'm frankly _horrified_ to learn that BitcoinJ ships its own root CA certificates bundle. This means that, if a root CA gets breached and a certificate gets revoked, all BitcoinJ-using software will be vulnerable until BitcoinJ ships an update *and* the software in question pulls in the new BitcoinJ update and releases its own update. That might never happen.

2023-06-07 15:28:38 UTC

- reply

📅 Original date posted:2015-01-19
📝 Original message:Even if a compact binary encoding is a high priority, there are more "standard" choices than Google Protocol Buffers. For example, ASN.1 is a very rigorously defined standard that has been around for decades, and ASN.1 even has an XML encoding (XER) that is directly convertible to/from the binary encoding (BER/DER), given the schema. In practice, I'm mostly agnostic about what encoding is actually used in BIP70, and I wouldn't fault BIP70 for choosing Google Protocol Buffers, but the very existence of Protobuf perplexes me, as it apparently re-solves a problem that was solved 40 years ago by ASN.1. It's as though the engineers at Google weren't aware that ASN.1 existed.
On Monday, 19 January 2015, at 7:07 pm, Richard Brady wrote:
> Hi Gavin, Mike and co
>
> Is there a strong driver behind the choice of Google Protocol Buffers for
> payment request encoding in BIP-0070?
>
> Performance doesn't feel that relevant when you think that:
> 1. Payment requests are not broadcast, this is a request / response flow,
> much more akin to a web request.
> 2. One would be cramming this data into a binary format just so you can
> then attach it to a no-so-binary format such as HTTP.
>
> Some great things about protocols/encodings such as HTTP/JSON/XML are:
> 1. They are human readable on-the-wire. No Wireshark plugin required,
> tcpdump or ngrep will do.
> 2. There are tons of great open source libraries and API for parsing /
> manipulating / generating.
> 3. It's really easy to hand-craft a test message for debugging.
> 4. The standards are much easier to read and write. They don't need to
> contain code like BIP-0070 currently does and they can contain examples,
> which BIP70 does not.
> 5. They are thoroughly specified by independent standards bodies such as
> the IETF. Gotta love a bit of MUST / SHOULD / MAY in a standard.
> 6. They're a family ;-)
>
> Keen to hear your thoughts on this and very keen to watch the payment
> protocol grow regardless of encoding choice! My background is SIP / VoIP
> and I think that could be a fascinating use case for this protocol which
> I'm hoping to do some work on.
>
> Best,
> Richard

2023-06-07 15:26:08 UTC

- reply

📅 Original date posted:2014-10-03
📝 Original message:Oops, sorry. I meant: replace the top stack item with the block height of the txin doing the redeeming. (So the script can calculate the "current time" to some reference time embedded in the script.)
On Friday, 3 October 2014, at 10:28 am, Matt Whitlock wrote:
> Is there a reason why we can't have the new opcode simply replace the top stack item with the block height of the txout being redeemed? Then arbitrary logic could be implemented, including "output cannot be spent until a certain time" and also "output can ONLY be spent until a certain time," as well as complex logic with alternative key groups with differing time constraints.
>
> OP_CHECKLOCKTIMEVERIFY, as conceived, seems too limited, IMHO.
>
>
> On Thursday, 2 October 2014, at 4:05 pm, Flavien Charlon wrote:
> > Very good, I like the proposal.
> >
> > A question I have: can it be used to do the opposite, i.e. build a script
> > that can only be spent up until block X?
> >
> > On Thu, Oct 2, 2014 at 2:09 AM, Peter Todd <pete at petertodd.org> wrote:
> >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA256
> > >
> > >
> > >
> > > On 1 October 2014 17:55:36 GMT-07:00, Luke Dashjr <luke at dashjr.org> wrote:
> > > >On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote:
> > > >> On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr <luke at dashjr.org>
> > > >wrote:
> > > >> >Thoughts on some way to have the stack item be incremented by the
> > > >> >height at
> > > >> >which the scriptPubKey was in a block?
> > > >>
> > > >> Better to create a GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator.
> > > >> scriptPubKey would be:
> > > >> GET-TXIN-BLOCKHEIGHT-EQUALVERIFY
> > > >> (fails unless top stack item is equal to the txin block height)
> > > >> <delta height> ADD
> > > >> (top stack item is now txin height + delta height)
> > > >> CHECKLOCKTIMEVERIFY
> > > >
> > > >This sounds do-able, although it doesn't address using timestamps.
> > >
> > > For timestamps replace "height" with "time" in the above example; the
> > > minimum block time rule will prevent gaming it.
> > >
> > >
> > > >> You'd want these sacrifices to unlock years into the future to
> > > >thoroughly
> > > >> exceed any reasonable business cycle; that's so far into the future
> > > >that
> > > >> miners are almost certain to just mine them and collect the fees.
> > > >
> > > >For many use cases, short maturity periods are just as appropriate IMO.
> > >
> > > Very easy to incentivise mining centralisation with short maturities. I
> > > personally think just destroying coins is better, but it doesn't sit well
> > > with people so this is the next best thing.
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: APG v1.1.1
> > >
> > > iQFQBAEBCAA6BQJULKWsMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
> > > cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhcg8CACueZNGfWaZR+xyG9/o
> > > JwDBCnqOtwr6Bnosg3vNcRIDUnmsh+Qkk5dk2JpqYNYw7C3duhlwHshgsGOFkHEV
> > > f5RHDwkzGLJDLXrBwxxcIDdm3cJL8UVpQzJ7dD7aSnfj7MU/0aru3HaIU2ZfymUb
> > > 63jhul6FGbXH3K6p3bOoNrfIrCCGOv8jOIzeAgxNPydk8MVPgRhlYLAKBJxu8nMr
> > > 1oJGeaKVSGSPSrRdgS8tI4uOs0F4Q49APrLPGxGTERlATmWrr+asHGJTIxsB2IEm
> > > vrNgVRpkaN4Of9k96qzD9ReKfBfqm0WQKLolcXCVqGpdoHcvXh2AeWdjB/EFTyOq
> > > SOgO
> > > =WybM
> > > -----END PGP SIGNATURE-----
> > >
> > >
> > >
> > > ------------------------------------------------------------------------------
> > > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> > > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> > > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> > > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> > >
> > > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> > > _______________________________________________
> > > Bitcoin-development mailing list
> > > Bitcoin-development at lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > >

2023-06-07 15:26:07 UTC

- reply

📅 Original date posted:2014-10-03
📝 Original message:Is there a reason why we can't have the new opcode simply replace the top stack item with the block height of the txout being redeemed? Then arbitrary logic could be implemented, including "output cannot be spent until a certain time" and also "output can ONLY be spent until a certain time," as well as complex logic with alternative key groups with differing time constraints.
OP_CHECKLOCKTIMEVERIFY, as conceived, seems too limited, IMHO.
On Thursday, 2 October 2014, at 4:05 pm, Flavien Charlon wrote:
> Very good, I like the proposal.
>
> A question I have: can it be used to do the opposite, i.e. build a script
> that can only be spent up until block X?
>
> On Thu, Oct 2, 2014 at 2:09 AM, Peter Todd <pete at petertodd.org> wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> >
> >
> > On 1 October 2014 17:55:36 GMT-07:00, Luke Dashjr <luke at dashjr.org> wrote:
> > >On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote:
> > >> On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr <luke at dashjr.org>
> > >wrote:
> > >> >Thoughts on some way to have the stack item be incremented by the
> > >> >height at
> > >> >which the scriptPubKey was in a block?
> > >>
> > >> Better to create a GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator.
> > >> scriptPubKey would be:
> > >> GET-TXIN-BLOCKHEIGHT-EQUALVERIFY
> > >> (fails unless top stack item is equal to the txin block height)
> > >> <delta height> ADD
> > >> (top stack item is now txin height + delta height)
> > >> CHECKLOCKTIMEVERIFY
> > >
> > >This sounds do-able, although it doesn't address using timestamps.
> >
> > For timestamps replace "height" with "time" in the above example; the
> > minimum block time rule will prevent gaming it.
> >
> >
> > >> You'd want these sacrifices to unlock years into the future to
> > >thoroughly
> > >> exceed any reasonable business cycle; that's so far into the future
> > >that
> > >> miners are almost certain to just mine them and collect the fees.
> > >
> > >For many use cases, short maturity periods are just as appropriate IMO.
> >
> > Very easy to incentivise mining centralisation with short maturities. I
> > personally think just destroying coins is better, but it doesn't sit well
> > with people so this is the next best thing.
> > -----BEGIN PGP SIGNATURE-----
> > Version: APG v1.1.1
> >
> > iQFQBAEBCAA6BQJULKWsMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
> > cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhcg8CACueZNGfWaZR+xyG9/o
> > JwDBCnqOtwr6Bnosg3vNcRIDUnmsh+Qkk5dk2JpqYNYw7C3duhlwHshgsGOFkHEV
> > f5RHDwkzGLJDLXrBwxxcIDdm3cJL8UVpQzJ7dD7aSnfj7MU/0aru3HaIU2ZfymUb
> > 63jhul6FGbXH3K6p3bOoNrfIrCCGOv8jOIzeAgxNPydk8MVPgRhlYLAKBJxu8nMr
> > 1oJGeaKVSGSPSrRdgS8tI4uOs0F4Q49APrLPGxGTERlATmWrr+asHGJTIxsB2IEm
> > vrNgVRpkaN4Of9k96qzD9ReKfBfqm0WQKLolcXCVqGpdoHcvXh2AeWdjB/EFTyOq
> > SOgO
> > =WybM
> > -----END PGP SIGNATURE-----
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> >
> > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >

2023-06-07 15:25:48 UTC

- reply

📅 Original date posted:2014-09-15
📝 Original message:On Monday, 15 September 2014, at 5:10 pm, Thomas Zander wrote:
> So for instance I start including a bitcoin public key in my email signature.
> I don't sign the emails or anything like that, just to establish that everyone
> has my public key many times in their email archives.
> Then when I need to proof its me, I can provide a signature on the content
> that the requester wants me to sign.
That would not work. You would need to sign your messages. If you were merely attaching your public key to them, then the email server could have been systematically replacing your public key with some other public key, and then, when you would later try to provide a signature, your signature would not verify under the public key that everyone else had been seeing attached to your messages.

2023-06-07 15:24:39 UTC

- reply

📅 Original date posted:2014-07-31
📝 Original message:It would make more sense to introduce a new script opcode that pushes the current block height onto the operand stack. Then you could implement arbitrary logic about which blocks the transaction can be valid in. This would require that the client revalidate all transactions in its mempool (really, only those making use of this opcode) whenever the chain tip changes.
On Thursday, 31 July 2014, at 5:58 pm, Kaz Wesley wrote:
> There is currently little in place for managing transaction lifetime
> in the network's mempools (see discussion in github in #3722 "mempool
> transaction expiration", and it seems to be a major factor blocking
> some mempool exchange, see #1833/1918, #3721). Expiry per-node a
> certain amount of wall time after receipt has been proposed, but
> that's a fragile mechanism -- a single node could keep all relayable
> transactions alive forever by remembering transactions until most
> nodes have dropped them and then releasing them back into the wild.
>
> I have a proposal for a way to add finite and predictable lifespans to
> transactions in mempools: we d̶e̶s̶t̶r̶o̶y̶ ̶t̶h̶e̶
> ̶r̶e̶s̶u̶r̶r̶e̶c̶t̶i̶o̶n̶ ̶h̶u̶b̶ use nLockTime and a new standardness
> rule. It could be done in stages, would not necessarily require even a
> soft fork, and does not cause problems with reorgs like the proposal
> in #3509:
> 1. start setting nLockTime to the current height by default in newly
> created transactions (or slightly below the current height, for
> reorg-friendliness)
> 2. once users have had some time to upgrade to clients that set
> nLockTime, start discouraging transactions without nLockTime --
> possibly with a slightly higher fee required for relay
> 3. start rate-limiting relay of transactions without an nLockTime
> (maybe this alone could be used to achieve [2])
> 4. add a new IsStandard rule rejecting transactions with an nLockTime
> more than N blocks behind the current tip (for some fixed value N, to
> be determined)
>
> Transactions would stop being relayed and drop out of mempools a fixed
> number of blocks from their creation; once that window had passed, the
> sender's wallet could begin to expect the transaction would not be
> confirmed. In case a reorg displaces a transaction until after its
> expiry height, a miner can still put it back in the blockchain; the
> expiry height is just a relay rule. Also, a user who needed to get
> their original "expired" transaction confirmed could still do so by
> submitting it directly to a miner with suitable policies.

2023-06-07 15:22:55 UTC

- reply

📅 Original date posted:2014-06-16
📝 Original message:On Monday, 16 June 2014, at 5:07 pm, Justus Ranvier wrote:
> On 06/16/2014 04:25 PM, Matt Whitlock wrote:
> > How can there be any kind of lottery that doesn't involve proof of
> > work or proof of stake? Without some resource-limiting factor,
> > there is no way to limit the number of "lottery tickets" any given
> > individual could acquire. The very process of Bitcoin mining was
> > invented specifically to overcome the Sybil problem, which had
> > plagued computer scientists for decades, and now you're proposing a
> > system that suffers from the same problem. Or am I wrong about
> > this?
>
> If you allow the solution set to include pay-to-play networks, and not
> just free P2P networks, then it's easier to find a solution
>
> Imagine every node is competing with its peers in terms of relevancy.
> Relevancy is established by delivering newly-seen transactions first.
>
> Each node keeps track of which of its peers send it transactions that
> it hadn't seen and forwarded to them yet (making sure that the
> transactions do make it into a block) and uses that information to
> determine whether or not it should be paying that peer, or if that
> peer should be paying it, or if they are equal relevancy and no net
> payment is required.
>
> Once any given pair of nodes can establish who, if anyone, should be
> paying they could use micropayment channels to handle payments.
>
> Nodes that are well connected, and with high uptimes would end up
> being net recipients of payments. Mobile nodes and other low-uptime
> nodes would be net payers.
>
> Now that you've established a market for the service of delivering
> transaction information, you can rely on price signals to properly
> match supply and demand.
>
> People who hate market-based solutions could always run these nodes
> and configure them to refuse to pay anyone, and to charge nothing to
> their peers, if that's what they wanted.
This is a cool idea, but doesn't it generate some perverse incentives? If I'm running a full node and I want to pay CheapAir for some plane tickets, I'll want to pay in the greatest number of individual transactions possible, to maximize the rewards that I'll receive from my connected peers. This maybe would not be a problem if transaction fees were required on all transactions, but as it is (e.g., while fee-free transactions can be accepted into blocks if they have high enough priority), I can "preload" my wallet with hundreds of small-ish outputs, let them sit there for a few months to accumulate coin age, and then spend each little piece in a separate transaction when it comes time to pay for a big-ticket purchase. It's more lucrative for me to pay for my plane ticket in 100 separate, low-value transactions than in one high-value transaction. So you're incentivizing greater consumption of bandwidth and storage.

2023-06-07 15:22:54 UTC

- reply

📅 Original date posted:2014-06-16
📝 Original message:How can there be any kind of lottery that doesn't involve proof of work or proof of stake? Without some resource-limiting factor, there is no way to limit the number of "lottery tickets" any given individual could acquire. The very process of Bitcoin mining was invented specifically to overcome the Sybil problem, which had plagued computer scientists for decades, and now you're proposing a system that suffers from the same problem. Or am I wrong about this?
On Monday, 16 June 2014, at 1:12 am, Odinn Cyberguerrilla wrote:
> I have been noticing for some time the problem which Mike H. identified as
> how we are bleeding nodes ~ losing nodes over time.
>
> This link was referenced in the coindesk article of May 9, 2014:
>
> http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/CANEZrP2rgiQHpekEpFviJ22QsiV%2Bs-F2pqosaZOA5WrRtJx5pg%40mail.gmail.com/#msg32196023
>
> (coindesk article for reference: http://www.coindesk.com/bitcoin-nodes-need/)
>
> The proposed solution is noted here as a portion of an issue at:
> https://github.com/bitcoin/bitcoin/issues/4079
>
> Essentially that part which has to do with helping reduce
> the loss of nodes is as follows:
>
> "a feature similar to that suggested by @gmaxwell that would process small
> change and tiny txouts to user specified donation targets, in an
> incentivized process. Those running full nodes (Bitcoin Core all the
> time), processing their change and txouts through Core, would be provided
> incentives in the form of a 'decentralizing lottery' such that all
> participants who are running nodes and donating no matter how infrequently
> (and no matter who they donate to) will be entered in the 'decentralizing
> lottery,' the 'award amounts' (which would be distinct from 'block
> rewards' for any mining) would vary from small to large bitcoin amounts
> depending on how many participants are involved in the donations process.
> This would help incentivize individuals to run full nodes as well as
> encouraging giving and microdonations. The option could be expressed in
> the transactions area to contribute to help bitcoin core development for
> those that are setting up change and txouts for donations, regarding the
> microdonation portion (which has also has been expressed conceptually at
> abis.io"
>
> This addresses the issue of how to incentivize more
> interested individuals to run full nodes (Bitcoin Core). The lottery
> concept (which would be applicable to anyone running the full node
> regardless of whether or not they are mining) is attractive from the point
> of view that it will complement the block reward concept already in place
> which serves those who mine, but more attractive to the individual who
> doesn't feel the urge to mine, but would like to have the chance of being
> compensated for the effort they put into the system.
>
> I hope that this leads to additional development discussion on these
> concepts regarding incentivizing giving. This may also involve a process
> BIP. I look forward to your remarks.
>
> Respect,
>
> Odinn

2023-06-07 15:21:22 UTC

- reply

📅 Original date posted:2014-05-16
📝 Original message:Is Peter Todd's server actually up? The Google public DNS resolver at 8.8.8.8 can't resolve testnet-seed.bitcoin.petertodd.org either (SERVFAIL).
On Friday, 16 May 2014, at 6:34 pm, Andreas Schildbach wrote:
> Apparently British Telecom also cannot speak to Peter Todd's server.
>
> That another very large ISP in Europe.
>
>
> On 05/15/2014 01:50 PM, Andreas Schildbach wrote:
> > I'm bringing this issue up again. The current Bitcoin DNS seed
> > infrastructure is unstable. I assume this is because of we're using a
> > custom DNS implementation which is not 100% compatible. There have been
> > bugs in the past, like a case sensitive match for the domain name.
> >
> > Current state (seeds taken from bitcoinj):
> >
> > mainnet:
> >
> > seed.bitcoin.sipa.be OK
> > dnsseed.bluematt.me OK
> > dnsseed.bitcoin.dashjr.org SERVFAIL, tried multiple ISPs
> > seed.bitcoinstats.com OK
> >
> > testnet:
> >
> > testnet-seed.bitcoin.petertodd.org SERVFAIL, just from Telefonica
> > testnet-seed.bluematt.me OK (but only returns one node)
> >
> > Note: Telefonica is one of Europe's largest ISPs.
> >
> > I would try to improve DNS myself, but I'm not capable of writing C. My
> > "fix" would be to reimplement everything in Java -- I doubt you guys
> > would be happy with that.
> >
> >
> > ------------------------------------------------------------------------------
> > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> > Instantly run your Selenium tests across 300+ browser/OS combos.
> > Get unparalleled scalability from the best Selenium testing platform available
> > Simple to use. Nothing to install. Get started now for free."
> > http://p.sf.net/sfu/SauceLabs
> >
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:21:17 UTC

- reply

📅 Original date posted:2014-05-12
📝 Original message:On Monday, 12 May 2014, at 9:53 am, Gregory Maxwell wrote:
> I've noticed some folks struggling to attach labels to their yet to be
> numbered BIPs.
>
> I'd recommend people call them "draft-<main author name>-<what it
> does>" like draft-maxwell-coinburning in the style of pre-WG IETF
> drafts.
Why is there such a high bar to getting a number assigned to a BIP anyway? BIP 1 seems to suggest that getting a BIP number assigned is no big deal, but the reality seems to betray that casual notion. Even proposals with hours of work put into them are not getting BIP numbers. It's not exactly as though there's a shortage of integers. Are numbers assigned only to proposals that are well liked? Isn't the point of assigning numbers so that we can have organized discussions about all proposals, even ones we don't like?

2023-06-07 15:17:13 UTC

- reply

📅 Original date posted:2014-04-22
📝 Original message:On Tuesday, 22 April 2014, at 10:39 am, Tamas Blummer wrote:
> Extra encoding for testnet is quite useless complexity in face of many alt chains.
> BIPS should be chain agnostic.
I would argue that Bitcoin should be altcoin-agnostic. :)
I have no interest in catering to altcoins. But that's just me.

2023-06-07 15:17:12 UTC

- reply

📅 Original date posted:2014-04-22
📝 Original message:On Tuesday, 22 April 2014, at 4:11 am, Matt Whitlock wrote:
> On Tuesday, 22 April 2014, at 10:06 am, Jan Møller wrote:
> > - I think it is very useful to define different prefixes for testnet
> > keys/seeds. As a developer I use the testnet every day, and many of our
> > users use it for trying out new functionality. Mixing up keys meant for
> > testnet and mainnet is bad.
>
> A fair point. I'll add some prefixes for testnet.
Testnet encodings are added: https://github.com/whitslack/btctool/blob/bip/bip-xxxx.mediawiki

2023-06-07 15:17:12 UTC

- reply

📅 Original date posted:2014-04-22
📝 Original message:On Tuesday, 22 April 2014, at 10:39 am, Jan Møller wrote:
> On Tue, Apr 22, 2014 at 10:29 AM, Matt Whitlock <bip at mattwhitlock.name>wrote:
> > On Tuesday, 22 April 2014, at 10:27 am, Jan Møller wrote:
> > > > > - Please allow M=1. From a usability point of view it makes sense to allow
> > > > > the user to select 1 share if that is what he wants.
> > > >
> > > > How does that make sense? Decomposing a key/seed into 1 share is
> > > > functionally equivalent to dispensing with the secret sharing scheme
> > > > entirely.
> > > >
> > > I agree that it may look silly to have just one-of-one share from a
> > > technical point of view, but from an end-user point of view there could be
> > > reasons for just having one piece of paper to manage. If M can be 1 then
> > > the software/hardware doesn't have to support multiple formats,
> > > import/export paths + UI (one for SIPA keys in one share, one for HD seeds
> > > in one share, one for SIPA keys + HD seeds in multiple shares).
> > >
> > > Less complexity & more freedom of choice.
> >
> > Alright. It's a fair argument. Do you agree with encoding M using a bias
> > of -1 so that M up to and including 256 can be encoded in one byte?
>
> Necessary Shares = M+1, not a problem
>
> I would probably encode N-of-M in 1 byte as I don't see good use cases with
> more than 17 shares. Anyway, I am fine with it as it is.
Encoding bias of M changed to -1, and test vectors updated:
https://github.com/whitslack/btctool/blob/bip/bip-xxxx.mediawiki

2023-06-07 15:17:11 UTC

- reply

📅 Original date posted:2014-04-22
📝 Original message:On Tuesday, 22 April 2014, at 10:39 am, Jan Møller wrote:
> Necessary Shares = M+1, not a problem
>
> I would probably encode N-of-M in 1 byte as I don't see good use cases with
> more than 17 shares. Anyway, I am fine with it as it is.
I agree that M > 16 is probably not a viable use case for human beings, but machines would probably be able to make use of it. I, for one, welcome our new robot overlords.
Also, the byte that encodes M−1 is optional, so if you're concerned about space, you can omit it (and the checksum).

2023-06-07 15:17:11 UTC

- reply

📅 Original date posted:2014-04-22
📝 Original message:On Tuesday, 22 April 2014, at 10:27 am, Jan Møller wrote:
> > > - Please allow M=1. From a usability point of view it makes sense to
> > allow
> > > the user to select 1 share if that is what he wants.
> >
> > How does that make sense? Decomposing a key/seed into 1 share is
> > functionally equivalent to dispensing with the secret sharing scheme
> > entirely.
> >
> >
> I agree that it may look silly to have just one-of-one share from a
> technical point of view, but from an end-user point of view there could be
> reasons for just having one piece of paper to manage. If M can be 1 then
> the software/hardware doesn't have to support multiple formats,
> import/export paths + UI (one for SIPA keys in one share, one for HD seeds
> in one share, one for SIPA keys + HD seeds in multiple shares).
>
> Less complexity & more freedom of choice.
Alright. It's a fair argument. Do you agree with encoding M using a bias of -1 so that M up to and including 256 can be encoded in one byte?

2023-06-07 15:17:10 UTC

- reply

📅 Original date posted:2014-04-22
📝 Original message:On Tuesday, 22 April 2014, at 10:06 am, Jan Møller wrote:
> This is a very useful BIP, and I am very much looking forward to
> implementing it in Mycelium, in particular for bip32 wallets.
> To me this is not about whether to use SSS instead of multisig
> transactions. In the end you want to protect a secret (be it a HD master
> seed or a private key) in such a way that you can recover it in case of
> partial theft/loss. Whether I'll use the master seed to generate keys that
> are going to be used for multisig transactions is another discussion IMO.
>
> A few suggestions:
> - I think it is very useful to define different prefixes for testnet
> keys/seeds. As a developer I use the testnet every day, and many of our
> users use it for trying out new functionality. Mixing up keys meant for
> testnet and mainnet is bad.
A fair point. I'll add some prefixes for testnet.
> - Please allow M=1. From a usability point of view it makes sense to allow
> the user to select 1 share if that is what he wants.
How does that make sense? Decomposing a key/seed into 1 share is functionally equivalent to dispensing with the secret sharing scheme entirely.
> I have no strong opinions of whether to use GF(2^8) over Shamir's Secret
> Sharing, but the simplicity of GF(2^8) is appealing.
I'll welcome forks of my draft BIP. I don't really have the inclination to research GF(2^8) secret sharing schemes and write an implementation at the present time, but if someone wants to take my BIP in that direction, then okay.

2023-06-07 15:17:09 UTC

- reply

📅 Original date posted:2014-04-08
📝 Original message:On Monday, 7 April 2014, at 7:07 pm, Gregory Maxwell wrote:
> On Mon, Apr 7, 2014 at 6:46 PM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> > On Monday, 7 April 2014, at 5:38 pm, Gregory Maxwell wrote:
> >> On Mon, Apr 7, 2014 at 5:33 PM, Nikita Schmidt
> >> <nikita at megiontechnologies.com> wrote:
> >> > Regarding the choice of fields, any implementation of this BIP will
> >> > need big integer arithmetic to do base-58 anyway.
> >> Nah, it doesn't. E.g.
> >> https://gitorious.org/bitcoin/libblkmaker/source/eb33f9c8e441ffef457a79d76ceed1ea20ab3059:base58.c
> > That only *decodes* Base58Check. It has no encode function, which would require biginteger division.
>
> Yes thats only a decode but the same process (long division with
> manual carries) works just fine the other way. There is absolutely no
> need to use big integers for this.
What do you think a big-integer division by a word-sized divisor *is*? Obviously rolling your own is always an option. Are you just saying that Base58 encoding and decoding is easier than Shamir's Secret Sharing because the divisors are small?

2023-06-07 15:17:09 UTC

- reply

📅 Original date posted:2014-04-07
📝 Original message:On Monday, 7 April 2014, at 5:38 pm, Gregory Maxwell wrote:
> On Mon, Apr 7, 2014 at 5:33 PM, Nikita Schmidt
> <nikita at megiontechnologies.com> wrote:
> > Regarding the choice of fields, any implementation of this BIP will
> > need big integer arithmetic to do base-58 anyway.
>
> Nah, it doesn't. E.g.
> https://gitorious.org/bitcoin/libblkmaker/source/eb33f9c8e441ffef457a79d76ceed1ea20ab3059:base58.c
That only *decodes* Base58Check. It has no encode function, which would require biginteger division.

2023-06-07 15:17:08 UTC

- reply

📅 Original date posted:2014-04-04
📝 Original message:On Friday, 4 April 2014, at 5:51 pm, Nikita Schmidt wrote:
> On 4 April 2014 01:42, Matt Whitlock <bip at mattwhitlock.name> wrote:
> > The fingerprint field, Hash16(K), is presently specified as a 16-bit field. Rationale: There is no need to consume 4 bytes just to allow shares to be grouped together. And if someone has more than 100 different secrets, they probably have a good system for managing their shares and won't need the hash anyway.
>
> Right, of course. Sorry, I didn't notice there was an update. Two
> bytes are plenty.
>
> I'm worried however about the dependency on SHA-512, which may be
> stretching it for a tiny embedded application. The other uses of
> HashL can be avoided. We are balancing here between consistency with
> the rest of this proposal, where everything is done via HashL, and
> consistency with the general practice of generating fingerprints with
> SHA-256, like in Base58Check.
I'd be fine with changing the key fingerprint algorithm to something else. Do you like CRC16?
> >> Speaking of encoding, is it not wasteful to allocate three different
> >> application/version bytes just for the sake of always starting with
> >> 'SS'? It would be OK if it were accepted as a BIP, but merely as a
> >> de-facto standard it should aim at minimising future chances of
> >> collision.
> >
> > I agree on principle, however I think the more user-acceptable behavior is for all base58-encoded Shamir shares to begin with a common prefix, such as "SS". Users are accustomed to relying on the prefix of the base58 encoding to understand what the object is: "1" for mainnet pubkey hash, "3" for mainnet script hash, "5" for uncompressed private key, "P" for passphrase-protected private key, etc.
>
> Yes, "5" for uncompressed private key and "K" or "L" for compressed
> private key. One A/VB and three prefixes in base58. Am I the only
> one to see this as a counter-example?
>
> However, thinking about this, I can find logic in wanting to stabilise
> text prefixes at a cost of six A/V bytes (as per the latest spec).
> There are only 58 first characters versus 256 AVBs, so we should
> rather be saving the former.
The type of a base58-encoded object is determined not only by the application/version byte but by the payload length as well. For example, a base58-encoded object with an application/version byte of 0x80 but a payload length of 16 bytes would not be mistakable for a Bitcoin private key, even though AVB 0x80 does denote a Bitcoin private key when the payload length is 32 or 33 bytes. So it's not as simple as saying that this proposal costs 6 AVBs. It really costs one AVB for 18-byte payloads, one AVB for 21-byte payloads, one AVB for 34-byte payloads, one AVB fo 37-byte payloads, one AVB for 66-byte payloads, and one AVB for 69-byte payloads.
> >> What about using the same P256 prime as for the elliptic curve? Just
> >> for consistency's sake.
> >
> > The initial draft of this BIP used the cyclic order (n) of the generator point on the secp256k1 elliptic curve as the modulus. The change to the present scheme was actually done for consistency's sake, so all sizes of secret can use a consistently defined modulus.
>
> Fair enough. Although I would have chosen the field order (p) simply
> because that's how all arithmetic already works in bitcoin. One field
> for everybody. It's also very close to 2^256, although still smaller
> than your maximum prime. Now of course with different bit lengths we
> have to pick one consistency over others.
As Gregory Maxwell pointed out, you can't use p when you're dealing with private keys, as that is the order of the finite field over which the elliptic curve is defined, but private keys are not points on that curve; a private key is a scalar number of times to multiply the generator point. That means you have to use the order of the generator point as the modulus when working with private keys.
> >> Also, I'm somewhat inclined towards using the actual x instead of j in
> >> the encoding. I find it more direct and straightforward to encode the
> >> pair (x, y). And x=0 can denote a special case for future extensions.
> >> There is no technical reason behind this, it's just for (subjective)
> >> clarity and consistency.
> >
> > There is a technical reason for encoding j rather than x[j]: it allows for the first 256 shares to be encoded, rather than only the first 255 shares.
>
> Wow, big deal. It's hard to imagine anyone needing exactly 256
> shares, but who knows. And with j = x (starting from 1) we'd get
> user-friendly share numbering and simpler formulas in the spec and
> possibly in the implementation, with no off-by-one stuff. And M
> instead of M-2...
It's common for implementation limits to be powers of two. I don't foresee any off-by-one errors, as the spec is clear on the value of each byte in the encoding.

2023-06-07 15:17:08 UTC

- reply

📅 Original date posted:2014-04-04
📝 Original message:On Friday, 4 April 2014, at 10:51 am, Gregory Maxwell wrote:
> On Fri, Apr 4, 2014 at 10:16 AM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> > Honestly, that sounds a lot more complicated than what I have now. I made my current implementation because I just wanted something simple that would let me divide a private key into shares for purposes of dissemination to my next of kin et al.
>
> I suggest you go look at some of the other secret sharing
> implementations that use GF(2^8), they end up just being a couple of
> dozen lines of code. Pretty simple stuff, and they work efficiently
> for all sizes of data, there are implementations in a multitude of
> languages. There are a whole bunch of these.
Okay, I will.
> > Do you have a use case in mind that would benefit from byte-wise operations rather than big-integer operations? I mean, I guess if you were trying to implement this BIP on a PIC microcontroller, it might be nice to process the secret in smaller bites. (No pun intended.) But I get this feeling that you're only pushing me away from the present incarnation of my proposal because you think it's too similar (but not quite similar enough) to a threshold ECDSA key scheme.
>
> It lets you efficiently scale to any size data being encoded without
> extra overhead or having additional primes. It can be compactly
> implemented in Javascript (there are several implementations you can
> find if you google), it shouldn't be burdensome to implement on a
> device like a trezor (much less a real microcontroller).
Those are fair points.
> And yea, sure, it's distinct from the implementation you'd use for
> threshold signing. A threshold singing one would lack the size agility
> or the easy of implementation on limited devices. So I do think that
> if there is to be two it would be good to gain the advantages that
> can't be achieved in an threshold ECDSA compatible approach.
I agree. I'll look into secret sharing in GF(2^8), but it may take me a few days.

2023-06-07 15:17:07 UTC

- reply

📅 Original date posted:2014-04-04
📝 Original message:On Friday, 4 April 2014, at 9:25 am, Gregory Maxwell wrote:
> On Fri, Apr 4, 2014 at 9:05 AM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> > On Friday, 4 April 2014, at 7:14 am, Gregory Maxwell wrote:
> >> I still repeat my concern that any private key secret sharing scheme
> >> really ought to be compatible with threshold ECDSA, otherwise we're
> >> just going to have another redundant specification.
> >
> > I have that concern too, but then how can we support secrets of sizes other than 256 bits? A likely use case for this BIP (even more likely than using it to decompose Bitcoin private keys) is using it to decompose BIP32 master seeds, which can be 512 bits in size. We can't use secp256k1_n as the modulus there.
>
> Well, if you're not doing anything homorphic with the result the
> computation should probably be over a small field (for computational
> efficiency and implementation simplicity reasons) and the data split
> up, this also makes it easier to deal with many different data sizes,
> since the various sizes will more efficiently divide into the small
> field. The field only needs to be large enough to handle the number
> of distinct shares you wish to issue, so even an 8 bit field would
> probably be adequate (and yields some very simple table based
> implementations).
Are you proposing to switch from prime fields to a binary field? Because if you're going to "break up" a secret into little pieces, you can't assume that every piece of the secret will be strictly less than some 8-bit prime modulus. And if you're going to do a base conversion, then you have to do arbitrary-precision integer math anyway, so I don't see that the small field really saves you any code.
> If that route is taken, rather than encoding BIP32 master keys, it
> would probably be prudent to encode the encryption optional version
> https://bitcointalk.org/index.php?topic=258678.0 ... and if we're
> talking about a new armored private key format then perhaps we should
> be talking about Mark Friedenbach's error correcting capable scheme:
> https://gist.github.com/maaku/8996338#file-bip-ecc32-mediawiki
> (though it would be nicer if we could find a decoding scheme that
> supported list decoding without increasing the complexity of a basic
> implementation, since an advanced recovery tool could make good use of
> a list decode)
Weren't you just clamoring for implementation *simplicity* in your previous paragraph? :)

2023-06-07 15:17:07 UTC

- reply

📅 Original date posted:2014-04-04
📝 Original message:On Friday, 4 April 2014, at 10:08 am, Gregory Maxwell wrote:
> On Fri, Apr 4, 2014 at 9:36 AM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> > Are you proposing to switch from prime fields to a binary field? Because if you're going to "break up" a secret into little pieces, you can't assume that every piece of the secret will be strictly less than some 8-bit prime modulus. And if you're going to do a base conversion, then you have to do arbitrary-precision integer math anyway, so I don't see that the small field really saves you any code.
>
> Yes, I'm proposing using the binary extension field of GF(2^8). There
> are many secret sharing and data integrity applications available
> already operating over GF(2^8) so you can go compare implementation
> approaches without having to try them our yourself. Obviously anything
> efficiently encoded as bytes will efficiently encode over GF(2^8).
Honestly, that sounds a lot more complicated than what I have now. I made my current implementation because I just wanted something simple that would let me divide a private key into shares for purposes of dissemination to my next of kin et al.
> > Weren't you just clamoring for implementation *simplicity* in your previous paragraph? :)
>
> I do think there is a material difference in complexity that comes in
> layers rather than at a single point. It's much easier to implement a
> complex thing that has many individually testable parts then a single
> complex part. (Implementing arithmetic mod some huge P is quite a bit
> of work unless you're using some very high level language with
> integrated bignums— and are comfortable hoping that their bignums are
> sufficiently consistent with the spec).
I already have a fairly polished implementation of my BIP, and it's not written in a "very high-level language"; it's C++, and the parts that do the big-integer arithmetic are basically C. I'm using the GMP library: very straightforward, very reliable, very fast.
Do you have a use case in mind that would benefit from byte-wise operations rather than big-integer operations? I mean, I guess if you were trying to implement this BIP on a PIC microcontroller, it might be nice to process the secret in smaller bites. (No pun intended.) But I get this feeling that you're only pushing me away from the present incarnation of my proposal because you think it's too similar (but not quite similar enough) to a threshold ECDSA key scheme.

2023-06-07 15:17:06 UTC

- reply

📅 Original date posted:2014-04-04
📝 Original message:On Friday, 4 April 2014, at 7:14 am, Gregory Maxwell wrote:
> I still repeat my concern that any private key secret sharing scheme
> really ought to be compatible with threshold ECDSA, otherwise we're
> just going to have another redundant specification.
I have that concern too, but then how can we support secrets of sizes other than 256 bits? A likely use case for this BIP (even more likely than using it to decompose Bitcoin private keys) is using it to decompose BIP32 master seeds, which can be 512 bits in size. We can't use secp256k1_n as the modulus there.

2023-06-07 15:17:05 UTC

- reply

📅 Original date posted:2014-04-03
📝 Original message:On Thursday, 3 April 2014, at 4:41 pm, Nikita Schmidt wrote:
> I agree with the recently mentioned suggestion to make non-essential
> metadata, namely key fingerprint and degree (M), optional. Their
> 4-byte and 1-byte fields can be added individually at an
> implementation's discretion. During decoding, the total length will
> determine which fields are included.
The fingerprint field, Hash16(K), is presently specified as a 16-bit field. Rationale: There is no need to consume 4 bytes just to allow shares to be grouped together. And if someone has more than 100 different secrets, they probably have a good system for managing their shares and won't need the hash anyway.
> Encoding for the testnet is not specified.
Hmm, is that actually needed?
> Speaking of encoding, is it not wasteful to allocate three different
> application/version bytes just for the sake of always starting with
> 'SS'? It would be OK if it were accepted as a BIP, but merely as a
> de-facto standard it should aim at minimising future chances of
> collision.
I agree on principle, however I think the more user-acceptable behavior is for all base58-encoded Shamir shares to begin with a common prefix, such as "SS". Users are accustomed to relying on the prefix of the base58 encoding to understand what the object is: "1" for mainnet pubkey hash, "3" for mainnet script hash, "5" for uncompressed private key, "P" for passphrase-protected private key, etc.
> I'd add a clause allowing the use of random coefficients instead of
> deterministic, as long as the implementation guarantees to never make
> another set of shares for the same private key or master seed.
I'm not sure that's necessary, as this is an Informational BIP. Implementations are free to ignore it. Shares with randomly selected coefficients would work just fine in a share joiner that conforms to the BIP, so I would expect implementors to feel free to ignore the deterministic formula and use randomly selected coefficients.
> What about using the same P256 prime as for the elliptic curve? Just
> for consistency's sake.
The initial draft of this BIP used the cyclic order (n) of the generator point on the secp256k1 elliptic curve as the modulus. The change to the present scheme was actually done for consistency's sake, so all sizes of secret can use a consistently defined modulus.
> Also, I'm somewhat inclined towards using the actual x instead of j in
> the encoding. I find it more direct and straightforward to encode the
> pair (x, y). And x=0 can denote a special case for future extensions.
> There is no technical reason behind this, it's just for (subjective)
> clarity and consistency.
There is a technical reason for encoding j rather than x[j]: it allows for the first 256 shares to be encoded, rather than only the first 255 shares.
If you want a sentinel value reserved for future extensions, then you might take notice that 0xFFFF is an invalid key fingerprint, along with several other values, and also that 0xFF is an unusable value of M−2, as that would imply M=257, but the scheme can only encode up to 256 shares, so one would never have enough shares to meet the threshold. I considered having the two optional fields be mandatory and allowing 0xFFFF and 0xFF as "redacted" field values, but I like allowing the shares to be shorter if the optional fields are omitted. (Imagine engraving Shamir secret shares onto metal bars by hand with an engraving tool. Fewer characters is better!)

2023-06-07 15:16:55 UTC

- reply

📅 Original date posted:2014-04-05
📝 Original message:On Saturday, 5 April 2014, at 12:21 pm, Jorge Timón wrote:
> I like both DD-MM-YYYY and YYYY-MM-DD. I just dislike MM-DD-YYYY and YYYY-DD-MM.
Your preferences reflect a cultural bias. The only entirely numeric date format that is unambiguous across all cultures is YYYY-MM-DD. (No culture uses YYYY-DD-MM, or at least the ISO seems to think so.)

2023-06-07 15:16:53 UTC

- reply

📅 Original date posted:2014-04-01
📝 Original message:The creation date in your BIP header has the wrong format. It should be 01-04-2014, per BIP 1.
:-)
On Tuesday, 1 April 2014, at 9:00 pm, Pieter Wuille wrote:
> Hi all,
>
> I understand this is a controversial proposal, but bear with me please.
>
> I believe we cannot accept the current subsidy schedule anymore, so I
> wrote a small draft BIP with a proposal to turn Bitcoin into a
> limited-supply currency. Dogecoin has already shown how easy such
> changes are, so I consider this a worthwhile idea to be explored.
>
> The text can be found here: https://gist.github.com/sipa/9920696
>
> Please comment!
>
> Thanks,
>
> --
> Pieter
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:16:42 UTC

- reply

📅 Original date posted:2014-03-29
📝 Original message:On Saturday, 29 March 2014, at 5:28 pm, Roy Badami wrote:
> Right now there are also people simply taking base58-encoded private
> keys and running them through ssss-split.
>
> It has a lot going for it, since it can easily be reassembled on any
> Linux machine without special software (B Poettering's Linux command
> line SSSS implementation[1] seems to be included in most Linux distros).
>
> roy
>
> [1] http://point-at-infinity.org/ssss/
Respectfully, it's also possible to take a base58-encoded private key and run it through GPG, which is included in most Linux distros. But yet we have BIP38.

2023-06-07 15:16:41 UTC

- reply

📅 Original date posted:2014-03-29
📝 Original message:On Saturday, 29 March 2014, at 2:08 pm, Alan Reiner wrote:
> Regardless of how SSSS does it, I believe that obfuscating that
> information is bad news from a usability perspective. Undoubtedly,
> users will make lots of backups of lots of wallets and think they
> remember the M-parameter but don't. They will accidentally mix in some
> 3-of-5 fragments with their 2-of-4 not realizing they are incompatible,
> or not able to distinguish them. Or they'll distribute too many
> thinking the threshold is higher and end up insecure, or possibly not
> have enough fragments to restore their wallet thinking the M-value was
> lower than it actually was.
>
> I just don't see the value in adding such complexity for the benefit of
> obfuscating information an attacker might be able to figure out anyway
> (most backups will be 2-of-N or 3-of-N) and can't act on anyway (because
> he doesn't know where the other frags are and they are actually in
> safe-deposit boxes)
Okay, you've convinced me. However, it looks like the consensus here is that my BIP is unneeded, so I'm not sure it would be worth the effort for me to improve it with your suggestions.

2023-06-07 15:16:41 UTC

- reply

📅 Original date posted:2014-03-29
📝 Original message:On Saturday, 29 March 2014, at 1:52 pm, Alan Reiner wrote:
> On 03/29/2014 01:19 PM, Matt Whitlock wrote:
> > I intentionally omitted the parameter M (minimum subset size) from the shares because including it would give an adversary a vital piece of information. Likewise, including any kind of information that would allow a determination of whether the secret has been correctly reconstituted would give an adversary too much information. Failing silently when given incorrect shares or an insufficient number of shares is intentional.
>
> I do not believe this is a good tradeoff. It's basically obfuscation of
> something that is already considered secure at the expense of
> usability. It's much more important to me that the user understands
> what is in their hands (or their family members after they get hit by a
> bus), than to obfuscate the parameters of the secret sharing to provide
> a tiny disadvantage to an adversary who gets ahold of one.
>
> The fact that it fails silently is really all downside, not a benefit.
> If I have enough fragments, I can reconstruct the seed and see that it
> produces addresses with money. If not, I know I need more fragments.
> I'm much more concerned about my family having all the info they need to
> recover the money, than an attacker knowing that he needs two more
> fragments instead of which are well-secured anyway.
For what it's worth, ssss also omits from the shares any information about the threshold. It will happily return a garbage secret if too few shares are combined. (And actually, it will happily return a garbage secret if too *many* shares are combined, too. My implementation does not have that problem.)

2023-06-07 15:16:40 UTC

- reply

📅 Original date posted:2014-03-29
📝 Original message:On Saturday, 29 March 2014, at 12:59 pm, Alan Reiner wrote:
> I won't lie, there's a lot of work that goes into making an interface
> that makes this feature "usable." The user needs clear ways to identify
> which fragments are associated with which wallet, and which fragments
> are compatible with each other.
The same is true of the multiple private keys involved in a multi-signature addresses.
> They need a way to save some fragments
> to file, print them, or simply write them down.
I proposed a share encoding scheme for exactly this purpose.
> They need a way to
> re-enter fragment, reject duplicates, identify errors, etc. Without it,
> the math fails silently, and you end up restoring a different wallet.
I intentionally omitted the parameter M (minimum subset size) from the shares because including it would give an adversary a vital piece of information. Likewise, including any kind of information that would allow a determination of whether the secret has been correctly reconstituted would give an adversary too much information. Failing silently when given incorrect shares or an insufficient number of shares is intentional.
> Also I put the secret in the highest-order coefficient of the
> polynomial,
Does it make any difference which coefficient holds the secret? It's convenient to put it in the lowest-order coefficient to simply the recovery code.
> and made sure that the other coefficients were
> deterministic. This meant that if print out an M-of-N wallet, I can
> later print out an M-of-(N+1) wallet and the first N fragments will be
> the same. I'm not sure how many users would trust this, but we felt it
> was important in case a user needs to export some fragments, even if
> they don't increase N.
My BIP likewise deterministically chooses the coefficients so that the shares of a secret are consistent across all runs of the algorithm having the same M. As I'm sure you're aware, N (the number of shares to output) plays no part in the calculation and merely controls how many times the outermost loop is executed. My BIP doesn't even mention this parameter.

2023-06-07 15:16:39 UTC

- reply

📅 Original date posted:2014-03-29
📝 Original message:On Saturday, 29 March 2014, at 11:08 am, Watson Ladd wrote:
> https://freedom-to-tinker.com/blog/stevenag/new-research-better-wallet-security-for-bitcoin/
Thanks. This is great, although it makes some critical references to an ACM paper for which no URL is provided, and thus I cannot implement it.
A distributed ECDSA notwithstanding, we still need a way to decompose a BIP32 master seed into shares. I am envisioning a scenario in which I might meet my sudden and untimely demise, and I wish to allow my beneficiaries to reconstruct my wallet's master seed after my death. I would like to distribute seed shares to each of my beneficiaries and some close friends, such that some subset of the shares must be joined together to reconstitute my master seed. Shamir's Secret Sharing Scheme is perfect for this use case. I am presently working on extending my draft BIP so that it also applies to BIP32 master seeds of various sizes.

2023-06-07 15:16:39 UTC

- reply

📅 Original date posted:2014-03-29
📝 Original message:On Saturday, 29 March 2014, at 4:51 am, Matt Whitlock wrote:
> On Saturday, 29 March 2014, at 9:44 am, Tamas Blummer wrote:
> > I used Shamir's Secret Sharing to decompose a seed for a BIP32 master key, that is I think more future relevant than a single key.
> > Therefore suggest to adapt the BIP for a length used there typically 16 or 32 bytes and have a magic code to indicate its use as key vs. seed.
>
> Master keys of 32 bytes would work as-is, as ordinary private keys are also 32 bytes. Secrets of other lengths could be supported if the function that generates a[i] from a[i-1] (which is presently SHA-256) were replaced with a function having parameterized output length, such as scrypt.
Actually, secrets with value greater than secp256k1_N cannot be supported because the modular arithmetic would destroy them. But any secret smaller than 256 bits would be fine.

2023-06-07 15:16:39 UTC

- reply

📅 Original date posted:2014-03-29
📝 Original message:On Saturday, 29 March 2014, at 7:36 am, Gregory Maxwell wrote:
> On Sat, Mar 29, 2014 at 7:28 AM, Watson Ladd <wbl at uchicago.edu> wrote:
> > This is not the case: one can use MPC techniques to compute a
> > signature from shares without reconstructing the private key. There is
> > a paper on this for bitcoin, but I don't know where it is.
>
> Practically speaking you cannot unless the technique used is one
> carefully selected to make it possible. This proposal isn't such a
> scheme I beleieve, however, and I think I'd strongly prefer that we
> BIP standardize a formulation which also has this property.
I too would prefer that, but I do not believe there exists a method for computing a traditional signature from decomposed private key shares. Unless I'm mistaken, the composed signature has a different formula and requires a different verification algorithm from the ECDSA signatures we're using today. Thus, such a scheme would require a change to the Bitcoin scripting language. I specifically did not want to address that in my BIP because changes like that take too long. I am aiming to be useful in the present.

2023-06-07 15:16:38 UTC

- reply

📅 Original date posted:2014-03-29
📝 Original message:On Saturday, 29 March 2014, at 10:19 am, Jeff Garzik wrote:
> On Sat, Mar 29, 2014 at 10:10 AM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> > Multisig does not allow for the topology I described. Say the board has seven directors, meaning the majority threshold is four. This means the organization needs the consent of six individuals in order to sign a transaction: the president, the CFO, and any four of the board members. A 6-of-9 multisig would not accomplish the same policy, as then any six board members could successfully sign a transaction without the consent of the president or CFO. Of course the multi-signature scheme could be expanded to allow for hierarchical threshold topologies, or Shamir's Secret Sharing can be used to distribute keys at the second level (and further, if desired).
>
> Disagree with "does not allow" Review bitcoin's script language.
>
> Bitcoin script can handle the use case you describe. Add conditionals
> to the bitcoin script, OP_IF etc. You can do 'multisig AND multisig'
> type boolean logic entirely in script, and be far more flexible than a
> single CHECKMULTISIG affords.
Depends on your definition of "can." Bitcoin's scripting language is awesome, but it's mostly useless due to the requirement that scripts match one of a select few "standard" templates in order to be allowed to propagate across the network and be mined into blocks. I really hate IsStandard and wish it would die.

2023-06-07 15:16:37 UTC

- reply

📅 Original date posted:2014-03-29
📝 Original message:On Saturday, 29 March 2014, at 2:36 pm, Mike Hearn wrote:
> Right - the explanation in the BIP about the board of directors is IMO a
> little misleading. The problem is with splitting a private key is that at
> some point, *someone* has to get the full private key back and they can
> then just remember the private key to undo the system. CHECKMULTISIG avoids
> this.
The implication is that every director would want to retain the board's private key for himself but also would want to prevent every other director from successfully retaining the private key for himself, leading to a perpetual stalemate in which no director ever gets to retain the private key.
> I can imagine that there may be occasional uses for splitting a wallet seed
> like this, like for higher security cold wallets, but I suspect an ongoing
> shared account like a corporate account is still best off using
> CHECKMULTISIG or the n-of-m ECDSA threshold scheme proposed by Ali et al.
Multisig does not allow for the topology I described. Say the board has seven directors, meaning the majority threshold is four. This means the organization needs the consent of six individuals in order to sign a transaction: the president, the CFO, and any four of the board members. A 6-of-9 multisig would not accomplish the same policy, as then any six board members could successfully sign a transaction without the consent of the president or CFO. Of course the multi-signature scheme could be expanded to allow for hierarchical threshold topologies, or Shamir's Secret Sharing can be used to distribute keys at the second level (and further, if desired).

2023-06-07 15:16:36 UTC

- reply

📅 Original date posted:2014-03-29
📝 Original message:On Saturday, 29 March 2014, at 10:08 am, Chris Beams wrote:
> Matt, could you expand on use cases for which you see Shamir's Secret Sharing Scheme as the best tool for the job? In particular, when do you see that it would be superior to simply going with multisig in the first place? Perhaps you see these as complimentary approaches, toward defense-in-depth? In any case, the Motivation and Rationale sections of the BIP in its current form are silent on these questions.
Okay, yes, I will address these questions.

2023-06-07 15:16:36 UTC

- reply

2023-06-07 15:16:35 UTC

- reply

📅 Original date posted:2014-03-29
📝 Original message:On Saturday, 29 March 2014, at 9:44 am, Tamas Blummer wrote:
> I used Shamir's Secret Sharing to decompose a seed for a BIP32 master key, that is I think more future relevant than a single key.
> Therefore suggest to adapt the BIP for a length used there typically 16 or 32 bytes and have a magic code to indicate its use as key vs. seed.
Master keys of 32 bytes would work as-is, as ordinary private keys are also 32 bytes. Secrets of other lengths could be supported if the function that generates a[i] from a[i-1] (which is presently SHA-256) were replaced with a function having parameterized output length, such as scrypt.
Base58Check encodings of shares for secrets of lengths other than 32 bytes would have prefixes other than "SS", but that's not a huge concern. I suspect 32 bytes would be the most common secret length anyway, wouldn't you?

2023-06-07 15:16:35 UTC

- reply

📅 Original date posted:2014-03-29
📝 Original message:On Saturday, 29 March 2014, at 9:44 am, Tamas Blummer wrote:
> I used Shamir's Secret Sharing to decompose a seed for a BIP32 master key, that is I think more future relevant than a single key.
> Therefore suggest to adapt the BIP for a length used there typically 16 or 32 bytes and have a magic code to indicate its use as key vs. seed.
I have expanded the BIP so that it additionally applies to BIP32 master seeds of sizes 128, 256, and 512 bits.
https://github.com/whitslack/btctool/blob/bip/bip-xxxx.mediawiki
The most significant change versus the previous version is how the coefficients of the polynomials are constructed. Previously they were SHA-256 digests. Now they are SHA-512 digests, modulo a prime number that is selected depending on the size of the secret.

2023-06-07 15:16:34 UTC

- reply

📅 Original date posted:2014-03-29
📝 Original message:Abstract: A method is described for dividing a Bitcoin private key into shares in a manner such that the key can be reconstituted from any sufficiently large subset of the shares but such that individually the shares do not reveal any information about the key. This method is commonly known as Shamir's Secret Sharing Scheme. Additionally, an encoding methodology is proposed to standardize transmission and storage of shares.
Complete BIP: https://github.com/whitslack/btctool/blob/bip/bip-xxxx.mediawiki
I am looking to have this BIP assigned a number and added to the bitcoin/bips repository. I invite any comments, questions, or suggestions.