Samba

Developing a USB gadget application that runs on Linux?Following a recent Ceph USB gateway project, I was looking at ways to test a Linux USB device without the need to fiddle with cables, or deal with slow embedded board boot times.Ideally USB ... [More] gadget testing could be performed by running the USB device code within a virtual machine, and attaching the VM's virtual USB device port to an emulated USB host controller on the hypervisor system.I was unfortunately unable to find support for virtual USB device ports in QEMU, so I abandoned the above architecture, and discovered dummy_hcd.ko instead.The dummy_hcd Linux kernel module is an excellent utility for USB device testing from within a standalone system or VM.dummy_hcd.ko offers the following features: Re-route USB device traffic back to the local system Effectively providing device loopback functionality USB high-speed and super-speed connection simulation It can be enabled via the USB_DUMMY_HCD kernel config parameter. Once the module is loaded, no further configuration is required. [Less]

I ran some quick numbers on the last retargeting period (blocks 415296 through 416346 inclusive) which is roughly a week’s worth. Blocks were full: median 998k mean 818k (some miners blind mining on top of unknown blocks). Yet of the 1,618,170 ... [More] non-coinbase transactions, 48% were still paying dumb, round fees (like 5000 satoshis). Another 5% were paying dumbround-numbered per-byte fees (like 80 satoshi per byte). The mean fee was 24051 satoshi (~16c), the mean fee rate 60 satoshi per byte. But if we look at the amount you needed to pay to get into a block (using the second cheapest tx which got in), the mean was 16.81 satoshis per byte, or about 5c. tl;dr: It’s like a tollbridge charging vehicles 7c per ton, but half the drivers are just throwing a quarter as they drive past and hoping it’s enough. It really shows fees aren’t high enough to notice, and transactions don’t get stuck often enough to notice. That’s surprising; at what level will they notice? What wallets or services are they using? [Less]

