Bitcoin Forum
June 20, 2024, 10:09:04 PM *
News: Voting for pizza day contest
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 »
1  Bitcoin / Development & Technical Discussion / Public Verification of P2WSH Threshold Multi-Signature Addresses on: August 07, 2021, 12:05:41 PM
Hello BitcoinTalk,

I have been asked to help the Grin community verify their Bitcoin P2WSH Threshold Multi-Signuture Address.

They have a 4 out-of 6 address, however need to prove to the community that they have access to all six keys.

https://github.com/grincc/security/issues/1


The proposed solution was to create a transaction that 'oversigns' with 6 keys, included and include that transaction on the blockchain.

They created a test transaction:
https://blockstream.info/tx/cfbc3792e42a6832825f5b4f9dcb264d7a84662f0365661a05c1db591546bac3?expand

In the process they had all six keys sign the transaction.  However when viewed on the blockchain it seems that only four of the six signatures are present.

Maybe this is a bug in electurm? It truncates the unseeded signatures, maybe to save on blockchain space? However this is exacly not what we want in this case.


Overall it would be great to get some feedback on how to properly verify and collate the keys and signatures of multi-signature transactions.  Some sort of nice GUI that displays the information clearly would be of great help.
2  Bitcoin / Development & Technical Discussion / Strong Anti-Replay via Coinbase Transactions (OP_ANTI_REPLAY) on: March 25, 2017, 06:29:38 AM

I have made a BIP Proposal,  To help protect against transaction replay attacks.  Would love to gather some comments.

Code:

<pre>
  BIP: ???
  Layer: Consensus (soft fork)
  Title: Strong Anti-Replay via Coinbase Transactions
  Author: Cameron Garnham <da2ce7 at gmail.com>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-???
  Status: Draft
  Type: Standards Track
  Created: 2017-03-25
  License: BSD-3-Clause
           CC0-1.0
</pre>

==Abstract==

This document specifies a soft fork that enables users to make transactions with a strong expectation that such transactions cannot be replayed on a different chain.

Important Note: In the case that an adversary hard-fork, the strong guarantee of non-replayabilty via this BIP may not be supported.

==Definitions==



==Motivation==

In the case of a chain split, it is important to protect users from, potentially significant, loss of funds from transaction replay attacks.


==Specification==

Upon activation of the soft-fork (activation methodology undefined in this proposal), the following new rules become activated on the Bitcoin Network.

New ‘anti-replay’ OpCode.  Take an unused NoOp and redefine it as ‘OP_ANTI_REPLAY’.

The script must only have the form:

scriptPubKey: (empty)
scriptSig: OP_ANTI_REPLAY

OP_ANTI_REPLAY has the following specification:

• OP_ANTI_REPLAY outputs must only be created in a coinbase transaction.
• OP_ANTI_REPLAY coinbase outputs must only have the value of 1 Satoshi.
• Transaction must not included more than 1 OP_ANTI_REPLAY input.
• If a OP_ANTI_REPLAY input is included in a transaction, the transaction must also be marked as Opt-In-RBF (BIP 125).

The Bitcoin Network should maintain a total of exactly 100 000 OP_ANTI_REPLAY outputs, with the exception of the the first 99 blocks after activation of this soft fork.

Upon activation of this soft fork.  Every blocks coinbase transaction will be required to create exactly 1000 new OP_ANTI_REPLAY outputs, up to the total of 100 000.

If a OP_ANTI_REPLAY is spent in a block, a corresponding new OP_ANTI_REPLAY must be included in the same block.

It is recommend the miners account the size of a OP_ANTI_REPLAY transaction as:  transactions size + size of a OP_ANTI_REPLAY output in coinbase.

In the case of an chain split after this BIP has activated, miners should ‘recycle’ all the OP_ANTI_REPLAY outputs via spending and recreating them in new blocks.  Renewing the protection to the new chain.


=== Reference implementation ===

