Dave Scotese [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-07-24 to 2022-07-11
💬 Posted a total of 72 messages
📚 Participated in the following categories: bitcoin-dev, BIP Draft, BIP/Draft, Pre-BIP, bitcoin-discuss
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub15wz8j5cse6sexlw6f5q7arc5efe5hxn6kcxxyy222et8qms4u3lsemaru8

Profile Code

nprofile1qqs28pre2vgvagvn0hdy6q0w3u2v5u6tnfatvrrzz999v4nsdc27glczlhe5h

Author Public Key

npub15wz8j5cse6sexlw6f5q7arc5efe5hxn6kcxxyy222et8qms4u3lsemaru8

Show more details

Last Notes

2023-06-07 18:17:16

- reply

📅 Original date posted:2019-04-01
📝 Original message:I think EXACTLY ONE YEAR is the perfect time. Well, a year and a day for
me because I'm on the wrong side of the date line, apparently.
On Sun, Mar 31, 2019 at 6:04 PM Ricardo Filipe via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> one year seems too long. i think with the BIP-148 experience you have
> we could easily get there in 6 months at most.
>
> Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> escreveu no dia segunda, 1/04/2019 à(s) 01:33:
> >
> > Certain parts of the community have been selling bitcoins for
> unreasonably
> > low prices. This has halted Bitcoin's valuation at $20k and even driven
> the
> > price down below $15k! However, clearly Bitcoin is worth much more than
> > that, and there is widespread support for higher prices.
> >
> > In light of this, I have written and implemented two BIPs: one to add a
> > signed price field to Bitcoin transactions, and the other to softfork a
> > minimum price of $50k USD/BTC a year from today.
> >
> > The BIPs are here, as well as included at the bottom of this email for
> > convenience:
> >
> https://github.com/luke-jr/bips/blob/softfork_50k/bip-usdprice.mediawiki
> >
> https://github.com/luke-jr/bips/blob/softfork_50k/bip-softfork-50k-price.mediawiki
> >
> > A reference implementation is here:
> >
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:softfork_50k
> >
> > Please review ASAP so we can get these deployed in Bitcoin Core v0.18.
> >
> > Luke
> >
> >
> > <pre>
> > BIP: ?
> > Layer: Applications
> > Title: Signed USD Price Indicator
> > Author: Luke Dashjr <luke+bip at dashjr.org>
> > Comments-Summary: No comments yet.
> > Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
> > Status: Draft
> > Type: Standards Track
> > Created: 2019-04-01
> > License: BSD-2-Clause
> > </pre>
> >
> > ==Abstract==
> >
> > This BIP proposes a method to explicitly specify and sign the USD/BTC
> price
> > for transactions.
> >
> > ==Copyright==
> >
> > This BIP is licensed under the BSD 2-clause license.
> >
> > ==Motivation==
> >
> > Certain parts of the community have been selling bitcoins for
> unreasonably low
> > prices. This has halted Bitcoin's valuation at $20k and even driven the
> price
> > down below $15k! However, clearly Bitcoin is worth much more than that,
> and
> > there is widespread support for higher prices.
> >
> > This problem can be fixed by setting a global minimum price for bitcoins.
> > Unfortunately, today, the consensus protocol is completely oblivious to
> the
> > price bitcoins are traded at. Therefore, we must first add a field to
> Bitcoin
> > transactions to indicate their price.
> >
> > ==Specification==
> >
> > ===New field and legal implication===
> >
> > A new field is added to Bitcoin transactions. This field, if present,
> must
> > represent the honest and true USD/BTC rate used for the transaction. By
> > signing the transaction, the sender legally affirms this is the
> valuation of
> > bitcoins used for the transaction.
> >
> > For the avoidance of doubt: when the transaction is valued in a currency
> other
> > than USD, any reasonable exchange rate may be used to come up with the
> USD
> > valuation.
> >
> > ===Serialisation===
> >
> > When serialising the transaction for any purpose, including signing,
> weight
> > calculation, and so on, the output count must be incremented by one.
> Prior to
> > the first real output, the following bytes must be inserted:
> >
> > * Constant: 00 00 00 00 00 00 00 00
> > * A single byte, the size in bytes of the remainder of the inserted data
> > * Constant: 6a 04 55 53 44 24
> > * A single byte, the size in bytes of the remainder of the inserted data
> > * The USD/BTC rate used for the transaction, in standard signed integer
> > serialisation, with all leading zeros removed (except as necessary to
> > preserve the sign bit).
> >
> > ==Backwards compatibility==
> >
> > ===Consensus===
> >
> > The new price field is serialised as a dummy output, with a value of
> zero, and
> > a scriptPubKey that begins with OP_RETURN (6a). Existing nodes will
> ignore
> > this dummy output, and the leading OP_RETURN in the scriptPubKey ensures
> it
> > is never considered spendable.
> >
> > Therefore, current nodes will ignore the new field entirely, and accept
> > transactions using it.
> >
> > ===Wallets===
> >
> > Existing wallets do not typically generate price indicators as specified.
> > Under this BIP, this absence of the field is perfectly acceptable.
> >
> > ==Reference implementation==
> >
> >
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:usd_price_tx_field
> >
> > <pre>
> > BIP: ?
> > Layer: Consensus (soft fork)
> > Title: $50k USD/BTC Minimum Price
> > Author: Luke Dashjr <luke+bip at dashjr.org>
> > Comments-Summary: No comments yet.
> > Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
> > Status: Draft
> > Type: Standards Track
> > Created: 2019-04-01
> > License: BSD-2-Clause
> > Requires: usdprice
> > </pre>
> >
> > ==Abstract==
> >
> > This BIP defines a minimum price of $50k USD/BTC for Bitcoin
> transactions.
> >
> > ==Copyright==
> >
> > This BIP is licensed under the BSD 2-clause license.
> >
> > ==Motivation==
> >
> > Certain parts of the community have been selling bitcoins for
> unreasonably low
> > prices. This has halted Bitcoin's valuation at $20k and even driven the
> price
> > down below $15k! However, clearly Bitcoin is worth much more than that,
> and
> > there is widespread support for higher prices.
> >
> > bip-usdprice defines a new field to indicate the price of transactions.
> Using
> > this, we can softfork to require a minimum transaction price.
> >
> > ==Specification==
> >
> > Beginning with block height 622370 (expected approximately 2020 April
> 1), a
> > block is reject as invalid unless all transactions it contains both
> declare a
> > USD/BTC price (as defined in bip-usdprice) and specify a price that is
> at a
> > minimum $50k USD/BTC.
> >
> > ==Backwards compatibility==
> >
> > As a soft fork, older nodes will continue to accept the blockchain
> without
> > modification. Non-upgraded nodes, however, will not validate the minimum
> > price requirement, and may accept invalid blocks if miners choose to make
> > them. Since transactions not declaring a price are at this time still
> > common-place, the softfork activation has been set a full year into the
> > future to ensure time to upgrade both nodes and wallet software.
> >
> > ==Reference implementation==
> >
> >
> https://github.com/luke-jr/bitcoin/compare/usd_price_tx_field...softfork_50k
> > _______________________________________________
> > 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
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190331/6f6bb0ce/attachment.html>

2023-06-07 18:15:31

- reply

📅 Original date posted:2018-12-03
📝 Original message:The last difficulty change took about 20% longer than expected. How large
does the time between difficulty changes have to get for us to make
changes? In other words, if, at some point, block confirmation times are
averaging, say, hours or days, will we hardfork to speed things up?
One option is NO. When enough economic interests align to amass the
computing power to get important bitcoin transactions into a block, then
they will work out a way to get that block confirmed. This allows other
cryptocurrencies and technologies like LN to fill in.
There may be a group that will fork the code in order to adjust the
difficulty more rapidly, and bitcoin holders will put a value on
bitcoin-FDA ("Faster-Difficuly-Adjustment"), which is fine with me. We can
learn how to fork peacefully from what we learned when BCH was born, and
what we learned when it split.
I think some insight into how core developers will handle increasing
demands to use faster difficulty adjustments (if they respond at all) will
be helpful, and this is why I'm asking.
Dave Scotese
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181203/9ca5ce6b/attachment-0001.html>

2023-06-07 17:53:35

- reply

📅 Original date posted:2016-09-23
📝 Original message:If Alice knows enough to see that she needs CHECKBLOCKATHEIGHT to avoid
paying Bob twice, then she also knows that Fred owes her 4BTC. If Bob
complains about getting paid faster, Alice can let him know that Fred
essentially stole his coins and that when she is certain he (and she) can't
get them back, she will send a different four coins to Bob. If she can
establish trust with Bob (She'd trust Bob to pay her back if he gets back
the coins Fred stole), then she can pay him again. Bob could also make a
transaction to send the first input from Alice back to her (since he
doesn't have those coins anyway), sign it, and send that to her. She can
then keep it instead of having to use the new opcode.
Or she can let her wallet use the new opcode so that the logic is built in,
if we add this opcode. Wallet makers who want to help solve this problem
can either implement the new opcode, or they can offer people like Bob the
ability to refund orphaned transactions so that they can be duplicated in
the valid chain without any risk to the original sender.
With the opcode, Alice can solve the problem by herself. Without it, Bob
can solve it for Alice.
While the opcode adds complexity, it enables victims of double-spends to
pay untrusted creditors (Bob) without the risk that orphaned chains create
of paying them twice. I'm not sure the added complexity is worth the
reward. The reward is to protect Bitcoiners (Alice) from people we'd call
"untrusted creditors" (Bob) and I think that might be a mistake. Getting a
refund transaction signed and sent back to Alice is similar to how the LN
will work (where wallets hold transactions that they don't broadcast).
Am I understanding this correctly?
On Fri, Sep 23, 2016 at 3:34 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Joe sends Alice 5 BTC (UTXO 0).
> Fred sends Alice 4 BTC (UTXO 1).
> Alice sends Bob 4 BTC using UTXO 1 (creating UTXO 2).
> Fred double-spends UTXO 1 with UTXO 1-B. This invalidates Alice's transfer
> to
> Bob.
> Alice has UTXO 0 which she can send to Bob (UTXO 3), but if she does so,
> it is
> possible that UTXO 0 could be mined, and then both UTXO 2 and UTXO 3 which
> would result in her giving Bob a total of 8 BTC rather than merely 4 BTC.
> Even if Alice waits until Fred's UTXO 1-B confirms 10 blocks deep, it is
> not
> impossible for a reorganization to reverse those 10 blocks and confirm
> UTXO 1
> again.
> Using OP_CHECKBLOCKATHEIGHT, however, Alice can create UTXO 3 such that it
> is
> valid only in the blockchain where Fred's UTXO 1-B has confirmed. This
> way, if
> that block is reorganized out, UTXO 3 is invalid, and either Bob receives
> only
> the original UTXO 2, or Alice can create a UTXO 3-B which is valid in the
> reorganized blockchain if it again confirms the UTXO 1-B double-spend.
>
> Luke
>
> On Friday, September 23, 2016 2:37:39 PM Tom via bitcoin-dev wrote:
> > On Friday 23 Sep 2016 09:57:01 Luke Dashjr via bitcoin-dev wrote:
> > > This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the Bitcoin
> > > scripting system to address reissuing bitcoin transactions when the
> coins
> > > they spend have been conflicted/double-spent.
> > >
> > > https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki
> >
> > Can you walk us through a real live usecase which this solves? I read it
> > and I think I understand it, but I can't see the attack every giving the
> > attacker any benefit (or the attacked losing anything).
> > _______________________________________________
> > 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
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160923/a0d9fa2b/attachment-0001.html>

2023-06-07 17:49:40

- reply

📅 Original date posted:2016-03-03
📝 Original message:It would be a shame to prohibit someone from rewarding whoever mines their
transaction. A good example would be a transaction designed to record some
information which is damning to powerful authorities, sort of like the
service cryptograffiti offers. When we try to protect others by
prohibiting behavior we think is foolish, we may save some fools, but at
the same time, we hurt the best of us.
On Thu, Mar 3, 2016 at 7:36 AM, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> There's an absurd fee (non-consensus) check already. Maybe that check can
> be improved, but probably the wallet layer is more appropriate for this.
> On Mar 3, 2016 16:23, "Henning Kopp via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi,
>> I think there is no need to do a hardfork for this. Rather it should
>> be implemented as a safety-mechanism in the client. Perhaps a warning
>> can pop up, if one of your conditions A) or B) is met.
>>
>> All the best
>> Henning Kopp
>>
>>
>> On Thu, Mar 03, 2016 at 05:02:11AM -0800, Alice Wonder via bitcoin-dev
>> wrote:
>> > I think the next hard fork should require a safety rule for TX fees.
>> >
>> >
>> https://blockchain.info/tx/6fe69404e6c12b25b60fcd56cc6dc9fb169b24608943def6dbe1eb0a9388ed08
>> >
>> > 15 BTC TX fee for < 7 BTC of outputs.
>> >
>> > Probably either a typo or client bug.
>> >
>> > My guess is the user was using a client that does not adjust TX fee, and
>> > needed to manually set it in order to get the TX in the block sooner,
>> and
>> > meant 15 mBTC or something.
>> >
>> > I suggest that either :
>> >
>> > A) TX fee may not be larger than sum of outputs
>> > B) TX fee per byte may not be larger than 4X largest fee per byte in
>> > previous block
>> >
>> > Either of those would have prevented this TX from going into a block.
>> >
>> > Many people I know are scared of bitcoin, that they will make a TX and
>> make
>> > a mistake they can't undo.
>> >
>> > Adding protections may help give confidence and there is precedence to
>> doing
>> > things to prevent typo blunders - a public address has a four byte
>> checksum
>> > to reduce the odds of a typo.
>> >
>> > This kind of mistake is rare, so a fix could be included in the coming
>> HF
>> > for the possible July 2017 block increase.
>> >
>> > Thank you for your time.
>> >
>> > Alice Wonder
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>>
>> --
>> Henning Kopp
>> Institute of Distributed Systems
>> Ulm University, Germany
>>
>> Office: O27 - 3402
>> Phone: +49 731 50-24138
>> Web: http://www.uni-ulm.de/in/vs/~kopp
>> _______________________________________________
>> 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
>
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160303/970dc2e2/attachment.html>