Introduction Ceph's vstart.sh utility is very useful for deploying and testing a mock cluster directly from the Ceph source repository. It can: Generate a cluster configuration file and authentication keys Provision and deploy a number of OSDs Backed ... [More] by local disk, or memory using the --memstore parameter Deploy an arbitrary number of monitor, MDS or rados-gateway nodes All services are deployed as the running user. I.e. root access is not needed.Once deployed, the mock cluster can be used with any of the existing Ceph client utilities, or exercised with the unit tests in the Ceph src/test directory.When developing or testing Linux kernel changes for CephFS or RBD, it's useful to also be able to use these kernel clients against a vstart.sh deployed Ceph cluster. Test Environment Overview - image based on content by Sage Weil The instructions below walk through configuration and deployment of all components needed to test Linux kernel RBD and CephFS modules against a mock Ceph cluster. The procedure was performed on openSUSE Leap 42.1, but should also be applicable for other Linux distributions.Network SetupFirst off, configure a bridge interface to connect the Ceph cluster with a kernel client VM network:> sudo /sbin/brctl addbr br0> sudo ip addr add 192.168.155.1/24 dev br0> sudo ip link set dev br0 upbr0 will not be bridged with any physical adapters, just the kernel VM via a TAP interface which is configured with:> sudo /sbin/tunctl -u $(whoami) -t tap0> sudo /sbin/brctl addif br0 tap0> sudo ip link set tap0 upFor more information on the bridge setup, see:http://blog.elastocloud.org/2015/07/qemukvm-bridged-network-with-tap.htmlCeph Cluster DeploymentThe Ceph cluster can now be deployed, with all nodes accepting traffic on the bridge network:> cd $ceph_source_dir> cd src> OSD=3 MON=1 RGW=0 MDS=1 ./vstart.sh -i 192.168.155.1 -n --memstore$ceph_source_dir should be replaced with the actual path. Be sure to specify the same IP address with -i as was assigned to the br0 interface.More information about vstart.sh usage can be found at: http://docs.ceph.com/docs/hammer/dev/dev_cluster_deployement/Kernel VM DeploymentBuild a kernel:  > cd $kernel_source_dir> make menuconfig $kernel_source_dir should be replaced with the actual path. Ensure CONFIG_BLK_DEV_RBD=m, CONFIG_CEPH_FS=y, CONFIG_CEPH_LIB=y, CONFIG_E1000=y and CONFIG_IP_PNP=y are set in the kernel config. A sample can be found here.  > make> INSTALL_MOD_PATH=./mods make modules_install Create a link to the modules directory ./mods, so that Dracut can find them: > sudo ln -s $PWD/mods/lib/modules/$(make kernelrelease) \ /lib/modules/$(make kernelrelease)Generate an initramfs with Dracut. This image will be used as the test VM. > export CEPH_SRC=$ceph_source_dir/src> dracut --no-compress --kver "$(cat include/config/kernel.release)" \ --install "tail blockdev ps rmdir resize dd vim grep find df sha256sum \ strace mkfs.xfs /lib64/libkeyutils.so.1" \ --include "$CEPH_SRC/mount.ceph" "/sbin/mount.ceph" \ --include "$CEPH_SRC/ceph.conf" "/etc/ceph/ceph.conf" \ --add-drivers "rbd" \ --no-hostonly --no-hostonly-cmdline \ --modules "bash base network ifcfg" \ --force myinitrdBoot the kernel and initramfs directly using QEMU/KVM: > qemu-kvm -smp cpus=2 -m 512 \ -kernel arch/x86/boot/bzImage -initrd myinitrd \ -device e1000,netdev=network1,mac=b8:ac:6f:31:45:70 \ -netdev tap,id=network1,script=no,downscript=no,ifname=tap0 \ -append "ip=192.168.155.2:::255.255.255.0:myhostname \ rd.shell=1 console=ttyS0 rd.lvm=0 rd.luks=0" \ -nographicThis should bring up a Dracut debug shell in the VM, with a network configuration matching the values parsed in via the ip= kernel parameter.dracut:/# ip a...2: eth0: ... mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether b8:ac:6f:31:45:70 brd ff:ff:ff:ff:ff:ff inet 192.168.155.2/24 brd 192.168.155.255 scope global eth0For more information on kernel setup, see:http://blog.elastocloud.org/2015/06/rapid-linux-kernel-devtest-with-qemu.htmlRBD Image ProvisioningAn RBD volume can be provisioned using the regular Ceph utilities in the Ceph source directory:> cd $ceph_source_dir/src> ./rados lspoolsrbd...By default, an rbd pool is created by vstart.sh, which can be used for RBD images: > ./rbd create --image-format 1 --size 1024 1g_vstart_img> ./rbd ls -lNAME SIZE PARENT FMT PROT LOCK1g_vstart_img 1024M 1Note: "--image-format 1" is specified to ensure that the kernel supports all features of the provisioned RBD image.Kernel RBD UsageFrom the Dracut shell, the newly provisioned 1g_vstart_img image can be mapped locally using the sysfs filesystem:dracut:/# modprobe rbd[ 9.031056] rbd: loadeddracut:/# echo -n "192.168.155.1:6789 name=admin,secret=AQBPiuhd9389dh28djASE32Ceiojc234AF345w== rbd 1g_vstart_img -" > /sys/bus/rbd/add[ 347.743272] libceph: mon0 192.168.155.1:6789 session established[ 347.744284] libceph: client4121 fsid 234b432f-a895-43d2-23fd-9127a1837b32[ 347.749516] rbd: rbd0: added with size 0x40000000Note: The monitor address and admin credentials can be retrieved from the ceph.conf and keyring files respectively, located in the Ceph source directory.The /dev/rbd0 mapped image can now be used like any other block device:dracut:/# mkfs.xfs /dev/rbd0 ...dracut:/# mkdir -p /mnt/rbdfsdracut:/# mount /dev/rbd0 /mnt/rbdfs[ 415.841757] XFS (rbd0): Mounting V4 Filesystem[ 415.917595] XFS (rbd0): Ending clean mountdracut:/# df -h /mnt/rbdfsFilesystem Size Used Avail Use% Mounted on/dev/rbd0 1014M 33M 982M 4% /mnt/rbdfsKernel CephFS Usagevstart.sh already goes to the effort of deploying a filesystem:> cd $ceph_source_dir/src> ./ceph fs ls> name: cephfs_a, metadata pool: cephfs_metadata_a, data pools: [cephfs_data_a ]All that's left is to mount it from the kernel VM using the mount.ceph binary that was copied into the initramfs:dracut:/# mkdir -p /mnt/mycephfsdracut:/# mount.ceph 192.168.155.1:6789:/ /mnt/mycephfs \ -o name=admin,secret=AQBPiuhd9389dh28djASE32Ceiojc234AF345w==[ 723.103153] libceph: mon0 192.168.155.1:6789 session established[ 723.184978] libceph: client4122 fsid 234b432f-a895-43d2-23fd-9127a1837b32dracut:/# df -h /mnt/mycephfs/Filesystem Size Used Avail Use% Mounted on192.168.155.1:6789:/ 3.0G 4.0M 3.0G 1% /mnt/mycephfsNote: The monitor address and admin credentials can be retrieved from the ceph.conf and keyring files respectively, located in the Ceph source directory.CleanupUnmount CephFS:dracut:/# umount /mnt/mycephfsUnmount the RBD image:dracut:/# umount /dev/rbd0[ 1592.592510] XFS (rbd0): Unmounting FilesystemUnmap the RBD image (0 is derived from /dev/rbdX):dracut:/# echo -n 0 > /sys/bus/rbd/removePower-off the VM:dracut:/# echo 1 > /proc/sys/kernel/sysrq && echo o > /proc/sysrq-trigger[ 1766.387417] sysrq: SysRq : Power Offdracut:/# [ 1766.811686] ACPI: Preparing to enter system sleep state S5[ 1766.812217] reboot: Power downShutdown the Ceph cluster:> cd $ceph_source_dir/src> ./stop.shConclusionA mock Ceph cluster can be deployed from source in a matter of seconds using the vstart.sh utility.Likewise, a kernel can be booted directly from source alongside a throwaway VM and connected to the mock Ceph cluster in a couple of minutes with Dracut and QEMU/KVM.This environment is ideal for rapid development and integration testing of Ceph user-space and kernel components, including RBD and CephFS. [Less]