To-Be-Implemented

==Backwards Compatibility==

This deployment is compatible with all existing bitcoin software.

Upon activation, all deployed Bitcoin Full Nodes will enforce the anti-replay projections for Bitcoin Users. (Only upgraded nodes will enforce the other OP_ANTI_REPLAY requirements).

==Rationale==

The only know way of guaranteeing that a transaction cannot be replayed is to include an input that cannot exist, by-definition, on the alternative chain.  Coinbase transactions are the only transaction type that is know to exhibit this property strongly.

This BIP makes it convenient for wallets to automate the inclusion of new coinbase inputs into transactions that spend potentially repayable transactions.  Everything in this BIP could be done manually by close cooperation between the users and miners, however the author thinks that it is preferable to have it well-defined and enforced.

On Opt-In-RBF enforcement:  In the case of conflicting spends of OP_ANTI_REPLAY outputs, the higher-fee transaction should take priority.  Wallets may select a random OP_ANTI_REPLAY, then check if the competing transaction has a sufficiently low fee to be replaced.

It is expected that every OP_ANTI_REPLAY output will be in the memory pools waiting to be spend; users must compete for this resource.

==Future Questions==

SegWit Compatibility?

==References==

Opt-In-RBF:  https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki

==Copyright==

This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.



Mailing List Post: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013777.html


3  Bitcoin / Bitcoin Discussion / Reponse to Roger Ver's "Time to End the Block-Size Blockade" essay on: July 07, 2016, 01:39:47 AM
Hello, many here know of Roger's essay published on the reputable website of the Foundation for Economic Education:

https://fee.org/articles/time-to-end-the-block-size-blockade/


I wrote a considered response to Roger's essay, however, unfortunately, I have not had any response, either from Roger; or from the community at-large. Hence I'm kindly asking for some commentary / responses from the people here on this forum. In particular, are there any part of my post that are wrong, invalid, or misleading?



Original Reddit Post Here

Quote
There are many issues with this essay; really I was quite disappointed with Roger. The primary one being intellectual dishonesty from the use of a bad analogy. While this in itself doesn’t invalidate Rogers other claims, it doses put the other claims in poor light.

Firstly, to address the fundamental issue with the Starbucks analogy: Bitcoin isn’t like Starbucks Corporation; while there is only one Bitcoin Blockchain, there are tens of thousands of Starbucks stores.

To respond to increases in demand Starbucks can just open more stores (that operate more-or-less independently). However, with Bitcoin, we cannot just ‘add more nodes’ to respond to an increase in demand; as every (full) node must carry the entire burden of the network.

Roger dose correctly state:

Quote
Any time a Bitcoin user is willing to pay a fee that is larger than the marginal cost of including the transaction in a block, it makes economic sense for a miner to include it.

However, his statement is intellectually dishonest as he doesn’t analyze what the marginal cost actually is. Where in reality, the marginal cost of including a transaction in a not-full block is virtually zero. Meaning that it doesn’t matter what size blocks you have, they will constantly be full. (with exception to miners who have differing policies, but the economically rational miner will include transactions that have any fee above zero).

As we continue Roger doesn’t analyse the problems and benefits of blocks being full, instead, based upon his Starbucks fallacy, he just assumes that full blocks are bad. There are two main arguments of why ‘full blocks’ isn’t the evil that Roger plays it to be:

  • It is economically unavoidable. (The marginal cost of creating and including transactions is virtually zero).
  • Without full blocks there isn’t any fee-pressure. Where fees are increasingly important to the long-term health of the network. As the subsidy runs down, this should be compensated by an increase in transaction fees.

Yet neither of these arguments are addressed in Rogers essay.

Thus we come to the core contention of Rogers essay: (I paraphrase) “If we increase the blocksize, blocks will meet capacity again”. This is namely false, as it is completely reasonable to expect that blocks of any size to be full.