2023-06-07 17:48:22

- reply

📅 Original date posted:2016-02-02
📝 Original message:The section that starts "Should two software projects need to release"
addresses issues that are difficult to ascertain from what is written
there. I'll take a stab at what it means:
Would bitcoin be better off if multiple applications provided their own
implementations of API/RPC and corresponding application layer BIPs?
- While there is only one such application, its UI will be the obvious
standard and confusion in usability will be avoided.
- Any more than a single such application will benefit from the
coordination encouraged and aided by this BIP and BIP 123.
"To avoid doubt: comments and status are unrelated metrics to judge a BIP,
and neither should be directly influencing the other." makes more sense to
me as "To avoid doubt: comments and status are intended to be unrelated
metrics. Any influence of one over the other indicates a deviation from
their intended use." This can be expanded with a simple example: "In other
words, a BIP having the status 'Rejected' is no reason not to write
additional comments about it. Likewise, overwhelming support for a BIP in
its comments section doesn't change the requirements for the 'Accepted' or
'Active' status."
Since the Bitcoin Wiki can be updated with comments from other places, I
think the author of a BIP should be allowed to specify other Internet
locations for comments. So "link to a Bitcoin Wiki page" could instead be
"link to a comments page (strongly recommended to be in the Bitcoin
Wiki)". Also, under "Will BIP comments be censored or limited to
particular participants/"experts"?" You could add:
- The author of a BIP may indicate any commenting URL they wish. The
Bitcoin Wiki is merely a recommendation, though a very strong one.
On Mon, Feb 1, 2016 at 2:53 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I've completed an initial draft of a BIP that provides clarifications on
> the
> Status field for BIPs, as well as adding the ability for public comments on
> them, and expanding the list of allowable BIP licenses.
>
>
> https://github.com/luke-jr/bips/blob/bip-biprevised/bip-biprevised.mediawiki
>
> I plan to open discussion of making this BIP an Active status (along with
> BIP
> 123) a month after initial revisions have completed. Please provide any
> objections now, so I can try to address them now and enable consensus to be
> reached.
>
> Thanks,
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160201/b5dacb35/attachment.html>