Introduction Ceph's vstart.sh utility is very useful for deploying and testing a mock cluster directly from the Ceph source repository. It can: Generate a cluster configuration file and authentication keys Provision and deploy a number of OSDs Backed ... [More] by local disk, or memory using the --memstore parameter Deploy an arbitrary number of monitor, MDS or rados-gateway nodes All services are deployed as the running user. I.e. root access is not needed.Once deployed, the mock cluster can be used with any of the existing Ceph client utilities, or exercised with the unit tests in the Ceph src/test directory.When developing or testing Linux kernel changes for CephFS or RBD, it's useful to also be able to use these kernel clients against a vstart.sh deployed Ceph cluster. Test Environment Overview - image based on content by Sage Weil The instructions below walk through configuration and deployment of all components needed to test Linux kernel RBD and CephFS modules against a mock Ceph cluster. The procedure was performed on openSUSE Leap 42.1, but should also be applicable for other Linux distributions.Network SetupFirst off, configure a bridge interface to connect the Ceph cluster with a kernel client VM network:> sudo /sbin/brctl addbr br0> sudo ip addr add 192.168.155.1/24 dev br0> sudo ip link set dev br0 upbr0 will not be bridged with any physical adapters, just the kernel VM via a TAP interface which is configured with:> sudo /sbin/tunctl -u $(whoami) -t tap0> sudo /sbin/brctl addif br0 tap0> sudo ip link set tap0 upFor more information on the bridge setup, see:http://blog.elastocloud.org/2015/07/qemukvm-bridged-network-with-tap.htmlCeph Cluster DeploymentThe Ceph cluster can now be deployed, with all nodes accepting traffic on the bridge network:> cd $ceph_source_dir> cd src> OSD=3 MON=1 RGW=0 MDS=1 ./vstart.sh -i 192.168.155.1 -n --memstore$ceph_source_dir should be replaced with the actual path. Be sure to specify the same IP address with -i as was assigned to the br0 interface.More information about vstart.sh usage can be found at: http://docs.ceph.com/docs/hammer/dev/dev_cluster_deployement/Kernel VM DeploymentBuild a kernel:  > cd $kernel_source_dir> make menuconfig $kernel_source_dir should be replaced with the actual path. Ensure CONFIG_BLK_DEV_RBD=m, CONFIG_CEPH_FS=y, CONFIG_CEPH_LIB=y, CONFIG_E1000=y and CONFIG_IP_PNP=y are set in the kernel config. A sample can be found here.  > make> INSTALL_MOD_PATH=./mods make modules_install Create a link to the modules directory ./mods, so that Dracut can find them: > sudo ln -s $PWD/mods/lib/modules/$(make kernelrelease) \ /lib/modules/$(make kernelrelease)Generate an initramfs with Dracut. This image will be used as the test VM. > export CEPH_SRC=$ceph_source_dir/src> dracut --no-compress --kver "$(cat include/config/kernel.release)" \ --install "tail blockdev ps rmdir resize dd vim grep find df sha256sum \ strace mkfs.xfs /lib64/libkeyutils.so.1" \ --include "$CEPH_SRC/mount.ceph" "/sbin/mount.ceph" \ --include "$CEPH_SRC/ceph.conf" "/etc/ceph/ceph.conf" \ --add-drivers "rbd" \ --no-hostonly --no-hostonly-cmdline \ --modules "bash base network ifcfg" \ --force myinitrdBoot the kernel and initramfs directly using QEMU/KVM: > qemu-kvm -smp cpus=2 -m 512 \ -kernel arch/x86/boot/bzImage -initrd myinitrd \ -device e1000,netdev=network1,mac=b8:ac:6f:31:45:70 \ -netdev tap,id=network1,script=no,downscript=no,ifname=tap0 \ -append "ip=192.168.155.2:::255.255.255.0:myhostname \ rd.shell=1 console=ttyS0 rd.lvm=0 rd.luks=0" \ -nographicThis should bring up a Dracut debug shell in the VM, with a network configuration matching the values parsed in via the ip= kernel parameter.dracut:/# ip a...2: eth0: ... mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether b8:ac:6f:31:45:70 brd ff:ff:ff:ff:ff:ff inet 192.168.155.2/24 brd 192.168.155.255 scope global eth0For more information on kernel setup, see:http://blog.elastocloud.org/2015/06/rapid-linux-kernel-devtest-with-qemu.htmlRBD Image ProvisioningAn RBD volume can be provisioned using the regular Ceph utilities in the Ceph source directory:> cd $ceph_source_dir/src> ./rados lspoolsrbd...By default, an rbd pool is created by vstart.sh, which can be used for RBD images: > ./rbd create --image-format 1 --size 1024 1g_vstart_img> ./rbd ls -lNAME SIZE PARENT FMT PROT LOCK1g_vstart_img 1024M 1Note: "--image-format 1" is specified to ensure that the kernel supports all features of the provisioned RBD image.Kernel RBD UsageFrom the Dracut shell, the newly provisioned 1g_vstart_img image can be mapped locally using the sysfs filesystem:dracut:/# modprobe rbd[ 9.031056] rbd: loadeddracut:/# echo -n "192.168.155.1:6789 name=admin,secret=AQBPiuhd9389dh28djASE32Ceiojc234AF345w== rbd 1g_vstart_img -" > /sys/bus/rbd/add[ 347.743272] libceph: mon0 192.168.155.1:6789 session established[ 347.744284] libceph: client4121 fsid 234b432f-a895-43d2-23fd-9127a1837b32[ 347.749516] rbd: rbd0: added with size 0x40000000Note: The monitor address and admin credentials can be retrieved from the ceph.conf and keyring files respectively, located in the Ceph source directory.The /dev/rbd0 mapped image can now be used like any other block device:dracut:/# mkfs.xfs /dev/rbd0 ...dracut:/# mkdir -p /mnt/rbdfsdracut:/# mount /dev/rbd0 /mnt/rbdfs[ 415.841757] XFS (rbd0): Mounting V4 Filesystem[ 415.917595] XFS (rbd0): Ending clean mountdracut:/# df -h /mnt/rbdfsFilesystem Size Used Avail Use% Mounted on/dev/rbd0 1014M 33M 982M 4% /mnt/rbdfsKernel CephFS Usagevstart.sh already goes to the effort of deploying a filesystem:> cd $ceph_source_dir/src> ./ceph fs ls> name: cephfs_a, metadata pool: cephfs_metadata_a, data pools: [cephfs_data_a ]All that's left is to mount it from the kernel VM using the mount.ceph binary that was copied into the initramfs:dracut:/# mkdir -p /mnt/mycephfsdracut:/# mount.ceph 192.168.155.1:6789:/ /mnt/mycephfs \ -o name=admin,secret=AQBPiuhd9389dh28djASE32Ceiojc234AF345w==[ 723.103153] libceph: mon0 192.168.155.1:6789 session established[ 723.184978] libceph: client4122 fsid 234b432f-a895-43d2-23fd-9127a1837b32dracut:/# df -h /mnt/mycephfs/Filesystem Size Used Avail Use% Mounted on192.168.155.1:6789:/ 3.0G 4.0M 3.0G 1% /mnt/mycephfsNote: The monitor address and admin credentials can be retrieved from the ceph.conf and keyring files respectively, located in the Ceph source directory.CleanupUnmount CephFS:dracut:/# umount /mnt/mycephfsUnmount the RBD image:dracut:/# umount /dev/rbd0[ 1592.592510] XFS (rbd0): Unmounting FilesystemUnmap the RBD image (0 is derived from /dev/rbdX):dracut:/# echo -n 0 > /sys/bus/rbd/removePower-off the VM:dracut:/# echo 1 > /proc/sys/kernel/sysrq && echo o > /proc/sysrq-trigger[ 1766.387417] sysrq: SysRq : Power Offdracut:/# [ 1766.811686] ACPI: Preparing to enter system sleep state S5[ 1766.812217] reboot: Power downShutdown the Ceph cluster:> cd $ceph_source_dir/src> ./stop.shConclusionA mock Ceph cluster can be deployed from source in a matter of seconds using the vstart.sh utility.Likewise, a kernel can be booted directly from source alongside a throwaway VM and connected to the mock Ceph cluster in a couple of minutes with Dracut and QEMU/KVM.This environment is ideal for rapid development and integration testing of Ceph user-space and kernel components, including RBD and CephFS. [Less]