Roger dose a good job of arguing how is it is ‘possible’ to increase the blocksize. He completely fails to put it into a well-reasoned context of ‘why’ we need to rise the blocksize limit.

The marginal cost of getting into the ‘full’ blocks that are on the network now (with the 1MB limit), is only 8 cents (US). see: https://bitcoinfees.21.co/

  • Roger dose not address that there is virtually no fee-curve meaning: There are only really two types of transactions on the network: spam and fee paying. (edit: in that to outbid the spam, you only need to increase your fee from 4 cents to 8 cents; suggesting there isn't a strong demand for extra block-space from real fee-paying users.)
  • Roger also doesn’t address the economic implications of these 8 cent fees on the network. He doesn’t address at what point do fees become so large that it does have significant economic implications.
  • Roger doesn’t address any argument of what point we should start considering a fee market important to the future of Bitcoin (with miners being paid by fees).

Overall this essay is an embarrassment, and anti-intellectual. I can only assume that Roger didn’t put this essay out to rigours peer-review before publishing it.
4  Bitcoin / Bitcoin Discussion / Archival of "bitco.in" (including forums) blocked - WTF!? on: May 04, 2016, 07:27:32 PM
I was trying to archive some posts on the other "Bitcoin Forum" and quickly found out that is explicitly an disallowed action.

https://bitco.in/robots.txt

Code:
User-agent: ia_archiver
Disallow: /

User-agent: *
Disallow: /designertest/
Disallow: /forum/attachments/
Disallow: /forum/forums/*/?direction
Disallow: /forum/forums/*/?order
Disallow: /forum/help/
Disallow: /forum/login/
Disallow: /forum/lost-password/
Disallow: /forum/members/
Disallow: /forum/misc/
Disallow: /forum/online/
Disallow: /forum/posts/
Disallow: /forum/register/
Disallow: /forum/search/

What is more interesting is that the owners of the "bitco.in forum" have taken the time to explicitly block the archival site: https://archive.is/

For a site that claims:

Quote
Welcome to Bitcoin Forum.
No censorship. No BS.
5  Bitcoin / Bitcoin Discussion / Lightning is really cool! on: September 16, 2015, 05:28:15 AM
In studying the implications of lighting networks, it quickly becomes apparent that they may be just as revolutionary as basic Bitcoin transactions themselves.

If you view Bitcoin as a censorship resistant global settlement service, then it is logical to build systems that only go to settlement in the case of disagreement.

In the future, I forsee the the Bitcoin network layer 0 will only be used in the cases of fowl play (for adjudication), and public audibility (such as proof of reserves).

The future general case will be where transactions never even touch the Bitcoin network.

Thus it is logical that optimising for scale over security for the layer 0 network is completely foolish.  The later 0 network will gain it's value from being exceptionally secure.

Do you take the fact that the clerk at the the corner store failed to give you the correct change to the highest court in the land?

- Well, no, in general this is not necessary.  However if all other forms of justice fail, there should be an avenue to take the dispute for final adjudication.
6  Economy / Games and rounds / Bitcoin User Not Affected Meme Contest! on: June 29, 2015, 10:58:54 PM
I'm going to give some bits to people who make some great meme images! Smiley

Like mine here: https://twitter.com/da2ce7/status/615654069781200896


I will give the bits out in any way I like.  But have fun!
7  Economy / Speculation / Hope Bitcoin Price continues to stagnate (not up or down) for another 6 mth. on: March 01, 2015, 05:18:14 AM
Quite frankly, the Bitcoin infrastructure isn't ready for another big rally just now.  But I think in 6 months this will be looking much more solid for a hard rally.
8  Economy / Speculation / Trezor and other Secure Wallets will have a large effect on the Bitcoin Price on: February 08, 2015, 04:14:38 AM
I believe one of the main reasons for the slow decline of the bitcoin prices is that people who wish to invest a large amount of money do not feel comfortable about securely storing a large amount of value.

With BIP32 and TREZOR investors are starting to feel more confident that they can indeed manage holding their own Bitcoins.

Once a significant proportion of investors move to such secure Bitcoin storage technologies I believe that the incentive to sell will become much diminished.

I suspect that the in unofficial markets (such as Local Bitcoins and OTC) will be the first places to dry up in excess liquidity. (as in the average price on these markets will be higher than say on Bitstamp).

When this happens, I believe significantly because of secure wallets, we will be officially at the start of the next major bull market. (it is important to remember that the bitcoin prices is dictated by people who do not spend bitcoins rather those who do).

 Wink
9  Economy / Services / [Programing C++] Reimplementation of zlib: ISO C++11! [20 BTC] on: August 12, 2014, 03:12:36 PM
20 BTC project.

For an expert programer who has some spare time:


  • I wish to commission a reimplementation of zlib in C++11.
  • Not focused on performance.   Focus on safe, correct, and easy to ready code.  Should still be fast on a modern compiler.
  • This implementation should take advantage of the new C++11 features.
  • Include a C interface that is compatible with zlib.

MIT style license.


Edit:

We are not looking for a good wrapper, but a ground up reimplementation, using modern code.

This code only needs to compile with:  GCC 4.8, LLVM/clang 3.4, and MS Visual C++ 2013

This code need to be supported: Linux, MacOS X Mavericks, and Windows 7 SP1 (and later).



CMake build system +  Unit and Functional Tests.


We advice to not to start work until we have confirmed a plan with you.


please contact me at:  da2ce7 .. at .. gmail.com

10  Bitcoin / Press / [2014-06-09] Telegraph: The coming digital anarchy on: June 09, 2014, 03:16:23 PM
Quote
Bitcoin is giving banks a run for their money. Now the same technology threatens to eradicate social networks, stock markets, even national governments. Are we heading towards an anarchic future where centralised power of any kind will dissolve?

http://www.telegraph.co.uk/technology/news/10881213/The-coming-digital-anarchy.html


The best article on bitcoin I've read in the Mainstream media... ever.
11  Other / Meta / rename "Alternative clients" to "Clients" and Include Bitcoin-QT on: January 25, 2014, 01:40:02 AM
Let the Development & Technical Discussion root forum be about generic bitcoin technical issues.

 Smiley
12  Bitcoin / Press / 2014-01-21 - DLD14: Satoshi Nakamoto Reveal Himself? (no evidence of-course). on: January 24, 2014, 11:25:52 PM
Satoshi Nakamoto Reveal Himself? (no evidence of-course).



http://www.youtube.com/watch?v=J8JuTMFuXuU

@54min.


Otherwise very good Video.
13  Economy / Services / [Programing C++] Port of zlib to pure ISO C++03! Bounty! 2.2 BTC on: December 13, 2013, 01:57:27 AM
Bounty! (for Open Transaction Project)

Port zlibc to zlibc++ and earn Bitcoin!


Rules.

1. Github project with good documentation.
2. Autotools compile on many platforms.
3. 'make check' with comprehensive unit tests and functional tests.

License:  (same as zlib): http://en.wikipedia.org/wiki/Zlib_License

ISO C++03 strict compliance code, no warnings compile with GCC and clang.

Good luck!


Randy and Fellow Traveler (and of course myself) are going to be on the review board for this project.

Pledges:

da2ce7: 2.0BTC
randy: 0.2BTC

any questions/comments please comment on this thread.

Or on IRC: #opentransactions  on freenode.net
14  Economy / Services / Open Transactions Logo Competition! 2BTC on: June 05, 2013, 03:12:15 AM
Over in Open Transactions land, we are finding ourselves in need of a Logo.

So in true Bitcoin fashion, we are having a competition!

Rules:

Must have two versions: Greyscale and Colour (must look good in both).
Must be in a Vector Graphics format.

(optional) a banner version.


This competition will be open for at-least 2 weeks, or until we have found a great logo.

The prize pool is 2btc atm.  People are welcome to donate more to: 1D9eWaBqawJH4KUb5frWpwZtzkuSZEMnG3

Happy drawing.

Judges: markm, FellowTraveler, da2ce7

Edit: All Submissions must be under a http://creativecommons.org/publicdomain/zero/1.0/ licence.  (of course, we will still try and credit the artist where possible)
15  Bitcoin / Press / 2013-04-30 ABC Behind the News: Bitcoin (Video) on: April 30, 2013, 01:29:39 AM
Best Video on Bitcoin so far. I think!

http://www.abc.net.au/btn/story/s3744569.htm

 Grin Grin Grin
16  Other / Meta / 'Open Transactions' subforum in Project Development on: April 27, 2013, 11:46:58 AM
The Open Transactions related topics in Alternative clients have been moved to the Project Development forum.  This move is reasonable in itself, however the Project Development is much larger, and the OT related topics are getting lost easily.

Can we please have a Open Transactions sub-forum within the Project Development forum.  I am willing to moderate it.

Otherwise, maybe a generic 'Software' sub-forum would work.  Grin
17  Other / MultiBit / Multibit IRC on Freenode on: April 26, 2013, 12:55:21 AM
I've setup the #multibit channel on freenode.net

 Cheesy

If you wish, please join and hang out in this channel to provide support.  Wink
18  Bitcoin / Press / 2013-04-17 - 774 ABC Melbourne - Bitcoins and banking on: April 22, 2013, 04:07:07 AM
Bitcoins and banking: Revolutions with Jon Faine

Quote
The internet has already revolutionised finance through online payment and online banking.
Now an internet currency, the bitcoin, is making waves as it booms, busts and enters trading halts.
Melbourne-based computer programmer and founder of the Australian Bitcoin Facebook group Cameron Garnham explains the new currency to Jon Faine.
Revolutions airs weekly on Wednesdays at 10am on Mornings with Jon Faine

http://www.abc.net.au/local/audio/2013/04/19/3741138.htm


I had a interview with Jon Faine, went very well. Smiley

MP3: http://mpegmedia.abc.net.au/local/melbourne/201304/r1103624_13337350.mp3
19  Bitcoin / Press / 2013-04-12 Australian Financial Review: Hackers blamed for Bitcoin plunge on: April 16, 2013, 02:09:41 AM
http://www.afr.com/p/national/hackers_blamed_for_bitcoin_plunge_xaOWnfSuMJJiCcYrt6adSJ

Quote
Bitcoin, a digital currency, fell from a peak of over $US265 to under $US105, in what some say was an attack by hackers looking to manipulate the currency.

It recovered to $US180 by Thursday afternoon. Confidence in the safety of the fledgling unit had been shaken, but some Australian businesses still accept bitcoin in exchange for their products.

It only has value if people agree it does, said CommSec chief economist Craig James. “In many respects bitcoins have much in common with gold,” he said in a recent note to clients.

A bitcoin valued at $US180 would have seemed extremely high not long ago; on January 1, 2013, it was just $US13.
20  Bitcoin / Press / 2013-04-12 Herald Sun: Hacker currency Bitcoin crashes on: April 16, 2013, 02:06:49 AM
http://www.heraldsun.com.au/money/money-matters/bitcoin-crashes-hacker-currency-gets-wild-ride/story-fn312ws8-1226618761314

Quote
One Bitcoin supporter with a unique perspective on the boom-turned-to-bust might be Mike Caldwell, a 35-year-old software engineer based in suburban Utah. Caldwell mints physical versions of bitcoins at his residence, cranking out thousands of homemade tokens with codes protected by tamper-proof holographic seals - a retro-futuristic kind of prepaid cash.

His coins are stamped with the words "Vires in Numeris" - Latin for "Strength in Numbers."
Pages: [1] 2 3 4 5 6 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!