2023-06-07 17:48:03

- reply

📅 Original date posted:2016-01-21
📝 Original message:I agree with the prohibition of +1s. The core competency of those who
provide this list are moderation and technology, not managing a process
through which "involved people [indicate] whether they're for or against
it."
That is certainly an excellent function, but it can be offered by anyone
who wants to run a system for collecting and displaying those indications.
The email list itself is intended to be information rich, and such
"approval voting" is not information-rich enough in my view.
It is a shame that the moderated messages require so many steps to
retrieve. Is it possible to have the "downloadable version" from
https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/ for each month
contain the text of the moderated emails? They do contain the subjects, so
that helps.
On Wed, Jan 20, 2016 at 6:25 PM, xor--- via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thursday, January 21, 2016 11:20:46 AM Rusty Russell via bitcoin-dev
> wrote:
> > So, what should moderation look like from now on?
>
> The original mail which announced moderation contains this rule:
> > - Generally discouraged: [...], +1s, [...]
>
> I assume "+1s" means statements such as "I agree with doing X".
>
> Any sane procedure of deciding something includes asking the involved
> people
> whether they're for or against it.
> If there are dozens of proposals on how to solve a particular technical
> problem, how else do you want to decide it than having a vote?
> It's very strange that this is not allowed - especially if we consider that
> the Bitcoin community is in a state of constant dissent currently.
> The effect is likely that you push the actual decision-making to IRC, which
> less people have access to (since it's difficult to bear the high traffic),
> and thus form some kind of "inner circle" - which makes decisions seem even
> more as if they're being dictated.
>
> So please consider allowing people to say whether they agree with something
> something or don't.
>
>
> Other than that, thanks for the good latency of moderation, I guess you're
> doing hard work there :)
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160120/89ab35ee/attachment.html>

2023-06-07 17:47:38

- reply