With the release of version 0.7.1, Elasto is now capable of efficient (sparse aware) uploads and downloads to/from Microsoft Azure, using the Blob and File services.This is done by determining which regions of a Page Blob, File Service file, or ... [More] local file are allocated and only transferring those regions, which improves both network and storage utilisation. For Azure Page Blobs, the Get Page Ranges API request is used to obtain a list of allocated regions. For Azure File Service files, the List Ranges API request is used. For local files, SEEK_DATA and SEEK_HOLE are used to determine which regions of a file are allocated. Amazon S3 Objects and Azure Block Blobs are still downloaded and uploaded in entirety. Sparse regions are unsupported by these services. Elasto is free software, and can be obtained for openSUSE and many other Linux distributions from the openSUSE Build Service. Be safe, take backups before experimenting with this new feature. [Less]

With the release of version 0.7.1, Elasto is now capable of efficient (sparse aware) uploads and downloads to/from Microsoft Azure, using the Blob and File services.This is done by determining which regions of a Page Blob, File Service file, or ... [More] local file are allocated and only transferring those regions, which improves both network and storage utilisation. For Azure Page Blobs, the Get Page Ranges API request is used to obtain a list of allocated regions. For Azure File Service files, the List Ranges API request is used. For local files, SEEK_DATA and SEEK_HOLE are used to determine which regions of a file are allocated. Amazon S3 Objects and Azure Block Blobs are still downloaded and uploaded in entirety. Sparse regions are unsupported by these services. Elasto is free software, and can be obtained for openSUSE and many other Linux distributions from the openSUSE Build Service. Be safe, take backups before experimenting with this new feature. [Less]

I’ve been implementing segregated witness support for c-lightning; it’s interesting that there’s no address format for the new form of addresses.  There’s a segregated-witness-inside-p2sh which uses the existing p2sh format, but if you want raw ... [More] segregated witness (which is simply a “0” followed by a 20-byte or 32-byte hash), the only proposal is BIP142 which has been deferred. If we’re going to have a new address format, I’d like to make the case for shifting away from bitcoin’s base58 (eg. 1At1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2): base58 is not trivial to parse.  I used the bignum library to do it, though you can open-code it as bitcoin-core does. base58 addresses are variable-length.  That makes webforms and software mildly harder, but also eliminates a simple sanity check. base58 addresses are hard to read over the phone.  Greg Maxwell points out that the upper and lower case mix is particularly annoying. The 4-byte SHA check does not guarantee to catch the most common form of errors; transposed or single incorrect letters, though it’s pretty good (1 in 4 billion chance of random errors passing). At around 34 letters, it’s fairly compact (36 for the BIP141 P2WPKH). This is my proposal for a generic replacement (thanks to CodeShark for generalizing my previous proposal) which covers all possible future address types (as well as being usable for current ones): Prefix for type, followed by colon.  Currently “btc:” or “testnet:“. The full scriptPubkey using base 32 encoding as per http://philzimmermann.com/docs/human-oriented-base-32-encoding.txt. At least 30 bits for crc64-ecma, up to a multiple of 5 to reach a letter boundary.  This covers the prefix (as ascii), plus the scriptPubKey. The final letter is the Damm algorithm check digit of the entire previous string, using this 32-way quasigroup. This protects against single-letter errors as well as single transpositions. These addresses look like btc:ybndrfg8ejkmcpqxot1uwisza345h769ybndrrfg (41 digits for a P2WPKH) or btc:yybndrfg8ejkmcpqxot1uwisza345h769ybndrfg8ejkmcpqxot1uwisza34 (60 digits for a P2WSH) (note: neither of these has the correct CRC or check letter, I just made them up).  A classic P2PKH would be 45 digits, like btc:ybndrfg8ejkmcpqxot1uwisza345h769wiszybndrrfg, and a P2SH would be 42 digits. While manually copying addresses is something which should be avoided, it does happen, and the cost of making them robust against common typographic errors is small.  The CRC is a good idea even for machine-based systems: it will let through less than 1 in a billion mistakes.  Distinguishing which blockchain is a nice catchall for mistakes, too. We can, of course, bikeshed this forever, but I wanted to anchor the discussion with something I consider fairly sane. [Less]