📅 Original date posted:2016-01-07
📝 Original message:Maybe I'm being dense, but I don't see why 2**80 storage is required for
this attack. Also, I don't see why the attacker ever needs to get the
victim to accept "arbitrary_data". Perhaps I'm wrong about how the
collision attack works:
1. Create a script which is perfectly acceptable and would pass the
sniff test Gavin proposed (no arbitrary_data).
2. Set off CPU power to construct a second script that lets attacker
keep his coins and has the same hash. (This is where you get
"arbitrary_data").
3. Send a transaction with the first script to the seller as payment.
4. Wait for the transaction to be included in a block.
5. Redeem the transaction with the second script, thus stealing the
coins back.
So the seller would never see the I'd appreciate any correction to my
understanding here. Where do you need 2**80 storage? And when does the
seller have to accept "arbitrary_data"?
Thanks!
On Thu, Jan 7, 2016 at 11:19 AM, Adam Back via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> You could say 256 bit ECDSA is overkill lets go to 160 equivalently.
> Saves even more bytes.
>
> The problem with arguing down is where to stop.
>
> As Matt said these things dont degrade gracefully so a best practice
> is to aim for a bit of extra margin.
>
> 256-bit is quite common at this point since AES, SHA256 etc even in
> things with much less at stake than Bitcoin.
>
> You could send the compressed (unhashed) pubkey then there's no hash
> (and omit it from the sig). Greg had mentioned that in the past.
>
> I think it might be possible to do both (reclaim the hash bits in the
> serialisation of the pub key).
>
> Adam
>
> On 7 January 2016 at 20:02, Gavin Andresen via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I'm hoisting this from some private feedback I sent on the segregated
> > witness BIP:
> >
> > I said:
> >
> > "I'd also use RIPEMD160(SHA256()) as the hash function and save the 12
> > bytes-- a successful preimage attack against that ain't gonna happen
> before
> > we're all dead. I'm probably being dense, but I just don't see how a
> > collision attack is relevant here."
> >
> > Pieter responded:
> >
> > "The problem case is where someone in a contract setup shows you a
> script,
> > which you accept as being a payment to yourself. An attacker could use a
> > collision attack to construct scripts with identical hashes, only one of
> > which does have the property you want, and steal coins.
> >
> > So you really want collision security, and I don't think 80 bits is
> > something we should encourage for that. Normal pubkey hashes don't have
> that
> > problem, as they can't be constructed to pay to you."
> >
> > ... but I'm unconvinced:
> >
> > "But it is trivial for contract wallets to protect against collision
> > attacks-- if you give me a script that is "gavin_pubkey CHECKSIG
> > arbitrary_data OP_DROP" with "I promise I'm not trying to rip you off,
> just
> > ignore that arbitrary data" a wallet can just refuse. Even more likely, a
> > contract wallet won't even recognize that as a pay-to-gavin transaction.
> >
> > I suppose it could be looking for some form of "gavin_pubkey
> > somebody_else_pubkey CHECKMULTISIG ... with the attacker using
> > somebody_else_pubkey to force the collision, but, again, trivial contract
> > protocol tweaks ("send along a proof you have the private key
> corresponding
> > to the public key" or "everybody pre-commits pubkeys they'll use at
> protocol
> > start") would protect against that.
> >
> > Adding an extra 12 bytes to every segwit to prevent an attack that takes
> > 2^80 computation and 2^80 storage, is unlikely to be a problem in
> practice,
> > and is trivial to protect against is the wrong tradeoff to make."
> >
> > 20 bytes instead of 32 bytes is a savings of almost 40%, which is
> > significant.
> >
> > The general question I'd like to raise on this list is:
> >
> > Should we be worried, today, about collision attacks against RIPEMD160
> (our
> > 160-bit hash)?
> >
> > Mounting a successful brute-force collision attack would require at least
> > O(2^80) CPU, which is kinda-sorta feasible (Pieter pointed out that
> Bitcoin
> > POW has computed more SHA256 hashes than that). But it also requires
> O(2^80)
> > storage, which is utterly infeasible (there is something on the order of
> > 2^35 bytes of storage in the entire world). Even assuming doubling every
> > single year (faster than Moore's Law), we're four decades away from an
> > attacker with THE ENTIRE WORLD's storage capacity being able to mount a
> > collision attack.
> >
> >
> > References:
> >
> > https://en.wikipedia.org/wiki/Collision_attack
> >
> >
> https://vsatglobalseriesblog.wordpress.com/2013/06/21/in-2013-the-amount-of-data-generated-worldwide-will-reach-four-zettabytes/
> >
> >
> > --
> > --
> > Gavin Andresen
> >
> >
> > _______________________________________________
> > 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
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160107/b5c2e636/attachment.html>

2023-06-07 17:46:59

- reply

📅 Original date posted:2015-12-29
📝 Original message:There have been no decent objections to altering the block-selection
mechanism (when two block solutions appear at nearly the same time) as
described at
http://bitcoin.stackexchange.com/questions/39226
Key components are:
- Compute BitcoinDaysDestroyed using only transactions that have been in
your mempool for some time as oBTCDD ("old BTCDD").
- Use "nearly the same time" to mean separated in time by your guess of
the average duration of block propagation times.
- When two block solutions come in at nearly the same time, build on the
one that has the most oBTCDD, rather than the one that came in first.
The goal of this change is to reduce the profitability of withholding block
solutions by severely reducing the chances that a block solved a while ago
can orphan one solved recently. "Came in first" seems more easily gamed
than "most oBTCDD". As I wrote there, "*old coins* is always a dwindling
resource and *global nodes willing to help cheat* is probably a growing
one."
I will write a BIP if anyone agrees it's a good idea.
On Mon, Dec 28, 2015 at 12:26 PM, Ivan Brightly via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Far more concerning is network propagation effects between large and
>> small miners. For that class of issues, if you are in an environemnt
>> where selfish mining is possible - a fairly flat, easily DoS/sybil
>> attacked network topology - the profitability difference between small
>> and large miners even *without* attacks going on is a hugely worrying
>> problem. OTOH, if you're blocksize is small enough that propagation time
>> is negligable to profitability, then selfish mining attacks with <30%
>> hashing power aren't much of a concern - they'll be naturally defeated
>> by anti-DoS/anti-sybil measures.
>>
>
> Let's agree that one factor in mining profitability is bandwidth/network
> reliability/stability. Why focus on that vs electricity contracts or
> vertically integrated chip manufacturers? Surely, sufficient network
> bandwidth is a more broadly available commodity than <$0.02/kwh
> electricity, for example. I'm not sure that your stranded hydroelectric
> miner is any more desirable than thousands of dorm room miners with access
> to 10gbit university connections and free electricity.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151229/654898a2/attachment.html>

2023-06-07 17:44:44

- reply

📅 Original date posted:2015-11-14
📝 Original message:I decided to try to certify Wladimir's PGP keys (the old one (2346C9A6)
first, and then the new one (36C2E964), since it was signed with the old
one).
I visited
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009045.html
to see that the new key was referenced in a message signed by the old one.
I figure it's safe to assume that if the old key actually signed that
message, then the core dev using <laanwj at gmail.com
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>> is an
actual core dev (that's all I'd be worried about). So I copied the text
from ------BEGIN PGP SIGNED MESSAGE----- to -----END PGP SIGNATURE----- to
my clipboard and asked Kleopatra (on Windows) to verify it. It says the
signature is bad. If I alter the text of the email (so the signature would
be have to be different to be valid), it says exactly the same thing. So
maybe something is wrong with Kleopatra on Windows.
However, the SHA256SUMS.asc file I got from the magnet link posted in the
email (below) verifies just fine using the new key (36C2E964). So I
figure Kleopatra is not broken. It recognizes that the old key was used to
create the signature in that old email, but it says it's invalid. Has
Wladimir been secretly replaced by someone who doesn't have access to the
private key for 2346C9A6? Can you make a (bad) signature look like it was
made using a key you don't have? The whole reason for signing is so that we
will know if something like that happened. So did I do something wrong?
(I mean, besides using Windows).
I believe this is the expected result if someone took something Wladimir
signed and ripped off the signature and pasted it below this new message to
make everyone think the new message was genuine. Maybe Wladimir made an
edit after the signature was attached. Or maybe it got changed when it
went through the email system. It would be nice to know. Anyway, I fell
back on Windows security and ran the install because it said it verified
that the publisher was "The Bitcoin Foundation".
On Fri, Nov 13, 2015 at 5:13 AM, Wladimir J. van der Laan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Bitcoin Core version 0.11.2 is now available from:
>
> <https://bitcoin.org/bin/bitcoin-core-0.11.2/>
>
> Alternatively, through bittorrent:
>
>
> magnet:?xt=urn:btih:d6d3387160f7e14f6f27dc40ae84cf566ebf631b&dn=bitcoin-core-0.11.2&tr=udp%3A%2F%
> 2Ftracker.openbittorrent.com%3A80%2Fannounce&tr=udp%3A%2F%
> 2Ftracker.publicbt.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.ccc.de
> %3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk
> %3A6969&tr=udp%3A%2F%2Fopen.demonii.com
> %3A1337&ws=https%3A%2F%2Fbitcoin.org%2Fbin%2F
>
> This is a new minor version release, bringing bug fixes, the BIP65
> (CLTV) consensus change, and relay policy preparation for BIP113. It is
> recommended to upgrade to this version as soon as possible.
>
> Please report bugs using the issue tracker at github:
>
> <https://github.com/bitcoin/bitcoin/issues>
>
> Upgrading and downgrading
> =========================
>
> How to Upgrade
> - --------------
>
> If you are running an older version, shut it down. Wait until it has
> completely
> shut down (which might take a few minutes for older versions), then run the
> installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac)
> or
> bitcoind/bitcoin-qt (on Linux).
>
> Downgrade warning
> - ------------------
>
> Because release 0.10.0 and later makes use of headers-first
> synchronization and
> parallel block download (see further), the block files and databases are
> not
> backwards-compatible with pre-0.10 versions of Bitcoin Core or other
> software:
>
> * Blocks will be stored on disk out of order (in the order they are
> received, really), which makes it incompatible with some tools or
> other programs. Reindexing using earlier versions will also not work
> anymore as a result of this.
>
> * The block index database will now hold headers for which no block is
> stored on disk, which earlier versions won't support.
>
> If you want to be able to downgrade smoothly, make a backup of your entire
> data
> directory. Without this your node will need start syncing (or importing
> from
> bootstrap.dat) anew afterwards. It is possible that the data from a
> completely
> synchronised 0.10 node may be usable in older versions as-is, but this is
> not
> supported and may break as soon as the older version attempts to reindex.
>
> This does not affect wallet forward or backward compatibility. There are no
> known problems when downgrading from 0.11.x to 0.10.x.
>
> Notable changes since 0.11.1
> ============================
>
> BIP65 soft fork to enforce OP_CHECKLOCKTIMEVERIFY opcode
> - --------------------------------------------------------
>
> This release includes several changes related to the [BIP65][] soft fork
> which redefines the existing OP_NOP2 opcode as OP_CHECKLOCKTIMEVERIFY
> (CLTV) so that a transaction output can be made unspendable until a
> specified point in the future.
>
> 1. This release will only relay and mine transactions spending a CLTV
> output if they comply with the BIP65 rules as provided in code.
>
> 2. This release will produce version 4 blocks by default. Please see the
> *notice to miners* below.
>
> 3. Once 951 out of a sequence of 1,001 blocks on the local node's best
> block
> chain contain version 4 (or higher) blocks, this release will no
> longer accept new version 3 blocks and it will only accept version 4
> blocks if they comply with the BIP65 rules for CLTV.
>
> For more information about the soft-forking change, please see
> <https://github.com/bitcoin/bitcoin/pull/6351>
>
> Graphs showing the progress towards block version 4 adoption may be
> found at the URLs below:
>
> - - Block versions over the last 50,000 blocks as progress towards BIP65
> consensus enforcement: <http://bitcoin.sipa.be/ver-50k.png>
>
> - - Block versions over the last 2,000 blocks showing the days to the
> earliest possible BIP65 consensus-enforced block: <
> http://bitcoin.sipa.be/ver-2k.png>
>
> **Notice to miners:** Bitcoin Core’s block templates are now for
> version 4 blocks only, and any mining software relying on its
> getblocktemplate must be updated in parallel to use libblkmaker either
> version 0.4.3 or any version from 0.5.2 onward.
>
> - - If you are solo mining, this will affect you the moment you upgrade
> Bitcoin Core, which must be done prior to BIP65 achieving its 951/1001
> status.
>
> - - If you are mining with the stratum mining protocol: this does not
> affect you.
>
> - - If you are mining with the getblocktemplate protocol to a pool: this
> will affect you at the pool operator’s discretion, which must be no
> later than BIP65 achieving its 951/1001 status.
>
> [BIP65]: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
>
> BIP113 mempool-only locktime enforcement using GetMedianTimePast()
> - ----------------------------------------------------------------
>
> Bitcoin transactions currently may specify a locktime indicating when
> they may be added to a valid block. Current consensus rules require
> that blocks have a block header time greater than the locktime specified
> in any transaction in that block.
>
> Miners get to choose what time they use for their header time, with the
> consensus rule being that no node will accept a block whose time is more
> than two hours in the future. This creates a incentive for miners to
> set their header times to future values in order to include locktimed
> transactions which weren't supposed to be included for up to two more
> hours.
>
> The consensus rules also specify that valid blocks may have a header
> time greater than that of the median of the 11 previous blocks. This
> GetMedianTimePast() time has a key feature we generally associate with
> time: it can't go backwards.
>
> [BIP113][] specifies a soft fork (**not enforced in this release**) that
> weakens this perverse incentive for individual miners to use a future
> time by requiring that valid blocks have a computed GetMedianTimePast()
> greater than the locktime specified in any transaction in that block.
>
> Mempool inclusion rules currently require transactions to be valid for
> immediate inclusion in a block in order to be accepted into the mempool.
> This release begins applying the BIP113 rule to received transactions,
> so transaction whose time is greater than the GetMedianTimePast() will
> no longer be accepted into the mempool.
>
> **Implication for miners:** you will begin rejecting transactions that
> would not be valid under BIP113, which will prevent you from producing
> invalid blocks if/when BIP113 is enforced on the network. Any
> transactions which are valid under the current rules but not yet valid
> under the BIP113 rules will either be mined by other miners or delayed
> until they are valid under BIP113. Note, however, that time-based
> locktime transactions are more or less unseen on the network currently.
>
> **Implication for users:** GetMedianTimePast() always trails behind the
> current time, so a transaction locktime set to the present time will be
> rejected by nodes running this release until the median time moves
> forward. To compensate, subtract one hour (3,600 seconds) from your
> locktimes to allow those transactions to be included in mempools at
> approximately the expected time.
>
> [BIP113]: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki
>
> Windows bug fix for corrupted UTXO database on unclean shutdowns
> - ----------------------------------------------------------------
>
> Several Windows users reported that they often need to reindex the
> entire blockchain after an unclean shutdown of Bitcoin Core on Windows
> (or an unclean shutdown of Windows itself). Although unclean shutdowns
> remain unsafe, this release no longer relies on memory-mapped files for
> the UTXO database, which significantly reduced the frequency of unclean
> shutdowns leading to required reindexes during testing.
>
> For more information, see: <https://github.com/bitcoin/bitcoin/pull/6917>
>
> Other fixes for database corruption on Windows are expected in the
> next major release.
>
> 0.11.2 Change log
> =================
>
> Detailed release notes follow. This overview includes changes that affect
> behavior, not code moves, refactors and string updates. For convenience in
> locating
> the code changes and accompanying discussion, both the pull request and
> git merge commit are mentioned.
>
> - - #6124 `684636b` Make CScriptNum() take nMaxNumSize as an argument
> - - #6124 `4fa7a04` Replace NOP2 with CHECKLOCKTIMEVERIFY (BIP65)
> - - #6124 `6ea5ca4` Enable CHECKLOCKTIMEVERIFY as a standard script verify
> flag
> - - #6351 `5e82e1c` Add CHECKLOCKTIMEVERIFY (BIP65) soft-fork logic
> - - #6353 `ba1da90` Show softfork status in getblockchaininfo
> - - #6351 `6af25b0` Add BIP65 to getblockchaininfo softforks list
> - - #6688 `01878c9` Fix locking in GetTransaction
> - - #6653 `b3eaa30` [Qt] Raise debug window when requested
> - - #6600 `1e672ae` Debian/Ubuntu: Include bitcoin-tx binary
> - - #6600 `2394f4d` Debian/Ubuntu: Split bitcoin-tx into its own package
> - - #5987 `33d6825` Bugfix: Allow mining on top of old tip blocks for
> testnet
> - - #6852 `21e58b8` build: make sure OpenSSL heeds noexecstack
> - - #6846 `af6edac` alias `-h` for `--help`
> - - #6867 `95a5039` Set TCP_NODELAY on P2P sockets.
> - - #6856 `dfe55bd` Do not allow blockfile pruning during reindex.
> - - #6566 `a1d3c6f` Add rules--presently disabled--for using
> GetMedianTimePast as end point for lock-time calculations
> - - #6566 `f720c5f` Enable policy enforcing GetMedianTimePast as the end
> point of lock-time constraints
> - - #6917 `0af5b8e` leveldb: Win32WritableFile without memory mapping
> - - #6948 `4e895b0` Always flush block and undo when switching to new file
>
> Credits
> =======
>
> Thanks to everyone who directly contributed to this release:
>
> - - Alex Morcos
> - - ฿tcDrak
> - - Chris Kleeschulte
> - - Daniel Cousens
> - - Diego Viola
> - - Eric Lombrozo
> - - Esteban Ordano
> - - Gregory Maxwell
> - - Luke Dashjr
> - - Marco Falke
> - - Mark Friedenbach
> - - Matt Corallo
> - - Micha
> - - Mitchell Cash
> - - Peter Todd
> - - Pieter Wuille
> - - Wladimir J. van der Laan
> - - Zak Wilcox
>
> And those who contributed additional code review and/or security research.
>
> As well as everyone that helped translating on [Transifex](
> https://www.transifex.com/projects/p/bitcoin/).
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBCgAGBQJWReHOAAoJEHSBCwEjRsmmTAAH/iZQGklLHLIM6a2tTOj4d/O6
> xHg5bJhXGjtzO284Uy3phTzvk+e4mqBTjI8BrSr4D+Vw7mJrfWihdTLlgZYCwso3
> AyAk8ud1H42QanAfUvciY5uXd7cyzr8tCnCIBkvwJT5O8tI3FFhSMM5Fs86WnsP1
> Y10+93sxaVJUave2xm1bmgiwApFZKQ2MNU1IVgFaW8agB59fuqtPRnBdKiK/j+AO
> Jn1LKsObsINYhjtkAFiC66mUOBZ2N3rdhbN3LFl+u7EriTLoYk1OtZZhlC+rOueo
> nxl1H5SHStjrD27vE9Hv2qD5Ckrwo3zib8hZNIVs6MJjFnWUCwNtNg0nqDEvpn4=
> =xXdY
> -----END PGP SIGNATURE-----
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151113/debf1563/attachment-0001.html>

2023-06-07 17:43:17

- reply

📅 Original date posted:2015-10-13
📝 Original message:It was about 360MB (30 minutes ago?), but is now about 460MB. I'm sure it
won't keep going up that fast.
{
"size" : 3413,
"bytes" : 41892350
}
On Tue, Oct 13, 2015 at 5:08 PM, Jonathan Toomim (Toomim Bros) <j at toom.im>
wrote:
> 16 million divided by 1085 transactions is almost 15Kb per transaction =
> unlikely, right?
>
>
> The recent spam was about 15 kB per transaction, so that part sounds right.
>
> The anomalous thing that I saw was that the total bitcoind process usage
> was about 50-100x higher than I would have expected if the mempool was the
> main determinant of memory usage scaling. Can you tell me how much memory
> Task Manager is reporting your bitcoin process as using both today and
> tomorrow?
>
> On Oct 13, 2015, at 4:52 PM, Dave Scotese via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> {
> "size" : 1085,
> "bytes" : 16151768
> }
> It has been running about a day. I'll report tomorrow too. This is a
> Windows 8.1 box.
> 16 million divided by 1085 transactions is almost 15Kb per transaction =
> unlikely, right?
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "bitcoin-xt" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoin-xt+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151013/65f7f6f1/attachment-0001.html>

2023-06-07 17:42:08

- reply

📅 Original date posted:2015-10-01
📝 Original message:I am waiting for the bitcoin (not bitcoin-dev) mailing list so that anyone
who writes "That's off-topic" can also include a link to it.
Someone else mentioned that they read all these emails in about 15
minutes. I'm a bit slower than that, but I'm reading the vitcoin-xt stuff
too. It isn't too much for me, but it will be nice to have a more open
list, such as is planned. What's the hold up? Don't answer here, at least
not until the list is ready :-)
On Wed, Sep 30, 2015 at 6:38 AM, Benjamin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Richard,
>
> its great that people with a lot of experience in financial markets take
> interest in these topics. I don't think you will receive the best answers
> here. The Bitcointalk Altcoin section is currently the best place for such
> announcements. I believe there is room for a better board/list for new 2.0
> projects. Bitcoin dev is not very welcoming to discussions/debates/projects
> which go beyond digital cash systems (assets, markets, etc.), as it is very
> focused on the core problems which are under-funded.
>
> Anyone who wants to build a better venue for 2.0 projects feel free to
> contact me. This could be a mailing list or an upgraded message board. Most
> such boards are project/currency specific, but there is one missing for
> announcements.
>
> In terms of markets on top of blockchains, I have sent a private email.
>
> Regards,
> Benjamin
>
> On Wed, Sep 30, 2015 at 3:17 PM, Richard Olsen via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Lykke Corp based in Zürich funds the competition.
>>
>> 2 Mio Lykke coins (8'000 USD) is allocated to funding core development in
>> next 3 months,
>>
>> Richard
>>
>> On 30.09.2015, at 14:22, Thomas Kerin <thomas.kerin at gmail.com> wrote:
>>
>> Who is funding this?
>>
>> Why not fund Core development?
>> On 30 Sep 2015 7:37 am, "Richard Olsen via bitcoin-dev" <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> All,
>>>
>>> We are looking for participants in a Bitcoin related competition: the
>>> aim is to build a trading platform (initially for foreign exchange, other
>>> assets will follow) which lets participants settle their trades through the
>>> blockchain via coloured coins. To facilitate a quicker trade
>>> reconciliation, the use of a sidechain is a suggestion but by no means a
>>> requirement. There will be an online briefing event today where we will
>>> outline the requirements in more detail, though much of it we have posted
>>> on our website www.lykkex.com .
>>>
>>> As we want this to be a community driven effort rather than something
>>> turning into a proprietary technology, all contributions will be made
>>> available under a MIT license on Github.
>>>
>>> I look forward to answering your questions at the online briefing event
>>> or over email,
>>>
>>> Thank you and kind regards,
>>> Richard Olsen
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150930/3a3d121a/attachment-0001.html>

2023-06-07 17:41:31

- reply

📅 Original date posted:2015-09-28
📝 Original message:Why are they called soft forks when they are really hidden forks? Isn't
the point of a soft fork to prevent old clients from rejecting what they
don't have the code to validate? That seems dangerous.
notplato
On Mon, Sep 28, 2015 at 2:12 PM, odinn via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> And still no movement on BIP 63...
>
> https://bitcointalk.org/index.php?topic=1083961.20
>
> Apart from that,
>
> All my prior objections to XT still hold as expressed on this list.
> XT is not acceptable.
>
> On the topic of consensus:
>
> Reaching consensus, I hope, is something that developers can
> accomplish by refining and adjusting the BIPS and coming to agreement
> upon them. This should be something that can be done in a few months
> time, before the end of the year.
>
> Cheers,
>
> - - O
>
> Adam Back via bitcoin-dev:
> > I wonder what Gavin's views are, he's usually constructive, and see
> > if he'll include it in XT - I think he may have said he was
> > supportive.
> >
> > The rationale for soft vs hard-forks is well known, so I wont go
> > over them.
> >
> > Adam
> >
> >
> > On 28 September 2015 at 06:48, Mike Hearn via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> There is no consensus on using a soft fork to deploy this
> >> feature. It will result in the same problems as all the other
> >> soft forks - SPV wallets will become less reliable during the
> >> rollout period. I am against that, as it's entirely avoidable.
> >>
> >> Make it a hard fork and my objection will be dropped.
> >>
> >> Until then, as there is no consensus, you need to do one of two
> >> things:
> >>
> >> 1) Drop the "everyone must agree to make changes" idea that
> >> people here like to peddle, and do it loudly, so everyone in the
> >> community is correctly informed
> >>
> >> 2) Do nothing
> >>
> >>
> >>
> >> _______________________________________________ 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
> >
>
> - --
> http://abis.io ~
> "a protocol concept to enable decentralization
> and expansion of a giving economy, and a new social good"
> https://keybase.io/odinn
> -----BEGIN PGP SIGNATURE-----
>
> iQEcBAEBCgAGBQJWCa0jAAoJEGxwq/inSG8CuCUIALiRt6cE3b+9f+l9m6aMTjIR
> vTEIM/7B4dIZW9eatXmkxyd44uz5YoN93SlZtV62c90HCqqpFRBCfyXRyXzQ11E7
> 0i70or5LnWDOqrD1bSsCEdrQxPIpAQnv101UHe3iyn/uHAVBiz/HfqvGMruNt0r1
> 4sMecp+LedWpy6/p9c6iMHV1rhtYRfmRfJHj+9KlSn+in5PQKx2kieWqpfqjmlNs
> J/UNoLvRuF0YxDcqEdp2BAaI0s+NyXBo3YDi4R77U9YPRj/cYuWHh/yPKAvFW+2K
> 0d9NNuKSKEY/m4uW3ghPEJL7OxlGbOoNWFS3kcKYr+BanfsPTov7yHQhBuRBRPw=
> =hd0W
> -----END PGP SIGNATURE-----
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/fd9d5a38/attachment.html>

2023-06-07 17:40:53

- reply

📅 Original date posted:2015-09-18
📝 Original message:I am in a timezone that uses DST (currently PDT), but I would like us to
use a timezone that does NOT use DST. It will be nice to have something
that reflects the seasonal patterns like my own body does. I hate the time
change in both ways.
On Fri, Sep 18, 2015 at 2:50 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Friday, September 18, 2015 8:24:50 PM Btc Drak via bitcoin-dev wrote:
> > Google calendar is localised, so it doesn't matter. The problem with
> > quoting UTC anyway it the meeting times are going to change for those
> that
> > observe DST. It would be much better to quote an actual timezone of an
> > actual area so it will remain constant, like 1700 CEST, or 0900AM PDT for
> > example. Otherwise when the clocks change, what was a convenient meeting
> > time will become inconvenient for some.
>
> Not everyone does crazy clock-changing. Using such a time system for
> scheduling seems to inconvenience the wrong position. (although perhaps
> arguably better since most people probably use DST) :p
>
> (Aside, if Google Calendar can't support standard UTC, that sounds like an
> argument against using Google Calendar...)
>
> > Urgh... Can we hardfork time? It's clearly in need of an upgrade...
>
> Tonal time works nice any consistently. :D
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/3727a8c0/attachment.html>