Hi, I was one of the authors/bikeshedders of BIP9, which Pieter Wuille recently refined (and implemented) into its final form.  The bitcoin core plan is to use BIP9 for activations from now on, so let’s look at how it works! Some background: Blocks ... [More] have a 32-bit “version” field.  If the top three bits are “001”, the other 29 bits represent possible soft forks. BIP9 uses the same 2016-block periods (roughly 2 weeks) as the difficulty adjustment does. So, let’s look at BIP68 & 112 (Sequence locks and OP_CHECKSEQUENCEVERIFY) which are being activated together: Every soft fork chooses an unused bit: these are using bit 1 (not bit 0), so expect to see blocks with version 536870914. Every soft fork chooses an start date: these use May 1st, 2016, and time out a year later if it fails. Every period, we look back to see if 95% have a bit set (75% for testnet). If so, and that bit is for a known soft fork, and we’re within its start time that soft fork is locked-in: it will activate after another 2016 blocks, giving the stragglers time to upgrade. There are also two alerts in the bitcoin core implementation: If at any stage 50 of the last 100 blocks have unexpected bits set, you get Warning: Unknown block versions being mined! It’s possible unknown rules are in effect. If we see an unknown softfork bit activate: you get Warning: unknown new rules activated (versionbit X). Now, when could the OP_CSV soft forks activate? bitcoin-core will only start setting the bit in the first period after the start date, so somewhere between 1st and 15th of May[1], then will take another period to lock-in (even if 95% of miners are already upgraded), then another period to activate.  So early June would be the earliest possible date, but we’ll get two weeks notice for sure. The Old Algorithm For historical purposes, I’ll describe how the old soft-fork code worked.  It used version as a simple counter, eg. 3 or above meant BIP66, 4 or above meant BIP65 support.  Every block, it examined the last 1000 blocks to see if more than 75% had the new version.  If so, then the new softfork rules were enforced on new version blocks: old version blocks would still be accepted, and use the old rules.  If more than 95% had the new version, old version blocks would be rejected outright. I remember Gregory Maxwell and other core devs stayed up late several nights because BIP66 was almost activated, but not quite.  And as a miner there was no guarantee on how long before you had to upgrade: one smaller miner kept producing invalid blocks for weeks after the BIP66 soft fork.  Now you get two weeks’ notice (probably more if you’re watching the network). Finally, this change allows for miners to reject a particular soft fork without rejecting them all.  If we’re going to see more contentious or competing proposals in the future, this kind of plumbing allows it. Hope that answers all your questions!   [1] It would be legal for an implementation to start setting it on the very first block past the start date, though it’s easier to only think about version bits once every two weeks as bitcoin-core does. [Less]