2023-06-07 17:40:37

- reply

📅 Original date posted:2015-09-20
📝 Original message:Mike wrote:
... Obama would like to restrict guns, but can't, because they are too
popular (in the USA).
... Governments tolerate this sort of abuse [black markets] only because
they believe, I think correctly, that Bitcoin can have great benefits for
their ordinary voters and for now are willing to let the tech industry
experiment.
Those two reasons must be recognized for their differences. What does it
mean that something is "too popular" if the ultimate goal of government is
"great benefits for their ordinary voters"? It means the government
assumes that some things are bad for people even though they are popular.
Crystal meth and heroin come to mind. This is a natural concern of all
decent parents for their children, and the reason that cultures for
millennia have had rites of passage, wherein the child takes on the
responsibility of determining for him or her self whether or not a popular
thing provides great benefits. That responsibility is the birthright of
every human being. Why is there an institution that usurps it? How do the
people within that institution benefit from being part of it?
Some history to study and answer these questions includes:
- The origination of public schooling as motivated by Johann Fichte's
public letters to his king in response to Prussia's loss to Napolean at
Jena.
- Franz Oppenheimer's book, The State, tracing the origination of the
idea of a state, or group of people who make up and enforce laws.
- Carroll Quigley's history book, Tragedy and Hope.
- Larken Rose's book, Kicking the Dragon.
- The Republic, by Plato, but only once you understand those other books.
- If you want a shortcut, John Taylor Gatto did a five-hour interview
which is now titled "The Ultimate History Lesson with John Taylor Gatto."
It is heavily sourced by its producer in case anyone wants to verify the
information he provides.
I'm "notplato" for a reason.
notplato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150920/540fc23e/attachment.html>

2023-06-07 17:40:00

- reply

📅 Original date posted:2015-09-11
📝 Original message:Yes, this proposal is a policy that everyone would be free to ignore. I
should have introduced the situation in which this *unenforceable* policy
makes sense to me. Here it is:
Every miner is listening for valid block solutions but might receive two
valid blocks and then they have to decide which one to use. Choosing the
one you saw first is the default behavior. In that situation, we'd all
like everyone to choose the same block. I propose that a better heuristic
than "first seen" is to compare the BTCDD, *but only of transactions you
already have in your mempool*, and
*weight the BTCDD so that txns you got earlier are more important.*
The heuristic is most useful when the two blocks are received within a
small window of time, opting for the first-seen rule otherwise. I assume
many miners have an idea of how long it takes for anyone's new block to get
across the network, and more specifically, the range of times it takes for
new solutions to get to themselves. During this little time window, the
chances are 50/50 that they'll choose the right block. If the default
behavior were to use BTCDD during that time window (one second? I have no
idea!), then the chances would be significantly better.
I think Jorge is right that it doesn't benefit miners. It doesn't hurt
them either, unless they are trying to do selfish mining. Well, it
benefits them in terms of increased bitcoin stability by A) making it
easier for clients to decide which block is valid when they see two
competing with each other, B) motivating miners to add transactions instead
of mining empty blocks, C) severely decreasing the utility of any global
private network of nodes intended to spread selfishly-mined blocks, and D)
motivating miners to stay well-connected so that they get transactions
quickly.
I sent this to the list because it is only useful if it is set as default
behavior since most miners leave the defaults alone, and the benefits don't
materialize unless a majority follows the policy.
On Fri, Sep 11, 2015 at 11:37 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
>
> On Sep 11, 2015 1:18 PM, "Christophe Biocca" <christophe.biocca at gmail.com>
> wrote:
> >
> > It's pretty obvious that Dave is suggesting an alternate tie-breaker:
>
> I thought he was proposing a new consesnsus rule. I see, this would be
> just a policy validation that everybody would be free to ignore (like the
> "first seen" spend conflict tx replacement policy).
>
> I don't see how miners would benefit from running this policy so I would
> not expect them to run it in the long run (like the "first seen" spend
> conflict tx replacement policy).
> If miners don't use it, I don't see how users can benefit from running
> that policy themselves.
> They will still have to keep waiting some block confirmation to
> exponentially reduce the chances of a successful double-spend attack with
> each new confirmation (as explained in the bitcoin white paper).
>
> > Mind you, that risk doesn't apply if we prefer non-empty blocks to
> > empty blocks and leave it at that, or only switch if the new block
> > doesn't double spend transactions in the old one, so it's a fixable
> > issue.
>
> How do you know which of 2 blocks with the same height is "newer"?
>
> > On 11 September 2015 at 12:32, Jorge Timón
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > >
> > > On Sep 11, 2015 12:27 PM, "Dave Scotese via bitcoin-dev"
> > > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > >>
> > >> Rather than (promising to, and when they don't actually, at least
> > >> pretending to) use the first-seen block, I propose that a more
> sophisticated
> > >> method of choosing which of two block solutions to accept.
> > >
> > > There's already a criterion to chose: the one with more work (in valid
> > > blocks) on top of it.
> > >
> > >
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150911/5d843513/attachment.html>

2023-06-07 17:38:20

- reply

📅 Original date posted:2015-08-27
📝 Original message:Prabhat,
You write about OFAC, KYC, and AML.
The *Office of Foreign Assets Control* (*OFAC*) is a financial intelligence
<https://en.wikipedia.org/wiki/Financial_intelligence> and enforcement
agency of the U.S. government charged with planning and execution of
economic and trade sanctions
<https://en.wikipedia.org/wiki/Economic_sanctions> in support of U.S. national
security
<https://en.wikipedia.org/wiki/National_Security_of_the_United_States>
and foreign
policy <https://en.wikipedia.org/wiki/Foreign_policy_of_the_United_States>
objectives.
KYC means "Know Your Customer" which is something every intelligent
businessman does when his deals are significant. Support for "KYC" is
built into reality and needs no qualification, compliance, or control.
AML means "Anti-Money-Laundering" which smacks of overreach. Laundering
money serves to hide behaviors that authorities dislike, many of which are
actually helping the world. Neomoney says it best
<http://neomoney.net/?p=426>: "Indeed, money laundering describes a wide
range of activities that are undertaken by innocent participants in the
economy. Authorities’ growing expectation of a right to violate our privacy
to enforce their laws, and an expectation that we do nothing to protect
ourselves from that violation of privacy, lie at the heart of money
laundering propaganda."
So your work comes across as that of someone who has been duped into doing
the bidding of the largest and most successful criminal organization on
Earth. I do not accuse you of being deceived because no one can be blamed
for the damage done to them by such a powerful parasite. I wish only to
open your eyes, or, at least what worked for me, your ears
<http://peacerevolution.podomatic.com/>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150827/83887135/attachment.html>

2023-06-07 17:32:12

- reply

📅 Original date posted:2015-08-02
📝 Original message:It will help to assume that there is at least one group of evil people who
are investing in Bitcon's demise. Not because there are, but because there
might be. So let's assume they are making a set of a billion transactions,
or a trillion, and maintaining currently-being-legitimately-used hashing
power. When block size is large enough to frustrate other miners, this
hash power (or some piece of it) will be experimentally shifted to solving
a block containing an internally consistent subset of the prepared
trasnsactions to fill it - experimentally at first, but on the active
Bitcoin network. One seemingly random, bloated, useless (except for the
universal timestamp) block will be created and the evil group will measure
the effect on the mining community - client takedowns, market exits, and
whatever else interests them. Then they lie in wait, perhaps let out one
more to do another experiment, but with the goal of eventually catching us
unawares and doing as much damage to morale as possible.
Good concrete descriptions of the threats against which we want to guard
will be very helpful. Maybe there are already unit tests for such things
or requests for miners' reactions to them (as opposed to just the
software's behavior). My description might be a bit too long and perhaps
not a very good example, but do we have a place where such examples can be
constructed?
While we will do our best to guard against such nightmares, it's also
helpful to imagine what we will do if and when one of them ever actually
occurs. Yes, I'm paranoid; because those who like to control everything
are losing it.
Dave
On Sun, Aug 2, 2015 at 3:38 AM, Venzen Khaosan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> +1 on every point, sipa
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150802/1fb475bb/attachment.html>