Jakub Hrozek and I are proud to announce the first release of pam_wrapper. This tool allows you to either simplify testing PAM modules or your application using PAM to authenticate users. PAM (Pluggable Authentication Modules) is a layer of ... [More] abstraction on top of Unix authentication. For testing PAM-aware applications we have written a simple PAM module called pam_matrix. If you plan to test a PAM module you can use the pamtest library we have implemented. It simplifies testing of modules. You can combine it with the cmocka unit testing framework or you can use the provided Python bindings to write tests for your module in Python. Jakub and I have written an article for LWN.net to provide more details how to use it. You can find it here. Now start testing your PAM module or application! [Less]

One problem of filling blocks is that transactions with too-low fees will get “stuck”; I’ve read about such things happening on Reddit.  Then one of my coworkers told me that those he looked at were simply never broadcast properly, and broadcasting ... [More] them manually fixed it.  Which lead both of us to wonder how often it’s really happening… My approach is to look at the last 2 years of block data, and make a simple model: I assume the tx is not a priority tx (some miners reserve space for these; default 50k). I judge the “minimum feerate to get into a block” as the smallest feerate for any transaction after the first 50k beyond the coinbase (this is an artifact of how bitcoin core builds transactions; priority area first). I assume the tx won’t be included in “empty” blocks with only a coinbase or a single non-coinbase tx (SPV mining); their feerate is “infinite”. Now, what feerate do we assume?  The default “dumb wallet” fee is 10000 satoshi per kilobyte: bitcoin-core doesn’t do this pro-rata, so a median 300-byte transaction still pays 10000 satoshi by default (fee-per-byte 33.33).  The worse case is a transaction of exactly 1000 bytes (or, a wallet which does pro-rata fees), which would have a fee-per-byte of 10. So let’s consider the last two years (since block 277918).  How many blocks in a row we see with a fee-per-byte > 33.33, and how many we see with a feerate of > 10: Conclusion In the last two years you would never have experienced a delay of more than 10 blocks for a median-size transaction with a 10,000 satoshi fee. For a 1000-byte transaction paying the same fee, you would have experienced a 10 block delay 0.7% of the time, with a 20+ block delay on eight occasions: the worse being a 26 block delay at block 382918 (just under 5 hours).  But note that this fee is insufficient to be included in 40% of blocks during the last two years, too; if your wallet is generating such things without warning you, it’s time to switch wallets! Stuck low-fee transactions are not a real user problem yet.  It’s good to see adoption of smarter wallets, though, because it’s expected that they will be in the near future… [Less]