2023-06-07 15:48:35

- reply

📅 Original date posted:2015-08-19
📝 Original message:I guess every mailing list should have its own internal SNR discussions.
My answer is to respond when something is off-topic and offer a different
place for the topic. I haven't been doing that, partly because no one else
has, but mostly because I figured I don't have a strong handle on what is
off-topic and what isn't. Let's all start doing that. Of course, someone
can object to the claim, "No, I don't think this is off-topic... blah blah
blah," and people can respond. The norms will develop. It just requires
some relative humility, courage, and honesty.
On Wed, Aug 19, 2015 at 12:28 PM, Warren Togami Jr. via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> FYI, a few developers including Wladimir, Greg, Peter Todd, Pieter, and
> Alex Morcos have been discussing what to do about improving the signal
> noise ratio on bitcoin-dev list. One proposal similar to this discussion
> was to split it into multiple mailing lists. It was pointed out that the
> less technical Bitcoin discussion list already existed in the past and
> nobody used it. Generally the discussion went away from creating yet
> another mailing list and toward instituting an on-topic guidelines for
> bitcoin-dev. Gavin, Wladimir, and a few of the others agreed to a simple
> few paragraphs written by Alex Morcos. IIRC Wladimir agreed to post it.
> Has it been posted yet?
>
> On Wed, Aug 19, 2015 at 11:47 AM, Btc Drak via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Wed, Aug 19, 2015 at 3:20 PM, Jeff Garzik <jgarzik at gmail.com> wrote:
>> > bitcoin-dev for protocol discussion and bitcoin-core for Bitcoin Core
>> > discussion?
>>
>> Well -dev or both, I dont particularly see a difference at the moment,
>> and establishing two lists isnt really going to make a difference so
>> long as Bitcoin Core is the reference client, which it is by defacto.
>> The risk of having too many lists is interested stakeholders will miss
>> a discussions. Normal protocol and core discussions are usually pretty
>> low volume in any case.
>>
>> > As Jorge notes, a general discussion list has existed for a long time
>> with
>> > little use.
>>
>> I would suggest it's only because there havent been any rules for -dev
>> that would force general discussion over to the bitcoin list. On IRC
>> we regularly tell people in #bitcoin-dev they are OT and ask them to
>> move to #bitcoin and as a result, -dev remains quite clear of chit
>> chat, #bitcoin has a steady stream of general chatter.
>>
>> We could reduce the OT/noise of bitcoin-dev list considerably by
>> offloading the non-technical/academic debate to the bitcoin list. It
>> just needs a bit of shepherding. I am more than happy to help out.
>> Especially if the list already exists, we should consider making a
>> decision now.
>>
>> Who are the moderators for that list? Do we really want to use
>> sourceforge or are there alternatives, like another list on
>> linuxfoundation?
>>
>> ping @Warren.
>> _______________________________________________
>> 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
>
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/adb874db/attachment-0001.html>

2023-06-07 15:45:45

- reply

📅 Original date posted:2015-08-08
📝 Original message:I see value in lowering the block size or leaving it where it is. We expect
to run out of space, and I think it's a good idea to prepare for that,
rather than avoid it. When we run out of space and the block size is low,
we will see problems. If we raise the block size, we will NOT see these
problems until bitcoin is bigger and more important and the pressure is
higher.
Someone mentioned that when the backlog grows faster than it shrinks, that
is a real problem. I don't think it is. It is a problem for those who
don't wait for even one confirmation, but backlogs in the past have already
started training users to wait for at least one confirmation, or go
off-chain. I am comfortable leaving those zero-conf people in a little bit
of trouble. Everyone else can double-spend (perhaps that's not as easy as
it should be in bitcoin core) and use a higher fee, thus competing for
block space. Yes, $5 transactions suck, but $0.15 is not so bad and about
twice the average right now.
Meanwhile, the higher fees everyone starts feeling like paying, along with
the visibility of the problems caused by full-blocks, will provide
excellent justification and motivation for increasing the limit. My
favorite thing to do is to have a solution ready for a problem I expect to
see, see the problem (so I can measure things about it) and then implement
the solution.
In my experience, the single biggest reason not to run a full node has to
do with starting from scratch: "I used to run a full node, but last time I
had to download the full blockchain, it took ___ days, so I just use (some
wallet) now." I think that has been improved with headers-first, but many
people don't know it.
I have some ideas how a "full node" could postpone being "full" but still
be nearly completely operational so that the delay between startup and
having a full blockchain is nearly painless. It involves bonded
representation of important not-so-large pieces of data (blocks that have
my transactions, the complete UTXO as of some height, etc.). If I know
that I have some btc, I could offer it (say, 100 or 1000 transaction fees'
worth) to anyone who will guarantee good data to me, and then when I have
the whole blockchain, I will know if they were honest. If done right, the
whole network could know whether or not they were honest and enforce the
bond if they weren't. Credit the Lightening paper for parts of this idea.
Dave
On Fri, Aug 7, 2015 at 4:06 PM, Adam Back via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Please try to focus on constructive technical comments.
>
> On 7 August 2015 at 23:12, Thomas Zander via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > What will the backlash be when people here that are pushing for
> "off-chain-
> > transactions" fail to produce a properly working alternative, which
> > essentially means we have to say NO to more users.
>
> But > 99% of Bitcoin transactions are already off-chain. There are
> multiple competing companies offering consumer & retail service with
> off-chain settlement.
>
> I wasnt clear but it seemed in your previous mail that you seemed to
> say you dont mind trusting other people with your money, and so
> presumably you are OK using these services, and so have no problem?
>
> > At this time and this size of bitcoin community, my personal experience
> (and
> > I've been part of many communities) saying NO to new customers
>
> Who said no to anything? The systems of off-chain transfer already
> exist and are by comparison to Bitcoins protocol simple and rapid to
> adapt and scale.
>
> Indications are that we can even do off-chain at scale with Bitcoin
> similar trust-minimisation with lightning, and duplex payment
> channels; and people are working on that right now.
>
> I think it would be interesting and useful for someone, with an
> interest in low trust, high scale transactions, to work on and propose
> an interoperability standard and API for such off-chain services to be
> accessed by wallets, and perhaps periodic on-chain inter-service
> netting.
>
> Adam
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150808/904426c0/attachment.html>

2023-06-07 15:44:26

- reply

📅 Original date posted:2015-07-31
📝 Original message:Here are some books that will help more people understand why Adam's
concern is important:
Kicking the Dragon (by Larken Rose)
The State (by Franz Oppenheimer)
Like he said, it isn't much about bitcoin. Our crypto is just one of the
defenses we've created, and understanding what it defends will help us
maintain its value.
Dave
On Fri, Jul 31, 2015 at 6:16 AM, Adam Back via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I think trust the data-center logic obviously fails, and I was talking
> about this scenario in the post you are replying to. You are trusting the
> data-center operator period. If one could trust data-centers to run
> verified code, to not get hacked, filter traffic, respond to court orders
> without notifying you etc that would be great but that's unfortunately not
> what happens.
>
> Data-center operators are bound to follow laws, including NSLs and gag
> orders. They also get hacked, employ humans who can be corrupt,
> blackmailed, and themselves centralisation points for policy attack.
> Snowden related disclosures and keeping aware of security show this is very
> real.
>
> This isn't much about bitcoin even, its just security reality for hosting
> anything intended to be secure via decentralisation, or just hosting in
> general while at risk of political or policy attack.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150731/2339c6d8/attachment.html>